BEYUL Whitepaper — Pre-Testnet Edition: アーキテクチャと開示モデル

これは翻訳です。英語版が唯一の正典（canonical）であり、矛盾がある場合は英語版が優先されます。 技術識別子（BEYUL、BYL、privacychain、TDC、ADC、nullifier、commitment、viewing key、shielded pool、Groth16 など）は翻訳せず英語のまま残します。

プロジェクト： BEYUL　種別： プライバシー公開チェーンの研究プロトタイプ（pre-testnet）。BEYUL のプロトコル開発は現在 privacychain リポジトリで行われています。 ドキュメントの位置づけ： BEYUL ホワイトペーパー、pre-testnet（研究）版 — プロトコルのアーキテクチャ、開示モデル、および公開テストネット前の現在の境界を記述します。これは本番プロトコル仕様、投資文書、コンプライアンス意見、セキュリティ監査、トークン発行資料、メインネット告知のいずれでもありません。能力に関する主張は §3.1 のエビデンス規律に従います。ここに記載されるものは、その実際の成熟度を超えて記述されていません。 トークンの位置づけ： トークノミクスは未確定です。BYL はプロジェクトの短縮形 / ティッカーにすぎず、凍結されたデノミネーションではありません — デノミネーションおよびチェーンパラメータは Owner の明示的承認待ちのままです。本書はトークン配分やユーティリティ設計を定義しません。テストネットトークンは、使用される場合でも金銭的価値はなく、メインネットへの変換も約束されません。 正典言語： 英語版が唯一の正典です。中国語版（beyul-whitepaper-pretestnet.zh.md）は付随する作業用テキストであり、矛盾がある場合は英語版が優先されます。

主張の境界ボックス（最初にお読みください）

本書は以下のいずれの主張も行いません：

• 匿名性、追跡不可能性、または「絶対的な安全性」の主張をしません；
• 本番レベルのゼロ知識セキュリティの主張をしません（現在の実装は development-key の素材を使用）；
• 本番レベルのプライバシーの主張をしません（入金・出金額は現在オンチェーンで公開）；
• 規制当局の承認や「compliance by design」の主張をしません；
• 現在の設計にプロジェクト管理のグローバルな viewing key は含まれません。この性質はオープンな実装・テスト・外部監査によって検証されなければなりません；
• 公開テストネットもメインネットも存在しません；テストネットの準備は進行中で、マルチノード runbook と関連 gate はまだ完了していません；
• トークン価値、エアドロップ、利回り、リターン、取引所上場の約束はしません。本書はウォレット製品や DeFi を扱いません；
• 16-character disclosure code は基礎となる暗号セキュリティ資格情報ではありません（第 7 章）。

命名と技術識別子。 BEYUL はプロジェクト/製品名です。BEYUL のプロトコル開発は現在 privacychain リポジトリで行われています。privacychain は現在の技術識別子 — リポジトリ、プロトコル/モジュール/proto パッケージ、バイナリ、chain-id — のままであり、変更せずに保持されます。BYL は短縮形 / ティッカーです。デノミネーションおよびチェーンパラメータは Owner の明示的承認待ちのままであるため、BYL は凍結されたデノミネーションではありません。この命名規律は前向きのみに適用され、過去の文書は遡及的に改名されません。

1. 概要

BEYUL は**研究プロトタイプ段階（pre-testnet）**のプライバシー公開チェーンプロジェクトであり、**デフォルトでプライバシー（設計目標）**とユーザー制御による開示を備えた決済インフラを探求します。目標とする設計では、取引の詳細はデフォルトで公開されませんが、資産の所有者は限定された範囲で、選んだ相手に対して自発的に開示できます — Transaction Disclosure Code（TDC）は単一の取引を説明し、Asset Disclosure Code（ADC）は選択した資産のスナップショットを開示します。「デフォルトでプライバシー」は設計目標を表すものであり、現在のプロトタイプではありません（§5 参照）。

今日存在するのは、クライアント側の disclosure-code 導出プロトタイプ（ローカルでテスト済み。公開エビデンスパッケージは統合待ち）と、Cosmos SDK ベースの chain-application プロトタイプのみです。エンドツーエンドのサーバー側 grant、オンチェーン検証、ZK balance proof は実装されていません。trusted setup なし、外部監査なし、公開テストネットもメインネットもなし。入金・出金額は現在オンチェーンで公開されています。本ホワイトペーパー（pre-testnet 版）の目的は、公開テストネット開始前に、アーキテクチャの方向性、開示モデル、現在の境界を正確に記録すること — そして対応するエビデンスと監査が存在するときにのみ本番版に置き換えられることです。

