• インフラストラクチャートークン - レイヤー1のネットワーク（またはレイヤー2などの計算スタックの隣接部分）に対応する。-- その経済モデルは十分に開発され、広く理解されており、ブロック空間の需要と供給に基づいている。しかし、アプリケーション・トークン（「分散型ビジネス」において権利を伝達する、ブロックチェーン上でサービスを展開するためのスマート・コントラクト・プロトコル）については、経済モデルはまだ解明されていない。

• アプリケーショントークンのビジネスモデルは、その基礎となるソフトウェアと同じくらい表現豊かであるべきです。この目的のために、私たちはアプリ トークンのキャッシュフローを紹介します。これは、アプリが、ユーザーが提供する価値に対して報酬を得る方法を選択できる、寛容で柔軟なモデルを作成できるようにするアプローチです。このアプローチは、異なる法域における合法的な活動から手数料を生み出し、より大きなコンプライアンスを促します。同時に、ガバナンスの最小化を促しながら、契約から得られる価値を最大化します。

• ここで私たちが共有する原則は、分散型金融（DeFi）から分散型ソーシャルアプリ、DePINネットワーク、そしてその間にあるものまで、すべてのウェブ3アプリに当てはまります！すべての分野に当てはまります。

トークン・モデルへの挑戦

インフラ・トークンには需要と供給が組み込まれています。需要が増加すると供給が減少し、それに応じて市場が調整されます。多くのインフラストラクチャトークンに対するこのネイティブな経済基盤は、Ether Improvement Proposal 1559 (EIP-1559)によって加速されました。しかし、購入・燃焼モデルの散発的な試みにもかかわらず、アプリトークンにはEIP-1559と同様のモデルはありません。

アプリはブロックスペースのユーザーであり、プロバイダーではないため、ブロックスペースを使用する他の人から徴収するガス料金に頼ることはできません。そのため、独自の経済モデルを開発する必要があるのです。

ここにも法的な課題があります。インフラトークンの経済モデルは、典型的なブロックチェーン取引の一般的な性質と、それらが使用する手続きメカニズムにより、法的リスクの対象がはるかに少なくなります。しかし、アプリケーション・トークンの経済モデルでは、関連するアプリケーションが規制された活動の円滑化に依存している可能性があり、トークン保有者の仲介を管理する必要がある可能性があります。米国で高度に規制されているデリバティブ取引を促進する分散型取引所は、イーサとは大きく異なる。

こうした内在的・外在的な課題が組み合わさることで、トークンを適用するには異なる経済モデルが必要になります。これを念頭に置いて、私たちは可能な解決策を提案します。プロトコルの収益を最大化し、規制遵守にインセンティブを与え、ガバナンスの最小化を取り入れながら、アプリのトークン保有者が提供するサービスを補償するプロトコルを設計するアプローチです。私たちの目標はシンプルです。多くのインフラ・トークンがすでに持っているキャッシュフローと同じ経済的基盤をアプリ・トークンに与えることです。

私たちのソリューションは、アプリトークンが直面する3つの問題の解決に焦点を当てています：

