Wie liest man das Whitepaper eines Krypto-Projekts?

Die Kernproblemstellung verstehen

1. Identifizieren Sie den spezifischen Problempunkt, den das Projekt innerhalb der bestehenden Blockchain-Infrastruktur oder traditioneller Finanzsysteme lösen soll.

2. Überprüfen Sie, ob das Problem durch reale Daten, Fallstudien oder Hinweise auf dokumentierte Ineffizienzen untermauert wird.

3. Bewerten Sie, ob das Problem einzigartig ist oder lediglich eine umbenannte Version von Herausforderungen ist, die von früheren Protokollen wie Ethereum, Solana oder Cosmos angegangen wurden.

4. Beachten Sie, ob das Whitepaper explizit seine Zielgruppe angibt – Entwickler, Institutionen, Einzelhändler oder DeFi-Protokolle.

5. Untersuchen Sie Formulierungen, die Dringlichkeit oder Knappheit überbewerten, wie z. B. „einzige Lösung“, „beispiellose Krise“ oder „unumkehrbarer Wandel“, die eher auf Marketingvoreingenommenheit als auf technische Strenge hinweisen könnten.

Analyse der technischen Architektur

1. Suchen Sie das Systemdiagramm und verfolgen Sie, wie Komponenten wie Konsensschicht, Ausführungsumgebung, Speichermodell und Interoperabilitätsmodul interagieren.

2. Überprüfen Sie, ob kryptografische Grundelemente – wie Zero-Knowledge-Beweise, Schwellenwertsignaturen oder überprüfbare Zufallsfunktionen – mit präzisen algorithmischen Referenzen benannt sind (z. B. Groth16, BLS12-381).

3. Prüfen Sie, ob Skalierbarkeitsansprüche konkrete Durchsatzmetriken (TPS), Endgültigkeitszeit in Sekunden und Latenz unter definierten Netzwerkbedingungen angeben – und nicht nur theoretische Maxima.

4. Bewerten Sie die Dokumentationstiefe zu Zustandsübergangsregeln, Fork-Auflösungslogik und Validator-Slashing-Bedingungen.

5. Überprüfen Sie, ob Quellcode-Repositorys verknüpft sind, der Commit-Verlauf öffentlich ist und Prüfberichte von Firmen wie CertiK oder OpenZeppelin eingebettet oder mit Versionsnummern zitiert sind.

Bewertung des Tokenomics-Designs

1. Extrahieren Sie den gesamten Token-Vorrat, den zirkulierenden Vorrat beim Start und den Vesting-Zeitplan für Team, Investoren und Ökosystemfonds.

2. Funktionen des Kartendienstprogramms: Ist der Token für das Abstecken, die Gaszahlung, das Governance-Abstimmungsgewicht, die Gebührenumverteilung oder die Oracle-Berichterstattung erforderlich?

3. Identifizieren Sie Inflationsmechanismen – Blockprämien, Treasury-Minting oder protokollgesteuerte Wertsteigerung – und quantifizieren Sie die jährlichen Emissionsraten.

4. Überprüfen Sie die Sperrdauer für frühe Mitwirkende und ob Multi-Sig-Wallet-Adressen mit On-Chain-Verifizierungslinks offengelegt werden.

5. Erkennen Sie Warnsignale wie unbegrenzte Prägebefugnisse, undurchsichtige Reservezuteilungen oder eine um mehr als 35 % verzerrte Token-Verteilung an private Verkaufsteilnehmer.

Überprüfung von Governance- und Upgrade-Mechanismen

1. Bestimmen Sie, ob Governance-Vorschläge Mindestquorumsschwellen, eine zeitlich begrenzte Ausführung oder mehrstufige Abstimmungszyklen erfordern.

2. Prüfen Sie, ob Upgrade-Pfade fest im Protokoll verankert sind (z. B. über Proxy-Verträge) oder von zentralisierten Administratorschlüsseln abhängen.

3. Suchen Sie nach Definitionen der Angebotsberechtigung: Steht es allen Token-Inhabern offen oder ist es durch Mindestguthaben, Einsatzdauer oder Reputationswerte eingeschränkt?

4. Überprüfen Sie historische Beweise – wie vergangene Governance-Foren, Snapshot-Abstimmungen oder Abstimmungsaufzeichnungen in der Kette –, um die tatsächliche Dezentralisierung bei der Entscheidungsfindung zu beurteilen.

5. Bestätigen Sie, ob Notstoppfunktionen vorhanden sind und wer die Macht hat, sie aufzurufen – Multisig-Unterzeichner, DAO-Räte oder unveränderliche Logik.

Bewertung von Sicherheits- und Risikooffenlegungen

1. Suchen Sie den entsprechenden Risikoabschnitt und zählen Sie, wie viele verschiedene Bedrohungsvektoren erkannt wurden – intelligente Vertragsfehler, Oracle-Manipulation, MEV-Extraktion, Cross-Chain-Bridge-Exploits.

2. Vergleichen Sie den Prüfungsumfang mit der Implementierung: Haben die Prüfer nur den Token-Vertrag oder auch das Absteckmodul, die AMM-Logik und den Governance-Adapter überprüft?

3. Beachten Sie, ob bekannte Einschränkungen dokumentiert sind – z. B. „verhindert nicht das Front-Running im aktuellen DEX-Design“ oder „basiert auf einer externen Entropiequelle ohne Fallback“.

4. Überprüfen Sie, ob Details zum Bug-Bounty-Programm enthalten sind: Belohnungsstufen, Einreichungskanäle, Zeitpläne für die verantwortungsvolle Offenlegung.

5. Markieren Sie das Fehlen von Sicherheitsbescheinigungen Dritter, das Fehlen formeller Verifizierungsberichte oder das Auslassen bekannter Schwachstellen aus früheren Testnet-Verstößen.

Häufig gestellte Fragen

F1: Garantiert ein gut geschriebenes Whitepaper die Codequalität? Nein. Ein ausgefeiltes Whitepaper kann unvollständige Implementierungen, ungetestete Randfälle oder undokumentierte Abhängigkeiten verbergen. Code-Audits und Mainnet-Verhalten bleiben maßgebliche Validierungsquellen.

F2: Sollte ich Token-Zuteilungsdiagrammen ohne On-Chain-Verifizierung vertrauen? Nicht ohne Nachweis. Zuteilungsvisualisierungen können den Zeitpunkt, die Entsperrbedingungen oder die Verwahrungskontrolle falsch darstellen. Verfolgen Sie Wallet-Adressen immer mit Etherscan oder Solscan, um den Kontostand und den Transaktionsverlauf zu bestätigen.

F3: Was bedeutet es, wenn in einem Whitepaper die Erwähnung von Wettbewerbern vermieden wird? Dies signalisiert die mögliche Vermeidung einer vergleichenden Analyse. Bei Projekten, in denen Verweise auf ähnliche Protokolle weggelassen werden – wie Arbitrum vs. Optimism oder Chainlink vs. API3 – fehlt es oft an technischem Selbstbewusstsein oder klarer Wettbewerbspositionierung.

F4: Ist die Grammatikqualität ein verlässlicher Indikator für die Glaubwürdigkeit eines Projekts? Nicht von Natur aus. Teams, deren Muttersprache nicht Englisch ist, erstellen unter Umständen grammatikalisch unvollständige Dokumente und liefern gleichzeitig robuste Technik. Allerdings erfordern wiederholte sachliche Ungenauigkeiten – wie etwa die falsche Angabe der Bitcoin-Blockzeit oder der Ethereum-Konsensregeln – eine eingehendere Prüfung.