a16z：アプリケーショントークンはどのようにキャッシュフローを生む財務モデルを構築するのか？

2024.08.12

共有先

TechFlow厳選深潮セレクト

a16z：アプリケーショントークンはどのようにキャッシュフローを生む財務モデルを構築するのか？

アプリケーションのトークンビジネスモデルは、その基盤となるソフトウェアと同様に表現力を持つべきである。

2024.08.12 - 04:33:38

Web3業界の深掘り報道に専念し潮流を洞察

アプリケーションのトークンビジネスモデルは、その基盤となるソフトウェアと同様に表現力を持つべきである。

著者：Mason Hall、Porter Smith、Miles Jennings、Ross Shuel

翻訳：TechFlow

インフラストラクチャトークン、たとえばLayer1ネットワーク（またはLayer2などコンピューティングスタックの近接部分）については、ブロック空間の需給関係に基づく経済モデルがすでに比較的成熟しており、理解しやすい。しかし、「分散型ビジネス」において権利を付与するサービスを展開するアプリケーショントークン、すなわちブロックチェーン上にデプロイされたスマートコントラクトプロトコルについては、その経済モデルは依然として模索の段階にある。

アプリケーショントークンのビジネスモデルは、基盤となるソフトウェアと同様に表現力を持つべきである。 そのため我々はアプリケーショントークンのキャッシュフローモデルを提案する――これは、アプリケーションが柔軟で緩やかな経済モデルを構築できるようにしつつ、ユーザーが提供する価値に応じて報酬を受け取る方法を選択できるようにする手法である。このアプローチは、さまざまな法域における規制要件のもとで合法的な活動を通じて収益を得ることで、より高いコンプライアンスを促進する。同時に、プロトコルが蓄積する価値を最大化し、ガバナンスの最小化を推進する。

ここで紹介する原則は、分散型金融（DeFi）から分散型ソーシャルアプリ、分散型物理インフラネットワーク（DePIN）など、すべてのWeb3アプリケーションに適用される。

トークンモデルが直面する課題

インフラストラクチャトークンは内生的な需給関係の影響を受ける：需要が高まれば供給が減少し、市場がそれに応じて調整される。 このような経済的基盤は多くのインフラストラクチャトークンで強化されており、特にイーサリアム改善提案1559（EIP-1559）によって、すべてのイーサリアム取引にかかる基本料金の焼却メカニズムが導入されている。しかし、いくつかの「購入・焼却（buy-and-burn）」モデルの試みはあるものの、アプリケーショントークンにはEIP-1559に匹敵するメカニズムが存在しない。

アプリケーションはブロック空間の利用者であり、提供者ではないため、他のユーザーからガス料金を徴収するという依存関係を持てない。これが、独自の経済モデルを開発する必要性につながる。

法的課題も存在する：インフラストラクチャトークンの経済モデルは、典型的なブロックチェーン取引の汎用性とプログラムによるメカニズムにより、法的リスクに対して比較的強くできている。一方、アプリケーショントークンの経済モデルでは、規制対象の活動を促進する可能性があり、ガバナンストークン保有者の仲介が必要になる場合がある――これにより、経済モデルはより複雑になる。米国において、分散型取引所がデリバティブ取引を促進することは高度に規制された行為であり、イーサリアムのようなプロジェクトとは根本的に異なる。

こうした内的・外的な課題が重なる結果、アプリケーショントークンには異なる経済モデルが必要となる。これを踏まえ、我々は一つの解決策を提示する：アプリケーショントークン保有者が提供するサービスに対価を支払い、プロトコル収益を最大化し、コンプライアンスを促進するとともにガバナンスの最小化を実現するプロトコル設計の方法論である。私たちの目標はシンプルだ。キャッシュフローを通じて、多くのインフラストラクチャトークンと同等の経済的基盤をアプリケーショントークンにも提供することである。

本提案は、アプリケーショントークンが直面する以下の3つの課題に焦点を当てる：

