[BIP-163] Restructure Governance Process - Disband Governance Council

[Tritium]

[RFC] Restructure Governance Process - Disband Gov Council

TL;DR:

This BIP focuses around the process by which BIPs move from the Forum to Snapshot, and how approved snapshots are implemented on-chain.

First and foremost, if passed, it provides a single place with a consolidated statement of the current governance process (see Specification)

In doing so it:

• Disbands the Gov Council and allows any address with over 200,000 veBAL in delegation to post a snapshot.
• Sets more clear rules for what makes something fit for governance, and how snapshots must be posted.
• Clearly lays out the process for validating and implementing approved governance matters, and who is responsible for conducting said process.

Motivation

The motivations of this BIP are 2-fold:

1. Increase decentralization in Balancer governance.
2. Create more separation of concern between the governance decision making process and the risk-aware implementation of decided proposals.

Background:

Decision Making:

The Governance Process Revamp originally appointed a governance council with the mandate to ensuring “soft community consensus” before bringing a proposal to snapshot. In February 2022, Governance Process Revamp 2.0 proposed that “soft-consensus” was too subjective of a measurement, giving the council too much power vs veBAL Voters. It moved the councils mandate to ensuring that a proposal was “well-defined” in that it:

• Includes Motivation, Specification, and Risk sections.
• Includes an exact specification of any on-chain calls that need to be made, which include exact details of the calls to be run in english with required addresses and calls.
• Communicates clear and specific intent (not spam)
• Follows the rules set forth by and does not conflict with outstanding governance proposals.

In an effort to further decentralize, and with significant precedent for “well-defined” in place, it is unclear why a specific council is required to assert these things before bringing an item to snapshot. Further, there have been some murmurings in recent governance discussions of the Gov Council using their power to steer the governance process towards a specific outcome.

In the end, governance exists to enact the will of veBAL holders. Large governance participants and/or delegates seem to have sufficient vested interest in the protocol to treat the governance process with respect and not spam governance with incomplete and/or deceptive proposals.

Proposal Implementation:
The Balancer Maxis are responsible for facilitating the on-chain implementation of governance and operation of the protocol. In doing so, they currently must translate the specification of each governance topic into a a specific set of instructions (taking form of a Gnosis Safe Transaction Builder JSON file), validate that it does not create unreasonable risk for the protocol, load it into the safe, and coordinate with the respective signers to execute.

The Maxis and the Governance Council currently have the overlapping membership, so the process of ensuring that the specification is clear enough to generate such a JSON naturally occurs during the forum discussion. The specification often needs to be changed by the original proposer accordingly or needs change by the Maxis to ensure that exact implementation to spec is possible.

Specification

Proposal Requirements:

The following, posted to either the General Proposals or the BAL Gauges section of the Balancer Forum, is required for a proposal to go to snapshot:

• Includes Motivation Section: What is the reason for this, why is it good for the veBAL ecosystem?
• Includes 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.
• Includes multisig transaction payload: A compete Gnosis Safe Transaction Builder JSON. The Balancer Maxis can show you how to build this or put it together for you if you need help.
• Includes Risks: What risks does this pose to the protocol?
  • For Spend (how does it affect runway)
  • For Gauge Votes (consider pool makeup and caps as per the Gauge Framework and/or community discussion)
  • For other changes explain any and all risks clearly.

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 trade through it?

Submitting the Transaction Payload File(s) to github:

A PR must be created to the BalancerMaxis/multisig-ops repository on Github. Instructions and examples for how to build various transaction payloads and upload it to Github can be found HERE.

If not using examples. Here is a clearer spec:

• BIPs that require transactions against a single multisig should have their payload file uploaded named like BIP-XXX.json or BIP-XXX.csv directly into the /BIPs folder of this repo.
• BIPs that require transactions against multiple multisigs should have a directory named BIP-XXX with files for each multisig placed in this directory. Files should be named like [chain]-[multisig].[extention] where chain is like mainnet, arbi, polygon, etc and multisig is like dao, gauge, fees, etc.

Posting the Proposal to Snapshot:

Any address with over 200,000 veBAL held or in delegation may create a new snapshot vote directly on the snapshot forum. With great power comes great responsibility. Snapshot posters are expected to ensure the following:

• The Snapshot body should begin with a link to the transaction payload PR on github. Followed by the full text of the BIP. 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.
• 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 Poster 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.

NOTE: The technical process of defining and applying governance on-chain is likely to shift over time. A pull request of verifiable code to the Github repo listed below shall be considered the formal way to submit a payload. Details on additional types of payloads (other than transaction builder JSONs and airdrop CSVs) may be added. The main README for this repo will be kept up to date with information and specifications about how to create and submit payloads.

