Status
Priority: Medium - Important for long-term sustainabilityCore Questions
1. What are the tokenomics details?
2. How does the protocol get upgraded?
Tokenomics
Token Utility
What does the token do?| Use Case | Description |
|---|---|
| Gas fees | Pay for on-chain execution |
| Runner payments | Pay for off-chain compute |
| Staking | Validator/runner security |
| Governance | Voting on protocol changes |
Distribution Questions
| Question | Consideration |
|---|---|
| Initial allocation | Team, investors, community, treasury |
| Emission schedule | Inflationary, deflationary, fixed |
| Vesting | Lock-up periods for insiders |
| Public distribution | Airdrop, sale, mining/staking |
Economic Model
| Aspect | Options |
|---|---|
| Fee burn | Deflationary pressure |
| Staking rewards | Inflation to stakers |
| Runner incentives | How are runners paid? |
| Treasury | Protocol-owned liquidity |
Open Questions
- What’s the total supply?
- What percentage goes to team/investors?
- Is there a fee burn mechanism?
- How do runner economics integrate with tokenomics?
- What’s the staking APY target?
Governance
Upgrade Mechanisms
| Model | Description | Trade-off |
|---|---|---|
| Single client | One implementation | Faster iteration, centralization |
| Multi-client | Multiple implementations | Resilience, coordination cost |
| On-chain governance | Token-weighted voting | Plutocracy risk |
| Off-chain signaling | Soft consensus | Non-binding |
| Timelock | Delay between vote and execution | Security vs agility |
What Gets Governed?
| Category | Examples |
|---|---|
| Protocol parameters | Block time, gas limits, fees |
| Runner registry | Add/remove approved runners |
| Data sources | Approved oracles and APIs |
| Security | Emergency pauses, slashing params |
| Treasury | Fund allocation |
| Upgrades | Code changes, migrations |
Governance Process
Typical flow:- Who can submit proposals?
- What’s the quorum requirement?
- What’s the approval threshold?
- How long is the voting period?
- How long is the timelock?
- Are there emergency procedures?
Client Diversity
| Approach | Consideration |
|---|---|
| Single reference client | Simpler, but single point of failure |
| Multiple clients | Resilience, but spec ambiguity |
| Formal specification | Enables multi-client, expensive to create |
Upgrade Safety
How to prevent bad upgrades:| Mechanism | Purpose |
|---|---|
| Timelock | Time to review and exit |
| Veto | Emergency cancellation |
| Bug bounty | Find issues before deploy |
| Staged rollout | Testnet → limited mainnet → full |
| Rollback plan | What if upgrade breaks things? |
Governance Risks
Plutocracy
Token-weighted voting favors large holders:- Whales dominate decisions
- Small holders have no voice
- Potential for hostile governance
- Quadratic voting
- Delegation
- Time-weighted voting
- Conviction voting
Governance Attacks
| Attack | Description |
|---|---|
| Flash loan governance | Borrow tokens, vote, return |
| Vote buying | Off-chain payments for votes |
| Apathy exploitation | Low turnout enables minority control |
| Malicious proposals | Proposals that extract value |
Regulatory Considerations
Governance tokens may have regulatory implications:- Securities classification
- DAO liability
- Tax treatment
Open Sub-Questions
- Is governance on-chain or off-chain?
- What’s the minimum stake to propose?
- Are there different proposal types with different thresholds?
- How is the treasury managed?
- What’s the emergency response process?
- How do validator and governance incentives align?
Related Questions
- L1 vs L2 - Architecture affects upgrade complexity
- Runner Economics - Token economics for runners
- Consensus and Finality - Validator incentives