Krypto Whitepaper schreiben: Struktur, Inhalt und Fehler

Wozu dient ein Whitepaper und wer wird es lesen?

Ein Whitepaper dient dazu, dem Leser eine überprüfbare Erklärung des Projekts zu geben: welches Problem es löst, auf welche Weise und was über die Umsetzung bereits bekannt ist. Es ist kein Werbeprospekt und kein Ersatz für Dokumentation, Präsentation oder rechtliche Materialien. Legen Sie vor dem Schreiben fest, welche Entscheidung der Leser nach der Lektüre treffen soll: das Produkt verstehen, das technische Modell bewerten oder die Funktionsweise des Tokens untersuchen.

Bestimmen Sie die Hauptzielgruppen separat. Für den Nutzer ist es wichtig, das Anwendungsszenario zu verstehen; für den Entwickler die Architektur und Einschränkungen; für den Partner Abhängigkeiten und Integrationsschritte. Ein Dokument kann sich an mehrere Gruppen richten, sollte aber nicht alle durch das gleiche Detailniveau zwingen. Eine kurze Zusammenfassung hilft, das Wesentliche schnell zu erfassen, und spezielle Abschnitte bieten die Tiefe für diejenigen, die sie benötigen.

Beantworten Sie vor der Planung die folgenden Fragen:

• Was weiß der Leser bereits über das Produkt und die Blockchain?
• Welche Aussagen können durch das aktuelle Produkt, den Code oder Berechnungen bestätigt werden?
• Welche Begriffe müssen bei der ersten Verwendung definiert werden?
• Wie wird das Dokument mit der Website, der Dokumentation und den Launch-Materialien verknüpft?

Wenn ein kurzer Überblick für die erste Begegnung benötigt wird, kann er als Ergänzung dienen, sollte aber keine wesentlichen Bedingungen verbergen. Für einen umfassenderen Vorbereitungsplan verwenden Sie die Checkliste für den Token-Launch.

Welche Struktur eines Whitepapers hilft, das Projekt zu verstehen?

Eine praktische Struktur führt den Leser von der Aufgabe zur Lösung und zeigt dann die Mechanik und Einschränkungen. Die Reihenfolge kann je nach Produkt variieren, aber jeder Abschnitt sollte eine konkrete Frage beantworten und nicht eine allgemeine These mit anderen Worten wiederholen.

Ein nützliches Gerüst für das Dokument:

• Kurzzusammenfassung: Produkt, Zielgruppe, Problem und vorgeschlagene Lösung.
• Kontext und Problem: Wo aktuelle Ansätze versagen und für wen das wichtig ist.
• Produktbeschreibung: Nutzerszenarien, Kernfunktionen und Entwicklungsstand.
• Architektur: Komponenten, Datenflüsse, verwendete Netzwerke und externe Abhängigkeiten.
• Token und Wirtschaft: Zweck, Verteilung, verfügbare Mechanismen und Bedingungen, falls ein Token vorgesehen ist.
• Sicherheit und Einschränkungen: Bedrohungsmodell, ergriffene Maßnahmen, bekannte Kompromisse und offene Fragen.
• Entwicklungsplan und Governance: Meilensteine, Abhängigkeiten, verantwortliche Entscheidungen und Aktualisierungsmöglichkeiten des Dokuments.

Erstellen Sie für jeden Abschnitt eine These und eine Liste von Belegen: Spezifikation, Berechnung, Diagramm oder Kommentar des Verantwortlichen. Wenn Fakten noch fehlen, kennzeichnen Sie dies als offene Frage oder Plan, anstatt die Lücke mit einer selbstbewussten Formulierung zu füllen. Der Inhalt sollte die tatsächliche Struktur des Produkts widerspiegeln und nicht als universelle Vorlage dienen. Wenn das Projekt Material für die mündliche Präsentation der Idee benötigt, vergleichen Sie die Aufgabe mit dem Format Pitch Deck.

Wie beschreibt man Tokenomics und technische Mechanik?

Der Abschnitt über den Token sollte seine Rolle im Produkt und die Regeln für den Umlauf in verständlicher Sprache erklären. Wenn der Token für das beschriebene Szenario nicht benötigt wird oder seine Funktion noch nicht definiert ist, verschleiern Sie die Unsicherheit nicht mit komplexen Modellen: Halten Sie die Entscheidung als offen fest und stimmen Sie sie mit dem Team ab.