2. 位置づけと課題

公開台帳は、支払い関係、残高、資金の流れをあらゆる観察者にさらします。一方、ほとんどの強プライバシーシステムは選択的開示を運用上困難にします — ある相手に 1 件の取引を説明することが、しばしばすべてを閲覧できる能力を引き渡すことを意味します。BEYUL が探求する隙間は、「開示」を「隠蔽」と同格の第一級プリミティブにし、すべての開示をユーザー起点とすることです。

BEYUL は「完全に匿名で追跡不可能」という物語を競争の対象とせず、目標ともしません。

ビジョン。 公開台帳における金融プライバシーは反転しています。デフォルトで丸裸であり、隠すこと自体が疑わしく見えます。BEYUL の目標はこのデフォルトを反転させること — プライバシーをデフォルト状態とし、開示をユーザーの意図的できめ細かな選択とすること：どの取引を、どのフィールドを、誰に、どのくらいの期間。

設計原則。 プロトコルのあらゆる部分は以下に従います：

1. 開示は第一級の市民 — 開示プリミティブは隠蔽プリミティブと同格で設計・プロトタイプ化されます。
2. 最小権限 — 各鍵と資格情報は、その目的に必要な最小限の権限のみを持ちます。
3. spend authority は神聖 — いかなる開示フローも spend authority に触れてはなりません。ニーモニックはいかなる開示ステップにも入りません。
4. グローバル特権なし — プロトコルは、プロジェクトや第三者にグローバルな閲覧チャネルを提供しないよう設計されています。そのような分岐が存在しないことは、**オープンな実装・テスト・外部監査によって検証されるべき設計上の性質（§6）**であり、まだ保証ではありません。
5. 境界の正直さ — 各能力は自身が何をしないかを宣言します。脅威モデルと制限事項は公開されたままです。
6. エビデンス優先 — 能力に関する主張は、エビデンス（コード、テスト、監査）が存在して初めて引き上げられます — gate ベースで、日付の約束はありません。

2.1 BEYUL の開示の比較

本表は BEYUL の目標とする設計を、他システムの現在出荷済みの能力と比較します。以下に挙げる BEYUL の差別化要素（失効、取り消し、コンセンサスで強制される可視性、サーバーおよびオンチェーン検証を伴う取引単位/スナップショット単位の範囲指定）は、大部分が計画中またはクライアント側プロトタイプ（§3、§7 参照）であり、まだ出荷されていません。競合に関する事実は保守的に述べられ、本ホワイトペーパーで独立に再検証されていない項目は 【to verify】 と記されます。

意図する差別化要素は「より強い隠蔽」ではなく、よりきめ細かく、時間で区切られ、ユーザーが発行する開示です：Zcash/Monero の viewing key がアカウント全体・オールオアナッシング・無期限の読み取り許可であるのに対し、BEYUL の開示資格情報は 1 件の取引（TDC）または 1 件の資産スナップショット（ADC）に範囲指定され、失効を持ち、取り消し可能に設計されています — 可視フィールドの集合はウォレットの慣行ではなくコンセンサスによって強制されます。これらの性質は設計目標であり、その実装状況は §3 と §7 で正直に追跡されます。

出典。 Zcash/Monero：本プロジェクトの ZEC/XMR 深掘り調査レポート（一次情報源 — Zcash Protocol Specification；Monero ドキュメント；2026-06-12 時点）。Penumbra / Aztec / Namada の各行は、各プロジェクトの2026-06 時点の公式ドキュメントを記述したものです（Penumbra：protocol.penumbra.zone — viewing keys、FMD；Aztec：docs.aztec.network — keys、note discovery；Namada：docs.namada.net — shielded accounts）。残る【to verify】項目 — Penumbra の失効/取り消しおよび transaction-perspective のセマンティクス、Aztec のネイティブな失効/取り消し、Namada の正確な取り消しセマンティクス — は確認待ちです。これらの行は各プロジェクトのドキュメントが記述する内容を述べたものであり、他のシステムが「できない」という主張ではありません。

3. 現在の状況

3.1 エビデンスチェーン

上表の「プロトタイプ実装済み」の各行は、散文で主張されるのではなく、エビデンス記録に紐づいています。エビデンスチェーン（commit hash、CI 記録、正確なテストコマンドと出力、再現可能な実行手順）は Evidence Appendix に保持され、各能力は研究成熟度スケール L0–L5（設計 → プロトタイプ → 再現可能 → レビュー済み → ネットワークエビデンス → 本番）で評価されます。本ホワイトペーパーは、生のエビデンスを再記述するのではなく、その登録簿を参照します。

