仮想通貨ホワイトペーパーの書き方：構成とよくある間違い

仮想通貨ホワイトペーパーは、読者が何を判断するのに役立つべきですか？

仮想通貨ホワイトペーパーは、特定の読者がプロジェクトの提案を理解し、次に何を検討すべきかを判断するのに役立つべきです。これは製品ドキュメント、ピッチデッキ、または法的アドバイスの代わりにはなりません。ドラフトを始める前に、読者の判断を一文で書いてください。例えば、プロトコルを研究するか、トークンデザインを評価するか、提案されたユースケースを評価するかなどです。

次に、読者の質問をマッピングします。開発者はアーキテクチャ、依存関係、実装状況を必要とするかもしれません。トークン保有者は供給ルール、効用、ガバナンスを求めるかもしれません。潜在的なパートナーは、より広いエコシステムにおける製品の役割を必要とするかもしれません。1つの文書で複数の読者に対応できますが、無関係な詳細を探させるべきではありません。

短いブリーフを使用して以下を確立します：

• 問題とそれを経験する人。
• 提案された解決策と現在存在するもの。
• 文書の対象読者と次のアクション。
• どの主張が確認済み、計画中、または研究中か。

プロジェクトが初期段階で、簡潔な紹介が必要な場合は、概要を説明する前にホワイトペーパーと仮想通貨ピッチデッキを比較してください。デッキはプレゼンテーションをサポートします。ホワイトペーパーは読者により完全で参照可能な説明を提供します。

どのような構成が仮想通貨ホワイトペーパーを評価しやすくしますか？

役立つ構成は、読者の問題からプロジェクトの提案された答えへと進み、次にシステムがどのように機能し、何が不確かなままかを示します。中心的な説明を早い段階に置きます。読者は、製品の目的を知る前にトークン配分や技術用語を理解する必要はありません。

実用的な概要は以下の通りです：

1. 要約： 問題、提案、現在の状況。
2. 問題と背景： 誰が影響を受け、既存のアプローチが何を未解決のままにしているか。
3. 製品とシステム： ユーザーフロー、コアコンポーネント、それらの相互作用。
4. アーキテクチャ： 関連するコントラクト、チェーンの選択、依存関係、セキュリティに関する考慮事項。
5. トークンデザイン（該当する場合）： 目的、供給、配分、リリースルール、ガバナンス。
6. ロードマップとチーム： 完了した作業と計画中の作業を区別し、責任者を特定します。
7. リスクと参考文献： 制限事項を説明し、サポート資料を参照します。

デフォルトですべての見出しを埋めるのではなく、プロジェクトに合わせて概要を調整します。プロトコルペーパーではより深いアーキテクチャが必要かもしれません。アプリケーションではより多くのユーザーフロー説明が必要かもしれません。相互作用を明確にする場合に図を追加し、専門知識がなくても要点が理解できるようにキャプションを付けます。各主要概念に1つの用語を使用し、最初の使用時に定義し、セクション名を説明的に保ちます。読者は見出しをスキャンして文書の論旨を理解できるべきです。

トークン経済とプロジェクトの主張はどのように説明すべきですか？

トークンの仕組みを、孤立した数字やプロモーション用の言葉ではなく、読者が追跡できるルールとして説明します。トークンが何をするか、誰が受け取ったり使用したりできるか、供給がどのように変化するか、どのアクションがコード、ポリシー、または将来の決定によって管理されるかを述べます。プロジェクトにトークンがない場合は、憶測のトークンセクションを追加するのではなく、明確にそう述べます。

すべての供給または配分の記述について、単位、関連するアドレスまたは受取人カテゴリ、および情報が現在の状態を説明するのか計画を説明するのかを指定します。権利確定、アンロック、排出、バーン、またはその他の供給変更は、該当する場合にのみ明確にします。合計と用語を、ナラティブ、チャート、テーブル全体で一貫させます。オンチェーンの詳細については、利用可能な場合は読者を関連するエクスプローラーまたはコントラクト参照にリンクします。

公開前に、トークンおよび財務の責任者に各数値のソースとその表現を確認させます。文、ソース、責任者、ステータスを含む主張ログを保持します。ホワイトペーパーが上場やプロフィール更新と同時に準備されている場合は、CoinGecko供給検証で使用される資料と供給言語を調整します。文書はプロジェクトのデザインを説明するべきであり、トークンの使用、需要、または価値が保証されていることを示唆すべきではありません。

技術的な詳細を信頼性があり読みやすくするにはどうすればよいですか？

技術的な詳細は、知識のあるレビューアーが説明を証拠にまで追跡でき、一般の読者でもシステムの役割を理解できる場合に信頼性があります。製品を説明するために必要なレベルでアーキテクチャを説明します：コンポーネント、データフロー、コントラクトの責任、外部依存関係、重要な信頼前提。計画中または未監査の作業を完了済みまたは独立して検証済みとして提示しないでください。