ガバナンスに関連する課題
価値分配に関連する課題
規制対象活動に関連する課題

1. ガバナンスに関連する課題

アプリケーショントークンは通常ガバナンス権を有しており、分散型自律組織（DAO）の存在はインフラストラクチャトークンには見られない不確実性をもたらす。 米国で重要な事業活動を行うDAOの場合、もしDAOがプロトコル収益を支配したり、プロトコルの経済活動を仲介してプログラム化してしまうと、リスクが生じる。これらのリスクを回避するため、プロジェクトはガバナンスの最小化により、DAOの支配権を排除できる。それができないDAOにとっては、ワイオミング州の新たな分散型非営利協会（DUNA）という分散型法的エンティティがリスク軽減と税法遵守の助けとなる可能性がある。

2. 価値分配に関連する課題

アプリケーションは、トークン保有者に価値を還元する仕組みの設計において慎重である必要がある。投票権と経済的権利を結合する設計は、米国の証券法上の懸念を引き起こす可能性がある。特に、比例配分やトークンの購入・焼却といった単純で直接的なメカニズムは、配当や自社株買いに類似しており、トークンが株式とは異なる規制枠組みを享受すべきであるという主張を弱めかねない。

プロジェクトはステークホルダー・キャピタリズム――つまり、プロジェクトにとって有益な貢献をしたトークン保有者に報いる仕組み――を探るべきである。多くのプロジェクトは、フロントエンドの運営（Liquityなど）、プロトコルへの参加（Goldfinchなど）、あるいはセキュリティモジュールの一環として担保をコミットすること（Aaveなど）といった積極的な参加を奨励している。ここでの設計空間は非常に広いが、出発点としてよいのは、プロジェクト内のすべてのステークホルダーを洗い出し、どのような行動を奨励すべきかを特定し、そのインセンティブを通じてプロトコル全体で創出できる価値を決定することである。

簡素化のため、本稿ではガバナンス参加に対して報酬を与えるシンプルな補償モデルを仮定するが、他にも代替案は存在する。

3. 規制対象活動に関連する課題

規制対象の活動を促進するアプリケーションは、トークン保有者の価値蓄積メカニズムを設計する際にも注意を払う必要がある。 もしこれらのメカニズムが、適用法を遵守するフロントエンドやAPIを通じて価値を蓄積しなければ、トークン保有者は違法活動から利益を得ることになってしまう。

この問題に対する多くの提案は、米国で許可された活動に価値蓄積を制限することに集中している――例えば、特定資産の流動性プールでのみプロトコル手数料を有効化するなど。これによりプロジェクトは「最低共通分母的」な規制に縛られ、グローバルな自律ソフトウェアプロトコルとしての価値主張が損なわれる。また、これはガバナンスの最小化努力を直接的に弱める。どの料金戦略が規制適合的かを判断するのは、DAOの適切な任務ではない。

理想としては、プロジェクトは法的に許容されるあらゆる管轄域から手数料を得ることができ、DAOにその可否の判断を委ねる必要がない状態を目指すべきである。解決策は、プロトコルレベルでのコンプライアンスを求めることではなく、プロトコルが生成する手数料が、フロントエンドやAPIの発信元が適用法および規制を遵守している場合にのみ伝達されるようにすることである。米国があるアプリが促進する取引の手数料徴収を違法とすれば、世界の他の地域で完全に合法であっても、そのアプリのトークン経済価値はゼロにまで下がる可能性がある。手数料の蓄積と分配における柔軟性こそが、規制圧力に直面した際のレジリエンスを意味するのである。

中心的な課題：手数料のトレーサビリティ

