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

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

---

序文

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

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

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

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

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

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

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

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

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

---

Tierによる分類

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

Treasury資金: 適切

プロトコル動作に必須：

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

---

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

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

このTierにおいては、「件数上限」と「予算上限」を適応します。これがなければ、すべての言語、フレームワーク、ツールセットが「重要インフラ」ステータスを主張し、無制限のTreasury依存を生み出します。

Tier 2a: Essential Infrastructure

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

エコシステム機能に不可欠で、市場資金調達が合理的に不可能なインフラであると判断できるもの。

含まれるもの:

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

要件（すべて必須）:

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

---

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

Treasury資金: 不適切 – 市場資金のみ（トレジャリーからの資金提供の対象としては不適格。市場原理による資金調達を強く推奨する）

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

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

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

---

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

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

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

---

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

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

Step 1: 分類 → コア成果物によってTierを決定

Step 2: 要件確認

• Tier 1: 憲法遵守
• Tier 2: すべての要件 + 数量制限
• Tier 3/4: 市場資金（自動的にNO）

Step 3: 投票

• 要件を満たし制限内 → YES検討
• それ以外 → NO

---

なぜ厳格な制限が重要か

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

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

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

---

主要な区別

Reference (Tier 2a) vs Alternatives:

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

Essential (Tier 2a) vs Convenient (Tier 3):

• Essential: 言語に依存しない、プロトコル重要、代替なし
• Convenient: 言語特化、生産性向上、代替あり

---

長期的解決策

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

Tier 1はプロトコル開発のための予算配分を受ける
Tier 2は数量上限付きの重要インフラのための限定配分を受ける
Tier 3/4はTreasury資金を禁止される

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

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

---

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