DRep投票フレームワーク：持続可能なエコシステムのために

バージョン: 1.1.0 (Draft)
著者: Hix (COFFE/KISSA DRep)

v1.1からの変更点:

• 適切なNCLとして、前年に分配されたステーク報酬の15％を設定

v1.0からの変更点:

• Tier 2を3つのサブTier（2a、2b、2c）に再構成
• Tier 2b（Protocol Extensions）を新設
• Tier 2c（学術研究・基礎研究）を新設
• 研究（Research）と実装（Implementation）の区別を導入

English version→ DRep Voting Framework for Sustainable Ecosystem

序文

現在のNet Change Limit（NCL）構造は根本的なガバナンス上の課題を抱えています。

NCLは総支出上限のみを設定しており、カテゴリ別の予算配分は一切ありません。これは、コアプロトコル開発であろうと任意の開発者ツールであろうと、あらゆる提案が同じ未分化のリソースプール内で競争することを意味します。明確な境界がなければ、「必須インフラ」はあらゆるプロジェクトが主張できる言葉となり、類似提案が無限に増殖することを防ぐ体系的メカニズムは存在しません。

この構造的欠陥により、Treasury支出は先着順システムとして機能し、Tier 2とTier 3の提案が制限なく拡大することを許してしまう可能性を秘めています。その結果、戦略的な資源配分をすることが難しく、市場での資金調達をする方が適切な場合であっても、もっともらしい主張に対して資金を提供する「打ち出の小槌」となるリスクを抱えています。

私は、カルダノコミュニティでの合意のもと、「カテゴリ別のNCL配分」を確立すべきだと考えています。より強制力を持つために、最終的には憲法修正を通じて実現することが望ましいでしょう。

各Tierは、NCL内で明示的な予算配分を持つべきです。プロトコルレベルでのこの強制がなければ、数量制限を体系的に適用することはできず、競争的選定はその場しのぎのままであり、Treasury依存は際限なく拡大し続けます。

適切なNCLの基準

NCL（Net Change Limit）は、1年間にトレジャリーから引き出せるADAの上限を定めるパラメータです。この数値をどう設定するかは、カルダノの財政健全性に直結します。
私は、NCLの上限を「前年のステーキング報酬として市場に流れたADAの15%程度」とすることが適切と考えます。

根拠となるデータ（CIP-1694以降）

ガバナンス開始（2024年9月）から2026年5月までの約1年8ヶ月で、ステーキング報酬として₳915Mが市場に流通しました。同期間のトレジャリー出金は₳414M — つまりステーク報酬だけの場合と比較して、45%多いADAが放出されたことになります。
この「上乗せ分」が直接的な売り圧として機能するだけでなく、「今後いくら出金されるかわからない」という不確実性が機関投資家や大口の参入を抑制している可能性があります。

インフレの観点で数値を設定

PoSネットワークにおけるステーキング報酬は、市場参加者が織り込んだインフレです。トレジャリー出金はその上に乗る追加希釈であり、市場が織り込んでいない分の希釈となります。
2025年データ（流通量: 約36.2B ADA、ステーク報酬: 約₳548M）をもとに試算すると：

シナリオ	年間放出	実効インフレ率	インフレ加速率
ステーク報酬のみ（織り込み済み）	548M ADA	1.51%	baseline
2025年報酬の15%（₳82M）	630M ADA	1.74%	+15%
2025年実績ペース ₳277M	825M ADA	2.28%	+51%
NCL全て引き出した場合（₳350M）	898M ADA	2.48%	+64%

※ インフレ加速率 = ステーク報酬のみ（baseline）に対するインフレ率の増加割合

2025年の実績ペースでは、ADAの実効インフレ率がステーク報酬のみの場合と比べて51%加速しました。BTCは供給量が固定されているため、この追加希釈はADA/BTCに直接反映されます。同期間のADA/BTCは-48.7%下落しており、この数字と無関係ではないと考えます。

2026年におけるNCL（引き出し上限）の数値

2025年のステーキング報酬（₳548M）を基準にすると、15%は約₳82M/年です。本フレームワークでは、この₳82Mを2026年における「妥当なNCL」として適用します。

現在の執行ペース（2025年: ₳277M）と比べると3分の1以下ですが、予測可能で規律ある財政運営こそが、長期的なADAへの信頼と価値の安定につながると考えています。

Tier配分のない現状での投票方法