現在の自己評価：素材の大部分は L1–L2 であり、L5 のものはありません。Evidence Appendix の項目が（commit/CI で）埋まるまで、公開資料は「ローカルで検証済み；公開エビデンスパッケージは統合待ち」と述べ、「公開エビデンスを伴う実装済み」とは述べません。登録されたエビデンス記録のない能力は、その成熟度レベルを超えて記述できません。Evidence Appendix は docs/evidence-appendix.md にあります（内部用；公開エビデンスパッケージとともに公開予定）。E1/E3/E4 は 2026-06-19 に読み取り専用で再現され、CI の紐づけはまだ保留中です。

4. 技術モデル

プロトタイプは shielded-pool 状態機械を中心とします。非暗号学者向けに、プライベート残高のライフサイクルは次のように進みます：

1. Note。 使用可能な残高は note — （所有者、金額、ランダム性）の記録 — です。note 自体はオンチェーンに現れません。
2. Commitment。 チェーンは note への commitment（一方向の束縛ハッシュ）のみを格納し、追記専用の Merkle commitment tree に追加します。commitment 単独からは、観察者は所有者も金額も知りません。
3. Spend → nullifier。 note を使用するには、所有者がそれから導出した nullifier を公開します。nullifier は外部の観察者には commitment と結びつけられないよう設計されており（nullifier-key PRF 仮定の下；イエローペーパー §7.1）、その note に対しては決定論的であるため、同じ note は一度しか無効化できません。
4. double-spend 拒否。 チェーンは nullifier の集合を保持し、重複した nullifier は拒否されます。これにより、どの note が使用されたかを明かすことなく double-spend を防ぎます。
5. 有効性証明。 spend は「commitment が木の中にある note を所有しており、その nullifier を正しく導出した」というゼロ知識証明を伴い、それらの値のいずれも明かしません。検証は Groth16 パスを通じて行われます。

現在の検証器は development/skeleton の verifying-key 素材を trusted setup なしで使用しており、本番の soundness やプライバシーを確立しません。 標準的な対外表現：「プロトタイプには development-key の Groth16 検証パスが含まれます。まだ本番レベルのゼロ知識セキュリティは提供しません。」note 形式、commitment スキーム、nullifier 導出、木のセマンティクスの形式的定義については、イエローペーパー §§5–7 および §10 を参照してください。

4.1 なぜ独立したチェーンか、なぜ Cosmos か

開示モデルは、共有 L1 上のスマートコントラクトのデプロイや汎用 rollup ではきれいに得られない、いくつかの事柄に対する制御を必要とします：

• コンセンサスで強制される開示の可視性（§6）と shielded pool の供給整合性ルールは、状態遷移/コンセンサス層に存在しなければならず、ホストチェーンのバリデータや手数料市場がプロジェクトの管理外にあるコントラクトの内部にあってはなりません。
• ネイティブな shielded 状態（commitment tree、nullifier 集合、value-balance 会計）は、コントラクトストレージとしてよりも第一級のチェーン状態としての方が安価で監査可能であり、ホストチェーンの公開 mempool やメタデータモデルが意図以上に漏らすことを避けます。
• bonded-PoS バリデータセットは、供給整合性をすべての full node が再計算できるようにし、決済に適した即時ファイナリティを提供します。

Cosmos SDK + CometBFT は、staking/slashing モジュール、主権的なアップグレードガバナンス、即時ファイナリティを備えた成熟した BFT-PoS スタックのために選ばれています — いかなるトークンモデルへの支持としてでもありません（いずれも未確定）。これはアーキテクチャ選定の理由であり、独立したチェーンがデプロイされているという主張ではありません。実際の状況は §3 と §8 を参照してください。

4.2 パフォーマンス特性

2 種類の数値は分けて扱われます。固有（スキームレベル、引用可能）： BN254 曲線上の Groth16 は、定数サイズの証明（3 つの群要素：2×G1 + 1×G2、BN254 で約 128 B 圧縮 / 約 256 B 非圧縮）と定数時間の検証（回路サイズに依存しない、固定で少数のペアリングチェック）を持ちます。これらは BEYUL の実装からではなく、証明システム自体から導かれます。システムレベル（まだ測定されていない）： 証明時間、トランザクションスループット（TPS）、回路サイズ（制約数）は本番回路に依存しますが、本番回路は構築されていません — 現在のパスは dev/skeleton の verifying key を使用します（§4）。したがって、そのような数値はいずれも target / 【to be supplied】 であり、本番回路と trusted-setup または透明な証明パスが存在してからベンチマークされます（Roadmap §10、Phase 6）。この線より上では、システムレベルのパフォーマンス数値は一切主張されません。