Execution of Proposals approved by governance:

If the BIP passes, the Balancer Maxis will make every effort to confirm that the payload and the English definitions match, load the specified payloads into the appropriate multisig, and coordinate with signers for execution.

Following execution. The Maxis will comment on the forum post for the proposal and include a link to any transactions relevant to execution at the bottom of the body.

The Maxis may send the proposal back to the proposer for revision and a new snapshot (with the same BIP number) for the following reasons:

• The Payload does not match the english specification

• The Payload is not in a recognisable/verifiable form by the Maxis.

  • Tx Builder JSON files and airdrop CSVs are always ok.

• The Payload does simulate successfully in tenderly and/or produce the desired results on fork.

  • In this case the Maxis will help to fix the payload and facilitate a revote to approve.

• The snapshot did not conform the the guidelines defined directly above.

  • Start/End Time
  • Quorum
  • Necessary Content

The Gov Council therefore has no remaining purpose and is dissolved.

Technical Specification:

If this vote passes, the proposal validation setting in the balancer snapshot space settings should be configured to match the following. Note that we are currently working with snapshot to add the ability to restrict voting to be started on a specific day of the week. If more options become available to better validate inputs against the policies stand here before posting a snapshot, they may be applied without further governance:

Community Conversation, Revision and Alpha Testing:

Over the next week or two, as the community discusses this change the text of this BIP may be adapted. Additionally, I will work to build set of resources that explain the basics of how Balancer On-chain Governance works and provides template proposals and JSON files for various types of commonly requested governance. I will post links to these resources as links in this section of the Forum Post as they become available.

It would be very helpful to work with some Governance Proposers on to demonstrate the new BIP format in upcoming governance. If you’re interested in getting involved and bringing something to Balancer governance, please get in touch. You can message me here or find me on the Balancer Discord.

[Xeonus]

https://snapshot.org/#/balancer.eth/proposal/0xcd2cab0522b0e9a90ad40f93aca4505b17d60468224c22b69c4f9bd2bbd64e31

[solarcurve]

Apologies for not publicly commenting on this, which I can imagine must look strange given this is a very big governance change.

Myself and the other Maxis have worked closely with Tritium on this, tested out the processes outlined, etc.

Bit of historical context for folks might also be helpful. Back in the day it was decided to decentralize Balancer governance and allow the community to post proposals on snapshot. This prompted me to draft “Governance Process Revamp”, which created the Governance Council (GC). Included was a requirement that the community must reach “soft consensus” before a proposal could go to a vote.

Some time later it was realized the community might not always agree on something and a few determined ppl can give the appearance that soft consensus was not reached, or at least make it very difficult to come to an objective conclusion on whether it has been reached. This prompted me to draft “Governance Process Revamp 2.0” which removed the requirement of “soft consensus”, effectively opening the door for anyone to propose anything (that Balancer governance has the power to implement) and have it go to a vote.

This has led to some famously contentious proposals going to a vote which would have otherwise been blocked by lack of “soft consensus”. I would argue it’s very important to the value proposition of veBAL that nothing can stop a proposal that can be implemented from going to a vote. Only by voting can we truly know what veBAL voters support and that’s the only way to move forward as an ecosystem. Contentious issues inevitably will arise and they must be resolved by a vote. This is the sanctity of Balancer governance that has to be protected.

Despite the lack of any decision making authority on the part of the GC there remains a perception that the GC controls governance. BIP-163 removes that perception by dissolving the GC and replacing it with a threshold of 200k veBAL, which someone must own outright or have delegated to them in order to post snapshot proposals.

The fact that only proposals which Balancer governance has the capability to implement are valid is not changing and cannot change. Yes, someone could start a vote where this is not the case and it could pass - however, nothing would happen and nothing would be implemented.

The Maxis will fill the role of “verifier of last resort” to ensure Balancer’s governance process can continue to operate without any impediments. Many people who make proposals would not have the technical knowledge to write a correct specification and I believe that should not be a blocker the community has to deal with. In the case that a proposer cannot write the specification themselves the Maxis will step in to help and verify its accuracy. Obviously if a proposer can do this themselves all the better, and Maxis will simply verify its accuracy.

Functionally I would argue this BIP changes nothing, aside from putting forward some processes we believe are useful in a fully decentralized governance system. Today anyone can propose anything that Balancer governance has power to implement and it will go to a vote. After this BIP passes that will still be the case. Only difference is the GC disappears which is a very good thing as it removes any appearance of governance control by the Maxis, which could not be further from the truth. Maxis have virtually zero governance control as our entire voting stakes are delegated to us by other veBAL holders and can be rugged at anytime. We have zero decision making authority on what goes to a vote and we have never had such authority.

“Always has been”