このような憲法上のカテゴリ別予算が存在するまで、私はすべてのトレジャリー引き出しガバナンスアクションに対して厳格な評価基準を適用します。

この厳格なアプローチは、2つの条件下で必要となります。 第一に、NCL内にカテゴリ別予算配分が存在しない場合（現在の現実） 第二に、NCL予算がオンチェーン収益を大幅に上回り、持続不可能な支出パターンを生み出している場合

私の投票フレームワークは、個別提案が明確な技術的メリットを示している場合でも、短期的なプロジェクト資金よりも長期的なエコシステムの持続可能性を優先します。

このフレームワークは、明確なTier定義と明示的な数量制限、Tier 2検討のための厳格な要件、無制限の前例を作る提案の拒否、そしてTier 3および4インフラに対する市場メカニズムの保護を通じて、暫定的な規律を提供します。この規律がなければ、Treasuryが資金提供すべきものと市場が資金提供すべきものの境界は完全に侵食され、最終的にエコシステムの経済的健全性と競争力を損なうことになります。

研究（Research）と実装（Implementation）の区別

Treasury資金の評価においては、研究スコープと実装スコープを区別する必要があります。両者は経済的特性が根本的に異なるためです。

研究（Research）スコープ: 公共財的性質を持つ知識生産（論文、証明、仕様、プロトタイプ、CPS）。Tier 2cで評価され、公共財の論理によりTreasury資金が正当化されます。

実装（Implementation）スコープ: プロダクション可能なコード、ユーザー向けプロダクト、運用インフラ。標準的なTier分類（1、2a、2b、3、4）で評価されます。

基礎研究は、非排他性、不確実性、正の外部性、規模の経済という4つの特徴により、典型的な「市場の失敗」領域です。Cardanoがresearch-drivenなブロックチェーンとしての競争力を維持するためには、学術研究への持続的な投資が不可欠であり、これは合理的な時間軸では市場資金で代替することができません。

この区別により、長期的研究への投資不足と、市場資金で対応可能な実装への過剰投資の両方を防ぐことができます。

Tierによる分類

Tier 1: 純粋にプロトコルに関する提案（適切）

Treasury資金: 適切

プロトコル動作に必須：

• Consensus algorithmの研究開発
• Cryptography基盤
• Ledger rules & 仕様
• Hard fork実装

Tier 2: 重要なインフラに関する提案（条件付き）

Tier 2は、対象となる作業の性質によって3つのサブTierに分かれます。

Tier 2a: リファレンス & 必須実装

Treasury資金: 条件付きで判断（厳格要件 + 件数制限）

エコシステム機能に不可欠で、市場資金調達が合理的に不可能なインフラ。

数量: 最大2-3プロジェクトまで

含まれるもの:

• リファレンスノード実装（1つのみ）: プロトコル仕様を実行可能コードで定義し、他のすべての実装の標準として機能する。
• コア・プロトコル・ライブラリー（競争的RFP、最大2-3）: プロトコル仕様を実装し、hard-fork更新を必要とするライブラリ。言語に依存せず、単一のプログラミング言語ではなくエコシステム全体に貢献する必要がある。
• 複数ノード（client diversity）: ROIの観点から2番目の実装のみ。予算は競争的Request-For-Proposalを通じて配分される。
• 必須ガバナンスツール（競争的選定、最大1-2）: ほとんどのDRepが憲法上の義務を果たすために依存するツール。判定基準：これがなければガバナンスは機能するか？単に便利なだけであれば、Tier 3に分類される。

要件（すべて必須）:

• エコシステム全体への必要性（言語特化でない）
• プロトコル依存またはガバナンス重要
• 実行可能な市場資金調達の代替手段がない
• 限定予算内での競争的Request-For-Proposal選定
• 期限付き（最大1-2年）
• 市場移行計画が必要

Tier 2b: プロトコル拡張

Treasury資金: 条件付きで判断（厳格要件 + 件数制限）

ユーザーや開発者がプロトコルにアクセスするためのツール・インフラ。実装作業が対象であり、研究（Tier 2c）とは区別されます。

数量: 最大2-3プロジェクトまで

例示（網羅的ではない）:

• スマートコントラクト実行レイヤー（例：Plutus）
• ZK検証インフラ
• ガバナンスツール（例：投票インターフェース）
• リファレンス・ウォレット実装（保険的措置のみ。エコシステムにウォレットが存在しない場合に限る）