5. プライバシーモデルと現在の制限

現在のプロトタイプは本番レベルのプライバシーではありません。

pre-testnet / 低利用時には匿名集合は小さいか空であり、実際のユーザーがいなければプール内プライバシーは有意に確立されません — 強力なプライバシーは大規模で活発な匿名集合に依存し、実際の利用が存在するまで主張されません。バリデータ層の順序付け/MEV とネットワークメタデータは未緩和のままです。

匿名集合の形式的フレームワーク（shielded pool の匿名集合がどのように定義され限定されるか）はイエローペーパー（§15）に保持されています。本節はプライバシーの目標と現在の制限を述べるものであり、その形式モデルではありません。

6. 鍵と開示のモデル

権限の高い順に：Spend Key（唯一の使用権限；ユーザーのデバイスを決して離れず、開示フローに決して関与しない）→ Full View Key（読み取り専用；受信/送信の分割を計画）→ Audit Key（計画中：ユーザーが自発的に発行；期間限定、範囲限定、取り消し可能；プロトコルが義務付けるチャネルではない）→ Disclosure Credential（1 件の取引または 1 件の資産スナップショットに束縛された最小の開示単位）→ 16-character disclosure code（入口の短いコード；鍵ではない）。

プロジェクトの閲覧権限の境界：現在の設計にはプロジェクト管理の master viewing key は含まれません。この性質はチームへの信頼ではなく、オープンな実装・テスト・外部監査によって検証されなければなりません — 鍵導出パスはオープンソースとして出荷され、いかなる第三者も、プロジェクトに至る分岐が存在しないことを導出グラフで監査できます。外部監査が完了するまで、これは「検証されるべき設計上の性質」であり、「保証」ではありません。

ニーモニックの方針（アーキテクチャ計画であり、出荷された製品ではない）：ウォレットのルート鍵はデフォルトで 24 語のニーモニック（BIP39）を使用し、下流の鍵はドメイン分離（HKDF + domain tags）によって導出されます。ニーモニックはいかなる開示フローにも決して現れてはなりません。disclosure code も link_secret もニーモニック単独から導出可能であってはならず、TDC/ADC grant は自発的な開示の瞬間に CSPRNG とローカルな認可を用いて生成されます。

開示可視性の境界（設計要件）：開示資格情報の可視範囲 — 送信方向の可視性を含む — は、ウォレット実装の慣行ではなく、コンセンサス層のルールによって保証されるよう計画されています（送信側の可視性がウォレットの慣行に依存する Zcash からの業界の教訓）。この要件はオンチェーン検証スタック（roadmap Phase 5）とともに実現され、今日は実装されていません。

Disclosure Grant 層（独立レビュー待ち）：Disclosure Grant 層 — スコープ、失効、取り消し、監査ログ、viewer 権限 — は、独立した製品およびセキュリティレビュー待ちです。そのレビューが完了するまで、これらの境界性質のいずれにも依拠してはならず、いかなる文書もそれらが確立されていると示唆してはなりません。

7. TDC / ADC 開示プロトタイプ

7.1 用語とエンコーディング

公式な用語は「16-character Crockford Base32 disclosure code」（アルファベットは紛らわしい文字 I/L/O/U を除外；短コードのエントロピーは約 80 ビット）で、「16-character disclosure code」と略されます。「16-digit code」や「16-digit security code」といった表現は使用しません — 数字のみのスキーム（約 53 ビット）はエントロピー予算が不十分なため却下されました。

「16-character disclosure code は基礎となる暗号セキュリティ資格情報ではありません。これはユーザーにとって使いやすいアクセス入口であり、実際の認可は高エントロピーの disclosure credential、署名、範囲制限、失効、検証ロジックによって共同で保護されなければなりません。」

7.2 実際の現状（必読）

BEYUL が持つのは、ローカルでテストされた TDC/ADC クライアント側導出プロトタイプです。エンドツーエンドのサーバー grant、チェーン状態の検証、ZK balance proof は計画中で未実装です。したがって、次のように述べてはなりません：検証可能な開示が実装されている；資金がすでに証明できる；ADC が正確な残高を証明できる；あるいは disclosure code がオンチェーンで検証できる。

