Startseite
» Wissen
»
Wie man ein Krypto-Whitepaper liest: Eine praktische 8-Schritte-Anleitung
Wie man ein Krypto-Whitepaper liest: Eine praktische 8-Schritte-Anleitung
Die wichtigste Regel beim Lesen eines Krypto-Whitepapers ist einfach: Betrachten Sie es als eine Sammlung von Behauptungen, die es zu überprüfen gilt, nicht als Beweis für die Funktionsfähigkeit des Projekts . Ein gutes Whitepaper sollte Ihnen erklären, welches Problem das Projekt lösen will, wie das System funktionieren soll, warum ein Token benötigt wird, auf welchen Annahmen das Design basiert und welche Risiken und Kompromisse bestehen. Ihre Aufgabe ist es, diese Aussagen in Fragen umzuformulieren, die Sie anhand der aktuellen Dokumentation, des Quellcodes, der On-Chain-Daten, der Governance-Protokolle und unabhängiger Sicherheitsnachweise überprüfen können.
Dies ist wichtig, da Whitepaper schnell veralten können. Die Ethereum-Website weist ausdrücklich darauf hin, dass das Whitepaper von 2014 nach über einem Jahrzehnt Entwicklung nicht mehr dem aktuellen Stand von Ethereum entspricht, obwohl es weiterhin hilfreich ist, die ursprüngliche Vision zu verstehen. Dies verdeutlicht, dass ein Whitepaper oft ein historisches Designdokument und keine fortlaufend aktualisierte Spezifikation ist. Den entsprechenden Hinweis und den Originaltext finden Sie auf der Ethereum-Whitepaper-Seite .
Was sollten Sie verstanden haben, bevor Sie mit dem Lesen fertig sind?
Am Ende Ihrer Analyse sollten Sie das Projekt in verständlichem Deutsch erklären können, ohne die Marketingsprache zu wiederholen. Sie sollten wissen, wer das System benötigt, welche Änderungen sich durch die Nutzung ergeben, welche Komponente den behaupteten Vorteil erzeugt, welche Fehlerquellen bestehen, wo der Token seinen Platz hat, wer Upgrades oder die Finanzmittel kontrolliert und welche Behauptungen Sie unabhängig überprüft haben.
Wenn Sie diese Fragen nach dem Lesen des Dokuments nicht beantworten können, gehen Sie nicht voreilig davon aus, dass die fehlenden Details für Sie günstig sind. Markieren Sie sie als ungeklärt und suchen Sie nach besseren Belegen.
Schritt 1: Beginnen Sie mit der Zusammenfassung, dem Inhaltsverzeichnis, dem Datum und der Version.
Beginnen Sie nicht damit, jede Seite linear zu lesen. Suchen Sie zunächst nach Titel, Erscheinungsdatum, Versionsnummer, Zusammenfassung, Inhaltsverzeichnis und etwaigen rechtlichen oder technischen Hinweisen. Dies gibt Ihnen einen Überblick über das Dokument und zeigt Ihnen, ob Sie einen ursprünglichen Entwurf, eine spätere Überarbeitung oder eine veraltete Momentaufnahme lesen.
Bevor Sie einzelne Aussagen bewerten, sollten Sie zunächst die Version, das Datum, die Zusammenfassung und die Gliederung des Whitepapers ermitteln.
Ein Datum ist besonders wichtig, wenn ein Projekt bereits gestartet ist. Vergleichen Sie es mit der aktuellen Protokolldokumentation. Das veröffentlichte Whitepaper von Solana ist beispielsweise ein technischer Vorschlag mit einem rechtlichen Haftungsausschluss, der besagt, dass sich Pläne ändern können und zukünftige Ergebnisse nicht garantiert sind. Sie können das Originaldokument als offizielles Whitepaper von Solana (PDF) einsehen .
Kurze Fragen
Wann wurde der Artikel veröffentlicht bzw. zuletzt überarbeitet?
Ist das Projekt bereits live?
Bietet das Projekt eine aktuellere technische Dokumentation?
Sind die Abschnitte zu Token, Governance oder Roadmap noch aktuell?
Schritt 2: Formulieren Sie das Problem und die Lösung in Ihren eigenen Worten um.
Ermitteln Sie die Problemstellung und den Lösungsvorschlag. Formulieren Sie beides anschließend in ein bis zwei Sätzen. Vermeiden Sie dabei die im Projekt häufig verwendeten Adjektive wie „revolutionär“, „reibungslos“, „zukunftsweisend“ oder „unendlich skalierbar“. Ersetzen Sie diese durch konkrete Substantive, Handlungen und messbare Ergebnisse.
Man sollte das behauptete Problem, die vorgeschlagene Lösung, die Annahmen und die Abwägungen trennen, anstatt sie als eine einzige Marketingbotschaft zu lesen.
Beispielsweise besagte das ursprüngliche Bitcoin-Dokument nicht nur, dass digitale Zahlungen dezentralisiert sein sollten. Es schlug ein Peer-to-Peer-System für elektronisches Bargeld vor, das Online-Zahlungen direkt zwischen den Parteien ermöglichen sollte, ohne auf ein Finanzinstitut angewiesen zu sein, und beschrieb anschließend einen Proof-of-Work-basierten Mechanismus zur Transaktionsabwicklung. Das Originaldokument ist auf Bitcoin.org verfügbar .
Nachdem Problem und Lösung zusammengefasst wurden, sollte man sich fragen, ob das Problem überhaupt so relevant ist, dass eine Blockchain oder ein Token erforderlich ist. Ein Projekt, das genauso gut mit einer herkömmlichen Datenbank funktionieren könnte, kann dennoch nützlich sein. Im Whitepaper sollte jedoch erläutert werden, welchen Mehrwert die Dezentralisierung bietet und welche Kosten damit verbunden sind.
Schritt 3: Identifizieren Sie den Mechanismus, der das Projekt von anderen unterscheidet.
Kommen wir nun zum technischen Kern: Konsensfindung, Ausführungsmodell, Datenverfügbarkeit, Datenschutzmechanismus, Oracle-Design, Liquiditätsmodell, Brückenarchitektur, Speichermodell – kurzum, all das, was den behaupteten Vorteil des Projekts tatsächlich ausmacht. Sie müssen nicht jede Gleichung sofort verstehen. Wichtig ist jedoch, dass Sie die Ursache-Wirkungs-Kette verstehen.
Die Abschnitte zu Architektur und Konsens sollten in eine Checkliste der Komponenten, Abhängigkeiten, Sicherheitsannahmen und behaupteten Leistungsvorteile übersetzt werden.
Ein hilfreicher Test besteht darin, diesen Satz zu vervollständigen: „Das Projekt behauptet, X zu erreichen, weil es Y verwendet , was nur funktioniert, wenn Z weiterhin gilt.“ Der Teil „Z“ offenbart oft die wichtigste Annahme.
Prüfen Sie bei Leistungsdaten die Bedingungen. Eine theoretische Durchsatzberechnung unter Berücksichtigung einer bestimmten Netzwerkbandbreite, Hardwarekonfiguration oder idealisierter Arbeitslast entspricht nicht der tatsächlichen Produktionsleistung unter Netzüberlastung. Betrachten Sie alle Angaben zu Geschwindigkeit, Kosten, Finalität und Skalierbarkeit als unvollständig, bis Sie die Messmethode kennen.
Schritt 4: Überprüfen Sie die Tokenomics als Anreizsystem
Ein Abschnitt zur Tokenomics sollte mehr als nur die Frage „Wie hoch ist das maximale Angebot?“ beantworten. Man muss die Zuteilung, Ausgabe, Vesting, Freischaltungen, Gebührenflüsse, Staking- oder Wertpapieranreize, Governance-Rechte, Treasury-Kontrolle und die Quelle jeglicher Rendite verstehen.
Prüfen Sie, ob die Zuteilungsprozentsätze stimmen, wann das Angebot in Umlauf kommt, wer es erhält und welche konkrete Funktion der Token erfüllt.
Analysieren Sie die Zahlen. Wenn Insider, Investoren, Stiftungen oder Ökosystemfonds einen großen Anteil kontrollieren, fragen Sie nach, wann diese Token freigegeben werden und wer sie transferieren kann. Werden Staking-Belohnungen beworben, fragen Sie, ob diese aus Protokolleinnahmen, der Ausgabe neuer Token, Nutzergebühren oder einer anderen Quelle stammen. Eine hohe nominelle Rendite, die hauptsächlich durch Verwässerung finanziert wird, unterscheidet sich wirtschaftlich von einer Rendite, die durch externe Nachfrage gedeckt ist.
Unterscheiden Sie außerdem zwischen Token-Nutzen und Token-Wertschöpfung . Ein Token kann für Gebühren oder Governance-Zwecke benötigt werden, ohne dass sein Wert mit zunehmender Nutzung automatisch steigt. Das Whitepaper sollte nicht von „Das Netzwerk verwendet diesen Token“ auf „Daher sollte der Token an Wert gewinnen“ schlussfolgern.
Schritt 5: Vergleichen Sie das Whitepaper mit dem aktuellen Code und der Dokumentation.
Sobald Sie das Dokument verstanden haben, sollten Sie es nicht mehr als alleinige Informationsquelle betrachten. Vergleichen Sie es mit den aktuellen technischen Dokumenten des Projekts, öffentlichen Repositories, Versionshinweisen, implementierten Verträgen und Protokollspezifikationen. Achten Sie auf Funktionen, die entfernt, umbenannt, verschoben oder grundlegend überarbeitet wurden.
Vergleichen Sie das Dokument mit dem aktuellen Code, den Releases und der Dokumentation, um festzustellen, ob die Implementierung noch dem ursprünglichen Entwurf entspricht.
In diesem Schritt werden veraltete Whitepaper deutlich. Ethereum ist hierfür ein gutes Beispiel: Auf der Whitepaper-Seite des Projekts selbst wird darauf hingewiesen, dass das Originaldokument vor dem Start und den wichtigsten Aktualisierungen erstellt wurde. Die richtige Schlussfolgerung ist nicht, dass das alte Dokument nutzlos ist, sondern dass die ursprüngliche Designabsicht und die aktuelle Implementierung getrennt bewertet werden müssen.
Für die Protokollmechanik sollten Sie primäre technische Quellen bevorzugen. Uniswap veröffentlicht beispielsweise seine technischen Unterlagen in offizieller Dokumentation, darunter das Uniswap v2 Whitepaper , das zentrale Designentscheidungen wie ERC-20-Paare, das Preis-Orakel-Verhalten, Flash-Swaps und die Gebührenmechanik des Protokolls beschreibt.
Schritt 6: Überprüfen Sie Token- und Protokollansprüche nach Möglichkeit in der Blockchain.
Wenn das Projekt live ist, sind viele wichtige Fakten nicht mehr theoretisch. Bestätigen Sie die Adresse des bereitgestellten Vertrags aus einer offiziellen Quelle und prüfen Sie anschließend mithilfe des entsprechenden Blockchain-Explorers den verifizierten Vertragscode, das Angebot, die Inhaber, die Prägeberechtigungen, die Upgradefähigkeit, die Treasury-Wallets und die Transaktionsaktivität.
Verwenden Sie offizielle Vertragsadressen und On-Chain-Aufzeichnungen, um zu überprüfen, ob die Angaben zu Angebot, Token-Standard und Nutzen mit dem Live-System übereinstimmen.
Vertrauen Sie keiner Vertragsadresse, die Sie aus einem beliebigen Social-Media-Beitrag oder einer Suchanfrage kopiert haben. Beginnen Sie mit der offiziellen Projektdokumentation und folgen Sie der Adresse zu einem seriösen Block-Explorer. Wenn im Whitepaper eine Angebotsbegrenzung angegeben ist, suchen Sie nach Funktionen zum Erstellen von Smart Contracts oder privilegierten Rollen, die das Angebot beeinflussen könnten. Wenn die Governance als dezentralisiert beschrieben wird, ermitteln Sie, wer die Smart Contracts aktualisieren oder kritische Parameter ändern kann.
Schritt 7: Governance, Administratorschlüssel und tatsächliche Kontrolle abbilden
„Dezentrale Governance“ kann sehr unterschiedliche Bedeutungen haben. Es gilt festzulegen, wer Änderungen vorschlagen kann, wer abstimmen darf, was die Stimmkraft bestimmt, ob Abstimmungen bindend sind, ob eine Multisignatur die Ergebnisse außer Kraft setzen kann, wie Aktualisierungen erfolgen und wer die Finanzen kontrolliert.
Verfolgen Sie, wie aus Vorschlägen ausführbare Änderungen werden, und identifizieren Sie alle Administratorschlüssel, Upgrade-Berechtigungen, Multisignaturen oder Treasury-Kontrollen.
Besonderes Augenmerk sollte auf Notfallfunktionen gelegt werden. Eine Pausenfunktion oder ein Upgrade-Schlüssel können für ein junges Protokoll sinnvoll sein, verändern aber das Sicherheitsmodell. Entscheidend ist nicht, ob zentrale Kontrollmechanismen existieren, sondern ob diese klar offengelegt, angemessen beschränkt und mit den Projektversprechen vereinbar sind.
Schritt 8: Abschließend eine Überprüfung auf Warnsignale und Beweise durchführen
Bevor Sie entscheiden, dass ein Projekt mehr Zeit verdient, teilen Sie Ihre Notizen in drei Spalten ein: bestätigt , plausibel, aber unbestätigt , und widersprüchlich oder unklar . So verhindern Sie, dass aus sorgfältig formulierten Texten unhinterfragte Tatsachen werden.
Schließen Sie die Überprüfung mit der Prüfung von Sicherheitsnachweisen, Architekturabhängigkeiten, Konzentration, Transparenz der Governance und nicht eingehaltenen Versprechen ab.
Warnsignale, die einer genaueren Prüfung bedürfen
Versprechen von garantierten oder ungewöhnlich hohen Renditen ohne klare wirtschaftliche Grundlage.
Leistungszahlen ohne Testbedingungen, Methodik oder reproduzierbare Nachweise.
Eine Token-Zuteilung, die die Kontrolle konzentriert, ohne transparente Unverfallbarkeits- oder Governance-Sicherheitsvorkehrungen zu treffen.
Anonyme oder nicht überprüfbare Beiträge wurden als Ersatz für technische Beweise vorgelegt.
Ein Fahrplan voller Ergebnisse, aber wenig Erläuterung der Abhängigkeiten oder technischen Meilensteine.
Sicherheitsaussagen, die sich auf das Wort „geprüft“ stützen, ohne auf den tatsächlichen Prüfbericht und dessen Umfang zu verlinken.
Governance-Sprache, die Administratorschlüssel, Multisignaturen, Upgradefähigkeit oder Notfallbefugnisse ignoriert.
Ein Whitepaper, das im Widerspruch zu aktuellem Code, Dokumentationen oder implementierten Verträgen steht.
Aufsichtsbehörden warnen Anleger davor, Kryptowährungen als Ersatz für ein umfassendes Risikoverständnis zu betrachten. Die US-Börsenaufsicht SEC weist auf Investor.gov darauf hin, dass Investitionen in Krypto-Assets hochspekulativ sein und mit Volatilität, Illiquidität, intransparenten Eigentums- und Kontrollverhältnissen, technischen Ausfällen und eingeschränktem Anlegerschutz einhergehen können. Lesen Sie die Warnhinweise der Behörde zu Krypto-Wertpapieren auf Investor.gov, um mehr über die Risiken für Anleger zu erfahren.
„Geprüft“ als Marketing-Siegel ohne zugänglichen Bericht oder ungeklärte Feststellungen
Wie tief sollte man tauchen?
Der Umfang Ihrer Prüfung sollte Ihrem angestrebten Risiko entsprechen. Wenn Sie lediglich ein Protokollkonzept verstehen möchten, reichen möglicherweise das Whitepaper und die bestehende Dokumentation aus. Planen Sie die Nutzung eines Protokolls mit nennenswerten Geldern, ergänzen Sie Ihre Prüfung um Vertragsprüfung, Sicherheitsaudits, Governance-Analyse und eine Bewertung der operationellen Risiken. Bewerten Sie einen Token als Investition, berücksichtigen Sie zusätzlich die Angebotsdynamik, Freigabepläne, das Treasury-Verhalten, rechtliche Offenlegungen, die Marktstruktur, das Verwahrungsrisiko und das Risiko eines Totalverlusts.
Man muss kein Kryptograf sein, um ein Whitepaper gut zu lesen. Wichtig ist jedoch, die Stellen zu erkennen, an denen von Beweisen zu Annahmen übergegangen wird. Das beste Ergebnis ist nicht: „Ich habe jede Formel verstanden.“ Sondern: „Ich weiß, was das Projekt behauptet, was diese Behauptungen ermöglicht, welche Teile bereits implementiert sind, welche ich überprüft habe und welche Risiken noch bestehen.“
Fazit
Lesen Sie ein Krypto-Whitepaper als Beginn Ihrer Due-Diligence-Prüfung, nicht als deren Abschluss. Verstehen Sie zunächst das Problem und den Mechanismus. Testen Sie dann die Token-Anreize, vergleichen Sie das Whitepaper mit der aktuellen Implementierung, verifizieren Sie die Aussagen in der Blockchain, identifizieren Sie die tatsächlichen Verantwortlichen für Upgrades und Gelder und schließen Sie mit einer expliziten Checkliste für Beweise und Risiken ab. Ein technisch beeindruckendes Dokument kann dennoch eine schlechte Investition beschreiben, und eine vielversprechende Idee kann in der Umsetzung scheitern. Das Whitepaper ist gerade deshalb nützlich, weil es Ihnen Aussagen liefert, die Sie hinterfragen können.