Skip to main content

Governance - Overview

This page provides an overview of the On-chain Governance module that will be available on the v1.6.x release.

Table of contents

NameDescription
Interacting with the on-chain governance SCInteracting with the governance system smart contract.

Overview

The MultiversX network enables on-chain governance by issuing special types of transactions. This mechanism increases decentralization by allowing community members to directly propose and vote on changes, such as protocol upgrades or configuration adjustments.

  • Anyone can create a proposal by paying the proposal fee and specifying:
    • a commit hash (unique identifier, usually a GitHub commit or spec reference)
    • a start epoch and an end epoch (the voting window).
  • Any staked user (direct or delegated) can vote during the active period.
  • Voting power is proportional to stake: voting_power = staked_value (linear voting).

Implementation details

Proposals

In order for a proposal to be submitted, the following requirements need to be met:

  • For a period of at least 15 days, the proposal needs to be published on Agora for public debate and analysis;
  • Each proposal requires paying a ProposalFee (currently 500 EGLD);
  • Each proposal costs around 51 million of gas units to be submitted.
  • The starting epoch of the proposal's voting period needs to be set inside an interval of 30 epochs from the epoch in which the proposal was submitted;

After a proposal is created, the following rules will apply:

  • If the proposal passes, the fee is refunded to the issuer.
  • If the proposal fails, a penalty fee (called LostProposalFee) is deducted from the initial proposal fee, and the remaining amount is returned to the proposer.
  • If the proposal is vetoed, the fee is slashed (transferred to the Community Governance Pool) or reduced by the configured LostProposalFee.
  • Proposals cannot be duplicated: the same commit hash cannot be submitted twice.
  • Proposals can be cancelled by the issuer before the voting period starts. (introduced in v1.10.0 Barnard release)
  • Lost proposal fees may either be accumulated in the governance contract (retrievable by the contract owner) or redirected to a Community Governance Pool, depending on configuration.

Voting

  • The voting starts from the provided starting epoch and lasts at most 10 days.
  • There are four vote types: Yes, No, Abstain, and Veto.
  • Voting consumes gas (approx. 6 million units).
  • Voting power is derived from staked and delegated EGLD.
  • Delegation and liquid staking contracts can forward user votes.
  • Voting power is linear with stake: the more EGLD staked or delegated, the higher the voting power.
  • The contract tracks both used voting power/stake (applied in a proposal) and total available voting power/stake for each address.

Quorum and thresholds

A proposal can pass only if all conditions are met:

  • Quorum: at least MinQuorum% of the total voting power must participate. (currently at least 20% of total voting power)
  • Acceptance threshold: YES / (YES + NO + VETO) ≥ 66.67% (MinPassThreshold)
  • Veto threshold: if VETO votes exceed 33% of total participating voting power, the proposal is rejected and the proposal fee is slashed.

Closing and cleanup

Proposal closing permissions:

  • Before voting starts: Only the proposal issuer can close the proposal.
  • After voting ends: Any user can close the proposal.

Effects of closing:

  1. Finalizes the proposal outcome (passed/failed/vetoed).
  2. Unlocks any locked funds.
  3. Updates the proposal status in the governance system.

Cleanup options:

  • The clearEndedProposals function can be called to clean up expired but unclosed proposals.
  • This helps maintain system efficiency by removing inactive proposals.

Governance configuration

All thresholds and fees are defined in GovernanceConfigV2:

  • MinQuorum
  • MinPassThreshold
  • MinVetoThreshold
  • ProposalFee
  • LostProposalFee
  • LastProposalNonce

These values are set by the system and can be updated by contract owner calls.

Example

Let's suppose we have the following addresses that cast the following votes:

  • alice: staked value 2000 EGLD that vote Yes
  • bob: staked value 3000 EGLD that vote Yes
  • charlie: staked value 4000 EGLD that vote Yes
  • delta: staked value 1500 EGLD that vote No

The totals are:

  • Quorum = (2000+3000+4000+1500) = 10,500 EGLD
  • Yes = 9000 EGLD
  • No = 1500 EGLD
  • Abstain = 0
  • Veto = 0

Assume:

  • total staked in the system = 20,000 EGLD
  • MinQuorum = 20%
  • MinPassThreshold = 50%
  • MinVetoThreshold = 33%

Evaluation:

  • Quorum is satisfied: 10,500 > 4000
  • Yes > No: 9000 > 1500
  • Yes is ≥ 50% of votes: 9000 / 10,500 = 85.7%
  • Veto is below 33%: 0 < 3465

To sum it all, the proposal passes.