クライアントプロトタイプがカバーするもの（ローカルでテスト済み）：二要素 KEK（link_secret + 16 文字コード、両方が必須）；正準エンコーディング；TDC の送信者/受信者の役割束縛；TDC/ADC のドメイン分離（一方が他方を開けない）；AAD 改竄保護を備えた AEAD envelope（クライアント側 TDC/ADC エンベロープ；オンチェーン MsgDiscloseNote エンベロープの AAD は依然 target — イエローペーパー §2.3）；slow-hash のコード検証器（目標スイートは Argon2id；本番アダプタは未接続）；erasure-key の crypto-shredding。

7.3 TDC と ADC のセマンティクス

開示のトリレンマ：所有権を隠すシステムは、残高の完全性、履歴の非漏洩、viewing key を渡さないことを同時には約束できません — ユーザーは選択した notes の所有を証明できますが、追加の完全性ソースなしには何も省略していないことを証明できません。したがって ADC は段階化されており、ADC は選択した資産集合の選択した高さにおける残高をまさに開示します — 「残高を明かさない」と記述してはなりません。

ADC のリスク（公開を維持）：同じ相手への繰り返しのスナップショットは時間経過に伴う残高の変化を明かします；純資産の露出は身体的安全と強要のリスクです（ADC はデフォルトでオフであり、明示的な確認が必要）；ローテーションは観察者がすでに見たものを取り戻せません。

7.4 disclosure code FAQ

8. テストネット計画（現在の焦点）

8.1 バリデータモデル

テストネットは PoS 型 BFT バリデータモデルを使用します：Cosmos SDK + CometBFT、初期バリデータセット、staking モジュールのテストフロー。これは PoW ではなく、またメインネット級の PoS 経済的安全性ではありません — メインネットの経済モデルは本ホワイトペーパーの範囲外の長期研究です。

8.2 テストネットの準備状況（率直に）

テストネットの準備は進行中です：マルチノード runbook と関連 gate はまだ完了していません（該当するプルリクエストはすべてマージされておらず、チェックも通っていません）。これらの gate が閉じてエビデンスが登録されるまで、本プロジェクトは「testnet-ready」という表現を使用しません。

ローンチ前チェックリスト：エビデンスパッケージのクローズ；テストネットの chain-id と genesis；バリデータのオンボーディングガイド；3+ ノードのマルチノード runbook；faucet ポリシーとレート制限；公開 RPC/API ポリシー；監視ダッシュボード；インシデント対応プロセス；既知の制限リスト；参加者のコマンドフロー；テストネットトークンの無価値告知。

8.3 テストネットが検証できること / 証明できないこと

検証できること：ノードの稼働とブロック生成、staking モジュールのフロー、faucet、RPC、監視とインシデント対応、disclosure-code のデモフロー、shielded module のプロトタイプフロー。 証明できないこと：本番プライバシー、メインネットの PoS 経済的安全性、トークン価値、規制上の受容、本番 ZK soundness。テストネットのローンチを「本番検証」として宣伝してはなりません。

8.4 参加者への注意

テストネットトークンは金銭的価値もメインネットへの変換の約束もありません；公式ウォレットはありません — 公式に公開されたコマンドラインツールとドキュメントのみで参加してください；いかなるフローも、あなたのニーモニックを開示ステップに入れることを決して要求しません — あなたのニーモニックを尋ねる「公式」は詐欺師です；現在、いかなるトークンセール、プライベートラウンド、ホワイトリスト、エアドロップ登録もありません。

8.5 ガバナンス、アップグレード、経済的境界

この pre-testnet 段階では、BEYUL に分散型ガバナンスはありません。プロトコルのアップグレードとセキュリティ上重要な pin — genesis パラメータと pinned verifying key — は、初期バリデータセットと Owner が共同で管理します。これは率直に述べる中央集権的な信頼モデルであり、ネットワークとそのガバナンスが成熟するにつれて段階的にのみ分散化されます（DAO なし、分散化のタイムラインの約束なし）。バリデータを運用すること自体はアップグレード権限を付与しません；pinned VK と genesis は「バリデータセット + Owner」のアップグレードパスを通じてのみ変更されます。

経済的境界。 デノミネーション、供給量、経済パラメータは Owner の決定 — gate されており、本ホワイトペーパーでは定義されません（上記のトークンの位置づけ参照）。ここではデノミネーション、供給量、トークン経済モデルのいずれも固定しません。