図を使用して関係を示しますが、ページを装飾するためではありません。各図にタイトルを付け、コンポーネントにラベルを付け、矢印の意味を説明します。技術用語には、最初の使用時に平易な言葉での定義を添えます。開発者にのみ有用な実装の詳細は付録または技術文書に移動し、コアの議論は本文に残します。

ドラフトが完了する前にレビュートレイルを構築します：

• 技術責任者にアーキテクチャと実装状況を確認するよう依頼します。
• セキュリティ責任者に監査、管理、既知の制限の説明を確認するよう依頼します。
• 各事実主張にソースまたは指名されたレビューアーを添付します。
• 未解決の質問は、自信に満ちた表現で埋めるのではなく、明確にマークします。

プロジェクトがサードパーティのプロトコル、オラクル、ブリッジ、またはチェーンに依存する場合、その依存関係を名前を挙げて説明します。システムが何に依存しているかを明確に説明することは、実際の信頼前提を示さずにトラストレスと説明するよりも有用です。

リリース前にどの仮想通貨ホワイトペーパーの間違いを修正すべきですか？

最も有害なホワイトペーパーの間違いは、不明確な主張、矛盾する詳細、および文書の内容とプロジェクトが構築したものとの不一致です。これらは文書が配布された後ではなく、レビューで修正します。レビューアーには、文法や視覚的な洗練だけでなく、意味と証拠を確認するよう依頼します。

一般的な問題に注意します：

• 不明確なステータス： 計画中の機能が実際に稼働しているかのように書かれている。出荷済み、進行中、提案中の作業を別々にラベル付けします。
• 根拠のない確実性： 条件や証拠を説明せずに結果を示唆する表現。メカニズムの正確な説明に置き換えます。
• 一貫性のないトークン詳細： 供給、配分、リリースの説明がセクション間で異なる。承認された1つのソースと照合します。
• 読者への過負荷： 密度の高い実装詳細が製品の目的を隠す。専門家向けの資料は明確にリンクされた付録に移動します。
• 制限の欠落： 依存関係、未解決の質問、リスクが存在しない。読者がその関連性を評価できる場所に追加します。
• 古いコンテンツ： ロードマップやコントラクト参照がプロジェクトと一致しなくなった。リリース前に確認する責任者を割り当てます。

技術、トークン、編集、デザインのレビューを個別に実施します。コピー編集の前に矛盾を解決します。2つの矛盾するバージョンを磨くのは時間の無駄です。バージョン履歴を保持し、1人が最終ファイルとそのリンク資料を承認します。

ホワイトペーパーは何を確立でき、何がその管理外にありますか？

ホワイトペーパーはプロジェクトのデザインを文書化し、その証拠を説明し、前提を検査しやすくすることができます。しかし、取引所、データプラットフォーム、規制当局、または読者がそのプロジェクトをどのように評価するかを決定することはできません。特に、公開されたペーパー自体は、上場、プロフィール変更、承認、または特定の市場反応を保証しません。各プラットフォームは独自のレビュー基準を適用し、その決定と表示は著者の管理外です。

公開をバージョン管理されたプロジェクト資産として扱います。リリース前に、承認されたテキスト、著者または組織の帰属、文書の日付、アクセス可能なファイル形式、リンクされる遷移先を確認します。ウェブサイトの要約がペーパーと一致していることを確認します。トークンの詳細が変更された場合、どのセクション、チャート、サポートページが更新を必要とするかを特定し、文書の責任者を割り当てます。上場準備のために、関連する上場プロセスを通じて提出された情報とホワイトペーパーを整合させます。

簡単なリリースチェックリスト：

• 事実、用語、リンク、文書バージョンを確認します。
• 技術、トークン、および必要な法的レビューを取得します。
• デスクトップとモバイルでファイルをテストし、アクセシビリティを確認します。
• 承認されたバージョンを公開し、将来の更新を担当する人を記録します。

執筆能力が制約である場合は、ホワイトペーパーおよびライトペーパー作成の範囲を確認するか、ホワイトペーパー料金ガイドと成果物を比較します。適切な範囲は、準備されたソース資料の量とレビューが必要な技術責任者の数に依存します。

料金

開始価格はUSD表示です。カスタムバンドルやボリュームディスカウントはご相談ください。USDT、USDC、BTC、ETH、SOL、TON、またはプロジェクトトークンでのお支払いが可能です。

仕組み

1. 文書の役割を設定する主要な読者、その判断、およびペーパーがサポートすべきアクションを特定します。ペーパーが置き換えるべきでないものについて合意します。
2. ソース資料を収集し検証する製品、アーキテクチャ、トークン、ロードマップの情報を収集します。確認が必要な主張には、責任者と証拠ソースを記録します。
3. 概要を作成する読者が必要とする順序でセクションを配置します。プロジェクトの説明や読者に役立たない見出しは削除します。
4. ドラフトとレビュー主要な論旨を書き、技術およびトークンの責任者に事実と前提を確認するよう依頼します。コピー編集の前に矛盾する詳細を解決します。
5. 承認と保守最終ファイル、リンク、バージョンを承認されたソースと照合します。プロジェクトの詳細が変更された場合に更新する責任者を割り当てます。