Governance

The Mana DAO is a decentralised collective of MANA token holders and contributors who work together to shape the future of the protocol through a structured governance process. This community-driven model enables participants to propose, discuss, and vote on critical changes, guiding the evolution of the protocol and aligning with the collective goals of its members.

The Mana Protocol is governed by the MANA token holder community (MANA and stkMANA on Binance Smart Chain) through procedures, voting, and smart contract execution, collectively known as Mana Governance.

Processes

Mana's governance process is structured so that the protocol remains decentralised, secure, and adaptable. The lifecycle of a proposal is carefully designed to allow community members to present ideas, vote on them, and execute approved changes through a transparent and structured process.

Proposal Lifecycle

1. Governance Forum The proposal process begins with an idea introduced to the Mana Governance Forum. This is where initial discussions take place and feedback is gathered. The community helps refine the proposal before moving to the next stage.

2. Temp Check (Snapshot Voting) After discussion, the proposal proceeds to a TEMP CHECK via the Mana Snapshot Space. This informal vote gauges community sentiment. TEMP CHECK votes are non-binding but help determine if there is sufficient interest in moving forward. Proposals in this stage do not require detailed technical specifics.

3. MRFC (Mana Request for Final Comments) If the TEMP CHECK passes, the proposal moves to the MRFC stage, where it undergoes more formal scrutiny. Service providers and community members contribute detailed feedback on how the proposal would impact the protocol, preparing it for the MIP stage. MRFC voting also occurs on the Mana Snapshot Space.

4. MIP (Mana Improvement Proposal) The MIP stage is where the proposal becomes a formal, onchain submission. It includes two parts: metadata (stored on IPFS) and the contract payload. These are submitted through Mana's governance contracts, primarily on the BSC.

5. Voting Once submitted, the MIP enters a PENDING status before becoming ACTIVE for voting. Voting is conducted onchain through Mana governance contracts. A proposal succeeds if it meets quorum and vote differential requirements. If these thresholds aren’t met, the proposal fails.

6. Execution A successful proposal moves to the execution phase, where it is enacted via Mana's governance infrastructure. Depending on the type of proposal, a timelock delay (either one day or 7 days) is imposed before the changes are implemented.

Voting

Off-chain Voting (Snapshot)

Off-chain votes are used to measure community sentiment during the early stages of proposal development (Temp Checks and MRFCs). These non-binding votes take place on Snapshot and last for three days, allowing token holders to participate without transaction fees.

Onchain Voting (Governance Interfaces)

Once a proposal reaches the MIP stage, onchain voting is required. Token holders, delegates, or delegators vote on proposals using their MANA and stkMANA tokens. The process is secured through various governance interfaces, including Mana Devs Lending interface.

Voting is performing by calling the submitVote() function on the Governance conctract on BSC.

Voting Power

MANA and stkMANA (MANA staked in protocol safety module) token holders receive governance powers proportional to the sum of their balances on BSC.

There are two powers associated with each governance token:

• The proposal power that gives access to creating a proposal.

• The voting power which is used to vote for or against active proposals.

Governance powers can be either jointly or separately delegated to any BSC address.

Proposal Lifecycle

1. Payload Registration: Proposal contract containing executable logic are deployed. This process is permissionless.

2. Proposal Creation: A proposer with sufficient proposal power creates the proposal on BSC by interacting with the Governance contract. The proposer specifies the executor contract and proposal contract.

3. Proposal Activation: After a voting delay period (votingDelay), the proposal is activated. This involves taking a snapshot of the BSC's state.

4. Voting Period: Voting occurs on BSC. Voters submit their votes by calling submitVote() on the Governance contract, providing their token balances at the snapshot block.

5. Vote Closure: After the voting duration (voteDuration) elapses, voting is closed. The Governance contract on BSC validates the voting results against success metrics, such as minimum thresholds and vote differentials.

6. Proposal Queuing: If the proposal meets the success criteria, any address can move the proposal to Queued state by calling queue() on the Governance contract.

7. Proposal Execution: After the execution delay, any address can execute the proposal by calling execute() on the Governance contract.