Beschreiben Sie den Zweck des Tokens anhand der Aktionen des Nutzers oder des Protokolls. Geben Sie an, wo und unter welchen Bedingungen er verwendet wird, welche Rechte oder Funktionen damit verbunden sind und welche Einschränkungen gelten. Wenn Sie Informationen zu Angebot, Verteilung, Freischaltungen oder Emission angeben, gleichen Sie diese mit dem aktuellen Modell ab und verwenden Sie die Begriffe im gesamten Dokument konsistent. Vermischen Sie nicht Verteilungsanteil, Verfügbarkeit von Token und tatsächlichen Umlauf: Das sind verschiedene Konzepte.

Für den technischen Teil ist es hilfreich, Folgendes darzulegen:

• die Hauptkomponenten des Systems und ihre Interaktion;
• was bei einem normalen Nutzerszenario passiert;
• welche Aktionen der Smart Contract ausführt und was außerhalb der Kette bleibt;
• von welchen externen Diensten oder Netzwerken die Funktion abhängt;
• welche Annahmen und Kompromisse die gewählte Architektur hat.

Fügen Sie ein Diagramm hinzu, wenn es hilft, den Fluss von Vermögenswerten oder Daten zu verfolgen, und versehen Sie es mit Beschriftungen. Jedes Diagramm muss mit dem Text und der aktuellen Implementierung übereinstimmen. Tokenomics beweist nicht den zukünftigen Wert eines Vermögenswerts: Beschreiben Sie die Struktur und Bedingungen, nicht Schlussfolgerungen zur Rendite.

Wie kommt man von den Ausgangsmaterialien zum fertigen Text?

Ein Whitepaper ist einfacher zu erstellen, wenn Fakten vor dem Schreiben gesammelt werden und die Prüfung auf die Verantwortlichen der Abschnitte verteilt ist. Beginnen Sie nicht mit der Feinschliff der Formulierungen: Finden Sie zuerst Lücken im Modell, einigen Sie sich auf Begriffe und bestätigen Sie, dass die Teammitglieder dasselbe Produkt beschreiben.

Praktische Arbeitsreihenfolge:

• Sammeln Sie Quellen: Produktbeschreibung, Spezifikationen, Tokenomics, Diagramme, Entwicklungsstatus und Liste offener Entscheidungen.
• Weisen Sie Verantwortliche zu: Jede technische, produktbezogene und wirtschaftliche Aussage muss einen Eigentümer haben, der sie bestätigen kann.
• Stimmen Sie den Inhalt ab: Erstellen Sie einen Abschnittsplan und markieren Sie, welche Fakten bereits bestätigt sind und welche nur Pläne sind.
• Schreiben und prüfen Sie den Entwurf: Zuerst Logik und Vollständigkeit, dann Stil, Begriffe, Querverweise und visuelle Elemente.
• Legen Sie die Veröffentlichung fest: Geben Sie Version und Aktualisierungsdatum an und benennen Sie einen Verantwortlichen für spätere Änderungen.

Die Vorbereitungszeit hängt nicht von der Seitenzahl ab, sondern von der Verfügbarkeit von Experten, der Vollständigkeit der Materialien und der Geschwindigkeit der Abstimmungen. Reduzieren Sie Verzögerungen, indem Sie Kommentare in einem Dokument sammeln und Anmerkungen in sachliche, technische und redaktionelle unterteilen. Ein Redakteur kann Struktur und Klarheit verbessern, aber das Projektteam muss die Produktstruktur bestätigen.

Welche Fehler machen ein Whitepaper schwach?

Ein schwaches Whitepaper erklärt in der Regel nicht, wie die versprochene Lösung in der Praxis funktioniert. Der Leser sieht Terminologie, Pläne und kühne Behauptungen, kann aber den Zusammenhang zwischen Problem, Produkt und behaupteter Mechanik nicht überprüfen.

Prüfen Sie den Entwurf auf typische Fehler:

• Zu breite Problemthese. Geben Sie einen konkreten Nutzer, ein Szenario und den Mangel des bestehenden Ansatzes an.
• Technischer Jargon ohne Definition. Erklären Sie den Begriff bei der ersten Verwendung und verwenden Sie ihn in allen Abschnitten einheitlich.
• Pläne als funktionierende Funktionen dargestellt. Trennen Sie fertige Implementierung, laufende Entwicklung und mögliche Richtungen.
• Tokenomics getrennt vom Produkt beschrieben. Zeigen Sie, welche Aufgabe der Token löst, oder geben Sie ehrlich an, dass seine Rolle noch geklärt wird.
• Inkonsistente Werte und Begriffe. Gleichen Sie Text, Tabellen, Diagramme und öffentliche Materialien mit einer einzigen Datenquelle ab.
• Keine Diskussion von Einschränkungen. Geben Sie Abhängigkeiten und Kompromisse an, die die Nutzung des Systems beeinflussen können.