Tier 2bに該当するかは、以下の要件によって決定されるものであり、固定されたリストによって決定されるものではありません。エコシステムの進化とともに、新しいカテゴリのプロトコル・アクセシビリティ・ツールが登場する可能性があります。

要件（すべて必須）:

• エコシステム全体への必要性（言語特化やアプリケーション特化でない）
• ユーザーまたは開発者がコアプロトコル機能にアクセスするために必要
• 必要な品質水準で実行可能な市場資金調達の代替手段がない
• 複数の能力ある提供者が存在する場合は競争的Request-For-Proposal選定
• First-mover exception: 分野が新規で比較可能な実装が存在しない場合、初回イテレーションについては単一組織への資金提供を許容する。後続のイテレーションは競争的選定に移行しなければならない。
• 期限付き
• 市場移行計画が必要

Tier 2aとの区別:

• Tier 2a: プロトコルまたはガバナンスが機能するために必要なインフラ（reference node、alternative node、core libraries、essential governance tooling）
• Tier 2b: ユーザーや開発者がプロトコル機能にアクセスするために必要なインフラ

Tier 2c: 学術研究・基礎研究

Treasury資金: 条件付きで判断（厳格要件 + 定期的評価）

公共財的性質を持つ基礎研究および応用研究。アウトプットは知識成果物（査読済み論文、形式的証明、仕様、理論的フレームワーク、検証用プロトタイプ、CPS）であり、プロダクション可能なコードやユーザー向けプロダクトではありません。

Treasury資金が適切な理由:
基礎研究は典型的な「市場の失敗」領域です。Cardanoがresearch-drivenなブロックチェーンとしての競争力を維持するためには、学術研究への持続的な投資が必要不可欠であり、これは長期的な時間軸、公共財的性質、正の外部性を内部化できないという理由から、市場資金で代替することができません。

要件（すべて必須）:

1 – 研究の目的

• 研究提案は、カルダノエコシステムに関連したものであること

2 – 定期的な予算サイクル

• 研究予算は定められた間隔で評価される（年次、隔年、またはプロジェクト単位）
• 自動継続はなく、各サイクルごとに新規のガバナンスアクションが必要

3 – 継続には実質的な価値の証明が必要

• サイクルをまたぐ継続的な資金提供は自動的なものではない
• 各新規サイクルは、過去のサイクルの実質的な価値（論文、CPS、CIP、プロトタイプ）によって正当化されなければならない。過去に資金提供を受けていたという事実のみでは正当化されない
• 過去のアウトプットは公開検証可能でなければならない

4 – 予算の妥当性

• Work Package別および人員配分の詳細な内訳
• 学術業界標準と比較した一人当たりコスト
• 過去の資金提供サイクルとの比較（該当する場合）
• 現在の準備金を踏まえた累積的なTreasury影響

5 – 研究と実装の分離

• 研究予算と実装予算は、提案の構造において明確に分離されなければならない
• 提案は、どの部分が研究スコープでどの部分が実装スコープかを明示的に記述しなければならない
• 研究成果が実装段階に成熟した場合、その実装はTier 1またはTier 2bの別途提案として資金提供されるべきであり、Tier 2cの枠で継続されるべきではない

数量上限についての注記:
NCL（現在は1エポック区間あたり350M ADA）に紐づけた固定的なパーセンテージ上限を設定することは、個別提案の絶対的な妥当性を見えにくくする可能性があります。現在のNCL自体が最適値より大きい可能性があり、それを個別提案の評価基準とすることは、過剰支出を常態化させるリスクを伴います。DRepは、各Tier 2c提案を個別の要素に基づいて評価することが望ましいです。

Tier 3: 付属的なインフラに関する提案

Treasury資金: 不適切 – 市場資金のみ

有用だが必須ではない。代替手段が存在する：

• 3番目以降のnode implementations
• 言語特化ライブラリ
• 開発者ツール
• Explorers、indexers、APIs

市場資金源: VC、SPOコンソーシアム、スポンサーシップ、サブスクリプション

Tier 4: ユーザー向けのサービスやアプリケーション

Treasury資金: 不適切 – 市場原理による資金調達が適切

ユーザー向けサービス：dApps、ウォレット、サービス

NCL配分計画がない場合(現状)の評価プロセス

現在のNCL条件下（配分計画なし）では、以下の評価フローに従って投票します。

Step 1: 分類