非適合フロントエンドからの潜在的リスクに対処する上で、手数料のトレーサビリティは極めて重要である。 しかも、検閲リスクを導入したり、プロトコルをパーミッション型に変えることなく実現しなければならない。トレーサビリティがあれば、アプリケーションはトークン保有者に還元される手数料が、各保有者の管轄域において合法かつコンプライアンスを満たすフロントエンドからのみ発生することを保証できる。もし手数料がトレース不可能であれば、トークン保有者を非適合フロントエンド（つまり非適合フロントエンドが徴収した手数料）から隔離できず、保有者はリスクにさらされることになる。

手数料をトレース可能にするために、プロトコルは二段階のアプリケーショントークンステーキングシステムを採用できる：

第一段階： 手数料発生元のフロントエンドを識別する
第二段階： カスタムロジックに基づき、手数料を異なるプールにルーティングする

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

手数料のトレーサビリティには、ドメイン名から公開鍵/秘密鍵ペアへのマッピングが必要である。 このマッピングがなければ、悪意のあるフロントエンドが取引を偽造し、誠実なドメインから送信されたかのように装うことが可能になる。暗号技術により、フロントエンドを「登録」し、ドメイン名と公開鍵のマッピングを永続的に記録し、そのドメインが実際にその公開鍵を管理していることを証明し、秘密鍵で取引に署名できるようにする。これにより、取引（したがって手数料）を特定のドメインに帰属させることができる。

手数料のルーティング

いったん手数料の発信元がトレース可能になれば、プロトコルはそれらの手数料をどのように分配するかを決定できる。これにより、違法取引からの手数料からトークン保有者を守りつつ、DAOの分散型ガバナンス負担を増やすことなくできる。これを説明するために、アプリケーショントークンのステーキング設計について、各フロントエンドごとに個別のプールを持つケースから、すべてのフロントエンドをまとめる一つのプールまでを想定しよう。

最も単純な構成では、各フロントエンドの手数料を独立した専用ステーキングモジュールにルーティングできる。どのフロントエンドにステークするかを選ぶことで、トークン保有者は自分が受け取る手数料を選び、法的リスクを伴う手数料を避けられる。例えば、トークン保有者は欧州で全規制承認を得たフロントエンドに関連付けられたモジュールにのみステークできる。この設計は単純に思えるが、実際にはかなり複雑になり得る。50のフロントエンドがあれば50のステーキングプールができ、手数料の希釈がトークン価値に悪影響を及ぼす可能性がある。

設計範囲の反対側では、すべてのフロントエンドからの手数料を一括して集約できるが、これは手数料のトレーサビリティの目的に反する。すべての手数料が集約されれば、適合フロントエンドと非適合フロントエンドの手数料を区別できず、一つの「悪いリンゴ」が「バケツ一杯のリンゴ」を台無しにしてしまう。トークン保有者は、「何も受け取らない」か、「非適合フロントエンドの違法活動から利益を得るプールにステークする」かの二者択一を強いられることになる。この選択肢は多くの保有者を参加から遠ざけかねず、あるいは現在の最適でない設計――すなわちDAOがどこで手数料を適用できるかを評価しなければならない状況――に戻ってしまう。

キュレーションによる手数料トレーサビリティの解決

これらの複雑さはキュレーション（策定）によって解決できる。誰でもフロントエンドを作成できる無許可のスマートコントラクトプロトコルアプリケーションを想定しよう。このプロトコルには手数料とトークンがある。各フロントエンドは独自のステーキングモジュールを持つことができる。このプロトコルの一つのフロントエンドをApp.xyzと呼ぶことにする。

App.xyzは所在する法域の特定のコンプライアンスルールに従うことができる。App.xyzでのアプリケーション活動によりプロトコル手数料が発生する。App.xyzは独自のステーキングモジュールを持ち、トークン保有者は直接そのモジュールにステークするか、適合していると考える一連のフロントエンドを個別に選ぶキュレーターにステークできる。これらのステーキング参加者は、ステーク先のフロントエンドが生み出した手数料の形で報酬を得る。あるフロントエンドが100ドルの手数料を生み出し、100のエンティティがそれぞれ1トークンをステークしていれば、各エンティティは1ドルの権利を持つ。キュレーターは当初、そのサービスに対して手数料を請求できる。将来、政府が管轄区域内のフロントエンドのコンプライアンスをオンチェーンで認証することで、消費者保護を助けつつ、自動キュレーションの追加的利点を実現できるかもしれない。