1. ガバナンスの課題1.ガバナンスの課題

   アプリケーショントークンには一般的にガバナンスがあり、分散型自律組織（DAO）の存在は、インフラトークンにはない不確実性をもたらす可能性があります。米国で重要な事業を展開するDAOの場合、DAOが協定の収益をコントロールしたり、協定の経済活動を仲介・プログラムしたりするとリスクが生じる可能性がある。これらのリスクを回避するために、プロジェクトはガバナンスを最小化することでDAOのコントロールを排除することができる。それができないDAOのために、ワイオミング州の新しいDecentralised Unincorporated Nonprofit Association (DUNA)は、これらのリスクを軽減し、適用される税法を遵守するのに役立つ可能性のある分散型法人を提供します。

   2.価値分配の課題

   アプリは、トークン保有者に価値を分配するメカニズムを設計する際にも注意しなければなりません。議決権と経済的権利を組み合わせることで、特に比例配分やトークン購入破棄のような単純でわかりやすいメカニズムでは、米国の証券取引法の下で懸念が生じる可能性があります。これらの仕組みは配当や自社株買いと似ており、トークンは株式とは異なる規制の枠組みを持つべきだという主張を損なう可能性があります。

   プロジェクトはステークホルダー資本主義を探求すべきです。多くのプロジェクトは、運営フロントエンド（Liquity）、参加契約（Goldfinch）、セキュリティモジュールの一部としての担保提供（Aave）など、積極的な参加を奨励している。ここでのデザインスペースは非常にオープンであるが、良い出発点は、プロジェクトのすべてのステークホルダーをリストアップし、彼らがどのような行動をとることを奨励すべきかを特定し、そのようなインセンティブを通じて協定がどのような全体的な価値を生み出すことができるかを決定することである。

   シンプルにするために、この記事ではトークン保有者がガバナンスに参加することで報酬を得るシンプルな報酬モデルを想定していますが、他の選択肢も存在します。

   3.規制活動の課題

   規制活動を促進するアプリケーションは、トークン保有者の価値を蓄積するメカニズムを設計する際にも注意しなければなりません。これらのメカニズムが、認可されていないフロントエンドや、適用される法律に準拠していないAPIから価値を蓄積する場合、トークン保有者は違法な活動から利益を得る可能性があります。

   この問題に対する提案されている解決策のほとんどは、価値の蓄積を米国で許可されている活動に制限することに焦点を当てています。例えば、特定の資産を含む流動性プールに対してのみ合意された手数料を有効にすることなどです。これでは、プロジェクトは規制アプローチの最小公倍数の対象となり、グローバルに自律的なソフトウェア契約の価値提案が損なわれてしまう。また、ガバナンスの最小化努力も直接的に損なわれる。規制遵守の観点からどの手数料戦略が実行可能かを決定することは、DAOにとって適切なタスクではありません。

   理想的な世界では、プロジェクトは、何が許可されているかを決定するためにDAOに依存することなく、活動が許可されているあらゆる法域で手数料を請求できるべきです。解決策は、プロトコルレベルでの規制遵守を要求することではなく、手数料を生成するフロントエンドやAPIがフロントエンドの場所で適用される法律や規制を遵守している場合にのみ、プロトコルで生成された手数料が通過するようにすることです。米国が、アプリによって促進されるある種の取引に対して手数料を請求することを違法とした場合、たとえその行為が世界の他の国で完全に許容されていたとしても、アプリのトークンの経済的価値がゼロになる可能性があります。手数料の蓄積と分配における柔軟性は、最終的には規制の圧力に直面したときの回復力に等しい。

   中核的な課題：手数料の追跡

   手数料の追跡可能性は、非準拠のフロントエンドがもたらす可能性のある潜在的なリスクに対処するために、審査リスクを導入したり、契約をライセンスの対象にしたりすることなく、非常に重要です。を導入したり、契約をライセンスの対象としたりすることなく、非準拠のフロントエンドがもたらす可能性のあるリスクに対処するためには、料金のトレーサビリティが不可欠です。トレーサビリティがあれば、トークン保有者が得た手数料が、トークン保有者の管轄区域内で合法的に準拠したフロントエンドからのみ得たものであることをアプリケーションで確認できる。もし手数料が追跡可能でなければ、トークン保有者を非準拠のフロントエンドから蓄積された価値（すなわち、非準拠のフロントエンドによって収集された手数料）から隔離する方法はなく、トークン保有者を危険にさらす可能性があります。

   手数料を追跡可能にするために、プロトコルは2段階のアプリトークンプレッジシステム設計を使用することができます。

   ステップ1：手数料を生成するフロントエンドを特定する

   ステップ2：手数料を異なる資金プールにルーティングする。資金プールに送る。

   

   フロントエンドのマッピング

   料金のトレーサビリティには、ドメイン名を公開鍵と秘密鍵のペアにマッピングする必要があります。このマッピングがなければ、悪意のあるフロントエンドはトランザクションを偽装し、正直なドメイン名から来たように装うことができます。暗号技術によって、フロントエンドを「登録」し、ドメイン名と公開鍵のマッピングを不変的に文書化し、ドメイン名が実際にその公開鍵を管理していることを証明し、当該秘密鍵を使用してトランザクションに署名することができる。これにより、トランザクション、したがって料金を特定のドメイン名に帰属させることができる。="text-align: left;">一旦手数料の出所が追跡可能になれば、プロトコルはそれをどのように配分するかを決定することができ、DAOの分散型ガバナンスの負担を増やすことなく、トークン保有者を違法な取引からの手数料の受け取りから保護することができます。この点を説明するために、各フロントエンドのための1つの誓約プールから、すべてのフロントエンドのための1つの誓約プールまで、トークンの誓約を適用するためのさまざまな可能な設計を想像してみてください。

   最も単純なビルドでは、各フロントエンドの料金は特定のフロントエンドの誓約モジュールにルーティングできます。どのフロントエンドに誓約するかを選択することで、トークン保有者はどの手数料を受け取るかを決めることができ、トークン保有者を法的リスクにさらす可能性のある手数料を避けることができる。例えば、トークン保有者は、欧州ですべての規制認可を受けたフロントエンドに関連するモジュールにのみ質権を設定することができる。この設計は単純に聞こえるが、実際には非常に複雑である。50の異なるフロントエンドがあれば、50の誓約のプールが存在する可能性があり、手数料の希薄化はトークンの価値に悪影響を及ぼす可能性がある。

   

   設計のもう一方では、各フロントエンドの手数料を一元化することができます。しかし、これではコストのトレーサビリティという本来の目的が損なわれてしまいます。すべての手数料がプールされれば、コンプライアンスに準拠したフロントエンドの手数料とコンプライアンスに準拠していないフロントエンドの手数料を区別する方法はなくなる。トークン保有者は、手数料をまったく受け取らないか、自分の司法管轄区における非準拠フロントエンドの違法行為から利益を得るプールに誓約するかの選択を迫られることになる。となります。

   

   手数料のトレーサビリティ問題を解決するには、以下のように設定します。トレーサビリティの問題

   これらの複雑さは、設定によって解決することができます。誰もがフロントエンドを作成でき、どのフロントエンドも独自の誓約モジュールを持つことができる、ライセンスフリーのスマート・コントラクト・プロトコル・アプリケーションを考えてみましょう。このプロトコルアプリケーションのフロントエンドの1つをapp.xyzと呼ぶことにしましょう。

   app.xyzは、それが置かれている司法管轄区に特有のコンプライアンスルールに従うことができます。app.xyzから発信されるアプリケーション活動には、契約料が発生します。app.xyzには独自の誓約モジュールがあり、トークン保有者は、トークンを直接誓約したり、個別にコンプライアンスに準拠しているとみなされるフロントエンドのポートフォリオを選びたいセッターに誓約したりすることができます。これらのトークン誓約者は、誓約したフロントエンド・コレクションの手数料という形で収益を受け取る。フロントエンドが100ドルの手数料を生み出し、それぞれ1トークンを誓約した100のエンティティがある場合、各エンティティは1ドルを受け取る権利があります。セッターは当初、サービスに対して手数料を請求することができる。将来的には、政府は消費者を保護するために、自動化されたセットアップの副次的な利点を持つ、管轄区域内のコンプライアントフロントエンドを連鎖的に認証するかもしれない。

   このモデルにおける潜在的なリスクのひとつは、準拠したフロントエンドの管理オーバーヘッドがないため、非準拠のフロントエンドがより安く運営される可能性があることだ。また、フロントエンドのコストをトレーダーに回収させるモデルを設計し、回避行動をさらに誘発する可能性もある。このリスクを軽減する要因は2つある。第一に、ほとんどのユーザーは、フロントエンドが自国の法律や規制に準拠することを実際に期待している。これは、特に規制された大規模な組織に当てはまる。第二に、ガバナンスは、ルール違反を繰り返し、アプリケーションの実行可能性を危険にさらす非準拠のフロントエンドに対する最後の手段、または「拒否権」として機能することができ、それによって悪い行動を抑制することができます。

   最後に、登録されたフロントエンドを通じて開始されなかった取引によって発生したすべての手数料は、統一された誓約モジュールに入金され、プロトコルのスマートコントラクトと直接やり取りするボットやその他の取引によって発生した収益をプロトコルが捕捉できるようになります。

   理論から実践へ: アプローチを実践する

   アプリのトークンスタックをより詳細に再検討してみましょう。フロントエンドの誓約を容易にするために、プロトコルは、フロントエンドが登録する必要がある登録されたスマートコントラクトを作成する必要があります。

   1. 各フロントエンドまたはAPIは、ENS DNS統合のようなドメインのDNSレコードに特別なTXTレコードを追加できます。このTXTレコードには、フロントエンドが生成したキーペアの公開キーが含まれており、生成されると証明書と呼ばれます。

   2. フロントエンドクライアントは、register()関数を呼び出し、ドメイン名を所有していることを証明できます。ドメイン名と証明書の公開鍵、そしてその逆をマッピングし、この情報を保存します。

   3. クライアントを通してトランザクションが作成されるとき、それはまた、その証明書公開鍵でトランザクションロードに署名します。この情報はまとめられ、アプリケーションのスマートコントラクトに渡される。

   4. アプリのスマートコントラクトは証明書を検証し、それが正しいトランザクション件名に対応し、登録されているかどうかを確認する。そうであれば、取引が処理される。トランザクションによって生成された手数料は、ドメイン情報（レジストリから）とともにFeeCollectorコントラクトに送信される。

   5. FeeCollectorは、セットアップ担当者、ユーザー、検証者などが、ドメインまたはドメイングループに対して直接トークンを誓約することを可能にします。これらの契約は、各ドメインで誓約されたトークンの数、その誓約の各アドレスのシェア、および誓約された期間を追跡する必要があります。一般的な流動性マイニングの実装は、このコントラクトロジックの出発点として使用できます。

   6. セッターに誓約した（または手数料管理契約自体に直接誓約した）ユーザーは、その後、ドメインに誓約されたアプリケーショントークンの数に基づいて、手数料の対応するシェアを引き出すことができます。

   

   このアプローチは、アプリケーションDAOのガバナンス負担を増やすことなく導入することができます。実際、手数料スイッチはプロトコルによって促進されるすべてのトランザクションに対して恒久的にオンにすることができ、プロトコルの経済モデルに対するDAOのコントロールを取り除くことができるため、ガバナンスの負担は軽減されるかもしれません。

   アプリの種類に基づく追加の考慮事項

   これらの原則は、アプリのトークン経済モデルに広く適用されますが、アプリの種類によっては、考慮すべき他のコストが発生する可能性もあります。ティア1やティア2で構築されたアプリ、アプリチェーン、ロールアップを使用して構築されたアプリなどです。

   L1/L2 app considerations

   レイヤー1またはレイヤー2のブロックチェーン上に構築されたアプリは、スマートコントラクトをチェーン上に直接展開します。スマート・コントラクトをチェーン上に直接展開します。ユーザーがアプリケーションのスマート・コントラクトとやり取りすると、手数料が課金される。これは通常、リテール・ユーザーと基礎となるスマート・コントラクトの間のインターフェースとして機能する、使いやすいフロントエンド（アプリケーションやウェブサイトなど）を通じて行われる。この場合、手数料はすべてそのフロントエンドから発生します。上記のapp.xyzの例は、ティア1アプリの料金システムがどのように機能するかを示しています。

   アプリは、キュレーターに頼らずにフロントエンドの手数料をフィルタリングすることもできますし、ネットワーク手数料に貢献するフロントエンドに対してホワイトリストまたはブラックリストのアプローチを取ることもできます。ここでの目標は、トークン保有者とプロトコル全体が違法行為から利益を得たり、利益を得たりしないようにすることであり、法域固有の法律や規制を遵守することに変わりはありません。

   ホワイトリスト方式では、アプリはフロントエンドのルールを公開し、ルールに準拠するフロントエンドのレジストリを作成し、オプトインしたものに証明書を発行し、アプリの手数料の一部を受け取るためにフロントエンドにトークンの誓約を要求する。フロントエンドがこれらのルールに従わない場合は、削減され、手数料拠出証明書が取り消される。

   ブラックリスト方式では、アプリはルールを作成する必要はないが、アプリを起動するフロントエンドはパーミッションレスではない。その代わり、アプリケーションは、フロントエンドがアプリケーションを使用できるようにする前に、フロントエンドがその管轄区域のコンプライアンスを満たしていることを証明する法律事務所からの意見を提供するよう、あらゆるフロントエンドに要求する。意見書を受け取ると、アプリはフロントエンドに手数料拠出証明書を発行し、フロントエンドがコンプライアンスに適合していないという通知をアプリが規制当局から受け取った場合のみ、その証明書は取り消される。

   手数料の経路は、前のセクションで提供された例を反映しています。

   これらのアプローチはどちらも、DAOが一連のルールを作成して維持するか、コンプライアンスに関する法的見解を評価する必要があるため、分散型ガバナンスの負担を大幅に増加させます。場合によっては、これは受け入れられるかもしれませんが、ほとんどの場合、このコンプライアンスの負担を設定者にアウトソーシングすることが望ましいです。

   Application Chain Considerations

   アプリケーションチェーンは、バリデータがそのアプリケーションに対してのみ機能する、アプリケーション固有のブロックチェーンです。

   バリデーターはその仕事の見返りとして支払いを受ける。一般的にバリデーターはトークンのインフレ発行に基づいて報酬を受け取るレイヤー1ブロックチェーンとは異なり、一部のアプリチェーン（dYdXなど）は顧客手数料をバリデーターに渡す。

   このモデルでは、トークン保有者は報酬を受け取るためにバリデータに誓約しなければならない。バリデータは誓約のために設定されたモジュールとなる。

   この作業設定はレイヤー1バリデータとは異なる。アプリケーションチェーンバリデータはアプリケーション固有のトランザクションを解決する。この違いにより、アプリケーションチェーンバリデ ータは、自らが促進する根本的な活動に関連する、より高度な法的リスクを負う可能性がある。したがって、プロトコルはバリデータに、その法域の法律とバリデータ自身の快適なレベル に従って業務を遂行する自由を与えるべきである。重要なことは、バリデータのセットが地理的に分散している場合、アプリケーションチェーンの無許可の性質を危険にさらしたり、検閲の重大なリスクにさらしたりすることなく、これを行うことができるということです。

   料金トレーサビリティの利点を利用したいアプリケーションチェーンは、料金チャネルに至るまで、ティア1アプリと同様のアーキテクチャになります。ただし、バリデータはフロントエンドマッピングを使用して、どのトランザクションをどのフロントエンドから処理するかを決定できるようになる。どのトランザクションの手数料も、アクティブなバリデーターに流れ、参加しないことを選択した非アクティブなバリデーターは手数料を受け取ることができない。手数料の観点からは、バリデータは前述したプレッジモジュールのセッターと同じ機能を果たす。バリデータはまた、各法域においてどのフロントエンドが適合しているかを決定するキュレーターを選出することもできる。

   App Summary Considerations

   ロールアップは独自のブロックスペースを持ちますが、別のチェーンのセキュリティを継承することができます。今日、ほとんどのロールアップは、トランザクションの順序付けと包含を担当する単一のシーケンスジェネレーターを持っていますが、トランザクションは「強制包含」と呼ばれるプロセスを通じてレイヤー1に直接提出することができます。

   これらのロールアップがアプリケーション固有のものであり、そのシーケンスジェネレーターを固有のバリデーターとして確立する場合、そのシーケンスジェネレーターに含まれるトランザクションによって発生する手数料は、一連のコンプライアンスフロントエンドに基づいて、または共通のプールとして、プレッジャーに割り当てることができる。

   ロールアップがシーケンスジェネレーターのセットを分散化する場合、シーケンスジェネレーターは事実上のセット誓約モジュールとなり、手数料パイプラインはアプリケーションチェーンを反映することになる。シーケンスジェネレータは、料金割り当てのためのバリデータに取って代わり、各シーケンスジェネレータは、どのフロントエンド料金を受け入れるかを自身で決定することができます。

   アプリトークンにはさまざまなモデルが考えられますが、管理されたプレッジプールを提供することは、アプリ特有の外在的な課題に対処するのに役立つ前進の道です。アプリが直面する内在的・外在的な課題を認識することで、創設者は自分のプロジェクトのためのアプリトークンモデルをゼロからよりよく設計することができます。

   謝辞：このプロジェクトを始めてくれたポーター・スミスに感謝します。

   ここに記載された見解は、AH Capital Management, L.L.C. （以下、「a16z」）の各担当者の個人的見解であり、a16zまたはその関連会社の見解ではありません。(「a16z」)の見解であり、a16zまたはその関連会社の見解ではありません。