• 提案が研究スコープか実装スコープかを判別する
• どのTier（1、2a、2b、2c、3、4）に該当するかを判別する

Step 2: 要件確認

• Tier 1: 憲法遵守
• Tier 2a、2b: それぞれの全要件 + 数量制限
• Tier 2c: 全要件 + 定期的評価
• Tier 3/4: 市場資金（自動的にNO）

Step 3: 投票

• 要件を満たし制限内 → YES検討
• 要件を部分的に満たす → 留保条件を明記した条件付きYES、またはAbstain
• それ以外 → NO

なぜ厳格な制限が重要か

Tier 2カテゴリはTreasury資金として必要に見える一方で、予算制限と数量上限がなければTier 2インフラは無限に拡大します。すべてのプログラミング言語がそのライブラリを「必須インフラ」と主張でき、すべての追加node implementationが「重要な多様性」を追加すると主張できます。自然な停止点は存在せず（カテゴリはほぼすべての開発ツールを包含するまで成長し）、Tierを持つ目的そのものを無効化します。

予算制限と数量上限は明確な境界を作ります。Reference implementationは定義上単一です。権威ある標準として機能できる実装は1つだけです。2番目のnode implementationはclient diversityを確立しますが、3番目は収穫逓減をもたらします。言語特化ライブラリは、どれほど有用であっても、1つの言語を承認することがすべての言語を承認する前例を作るため、Tier 3に属します。開発者ツールも同じロジックに従います。市場がそれらを評価するなら、市場が資金提供します。

研究（Tier 2c）については、規律の形が異なります。定期的なサイクル、実質的な価値の証明に基づく更新、実装との明確な分離が規律として機能します。研究は知識を生産するものであり、製品を生産するものではなく、また基礎研究には長期的な時間軸が必要であるため、実装と同じように数量上限を設けることはできません。しかし、定期的な評価と実質的な成果物の査定により、path dependency（経路依存性）を防ぎ、研究資金が真の価値に結びつくことを担保します。

これらの境界は恣意的な制限ではありません。Treasury資金が民間投資をクラウドアウトするという経済的現実を反映しており、憲法上のカテゴリ予算がまだ存在しない場合、明確な制限が制御不能な拡大を防ぐ唯一のメカニズムです。

主要な区別

Reference (Tier 2a) vs Alternatives:

• Reference: 1つ、仕様を定義
• 2nd: 1つ、client diversity
• 3rd+: 市場資金

Essential (Tier 2a) vs Protocol Extension (Tier 2b):

• Essential: プロトコルまたはガバナンスが機能するために必要
• Protocol Extension: ユーザーや開発者がプロトコル機能にアクセスするために必要

実装 (Tier 2a/2b) vs 研究 (Tier 2c):

• 実装: プロダクションコード、ユーザー向けまたは運用基盤
• 研究: 知識成果物、論文、検証用プロトタイプ

Tier 2b vs Tier 3:

• Tier 2b: 言語に依存せず、プロトコルへのアクセスに必要、必要な規模で市場の代替手段がない
• Tier 3: 言語特化または利便性向上、代替手段が存在する

長期的解決策

Cardanoコミュニティは、Treasuryカテゴリ制限を確立する憲法修正を追求すべきです。

• Tier 1はプロトコル開発のための予算配分を受ける
• Tier 2aおよび2bは数量上限付きの重要・アクセシビリティインフラのための限定配分を受ける
• Tier 2cは定期的評価のもとで学術研究のための専用配分を受ける
• Tier 3および4はTreasury資金を禁止される

具体的な配分パーセンテージと強制メカニズムは、コミュニティの議論とガバナンスプロセスを通じて決定されるべきです。

このフレームワークは、このような構造的制限が憲法上実装されるまでの暫定的な判断基準として使用します。

フレームワークの位置づけ: これはあくまでフレームワークであり、Tier 1やTier 2の範囲内だからといって自動的に賛成するものではありません。各提案はフレームワークを参照しつつ、その都度、独自の判断によって投票を行います。

免責事項: これは、DRepとしての私の評価基準を表しています。他のDRepは異なる基準を適用する場合があります。透明性と一貫性のため、ここに評価基準を公表しています。

バージョン履歴:

v1.1.0 (2026-XX-XX): Tier 2b（Protocol Extensions）、Tier 2c（学術研究・基礎研究）、および研究と実装の区別を追加

v1.0.0 (2026-04-11): 初版