このモデルにおける潜在的リスクとして、非適合フロントエンドの運営コストは、コンプライアンスに伴う管理負担がないため低くなる可能性がある。また、取引者にフロントエンド手数料を還元するモデルを設計し、迂回手段をさらに促進する可能性もある。このリスクは二つの要素で緩和できる。第一に、大多数のユーザーは実際には地方法律を遵守するフロントエンドを望んでおり、特に大規模な規制対象機関では顕著である。第二に、ガバナンスは最終手段または「拒否権」として機能し、繰り返しルール違反を行いアプリの存続能力を脅かす非適合フロントエンドを抑制することで、悪行を抑止できる。

最後に、登録されたフロントエンドを通じて開始されないすべての取引の手数料は、単一の統合ステーキングモジュールに格納され、プロトコルはボットやプロトコルスマートコントラクトに直接インタラクトする取引から生じる収益を獲得できる。

理論から実装へ：手法の実践

アプリケーショントークンスタックをもう少し詳しく振り返ろう。フロントエンドステーキングを促進するために、プロトコルはフロントエンドが登録する登録用スマートコントラクトを設立する必要がある。

各フロントエンドまたはAPIは、ENS DNS統合のように、自身のドメイン名のDNSレコードに特別なTXTレコードを追加できる。このTXTレコードには、フロントエンドが生成した鍵ペアの公開鍵（証明書と呼ぶ）が含まれる。

フロントエンドクライアントはregister()関数を呼び出し、自身がそのドメインを所有していることを証明できる。ドメイン名と証明書の公開鍵のマッピングおよび逆方向のマッピングが保存される。
クライアントが取引を作成するとき、証明書の公開鍵で取引ペイロードに署名する。これらはパッケージ化され、アプリケーションのスマートコントラクトに渡される。
アプリケーションのスマートコントラクトは証明書を検証し、正しい取引主体に対応しており、登録済みかどうかを確認する。問題なければ取引を処理する。取引によって発生した手数料は、その後（登録局から）ドメイン名とともにFeeCollectorコントラクトに送られる。
FeeCollectorは、キュレーターやユーザー、バリデータなどが特定のドメインまたはドメイン群に直接トークンをステークできるようにする。これらのコントラクトは、各ドメインのステーク数量、各アドレスのそのステークにおける割合、ステーク期間を追跡しなければならない。人気のある流動性マイニング実装が、このコントラクトロジックの出発点として利用できる。キュレーターにステークしたユーザー（またはFeeCollectorコントラクトに直接ステークしたユーザー）は、そのドメインにステークされたアプリケーショントークンの量に応じて、対応する手数料の割合を引き出すことができる。このアーキテクチャはMetaMorpho/Morpho Blueに類似している。

この方式は、アプリケーションDAOのガバナンス負担を増やすことなく導入できる。事実、ガバナンス責任はむしろ減少する可能性がある。なぜなら、手数料スイッチはすべてのプロトコル取引に対して恒久的にオンにでき、DAOがプロトコル経済モデルを何らコントロールできなくなるからである。

アプリケーションタイプ別の追加考慮事項

これらの原則はアプリケーショントークン経済モデル全般に広く適用可能だが、アプリケーションの種類（Layer1やLayer2上に構築されたアプリ、アプリチェーン、Rollupを使用して構築されたアプリなど）に応じて、追加の手数料に関する考慮が必要となる場合がある。

L1/L2アプリケーションに関する考慮

