Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/fuseio/fuse-docs/llms.txt

Use this file to discover all available pages before exploring further.

Fuse Network governance is on-chain, meaning that changes to core network contracts are decided by validator votes rather than by a centralized authority. Any validator can open a ballot proposing a new contract implementation, and the outcome is enforced automatically by the protocol once the vote closes.

Governance actors

Governance is currently shared between three groups: Network validators vote on Fuse Improvement Proposals (FIPs) and on ballots to upgrade core contracts. Every validator has one vote regardless of stake size. Fuse Foundation and project team — Gibraltar-incorporated Fuse Network Limited — manages the core network protocol development and the Fuse treasury (primarily undistributed genesis FUSE supply). The project team implements network protocol updates that validators adopt and maintains the full-node software. No permission from the project team is needed to build on or integrate with Fuse. The broader community can participate by submitting FIPs, commenting on proposals, and delegating stake to validators whose governance positions they support.

What can be governed

The Voting contract (0x4c889f137232E827c00710752E86840805A70484) controls upgrades to four contract types:
Contract typeIDWhat it controls
Consensus1Validator set selection, staking mechanics, delegation
BlockReward2Yearly inflation rate, reward distribution logic
ProxyStorage3Implementation addresses for all core contracts
Voting4The governance process itself
All core contracts use upgradeable proxy patterns. Changing an implementation requires a successful ballot — no admin key can bypass the voting process.

Fuse Improvement Proposals (FIPs)

A FIP is a design document that describes a new feature or change to the Fuse Network. FIPs provide motivation, technical specifications, and context for the community. See FIP-1 for the full process definition.
FIPDescriptionStatus
FIP-1Introduction and explanation of the FIP processDone
FIP-2Enabling delegation of FUSE tokens to validatorsDone
FIP-3Lowering the minimum stake to run a validator node to 100K FUSEDone
FIP-4Multi-validators: validators can run multiple nodesUndone
FIP-5Validator key splitting: separated keys per validatorUndone
FIP-6Bridge implementation changeable by votingUndone
FIP-7Tiny Ethereum Network transactions on end of cycleUndone
FIP-8Adjusting block rewards by the validator’s stakeDone

How on-chain voting works

Validators interact with the Voting contract to open and vote on ballots.

Ballot parameters

ParameterDescriptionConstraints
startAfterNumberOfCyclesCycles to wait before voting opensMinimum 1
cyclesDurationHow long the ballot remains openMinimum 2, maximum 14 cycles
contractTypeWhich contract the ballot targets1–4 (see table above)
proposedValueAddress of the new contract implementationMust be a deployed contract
descriptionHuman-readable reason for the changeFree text
Maximum open ballots across the network: 100. Maximum open ballots per validator: 100 ÷ number of active validators.

Participating in governance

1

Deploy a new contract implementation

Write, test, and deploy the new implementation contract to Fuse Network. Record its address — this becomes the proposedValue in your ballot.
2

Open a ballot

As a validator, call newBallot on the Voting contract with the parameters above. The ballot opens for voting after startAfterNumberOfCycles cycles have passed.
3

Vote on open ballots

Any address can call vote(id, choice) on the Voting contract while a ballot is open:
  • choice = 1 — accept
  • choice = 2 — reject
Everyone can vote, but only validator votes count toward the final result when the ballot closes.
4

Check the outcome

After the ballot closes (at cycle end), call getQuorumState(id) to retrieve the result:
  • 1 — in progress
  • 2 — accepted
  • 3 — rejected
Use getAccepted(id) and getRejected(id) to see the vote tallies.
Ballots open and close at cycle boundaries. A ballot opened mid-cycle will not begin accepting votes until at least one full cycle has passed. Plan proposal timelines accordingly.

Checking active ballots

Call activeBallots() on the Voting contract to retrieve an array of currently open ballot IDs. Use getBallotInfo(id, address) to inspect the details and current vote state of any ballot.

Build docs developers (and LLMs) love