Governance Process
Summary
The Balancer Governance process has evolved through a number of BIPs as Balancer moves along on its quest towards decentralization. The most recent governance overhauls — BIP-918 (operational restructuring and core team mandate), BIP-919 (tokenomics revamp), and BIP-921 (1-BAL-1-vote Snapshot reconfiguration) — superseded earlier structural changes such as BIP-163.
Balancer governance submissions consist of 2 items: an English proposal and a multisig payload that executes the changes described on-chain. Balancer Onchain Limited, through its service provider MAXYZ, is tasked with supporting community members in putting together proposals when required, and with the final evaluation and execution of approved proposals.
Operational support can be reached on the Balancer Discord or through an issue in the Balancer Multisig Ops Repo.
Post-BIP-918/919/921 update
Governance is now exercised by BAL holders since the veBAL system was deprecated by BIP-919 and Snapshot strategies were reconfigured by BIP-921. Only registered members of the balancer.eth Snapshot space can submit proposals — the previous 200,000 veBAL submission threshold has been removed, and resolutions still require forum discussion before any Snapshot submission. See the Voting page for the full strategy stack and quorum.
Governance Timeline
The following timeline requirements apply to different proposal types (per DAO Governance Guidelines):
Forum Discussion Periods
| Proposal Type | Minimum Discussion | Submission Deadline |
|---|---|---|
| General proposals | 72 hours | Tuesday 20:00 CET |
| Funding proposals | 1 week | 1 week before snapshot |
Voting Schedule
- Voting starts: Friday 20:00 CET
- Voting ends: Tuesday 20:00 CET (4 days / 96 hours)
- Quorum: 10 million BAL
Execution Timeline
Standard multi-sig execution is typically performed at the end of the month (usually the last week).
Funding Proposals
Funding proposals and real-world contracts may require additional review periods and legal sign-off, potentially extending timelines beyond minimum requirements.
Outline
This page outlines the Balancer Governance Process from Request for Comment [RFC] through executing a result.
- Post a Request for Comment to the forum
- Facilitate preliminary discussion
- Update and refine RFC to become a Proposal
- Snapshot vote
- Execute result or try again in 30 days
Step 1: Write Request For Comment (RFC)
An initial request for governance is made up of 2 potential components. An English language description of the purpose of the proposal and the details of the changes to be made, and a payload to execute such changes on chain which can be loaded into Safe if on-chain changes are required for execution. When possible, any off-chain changes to code should also have PRs linked in governance.
English Description
Start a new conversation: General Proposals with the [RFC] tag. The message should contain the following sections.
- Link to Transaction Payload PR
- The Snapshot body should begin with a link to the transaction payload PR on GitHub. If the text is too long it can be truncated. Note that if the proposal requires no on-chain actions to be executed, the payload is not required.
- Note that this link can be added towards the end of the discussion process once the proposal is moving to snapshot.
- Background and motivation
- What is the current state or what you're addressing?
- What is the reason for this?
- Why is it good for Balancer?
- Is there any relevant information that the common reader might not know?
- English Specification
- Clearly state exactly what this proposal will change and the effects it will have on the operation of the protocol or balance of the treasury.
- Dependencies(if any)
- What is needed to introduce the change?
- Risk assessment
- What can go wrong? What is the impact of your proposal on the rest of the community, ecosystem, protocol?
- For Spend (how does it affect runway)
- For other changes, explain any and all risks clearly.
- What can go wrong? What is the impact of your proposal on the rest of the community, ecosystem, protocol?
- Open Questions
- Any obvious discussions or things you are still considering?
Step 2: Discussion
- Encourage and participate in discussions on the forum.
- Promote your topics, find voters, get feedback.
- Consider contacting Delegates to obtain their support.
- Encourage interested parties on Discord to gather their thoughts in a forum post
- It is advised that proper time is given for the community to discuss a proposal before bringing it to a Snapshot vote and that the original proposer is open to making changes as part of the discussion process.
- The Operator currently performs initial validation on any submitted snapshots and gets in touch with the proposer if there are issues, inviting them to take down their vote and repost it properly to avoid an end result that cannot be executed due to lack of compliance.
Step 3: Develop and validate transaction Pull Request
NOTE: The Operator team is available to build and validate your PR. If you don't want to get involved in the technical details of defining your execution, contact the team on Discord and they will be happy to help. Signers are listed in the Multisig documentation.
A Pull Request (PR) that posts a transaction to a Safe multisig which executes the changes specified by the BIP on-chain is required as part of the body of a Proposal specified above before it can be brought to valid snapshot.
The file(s) should be added into their own directory here on the Multisig Ops Repo. Once the BIP is ready to go to Snapshot vote and a BIP number is selected, the files will be moved into the BIPs directory following the apparent pattern there. The description of the pull request should contain a link to the Forum Post with the English Specification of it. The Operator will review the payload and post any concerns or questions in review.
Examples of how to submit payload PRs for common governance quests can be found HERE
Step 4: Voting
Voting takes place on Snapshot in the balancer.eth space. Voting power is denominated in raw BAL across seven production chains via a seven-strategy stack; on Ethereum, BAL underlying 80/20 BAL/WETH BPT (held directly or locked in veBAL) is also counted at face value. See Voting for the full strategy stack, the BalVotingPower contract, and per-chain delegation mechanics.
- Quorum: 10M BAL (converted from the previous 2M veBAL).
- Individual voter cap: removed (the 45% delegation cap from BIP-521 is no longer in effect).
A Snapshot vote that does not meet all governance specifications will not be considered valid even if it wins a majority. Please take your time when posting proposals.
If a Snapshot is approved but rejected for technical reasons, the team will help fix the payload and facilitate a re-vote.
If a vote fails in an approve/reject vote it will not be executed. Proposers are encouraged to wait at least 30 days and/or until something significant has changed before posting another vote. Delegates with sufficient voting power are asked to be considerate about creating governance noise by reposting failed votes in rapid succession.
Step 5: Execution
If the vote succeeds, follow through to make sure that it is properly executed. Depending on what the vote is about, it may require an action by the multisig. Balancer Onchain Ltd is responsible for organizing the on-chain execution of governance and work toward making their process as transparent as possible in the public Balancer Multisig Ops GitHub repository.
Assuming all reviews are finished and dependencies are met, the team will make every effort to execute on finished proposals in the same week that governance concludes. Note that in some cases complex BIPs may require more time for final multisigner review.