Layer1またはLayer2ブロックチェーン上のアプリケーションは、スマートコントラクトを直接オンチェーンにデプロイする。ユーザーがアプリケーションのスマートコントラクトとインタラクトするとき、手数料が課される。通常、このインタラクションは使いやすいフロントエンド（アプリやウェブサイトなど）を通じて行われ、それは一般ユーザーと基盤となるスマートコントラクトの間のインターフェースとして機能する。この場合、いかなる手数料もそのフロントエンドから発生する。前述のapp.xyzの例は、Layer1アプリケーションにおける手数料システムの動作方法を示している。

アプリケーションは、キュレーターに依存する代わりに、フロントエンド手数料をフィルタリングするホワイトリストまたはブラックリスト方式を採用することもできる。目的は、トークン保有者やプロトコル全体が違法活動から利益を得たり恩恵を受けたりしないようにし、特定の法域の法律・規制に従うことである。

ホワイトリスト方式では、アプリケーションがフロントエンドのルールを公表し、これらのルールに従うフロントエンドのレジストリを作成し、参加希望のフロントエンドに証明書を発行し、アプリケーション手数料の一部を得るためにフロントエンドにトークンをステークすることを要求する。フロントエンドがこれらのルールに従わない場合、その手数料への貢献資格が剥奪され、証明書が取り消される。

ブラックリスト方式では、アプリケーションがルールを設定する必要はなく、アプリケーション用のフロントエンド起動プロセスは無許可ではない。代わりに、アプリケーションは任意のフロントエンドが有効化される前に、その管轄域の規定に適合していることを証明する法律事務所の意見書を提出することを要求する。意見書を受領後、アプリケーションはフロントエンドに手数料貢献の証明書を発行し、監督当局からそのフロントエンドが不適合であるとの通知を受けた場合に限り、証明書を取り消す。

手数料パイプラインは前述の例と同様になる。

どちらの方式も分散型ガバナンスの負担を大幅に増加させ、DAOにルールの策定・維持またはコンプライアンスに関する法的意見の評価を求める。ある場合にはこれが許容できるが、ほとんどの場合、コンプライアンス負担をキュレーターに外部委託する方が好ましい。

アプリチェーンに関する考慮

アプリチェーンとは特定のアプリケーション向けに設計されたブロックチェーンであり、バリデータはそのアプリケーションのためにのみ働く。

その業務の対価として、これらのバリデータには報酬が支払われる。バリデータがインフレーショナルなトークン発行によって報酬を得る一般的なLayer1ブロックチェーンとは異なり、一部のアプリチェーン（dYdXなど）では顧客手数料がバリデータに転送される。

このモデルでは、トークン保有者は報酬を得るためにバリデータにステークしなければならない。バリデータは、キュレーションされたステーキングモジュールとなる。

この作業領域はLayer1バリデータとは異なる。アプリチェーンのバリデータは、特定のアプリケーションからの特定の取引を処理する。この違いゆえに、バリデータは促進する活動の性質からより大きな法的リスクを負う可能性がある。したがって、プロトコルはバリデータが所在する法域の法律および自身の許容度に応じて自由に作業を遂行できるようにすべきである。重要なのは、バリデータの地理的分布が分散化されていれば、アプリチェーンの無許可性を損なわず、重大な検閲リスクにさらされることなくこれを実現できることだ。

手数料のトレーサビリティの利点を利用するアプリチェーンアーキテクチャは、手数料パイプラインまではLayer1アプリケーションと同様になる。ただしバリデータはフロントエンドのマッピングを使って、処理したいフロントエンドを決定できる。特定の取引から発生する手数料はアクティブなバリデータセットに分配され、参加を選ばない非アクティブバリデータはこれらの手数料を逃す。手数料の観点からは、バリデータは前述のステーキングモジュールのキュレーターと同じ機能を果たし、これらのバリデータにステークした参加者は違法活動からの収入を得ないことを保証できる。バリデータはさらに、それぞれの管轄域内でどのフロントエンドがコンプライアンスを満たしているかを決定するためにキュレーターを選択できる。