Eine nützliche redaktionelle Prüfung ist einfach: Bitten Sie eine Person außerhalb des Teams, nach dem Lesen der Zusammenfassung den Zweck des Projekts und ein Schlüsselszenario wiederzugeben. Wenn sie Fakten durch eigene Annahmen ersetzt, präzisieren Sie den Text und fügen Sie fehlende Verbindungen hinzu. Fügen Sie keinen Umfang hinzu, um zu beeindrucken: Jede Aussage sollte helfen, das System zu verstehen.

Was sollte vor der Veröffentlichung eines Whitepapers geprüft werden?

Vor der Veröffentlichung prüfen Sie das Dokument als Informationsquelle über das Projekt: Der Leser muss Fakten von Absichten unterscheiden, Begriffe verstehen und Bestätigungen für wesentliche Aussagen finden. Die Prüfung ist nicht nur Aufgabe des Redakteurs – sie umfasst Personen, die für Produkt, Entwicklung, Wirtschaftsmodell und öffentliche Kommunikation verantwortlich sind.

Gehen Sie die endgültige Liste durch:

• Gleichen Sie alle technischen Beschreibungen mit der aktuellen Architektur und dem Entwicklungsstand ab.
• Prüfen Sie, ob das Token-Modell im Text mit Berechnungen und getroffenen Entscheidungen übereinstimmt.
• Kennzeichnen Sie Prognosen und Pläne als Pläne, nicht als vollendete Tatsachen.
• Stellen Sie sicher, dass Tabellen und Abbildungen lesbar sind und dem Text nicht widersprechen.
• Prüfen Sie Daten, Versionen, Links, Schreibweisen von Namen und Definitionen von Begriffen.
• Geben Sie an, wohin Korrekturen gemeldet werden können und wo die aktuelle Version zu finden ist.

Ein Whitepaper bestätigt nicht die Qualität des Projekts und ersetzt nicht die Prüfung von Smart Contracts, Produkt oder rechtlichem Modell. Die Veröffentlichung des Dokuments kontrolliert nicht die Entscheidungen der Plattformen: Listing und Moderation von CoinMarketCap oder CoinGecko erfolgen nach deren eigenen Kriterien und Verfahren. Man kann keine Zusage für ein Listing, Aufmerksamkeit des Publikums oder Marktergebnis auf Basis des Textes geben. Das Team kann für die Genauigkeit und zeitnahe Aktualisierung des Dokuments verantwortlich sein, aber nicht für die Entscheidung einer externen Plattform. Wenn sich nach einer Produktänderung öffentliche Informationen ändern, stimmen Sie diese mit anderen Materialien ab, einschließlich des Antrags für das CoinMarketCap-Listing.

Preise

Startpreise in USD. Individuelle Pakete und Mengenrabatte auf Anfrage. Zahlung in USDT, USDC, BTC, ETH, SOL, TON oder Ihrem Projekt-Token.

So funktioniert's

1. Fakten sammelnFordern Sie Spezifikationen, Diagramme, aktuelle Token-Parameter und Beschreibungen der Nutzerszenarien an. Markieren Sie separat Fragen, zu denen das Team noch keine Entscheidung getroffen hat.
2. Leser definierenWählen Sie die Hauptzielgruppen und entscheiden Sie, welche Erklärungen jede benötigt. Legen Sie den Zweck des Dokuments fest, um es nicht mit einer Präsentation oder Dokumentation zu verwechseln.
3. Struktur abstimmenOrdnen Sie die Abschnitte von Problem und Produkt über Architektur, Wirtschaft und Einschränkungen. Weisen Sie für jede These einen Spezialisten zu, der ihre Richtigkeit prüft.
4. Entwurf erstellenSchreiben Sie auf Basis bestätigter Materialien und trennen Sie aktuelle Funktionen von Plänen. Stellen Sie sicher, dass Definitionen und Werte zwischen den Abschnitten konsistent bleiben.
5. Prüfung und VeröffentlichungGleichen Sie Fakten mit dem Team ab, redigieren Sie Text, Diagramme und Links. Geben Sie die Version des Dokuments an und benennen Sie einen Verantwortlichen für Aktualisierungen.