From 68daafc35df8215bd7b7dbc6a4b3c41bb282205a Mon Sep 17 00:00:00 2001
From: apenzk <dr.andreas.penzkofer@gmail.com>
Date: Wed, 15 Oct 2025 15:43:41 +0200
Subject: [PATCH 1/5] init

---
 .github/CODEOWNERS      |   2 +
 .vscode/spellright.dict |   1 +
 MD/md-125/README.md     |  43 +++++++
 MIP/mip-125/README.md   | 270 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 316 insertions(+)
 create mode 100644 MD/md-125/README.md
 create mode 100644 MIP/mip-125/README.md

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**: <!--Either approved (:white_check_mark:), rejected (:x:), stagnant or withdrawn by the governance body. To be inserted by governance. -->
+
+## 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..a7a535ab
--- /dev/null
+++ b/MIP/mip-125/README.md
@@ -0,0 +1,270 @@
+# 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**: <!--Either approved (:white_check_mark:), rejected (:x:), stagnant or withdrawn by the governance body. To be inserted by governance. -->
+
+## 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.
+
+## 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:**
+
+- Delegate MVMT Fnd tokens to several validators to promote diversity.
+- Use initially permissioned / white-listed validators to reduce collusion risks.
+- Require minimum validator stake to ensure sufficient commitment.
+- Implement soft caps for combined stake per validator.
+- Roll out staking separately before governance decentralization.
+
+**Governance Behavior:**
+
+- Require minimum stake threshold for proposal submission.
+- Require low-enough threshold for passing proposals.
+- Implement and publish a progressive decentralization timeline for governance.
+
+### B. Staking Risks
+
+*Addresses [MD-125 D1: Comprehensive Risk Assessment Framework](../MD/md-125#d1-comprehensive-risk-assessment-framework)*
+
+#### 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.
+
+#### 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.
+
+#### 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.
+
+#### 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 controlled over slashing, that at least initially is recoverable. For example transfer slashed funds to a MVMT Fnd controlled treasury.
+
+#### 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)*
+
+#### 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.
+
+#### 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**.
+
+#### 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.
+
+#### 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.
+
+#### 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).
+
+#### 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.
+
+#### 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.
+
+
+## Changelog
+
+- **2025-10-15**: Initial risk assessment document created. [PR#125](https://github.com/movementlabsxyz/MIP/pull/125)

From 5e836907a4596b11415521ea39c67487a3c1b4cb Mon Sep 17 00:00:00 2001
From: apenzk <dr.andreas.penzkofer@gmail.com>
Date: Wed, 15 Oct 2025 15:49:41 +0200
Subject: [PATCH 2/5] updates

---
 MIP/mip-125/README.md | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/MIP/mip-125/README.md b/MIP/mip-125/README.md
index a7a535ab..6c836b8e 100644
--- a/MIP/mip-125/README.md
+++ b/MIP/mip-125/README.md
@@ -45,17 +45,22 @@ Based on the risk assessment, the following behavioral recommendations are made
 
 **Staking Launch Behavior:**
 
-- Delegate MVMT Fnd tokens to several validators to promote diversity.
 - 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.
-- Implement soft caps for combined stake per validator.
 - 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.
-- Implement and publish a progressive decentralization timeline for governance.
 
 ### B. Staking Risks
 
@@ -131,7 +136,7 @@ Based on the risk assessment, the following behavioral recommendations are made
 
 **Mitigation:**
 
-- Give well defined controlled over slashing, that at least initially is recoverable. For example transfer slashed funds to a MVMT Fnd controlled treasury.
+- 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.
 
 #### 5. Bootstrap Trust Risk
 

From 55acd940498b0e777278d66b36c3963c06e5e620 Mon Sep 17 00:00:00 2001
From: apenzk <dr.andreas.penzkofer@gmail.com>
Date: Wed, 15 Oct 2025 16:57:54 +0200
Subject: [PATCH 3/5] market ovserved risks

---
 MIP/mip-125/README.md | 100 +++++++++++++++++++++++++++++++++++++-----
 1 file changed, 88 insertions(+), 12 deletions(-)

diff --git a/MIP/mip-125/README.md b/MIP/mip-125/README.md
index 6c836b8e..9043ff56 100644
--- a/MIP/mip-125/README.md
+++ b/MIP/mip-125/README.md
@@ -66,7 +66,7 @@ Consider with reservations:
 
 *Addresses [MD-125 D1: Comprehensive Risk Assessment Framework](../MD/md-125#d1-comprehensive-risk-assessment-framework)*
 
-#### 1. Validator Concentration Risk
+#### 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.*
@@ -90,7 +90,7 @@ Consider with reservations:
 - 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.
 
-#### 2. Insufficient Validator Participation
+#### 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.*
@@ -105,7 +105,7 @@ Consider with reservations:
 - Start with a reasonable low minimum but permissioned validator set.
 - Adjust minimums dynamically post-launch.
 
-#### 3. Delegation Centralization
+#### 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.*
@@ -120,7 +120,7 @@ Consider with reservations:
 - Introduce soft delegation caps or diminishing returns.
 - Improve validator discovery and transparency tools.
 
-#### 4. Reward Pool and Treasury Risk Exposure
+#### 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.*
@@ -138,7 +138,7 @@ Consider with reservations:
 
 - 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.
 
-#### 5. Bootstrap Trust Risk
+#### 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.*
@@ -161,7 +161,7 @@ Consider with reservations:
 
 *Addresses [MD-125 D1: Comprehensive Risk Assessment Framework](../MD/md-125#d1-comprehensive-risk-assessment-framework)*
 
-#### 1. Proposal Spam and Governance Flooding
+#### 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.*
@@ -177,7 +177,7 @@ Consider with reservations:
 - Add **proposal cooldowns** and refundable deposits.
 - Require a threshold of minimum stake to submit a proposal.
 
-#### 2. Centralized Voting Power
+#### 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.*
@@ -192,7 +192,7 @@ Consider with reservations:
 - Acknowledge initial centralization phase.
 - Implement **progressive voting-power decentralization**.
 
-#### 3. Stake-based Governance Attacks
+#### 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.
 
@@ -205,7 +205,7 @@ Consider with reservations:
 
 - Implement a **stake limit** on validators, that is relative to the total stake of the network.
 
-#### 4. Governance Delay / Inflexibility
+#### C.4 Governance Delay / Inflexibility
 
 **Description:** Prolonged delay in decentralizing governance weakens confidence and agility.
 
@@ -221,7 +221,7 @@ Consider with reservations:
 - Publish **phase-based milestones** (e.g., multisig → on-chain voting).
 - Track progress publicly.
 
-#### 5. Rushed Upgrades
+#### C.5 Rushed Upgrades
 
 **Description:** Rapid or unchecked upgrades can introduce bugs or malicious code paths.
 
@@ -237,7 +237,7 @@ Consider with reservations:
 - Add **execution timelocks** on passed proposals.
 - Enable a temporary **emergency veto** (safety council).
 
-#### 6. Legal and Compliance Exposure
+#### 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.*
@@ -252,7 +252,7 @@ Consider with reservations:
 - Maintain **legal separation** between treasury and validators.
 - Apply **KYC / AML** for accredited participants where applicable.
 
-#### 7. Governance Threshold Too High
+#### 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.
 
@@ -269,6 +269,82 @@ Consider with reservations:
 - 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
 

From 229ab248ff912d42d92981678477e87b55e9ce50 Mon Sep 17 00:00:00 2001
From: apenzk <dr.andreas.penzkofer@gmail.com>
Date: Wed, 15 Oct 2025 20:24:43 +0200
Subject: [PATCH 4/5] edits

---
 MIP/mip-125/README.md | 115 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 115 insertions(+)

diff --git a/MIP/mip-125/README.md b/MIP/mip-125/README.md
index 9043ff56..3e3820a2 100644
--- a/MIP/mip-125/README.md
+++ b/MIP/mip-125/README.md
@@ -11,6 +11,18 @@ This proposal provides a comprehensive risk assessment framework for launching s
 
 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** |
+|---------------------|-------------------------|
+| B.1 Validator Concentration | C.1 Proposal Spam |
+| B.2 Low Validator Participation | C.2 Centralized Voting Power |
+| B.3 Delegation Centralization | C.3 Stake-based Governance Attacks |
+| B.4 Treasury Exposure | C.4 Governance Delay |
+| B.5 Bootstrap Trust | C.5 Rushed Upgrades |
+| | C.6 Legal Compliance |
+| | C.7 Governance Threshold Too High |
+
 ## 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.
@@ -66,6 +78,64 @@ Consider with reservations:
 
 *Addresses [MD-125 D1: Comprehensive Risk Assessment Framework](../MD/md-125#d1-comprehensive-risk-assessment-framework)*
 
+```mermaid
+flowchart TD
+    subgraph B1["B.1_Validator_Concentration"]
+        P1[Single Entity > 33% Stake]
+        P2[No Max Stake Cap]
+        P3[Uneven Delegation]
+    end
+    
+    B1 --> B2
+    
+    subgraph B2["B.2_Insufficient_Validator_Participation"]
+        P4[High Min Validator Stake]
+        P5[Restrictive Onboarding/KYC]
+    end
+    
+    B2 --> B3
+    
+    subgraph B3["B.3_Delegation_Centralization"]
+        P6[No Max Stake Per Validator]
+        P7[Low Visibility for Small Validators]
+    end
+    
+    B3 --> B4
+    
+    subgraph B4["B.4_Treasury_Exposure"]
+        P8[Foundation Token Concentration]
+        P9[Reward Treasury Used for Staking]
+    end
+    
+    B4 --> B5
+    
+    subgraph B5["B.5_Bootstrap_Trust"]
+        P10[Initial Validator Trust]
+        P11[Permissioned Launch Risks]
+    end
+    
+    style B1 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
+    style B2 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
+    style B3 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
+    style B4 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
+    style B5 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
+    style P1 fill:#ffcdd2
+    style P2 fill:#ffcdd2
+    style P3 fill:#ffcdd2
+    style P4 fill:#ffcdd2
+    style P5 fill:#ffcdd2
+    style P6 fill:#ffcdd2
+    style P7 fill:#ffcdd2
+    style P8 fill:#ffcdd2
+    style P9 fill:#ffcdd2
+    style P10 fill:#ffcdd2
+    style P11 fill:#ffcdd2
+    linkStyle 0 stroke:transparent,stroke-width:0px
+    linkStyle 1 stroke:transparent,stroke-width:0px
+    linkStyle 2 stroke:transparent,stroke-width:0px
+    linkStyle 3 stroke:transparent,stroke-width:0px
+```
+
 #### B.1 Validator Concentration Risk
 
 **Description:** Excessive stake concentration can lead to centralization, collusion, or network halts.
@@ -161,6 +231,51 @@ Consider with reservations:
 
 *Addresses [MD-125 D1: Comprehensive Risk Assessment Framework](../MD/md-125#d1-comprehensive-risk-assessment-framework)*
 
+```mermaid
+flowchart TD
+    subgraph C1["C.1_Proposal_Spam"]
+        P1[No Minimum Thresholds]
+        P2[Unlimited Proposal Frequency]
+    end
+    
+    C1 --> C2
+    
+    subgraph C2["C.2_Centralized_Voting_Power"]
+        P3[Large Token Concentration]
+        P4[Multiple Validators Same Operator]
+    end
+    
+    C2 --> C3
+    
+    subgraph C3["C.3_Stake_based_Governance_Attacks"]
+        P5[Stake-based Governance]
+        P6[Insufficient Stake Limit]
+    end
+    
+    C3 --> C4
+    
+    subgraph C4["C.4_Governance_Delay"]
+        P7[No Decentralization Roadmap]
+        P8[Dependencies on Off-chain Processes]
+    end
+    
+    style C1 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
+    style C2 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
+    style C3 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
+    style C4 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
+    style P1 fill:#ffcdd2
+    style P2 fill:#ffcdd2
+    style P3 fill:#ffcdd2
+    style P4 fill:#ffcdd2
+    style P5 fill:#ffcdd2
+    style P6 fill:#ffcdd2
+    style P7 fill:#ffcdd2
+    style P8 fill:#ffcdd2
+    linkStyle 0 stroke:transparent,stroke-width:0px
+    linkStyle 1 stroke:transparent,stroke-width:0px
+    linkStyle 2 stroke:transparent,stroke-width:0px
+```
+
 #### C.1 Proposal Spam and Governance Flooding
 
 **Description:** Without minimum thresholds, actors can overload governance with junk proposals.

From 9fcddb1ca47d027c546261d3e4c25f14952d0ef6 Mon Sep 17 00:00:00 2001
From: apenzk <dr.andreas.penzkofer@gmail.com>
Date: Wed, 15 Oct 2025 20:33:46 +0200
Subject: [PATCH 5/5] remove mermaids

---
 MIP/mip-125/README.md | 135 ++++++++----------------------------------
 1 file changed, 25 insertions(+), 110 deletions(-)

diff --git a/MIP/mip-125/README.md b/MIP/mip-125/README.md
index 3e3820a2..87dd0f3e 100644
--- a/MIP/mip-125/README.md
+++ b/MIP/mip-125/README.md
@@ -13,15 +13,15 @@ Each risk includes specific examples, root causes, and detailed mitigation strat
 
 #### Risk Categories Overview
 
-| **B. Staking Risks** | **C. Governance Risks** |
-|---------------------|-------------------------|
-| B.1 Validator Concentration | C.1 Proposal Spam |
-| B.2 Low Validator Participation | C.2 Centralized Voting Power |
-| B.3 Delegation Centralization | C.3 Stake-based Governance Attacks |
-| B.4 Treasury Exposure | C.4 Governance Delay |
-| B.5 Bootstrap Trust | C.5 Rushed Upgrades |
-| | C.6 Legal Compliance |
-| | C.7 Governance Threshold Too High |
+| **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
 
@@ -78,63 +78,13 @@ Consider with reservations:
 
 *Addresses [MD-125 D1: Comprehensive Risk Assessment Framework](../MD/md-125#d1-comprehensive-risk-assessment-framework)*
 
-```mermaid
-flowchart TD
-    subgraph B1["B.1_Validator_Concentration"]
-        P1[Single Entity > 33% Stake]
-        P2[No Max Stake Cap]
-        P3[Uneven Delegation]
-    end
-    
-    B1 --> B2
-    
-    subgraph B2["B.2_Insufficient_Validator_Participation"]
-        P4[High Min Validator Stake]
-        P5[Restrictive Onboarding/KYC]
-    end
-    
-    B2 --> B3
-    
-    subgraph B3["B.3_Delegation_Centralization"]
-        P6[No Max Stake Per Validator]
-        P7[Low Visibility for Small Validators]
-    end
-    
-    B3 --> B4
-    
-    subgraph B4["B.4_Treasury_Exposure"]
-        P8[Foundation Token Concentration]
-        P9[Reward Treasury Used for Staking]
-    end
-    
-    B4 --> B5
-    
-    subgraph B5["B.5_Bootstrap_Trust"]
-        P10[Initial Validator Trust]
-        P11[Permissioned Launch Risks]
-    end
-    
-    style B1 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
-    style B2 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
-    style B3 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
-    style B4 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
-    style B5 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
-    style P1 fill:#ffcdd2
-    style P2 fill:#ffcdd2
-    style P3 fill:#ffcdd2
-    style P4 fill:#ffcdd2
-    style P5 fill:#ffcdd2
-    style P6 fill:#ffcdd2
-    style P7 fill:#ffcdd2
-    style P8 fill:#ffcdd2
-    style P9 fill:#ffcdd2
-    style P10 fill:#ffcdd2
-    style P11 fill:#ffcdd2
-    linkStyle 0 stroke:transparent,stroke-width:0px
-    linkStyle 1 stroke:transparent,stroke-width:0px
-    linkStyle 2 stroke:transparent,stroke-width:0px
-    linkStyle 3 stroke:transparent,stroke-width:0px
-```
+| Risk | Causes |
+|------|--------|
+| B.1 Validator Concentration | • Single Entity > 33% Stake<br/>• No Max Stake Cap<br/>• Uneven Delegation |
+| B.2 Insufficient Validator Participation | • High Min Validator Stake<br/>• Restrictive Onboarding/KYC |
+| B.3 Delegation Centralization | • No Max Stake Per Validator<br/>• Low Visibility for Small Validators |
+| B.4 Treasury Exposure | • Foundation Token Concentration<br/>• Reward Treasury Used for Staking |
+| B.5 Bootstrap Trust | • Initial Validator Trust<br/>• Permissioned Launch Risks |
 
 #### B.1 Validator Concentration Risk
 
@@ -231,50 +181,15 @@ flowchart TD
 
 *Addresses [MD-125 D1: Comprehensive Risk Assessment Framework](../MD/md-125#d1-comprehensive-risk-assessment-framework)*
 
-```mermaid
-flowchart TD
-    subgraph C1["C.1_Proposal_Spam"]
-        P1[No Minimum Thresholds]
-        P2[Unlimited Proposal Frequency]
-    end
-    
-    C1 --> C2
-    
-    subgraph C2["C.2_Centralized_Voting_Power"]
-        P3[Large Token Concentration]
-        P4[Multiple Validators Same Operator]
-    end
-    
-    C2 --> C3
-    
-    subgraph C3["C.3_Stake_based_Governance_Attacks"]
-        P5[Stake-based Governance]
-        P6[Insufficient Stake Limit]
-    end
-    
-    C3 --> C4
-    
-    subgraph C4["C.4_Governance_Delay"]
-        P7[No Decentralization Roadmap]
-        P8[Dependencies on Off-chain Processes]
-    end
-    
-    style C1 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
-    style C2 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
-    style C3 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
-    style C4 fill:#fff3e0,stroke:#333,stroke-width:2px,width:900px
-    style P1 fill:#ffcdd2
-    style P2 fill:#ffcdd2
-    style P3 fill:#ffcdd2
-    style P4 fill:#ffcdd2
-    style P5 fill:#ffcdd2
-    style P6 fill:#ffcdd2
-    style P7 fill:#ffcdd2
-    style P8 fill:#ffcdd2
-    linkStyle 0 stroke:transparent,stroke-width:0px
-    linkStyle 1 stroke:transparent,stroke-width:0px
-    linkStyle 2 stroke:transparent,stroke-width:0px
-```
+| Risk | Causes |
+|------|--------|
+| C.1 Proposal Spam | • No Minimum Thresholds<br/>• Unlimited Proposal Frequency |
+| C.2 Centralized Voting Power | • Large Token Concentration<br/>• Multiple Validators Same Operator |
+| C.3 Stake-based Governance Attacks | • Stake-based Governance<br/>• Insufficient Stake Limit |
+| C.4 Governance Delay | • No Decentralization Roadmap<br/>• Dependencies on Off-chain Processes |
+| C.5 Rushed Upgrades | • No Timelock or Security Audit<br/>• No Rollback or Veto Mechanism |
+| C.6 Legal Compliance | • Move Inc-managed Staking<br/>• Lack of Compliance Framework |
+| C.7 Governance Threshold Too High | • Overly Conservative Threshold<br/>• Lack of Realistic Stake Analysis |
 
 #### C.1 Proposal Spam and Governance Flooding