Governance for protocol upgrades and changes


With the activation of rc/1.6.0 - Sirius, we introduce a Governance System Smart Contract, empowering users to propose and shape the future of the MultiversX protocol. Here’s a simplified breakdown of how you can participate and what you need to know:

1. Making a Proposal

  • Cost: Initiating a proposal requires a deposit of 1000 eGLD.
  • Risk: If the proposal is vetoed, a portion of the deposited amount will be forfeited. The exact amount depends on the established veto fee.

2. Voting

  • Duration: The voting period spans 10 epochs.
  • Eligibility: All stake holders and delegators can vote.
  • Special Contracts: Certain contracts can facilitate user votes by implementing the delegateVote function from the GovernanceSC. This allows the contract to delegate a specified amount of votes to a particular user.

3. Proposal Journey

To increase the likelihood of your proposal achieving the necessary quorum, follow this three-step approach before officially initiating it through the Governance Portal:

  1. Agora Discussion: Begin by presenting your proposal on this forum to gather feedback and foster discussions.
  2. Engagement: Promote your proposal further through various channels such as X/Twitter and engaging with influencers to build a support base.
  3. Official Submission: Once you feel confident with the backing received, officially launch your proposal through the Governance Portal for voting.

Protocol upgrades

When it comes to protocol updates, to foster transparency and engaged decision-making within our community, we are implementing clear rules and norms regarding protocol updates. These norms are diligently outlined on our Governance page for developers and validators to refer to, facilitating smooth operations and community synergy.

Types of Upgrades

1. Critical Upgrades

  • Definition: Emergency measures addressing urgent issues or vulnerabilities to ensure network security.
  • Procedure: Undertaken without the traditional governance process; a validator call suffices.
  • Approval: Recognized as accepted once endorsed by ⅔+1 of the validators who apply the update in their systems.

2. Maintenance Upgrades

  • Definition: Focuses on system improvements that do not alter existing state, token dynamics, or economics, targeting enhancements in processing, storage, and network functionalities.
  • Procedure: Similar to critical updates, circumventing the full governance process.

3. New Implemented Features

  • Definition: Introduction of new attributes or functionalities within the ecosystem.
  • Prerequisite: Features should be operable on the public testnet before initiation of any governance call.
  • Procedure: Entails a comprehensive governance process with the core team and foundation steering the majority of marketing and explanatory endeavors to nurture community consensus.

4. Token Economics Update

  • Definition: Modifications aiming to revise the established token economic framework.
  • Approval: Requires a higher quorum, posing an elevated fee risk for proposals that either do not meet the quorum or are rejected.
  • Restrictions: While not strictly prohibitable at the SC level, the team retains substantial sway in guiding the community’s stance through various platforms and veto power.

5. New Features as MIPs

  • Definition: Pertains to features at the discussion stage, not implemented yet.
  • Prerequisite: Strict mandate that the feature is functioning on the public testnet.
  • Discussion: MIPs should be deliberated in the MIPs category, distinct from the Governance category, to ensure focused and streamlined discussions.


Within the Releases category, we will diligently provide details of all impending releases, showcasing:

  • Description: In-depth information on every Pull Request (PR) and feature.
  • Release Type: Distinct categorization of the release according to its nature and objectives.
  • Governance Process: Detailed outline of the governance strategy pertinent to the specific release, providing clarity on the procedures and expectations.

We aim to encourage a collaborative, transparent, and dynamic environment for all stakeholders in the MultiversX Protocol, adhering by these structured guidelines. We welcome feedback and suggestions for further enhancement.