diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index ebf7f92f..19379ad0 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -11,6 +11,7 @@ /MD/md-5/ @l-monninger @apenzk /MD/md-15/ @l-monninger @apenzk /MD/md-93/ @andygolay +/MD/md-125/ @apenzk ## MIPs /MIP/mip-0/ @l-monninger @apenzk @@ -26,6 +27,7 @@ /MIP/mip-88/ @apenzk @Primata /MIP/mip-91/ @apenzk /MIP/mip-94/ @andygolay +/MIP/mip-125/ @apenzk ## MGs /MG/mg-0/ @l-monninger diff --git a/.vscode/spellright.dict b/.vscode/spellright.dict index 0508f073..cecc2979 100644 --- a/.vscode/spellright.dict +++ b/.vscode/spellright.dict @@ -4,6 +4,7 @@ Fastconfirmation Fastconfirmations Merkle multisig +permissioned postconfirm postconfirmed Postconfirmer diff --git a/MD/md-125/README.md b/MD/md-125/README.md new file mode 100644 index 00000000..22d4d566 --- /dev/null +++ b/MD/md-125/README.md @@ -0,0 +1,43 @@ +# MD-125: Risk Assessment for Staking and Governance Launch + +- **Description**: A desideratum requiring comprehensive identification and mitigation of risks associated with launching staking and governance mechanisms on Movement L1. +- **Authors**: [Andreas Penzkofer]() +- **Approval**: + +## Overview + +This desiderata establishes the requirement for a comprehensive risk assessment framework for launching staking and governance mechanisms on Movement L1. The framework must identify potential risks and provide clear mitigation strategies to ensure a secure and where possible decentralized launch. + +## Desiderata + +### D1: Comprehensive Risk Assessment Framework + +**User journey**: Network operators and participants can rely on a thorough analysis of potential risks and corresponding mitigation strategies for staking and governance launch. + +**Description**: Develop a comprehensive risk assessment that identifies all potential risks associated with launching staking and governance mechanisms, categorizes them appropriately, and provides specific mitigation strategies and techniques for each identified risk. + +**Justification**: Launching staking and governance without proper risk assessment could lead to network security vulnerabilities, centralization issues, governance attacks, treasury exposure, and regulatory compliance problems. A systematic approach to risk identification and mitigation techniques is essential for a successful launch. + +**Recommendations**: + +- Identify risks across staking and governance categories +- Provide specific examples and root causes for each risk +- Develop actionable mitigation strategies for each identified risk + +### D2: Behavioral Recommendations for Launch + +**User journey**: Network operators and participants can follow specific behavioral guidance to implement staking and governance launch in a secure and decentralized manner. + +**Description**: Provide clear behavioral recommendations for staking and governance launch that guide implementation decisions and operational practices. + +**Justification**: While risk assessment identifies what could go wrong, behavioral recommendations provide specific guidance on how to implement the launch correctly. This ensures consistent application of best practices across all stakeholders. + +**Recommendations**: + +- Include behavioral recommendations for staking launch (delegation diversity, permissioned validators, etc.) +- Include behavioral recommendations for governance launch (thresholds, decentralization timeline, etc.) + + +## Changelog + +- **2025-10-15**: Initial desiderata document created. [PR#125](https://github.com/movementlabsxyz/MIP/pull/125) diff --git a/MIP/mip-125/README.md b/MIP/mip-125/README.md new file mode 100644 index 00000000..87dd0f3e --- /dev/null +++ b/MIP/mip-125/README.md @@ -0,0 +1,381 @@ +# MIP-125: Risk Assessment for Staking and Governance Launch + +- **Description**: A comprehensive risk assessment document outlining potential risks in launching staking and governance on Movement L1, including mitigation strategies and policy recommendations. +- **Authors**: [Andreas Penzkofer]() +- **Desiderata**: [MD-125](../MD/md-125) +- **Approval**: + +## Abstract + +This proposal provides a comprehensive risk assessment framework for launching staking and governance mechanisms on Movement L1. The document identifies critical risks across two main categories: **staking risks** _(validator concentration, insufficient participation, delegation centralization, treasury exposure, and bootstrap trust)_ and **governance risks** _(proposal spam, centralized voting power, stake-based attacks, governance delays, rushed upgrades, and legal compliance)_. + +Each risk includes specific examples, root causes, and detailed mitigation strategies to guide parameter selection and policy design for a secure and decentralized launch. + +#### Risk Categories Overview + +| **B. Staking Risks** | **C. Governance Risks** | **D. Other Market-Observed Risks** | +|---------------------|-------------------------|------------------------------| +| B.1 Validator Concentration | C.1 Proposal Spam | D.1 Liquid-Staking Dominance | +| B.2 Low Validator Participation | C.2 Centralized Voting Power | D.2 Censorship Resistance | +| B.3 Delegation Centralization | C.3 Stake-based Governance Attacks | D.3 Epoch Timing & Liquidity Runs | +| B.4 Treasury Exposure | C.4 Governance Delay | D.4 Parameter-Change Blast Radius | +| B.5 Bootstrap Trust | C.5 Rushed Upgrades | D.5 No-Slashing Regimes | +| | C.6 Legal Compliance | D.6 Vote Bribery & Market Manipulation | +| | C.7 Governance Threshold Too High | D.7 Cross-Domain Governance Spillover | + +## Motivation + +The successful launch of staking and governance on Movement L1 requires careful consideration of various risks that could compromise network security, decentralization, and long-term sustainability. Without proper risk assessment and mitigation strategies, the network faces potential threats including validator centralization, governance attacks, treasury exposure, and regulatory compliance issues. This proposal addresses these concerns by providing a structured framework for identifying, analyzing, and mitigating risks before they materialize. + +### Definitions + +- **Validator stake**: The stake of a validator. +- **Delegated stake**: The stake of a delegator. +- **Combined stake**: The sum of the validator stake and the delegated stake. +- **MVMT Fnd**: The Movement Foundation. +- **Move Inc**: The Movement Inc. +- **Soft delegation caps**: A limit on the amount of stake that can be delegated to a validator. This limit can be exceeded (hence soft) if other validators reduce their combined stake. +- **Diminishing returns**: A function that reduces the reward to a validator the more stake it holds (delegated or directly). + +## Specification + +_The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174._ + +The risk assessment follows a structured approach: + +1. Risk identification through analysis of similar systems +2. Impact assessment with specific examples +3. Root cause analysis +4. Mitigation strategy development +5. Implementation considerations + +### A. Behavioral Recommendations + +*Addresses [MD-125 D2: Behavioral Recommendations for Launch](../MD/md-125#d2-behavioral-recommendations-for-launch)* + +Based on the risk assessment, the following behavioral recommendations are made to mitigate identified risks: + +**Staking Launch Behavior:** + +- Use initially permissioned / white-listed validators to reduce collusion risks. +- Delegate MVMT Fnd tokens to several validators to promote diversity. +- Require minimum validator stake to ensure sufficient commitment. +- Roll out staking separately before governance decentralization. + +Consider with reservations: + +- Implement soft caps (relative to the total stake) for combined stake per validator. Beyond code complexity this may not come without crypto-economic challenges, so this approach should be taken with reservations. + + +**Governance Behavior:** + +- Start with centralized governance. +- Implement and publish a progressive decentralization timeline for governance. +- Require minimum stake threshold for proposal submission. +- Require low-enough threshold for passing proposals. + +### B. Staking Risks + +*Addresses [MD-125 D1: Comprehensive Risk Assessment Framework](../MD/md-125#d1-comprehensive-risk-assessment-framework)* + +| Risk | Causes | +|------|--------| +| B.1 Validator Concentration | • Single Entity > 33% Stake
• No Max Stake Cap
• Uneven Delegation | +| B.2 Insufficient Validator Participation | • High Min Validator Stake
• Restrictive Onboarding/KYC | +| B.3 Delegation Centralization | • No Max Stake Per Validator
• Low Visibility for Small Validators | +| B.4 Treasury Exposure | • Foundation Token Concentration
• Reward Treasury Used for Staking | +| B.5 Bootstrap Trust | • Initial Validator Trust
• Permissioned Launch Risks | + +#### B.1 Validator Concentration Risk + +**Description:** Excessive stake concentration can lead to centralization, collusion, or network halts. +*Example: one validator holds 0.34 of total stake and goes offline, halting block production.* + +**Cause:** + +- A single entity controlling > 0.33 of total stake. Could be spread across several nodes. +- No max stake cap and uneven delegation distribution. + +**Mitigation:** + +- MVMT Fnd should delegate to several validators. +- Enforce a **max validator stake ratio** (e.g., 0.10). Limits concentration on a single validator. +- Only permit white-listed validators. Reduces risk of collusion between validators. +- Run a majority of validators self. +- Encourage **delegation diversity** through incentives. + +**Additional notes:** + +- Limiting the absolute total stake is risky and not considered as a valid option. An attacker could frontrun to stake a large amount of the total stake. Obviously it also discourages token participation and increases sell pressure. +- Minor: Total stake can diminish over time. Stakers cannot be forced to unstake, so it is possible that a validator can exceed the threshold. This issue is minor. +- Diversity can in principle be encouraged by giving higher APY to validators with lower stake, however this adds additional code complexity. + +#### B.2 Insufficient Validator Participation + +**Description:** A low number of active validators can lead to centralization and bad image. +*Example: only 6 of 20 potential validators can afford an amount $X as minimum, leaving the network under-decentralized.* + +**Cause:** + +- High min validator stake. +- Overly restrictive onboarding or KYC requirements. + +**Mitigation:** + +- Start with a reasonable low minimum but permissioned validator set. +- Adjust minimums dynamically post-launch. + +#### B.3 Delegation Centralization + +**Description:** Delegators may prefer well-known validators, concentrating stake and influence. +*Example: 0.70 of all delegated MOVE accrues to two MVMT Foundation-associated validators.* + +**Cause:** + +- No max stake per validator. +- Low visibility for smaller validators. + +**Mitigation:** + +- Introduce soft delegation caps or diminishing returns. +- Improve validator discovery and transparency tools. + +#### B.4 Reward Pool and Treasury Risk Exposure + +**Description:** Using Foundation or reward treasuries for staking can blur lines between governance funds and validator economics, putting them at risk. +*Example: the Foundation stakes part of its reward treasury, a slashing event reduces funds intended for future ecosystem rewards.* + +**Cause:** + +- Reward treasury used as validator capital. +- Undefined policy for treasury participation in staking. + +**Risk:** + +- Slashing due to errors or bugs could lead to unwarranted loss of funds. + +**Mitigation:** + +- Give well defined control over slashing, such that funds are at least initially recoverable. For example transfer slashed funds to a MVMT Fnd controlled treasury. + +#### B.5 Bootstrap Trust Risk + +**Description:** A small, permissioned validator set makes early consensus trust-based rather than decentralized. +*Example: If all validators are operated by Move Inc, centralizing control over consensus.* + +**Risk:** Bad image due to centralization. + +**Cause:** + +- Initial validators run by a single organization. +- No decentralization roadmap with concrete milestones. + +**Mitigation:** + +- Publish **decentralization milestones**. +- Gradually onboard new validators; enable appropriate **monitoring**. + +--- + +### C. Governance Risks + +*Addresses [MD-125 D1: Comprehensive Risk Assessment Framework](../MD/md-125#d1-comprehensive-risk-assessment-framework)* + +| Risk | Causes | +|------|--------| +| C.1 Proposal Spam | • No Minimum Thresholds
• Unlimited Proposal Frequency | +| C.2 Centralized Voting Power | • Large Token Concentration
• Multiple Validators Same Operator | +| C.3 Stake-based Governance Attacks | • Stake-based Governance
• Insufficient Stake Limit | +| C.4 Governance Delay | • No Decentralization Roadmap
• Dependencies on Off-chain Processes | +| C.5 Rushed Upgrades | • No Timelock or Security Audit
• No Rollback or Veto Mechanism | +| C.6 Legal Compliance | • Move Inc-managed Staking
• Lack of Compliance Framework | +| C.7 Governance Threshold Too High | • Overly Conservative Threshold
• Lack of Realistic Stake Analysis | + +#### C.1 Proposal Spam and Governance Flooding + +**Description:** Without minimum thresholds, actors can overload governance with junk proposals. +*Example: one actor submits 200 trivial proposals, crowding out legitimate ones.* + +**Cause:** + +- No **proposal deposit or stake threshold**. +- Unlimited proposal frequency. + +**Mitigation:** + +- Require proposers to bond **≥ X** fraction of circulating stake. +- Add **proposal cooldowns** and refundable deposits. +- Require a threshold of minimum stake to submit a proposal. + +#### C.2 Centralized Voting Power + +**Description:** Foundation or Move Inc controlling most voting power predetermines outcomes. +*For example, if Move Inc controls 0.70 of votes via delegation and passes proposals unilaterally.* + +**Cause:** + +- Large token concentration in a single entity. +- Multiple validators controlled by the same operator. + +**Mitigation:** + +- Acknowledge initial centralization phase. +- Implement **progressive voting-power decentralization**. + +#### C.3 Stake-based Governance Attacks + +**Description:** An attacker lends a large amount of tokens from the open market to a validator it controls, allowing it to pass proposals. + +**Cause:** + +- Stake-based governance. +- Insufficient stake limit on validators. + +**Mitigation:** + +- Implement a **stake limit** on validators, that is relative to the total stake of the network. + +#### C.4 Governance Delay / Inflexibility + +**Description:** Prolonged delay in decentralizing governance weakens confidence and agility. + +**Example:** One year post-launch, all governance still routes purely through Move Inc. + +**Cause:** + +- No decentralization roadmap. +- Dependencies on off-chain processes. + +**Mitigation:** + +- Publish **phase-based milestones** (e.g., multisig → on-chain voting). +- Track progress publicly. + +#### C.5 Rushed Upgrades + +**Description:** Rapid or unchecked upgrades can introduce bugs or malicious code paths. + +**Example:** A rushed proposal upgrades the staking contract and unintentionally locks validator funds. + +**Cause:** + +- No **timelock** or **security audit** before execution. +- No rollback or veto mechanism. + +**Mitigation:** + +- Add **execution timelocks** on passed proposals. +- Enable a temporary **emergency veto** (safety council). + +#### C.6 Legal and Compliance Exposure + +**Description:** Move Inc-managed staking or reward distribution can draw regulatory scrutiny if deemed custodial or yield-bearing. +*For example, if regulators classify Move Inc or MVMT Fnd staking returns as securities due to weak separation between treasury and validator operations.* + +**Cause:** + +- Move Inc or MVMT Fnd directly participating in staking rewards. +- Lack of a compliance framework for third-party validators. + +**Mitigation:** + +- Maintain **legal separation** between treasury and validators. +- Apply **KYC / AML** for accredited participants where applicable. + +#### C.7 Governance Threshold Too High + +**Description:** Maximum threshold for proposal passage may be set too high, preventing any proposals from passing and effectively halting governance. + +*Example: requiring 50% of total stake to pass proposals when only 30% of the total stake is active in governance, making governance impossible.* + +**Cause:** + +- Overly conservative threshold setting to prevent attacks. +- Lack of consideration for realistic stake distribution. + +**Mitigation:** + +- Set thresholds based on realistic stake distribution analysis. +- Implement graduated thresholds that can be adjusted over time. +- Monitor proposal passage rates and adjust thresholds if needed. + +--- + +### D. Market-Observed Risks + +This section expands on the risks discussed in the previous section by discussing additional risk categories observed across other ecosystems, including [Ethereum](https://ethereum.org/en/staking/), [Cosmos Hub](https://docs.cosmos.network/main/build/modules/gov), [Solana](https://docs.solana.com/staking), [Aptos](https://aptos.dev/nodes/staking), [Sui](https://docs.sui.io), and [Lido](https://lido.fi/governance). It discusses selected additional risk categories observed across these systems, that also may be relevant for Movement L1, and outlines corresponding mitigation strategies. + +> The here discussed risks are not necessarily applicable to Movement L1, but are documented for completeness and context. + +#### D.1 Liquid-Staking Dominance + +**Description:** Pooled staking entities (e.g., [Lido](https://lido.fi/)) can amass excessive governance influence, concentrating both economic and political power. + +**Mitigation:** + +- Apply voting-power caps to custodial pools. +- Require operator diversification and public validator reports. + +#### D.2 Censorship Resistance and Block Producer Neutrality + +**Description:** Jurisdictional or political pressures can induce censorship in block production, as seen with OFAC-compliant relays on [Ethereum](https://ethereum.org/en/developers/docs/mev/). See live relay censorship metrics on [MEV Watch](https://www.mevwatch.info/). + +**Mitigation:** + +- Define and publish a neutrality and inclusion policy. +- Require block producers and validators to provide non-censorship commitments. +- Monitor inclusion metrics on-chain to detect filtering. + +#### D.3 Epoch Timing and Liquidity Runs + +**Description:** When staking has long unbonding periods (time to withdraw staked tokens) or long epoch intervals (time between validator set updates), it can create liquidity crises during market stress. For example, if many users want to unstake simultaneously during a market crash, but the unbonding period is 21 days, this creates a "liquidity run" where users are stuck with illiquid staked tokens. Similarly, long epochs mean validator changes take too long to respond to emergencies, potentially allowing bad actors to maintain control longer than necessary. This has been observed in [Solana](https://solana.com/docs/references/staking) and [Sui](https://docs.sui.io/concepts/tokenomics/staking-unstaking) ecosystems. + +**Mitigation:** + +- Rate-limited exits and adaptive epoch duration. +- Emergency pause for redemptions only (not transfers). +- Publish clear unbonding timelines and redemption queues. + +#### D.4 Parameter-Change Blast Radius + +**Description:** Broad or rapid governance parameter changes can undermine network safety, as seen with the [Cosmos SDK governance module](https://docs.cosmos.network/main/build/modules/gov). + +**Mitigation:** + +- Classify parameters by security impact (e.g., Class A requires audit and timelock). +- Require simulation proofs for all Class A parameter updates. +- Maintain an on-chain public change log for transparency. + +#### D.5 No-Slashing Regimes + +**Description:** Networks like [Aptos](https://aptos.dev/network/blockchain/staking) and (historically) [Solana](https://solana.com/docs/references/staking) operate without slashing; both rely on performance-based incentives (Solana is actively exploring slashing). + +**Mitigation:** + +- Replace slashing with performance-based reward modulation. +- Define uptime and performance Service Level Agreements (SLAs). +- Enable automatic validator eviction for prolonged underperformance. + +#### D.6 Vote Bribery and Market Manipulation + +**Description:** Off-chain vote markets or direct bribery mechanisms can distort governance outcomes and weaken legitimacy. Such behaviors have been observed in token-based systems like [Curve DAO](https://resources.curve.finance/vecrv/overview/) (via "vote-bribe" markets on [Votium](https://docs.votium.app/explainers/voter-manual)) and [Balancer DAO](https://docs.balancer.fi/concepts/governance/veBAL/), where users are paid to direct votes toward certain pools. + +**Mitigation:** + +- Enforce quorum and turnout thresholds to prevent minority capture. +- Use snapshot voting windows to mitigate flash-borrow governance attacks. +- Encourage transparency and disclosure requirements for large proposers or bribery markets. + +#### D.7 Cross-Domain Governance Spillover + +**Description:** Application-level DAOs or bridge councils (e.g., [Sui DeepBook](https://docs.sui.io/standards/deepbook), an application-level protocol on Sui cited as an exemplar) can inadvertently influence Layer 1 decisions through token-weighted governance overlap. + +**Mitigation:** + +- Clearly scope governance domains and restrict proposal reach. +- Require opt-in voting for app-governed assets. +- Enforce upgrade isolation for core modules. + +## Changelog + +- **2025-10-15**: Initial risk assessment document created. [PR#125](https://github.com/movementlabsxyz/MIP/pull/125)