Version: 1.0.0
Author: Hix (COFFE/KISSA DRep)
日本語版はこちら→https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem-jp/
Preface
As a DRep, I recognize that the current Net Change Limit (NCL) structure presents a fundamental governance challenge.
The NCL establishes only a total spending cap without any category-based budget allocation. This means any proposal, whether for core protocol development or optional developer tooling, competes within the same undifferentiated pool of resources. Without clear boundaries, “essential infrastructure” becomes a claim any project can make, and there is no systematic mechanism to prevent similar proposals from proliferating indefinitely.
This structural deficit creates a scenario where Treasury spending operates as a first-come-first-served system, allowing Tier 2 and Tier 3 proposals to expand without limit. This results in a lack of strategic resource allocation, and the Treasury risks becoming an unlimited funding pool for any plausible claim, regardless of whether market funding would be more appropriate.
I strongly believe the Cardano community should establish category-based NCL allocation, likely through Constitutional Amendment.
Each Tier should have an explicit budget allocation within the NCL. Without this enforcement at the protocol level, quantity limits cannot be systematically applied, competitive selection remains ad-hoc, and Treasury dependency will continue to expand without bounds.
Voting Method without Tier Distribution (right now)
Until such constitutional category budgets exist, I apply exceptionally strict evaluation criteria to all Treasury Withdrawal Governance Actions.
This strict approach is necessary under two conditions:
first, when category-based budget allocation within NCL does not exist (our current reality)
second, when the NCL budget significantly exceeds on-chain revenue, creating unsustainable spending patterns.
My voting framework prioritizes long-term ecosystem sustainability over short-term project funding, even when individual proposals demonstrate clear technical merit.
This framework provides interim discipline through clear Tier definitions with explicit quantity limits, strict requirements for any Tier 2 consideration, rejection of proposals that would set unlimited precedent, and protection of market mechanisms for Tier 3 and 4 infrastructure. Without this discipline, the boundary between what Treasury should fund and what the market should fund will erode completely, ultimately harming the ecosystem’s economic health and competitive positioning.
Tier Classification
Tier 1: Pure Protocol (appropriate)
Treasury Funding: Appropriate
Essential for protocol operation:
- Consensus algorithm research & development
- Cryptography foundation
- Ledger rules & specification
- Hard fork implementation
Tier 2: Critical Infrastructure (conditional)
Treasury Funding: Conditional (strict requirements + quantity limits)
Without quantity caps, every language, framework, and toolset will claim “critical infrastructure” status, creating unlimited Treasury dependency.
Quantity: Maximum 2-3 projects
Infrastructure essential for ecosystem function that cannot reasonably be market-funded.
Includes:
– Reference node implementation (ONE only): Defines protocol specification in executable code and serves as the standard for all other implementations.
– Core protocol libraries (competitive RFP, max 2-3): Libraries that implement protocol specifications and require hard-fork updates. Must be language-agnostic and serve the entire ecosystem, not a single programming language.
– Alternative Node implementation (client diversity): Only 2nd implementation in a ROI perspective. The budget should be allocated via competitive Request-For-Proposal.
– Essential governance tooling (competitive selection, max 1-2): Tools that most DReps depend on to fulfill constitutional duties.
The test: would governance function without it? If merely convenient rather than essential, belongs in Tier 3.
Requirements (ALL mandatory):
– Ecosystem-wide necessity (not language-specific)
– Protocol-dependent or governance-critical
– No viable market-funding alternative
– Competitive Request-For-Proposal selection within a limited budget
– Time-limited (1-2 years max)
– Market transition plan required
Tier 3: Optional Infrastructure
Treasury Funding: Inappropriate – Market-funding only
Useful but not essential; alternatives exist:
- 3rd+ node implementations
- Language-specific libraries
- Developer tools
- Explorers, indexers, APIs
Market sources: VC, SPO consortiums, sponsorships, subscriptions
Tier 4: Application Layer
Treasury Funding: Inappropriate – Market only
User-facing services: dApps, wallets, services
Evaluation Process under No NCL distribution plan
Under current NCL condition (without any distribution plans), I will vote throughout the evaluation flows below.
Step 1: Classify → Determine Tier by core deliverables
Step 2: Check Requirements
- Tier 1: Constitutional compliance
- Tier 2: ALL requirements + quantity limits
- Tier 3/4: Market funding (automatic NO)
Step 3: Vote
- Requirements met + within limits → Consider YES
- Otherwise → NO
Why Strict Limits Matter?
While Tier2 category looks necessary for Treasury funding, Tier 2 infrastructure expands indefinitely without budget limits and quantity caps. Every programming language can claim its libraries are “essential infrastructure,” and every additional node implementation can argue it adds “critical diversity.” There is no natural stopping point (the category grows until it encompasses nearly all development tooling), defeating the purpose of having tiers at all.
Budget limits and Quantity caps create clear boundaries. The reference implementation is singular by definition: only one implementation can serve as the authoritative standard. A second node implementation establishes client diversity, but a third provides sharply diminishing returns. Language-specific libraries, no matter how useful, belong in Tier 3 because approving one language creates precedent for approving all languages. Developer tools follow the same logic—if the market values them, the market will fund them.
These boundaries are not arbitrary restrictions. They reflect the economic reality that Treasury funding crowds out private investment, and that clear limits are the only mechanism preventing uncontrolled expansion when constitutional category budgets do not yet exist.
Key Distinctions
Reference (Tier 2a) vs Alternatives:
- Reference: ONE, defines specification
- 2nd: ONE, client diversity
- 3rd+: Market funding
Essential (Tier 2a) vs Convenient (Tier 3):
- Essential: Language-agnostic, protocol-critical, no alternative
- Convenient: Language-specific, productivity, alternatives exist
Long-term Solution
The Cardano community should pursue a Constitutional Amendment establishing Treasury category limits.
Tier 1 would receive budget allocation for protocol development
Tier 2 would receive limited allocation for critical infrastructure with quantity caps
Tier 3/4 would be prohibited from Treasury funding. Specific allocation percentages and enforcement mechanisms should be determined through community discussion and the governance process.
This framework serves as interim discipline until such structural limits are constitutionally implemented.
**Disclaimer:** This represents my evaluation criteria as a DRep. Other DReps may apply different criteria. Provided for transparency and consistency.
