Balancer DOCS

Governance Process

Summary

The Balancer Governance process has evolved through a number of BIPs as balancer moves along on it's quest towards decentralization. The most recent governance overhaul BIP at the time of this writing is BIP-163open in new window.

Balancer governance submissions consist of 2 items, an English proposal and a multisig payload that executes the changes described onchain. The Balancer Maxis, who can be found on the Balancer Discordopen in new window or contacted through an issue in the Balancer Multisig Ops Repoopen in new window are tasked with supporting community members in putting together proposals when required, and with the final evaluation and execution of approved proposals. Below are more details on the governance process as of BIP-163.

img.png

Outline

This page outlines the Balancer Governance Process from Request for Comment [RFC] through executing a result.

  1. Post a Request for Comment to the forum
  2. Facilitate preliminary discussion
  3. Update and refine RFC to become a Proposal
  4. Snapshot vote
  5. 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 gnosis-safe if onchain 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 Proposalsopen in new window or veBAL Gauge additionsopen in new window 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 onchain 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 the veBAL ecosystem or the Balancer Protocol?
    • 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 Gauge Votes (consider pool makeup and caps as per the Gauge Framework defined in BIP- and/or community discussion) For other changes explain any and all risks clearly._
  • Open Questions
    • Any obvious discussions or things you are still considering?

Further, votes requesting new gauges should include the following information:

  • What are the initial fees set to, and what is the reasoning for this?
  • If stableswap, how is the A-factor set and why was the given a-factor chosen?
  • If custom pool, how does this pool generate revenue? Is 50% of the revenue generated sent to the fees collector? Where can details about the performance of this pool be found? Where can users deposit into it and swap through it?

Step 2: Discussion

  • Encourage and participate in discussions on the forum.
  • Promote your topics, find voters, get feedback.
  • 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 that the original proposer is open to making changes as part of the discussion process.
  • The Balancer Maxis currently perform initial validation on any submitted snapshots and get 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 can not be executed due to lack of compliance.

Step 3: Develop and validate transaction Pull Request

NOTE: The Balancer Maxis are also 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 Balancer Maxis and they will be happy to help. They can be found in the Balancer Discordopen in new window and are listed in the HEREopen in new window

A Pull Request(PR) that posts a transaction to a gnosis safe multisig which executes the changes specified by the BIP onchain 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 Repoopen in new window. Once the BIP is ready to go to Snapshot vote and a BIP number is selected, the files will be moved into the BIPs directoryopen in new window 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 Balancer Maxis 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 HEREopen in new window

Step 4: Snapshot

The Snapshot process is started when an address with at least 200,000 veBAL in delegation posts a snapshot to the forum that meets all of the required specifications as defined in BIP-163open in new window.

  • The Snapshot body should begin with a link to any required transaction payload PR on github. Followed by the full text of the BIP. If the text is too long, it can be truncated.
  • A link to the forum discussion should be included in the discussion (optional) field of Snapshot.
  • The BIP is titled like BIP-[XXX] Title from Forum, where XXX is the next number in the BIP sequence.
    • The original forum proposer should update their post to match the title from the Snapshot and include a link to it at the bottom of the body of the Forum Post.
  • Barring clear community consensus otherwise the vote Should be of Type “Basic Voting” and the choices should be one of [Yes, let’s do it - No, This is not the way - Abstain].
  • Runs for 96 hours starting on a Thursday (GMT).
  • Has a quorum of 2 million veBAL.
  • The linked payload matches the english specification and fails review and is in a recognizable/verifible form by the Maxis.
  • The linked payload simulates successfully in tenderly and/or produce the desired results on fork.

IMPORTANT: A Snapshot voting that does not meet all of the above requirements will not be valid even if it wins a majority of the votes. Please take your time when posting Snapshots. A number of the Balancer Maxis have delegations of over 200k veBAL and would be happy to help you post your Snapshot if you are unsure and it has some community support.

If a Snapshot is approved by governance but rejected for technical reasons, the Maxis will help to fix the payload and facilitate a revote to approve.

Step 5: Results and Execution

If the vote fails in an approve/reject vote it will not be executed on. Proposes are encouraged to wait at least 30 days and/or until something significant has changed before posting another vote, and delegates with sufficient veBAL to post votes are asked to be considerate about creating governance noise and SPAM by reposting failed votes in rapid succession.

If the vote succeeds or a result has been chosen, 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. The Balancer Maxis are currently responsible for organizing the onchain execution of governance and are working toward making their process as transparent as possible in the public Balancer Multisig Ops Github Repoopen in new window

Assuming all reviews are finished and dependencies are met, the Maxis will make every effort to execute on finished in the same week that governance concludes. Note that it some cases complex BIPs may require more time for final multisigner review.

The Maxis will endeavor to post a comment to the Forum post with a link to the execution TX upon execution.