9. 脅威モデル（緩和されるまで公開）

敵対者のクラス別に整理され、イエローペーパーの敵対者モデル（A1–A4）に合わせています。これは要約です；イエローペーパーが脅威モデルの権威ある参照であり、2 つの文書はドリフトしてはなりません — 相違がある場合はイエローペーパーが優先されます。

• A1 — 受動的なチェーン観察者（公開チェーンデータのみを読む）：公開された入金/出金の金額相関、タイミング相関、手数料/gas のサイドチャネル — 未緩和。commitments、nullifiers、anchors、プールのネットフロー口座は設計上公開されます。
• A2 — ネットワーク/インフラの敵対者（mempool、RPC、バリデータの順序付け、IP）：mempool の観察、バリデータの順序付けと検閲、ネットワーク層のメタデータ — 未緩和（順序付け/検閲は一部プロトコル対象外）；プロトコル外の取引所/ブリッジのメタデータ — 対象外。
• A3 — 開示側の敵対者（開示の受信者、またはコードを保持する者）：受信者による開示の転送は暗号学的に制御不能；取り消しは未実装；繰り返しのスナップショットによる ADC の時系列と純資産の露出；強要された発行 — 率直に述べる、未緩和。
• A4 — エンドポイント/ソーシャルの敵対者（ユーザーのデバイス、フィッシング）：ニーモニックやコードを狙うフィッシングとソーシャルエンジニアリング、偽ウォレットや偽の公式チャネル — 未緩和；ユーザー教育と公式チャネルリストで対処。

横断的・未解決：回路のバグ、trusted setup、外部監査 — 未検証 / 未解決 / 未完了。プール供給整合性（G-S ゲート）はオープンであり、保存則と double-spend は本番の性質としては主張されず、in-circuit および keeper の value-balance と 128↔64 ビット幅整合性（イエローペーパー §12.3 を反映）待ちです。テストネットトークンの価値と報酬に関する混同は許可されません — テストトークンは無価値であり、いかなる報酬の会計もシミュレーションです。

10. Roadmap（gate ベース、日付の約束なし）

各能力は次のいずれか 1 つの状態になければなりません：Implemented / Local tested / Prototype / Documentation only / Planned / Unverified / Not implemented。commit、CI 記録、テストコマンド、出力なしに「実装済み」と書ける主張はありません。

順序は不可逆です：testnet → TDC MVP → ADC_L1 → root-bound verification → production ZK → ADC_L2 → audit → pre-mainnet。

11. コンプライアンスの境界

BEYUL はコンプライアンスソリューションではありません：AML、KYC、travel-rule、凍結、制裁スクリーニング、報告のワークフローを実装せず、「compliant by design」を主張しません。すべての開示はユーザー起点です；プロトコルには強制開示チャネルはありません；現在の設計にはプロジェクト管理のグローバルな viewing key は含まれません（オープンな実装と監査で検証予定）。機関および個人は、自らの管轄区域のプライバシー資産に対する規制姿勢を独立して評価すべきです。

12. リスクに関する記述と免責事項

本書は情報提供のみを目的としており、次のいずれをも構成せず、またそのように解釈されてはなりません：証券、商品、金融商品の提供または販売；投資、法律、税務、財務上の助言；いかなる管轄区域におけるコンプライアンスの表明。本書には将来予想に関する記述（設計目標、テストネット計画、roadmap）が含まれ、重大な不確実性を伴います；実際の結果は大きく異なる場合があります。

本プロジェクトは現在いかなるトークンも発行していません；テストネットトークンは、使用される場合でも金銭的価値はありません。暗号資産ネットワークへの参加には重大なリスクが伴います。ご自身で調査し、専門の助言者にご相談ください。いかなる翻訳もこの英語の正典版と矛盾する場合は、この英語版が優先されます。この免責事項は汎用テンプレートであり、正式な公開前に該当管轄区域の法律顧問によるレビューが必要です。

13. 結論

BEYUL の方向性は、デフォルトでプライバシーかつユーザー制御による開示です。今日の信頼できる資産：chain-application プロトタイプ、ローカルでテストされた TDC/ADC クライアント側導出プロトタイプ、そして実装に厳密に整合させた状況表と脅威モデル。現在唯一の焦点は、公開テストネットローンチの前提条件：エビデンスのクローズ、マルチノード runbook、faucet と監視、参加者ドキュメントです。対応するエビデンスが存在するまで、本プロジェクトはメインネット、トークン、本番プライバシー、コンプライアンスに関する主張を行いません。