[BIP-921] 1-BAL-1-Vote Reconfiguration for `balancer.eth` Snapshot Space

Abstract

Implement the dual voting system from BIP-919. Replace the two veBAL-based Snapshot strategies with a seven-strategy stack denominated in raw BAL across all production chains with BAL deployed.

Voting Power Formula (BalVotingPower.sol)

Instead of giving voting power based on (decaying) veBAL balances, the DAO switches to a simple “1-BAL-1-Vote” model based on raw BAL balances and delegations across all production chains. In addition, BAL underlying any 80/20 BAL/WETH BPT position is included, both held directly and locked in veBAL (face value, i.e. decay ignored).

For voter u at the snapshot block:

  • Every chain: BAL.balanceOf(u) + delegated-in raw BAL (per chain’s Snapshot Delegate Registry)
  • Ethereum only: + BAL underlying 80/20 BAL/WETH BPT held by u
  • Ethereum only: + BAL underlying 80/20 BPT locked in veBAL by u

This formula is implemented in a stateless, ownerless, singleton view contract on Ethereum. It has one function: votingPower(address) which returns uint256. See GitHub - balancer/bal-voting-power · GitHub.

Strategy Stack

Chain Strategy (BAL) Address
Ethereum delegation(contract-call(BalVotingPower)) 0x411e723E6652347FF3Dd31749913A834e3D43DB4
Gnosis erc20-balance-of-delegation 0x7eF541E2a22058048904fE5744f9c7E4C57AF717
Arbitrum One erc20-balance-of-delegation 0x040d1EdC9569d4Bab2D15287Dc5A4F10F56a56B8
Base erc20-balance-of-delegation 0x4158734D47Fc9692176B5085E0F52ee0Da5d47F1
Polygon (PoS) erc20-balance-of-delegation 0x9a71012B13CA4d3D0Cdc72A177DF3ef03b0E76A3
Optimism erc20-balance-of-delegation 0xFE8B128bA8C78aabC59d4c64cEE7fF28e9379921
Avalanche (C-Chain) erc20-balance-of-delegation 0xE15bCB9E0EA69e6aB9FA080c4c4A5632896298C3

Any other chain Balancer is deployed on is excluded because it is either deprecated (zkEVM, Fraxtal, Mode; BIP-906) or does not have canonical BAL deployed (HyperEVM, Monad, Plasma). Polygon/Optimism/Avalanche are “under review” per BIP-918; they remain included until formally sunset.

erc20-balance-of-delegation is a default Snapshot strategy which sums raw token balance + delegated balance for that chain. Note that this is a Snapshot Pro strategy, and thus requires the current active subscription for it to remain active. delegation(contract-call(BalVotingPower)) is a combination of the default delegation and contract-call strategies. It simply calls the votingPower(address) function on the BalVotingPower contract mentioned above, adding any delegated voting power.

Threshold Changes

Quorum for a vote to be valid is simply converted from the current 2M veBAL to 10M BAL (rough scaling vector of 5x). The minimum voting power required to submit a proposal is removed; only registered members of the balancer.eth space can submit proposals. As per BIP-838, new governance proposals have to pass through the forum anyway before they can be submitted, so submitting a proposal to Snapshot directly is outdated. Lastly the 45% delegation cap (BIP-521) is removed.

Delegation

Per chain via Snapshot’s native Delegate Registry (0x469788fE6E9E9681C6ebF3bF78e7Fd26Fc015446, deterministic on all supported chains). Holders delegate once per chain they hold BAL on. Note that existing delegations for the current veBAL-based strategies will not carry over!

Technical Specifications

Update the balancer.eth Snapshot space to use the following new configuration JSON: feat: new snapshot config by gosuto-inzasheru · Pull Request #3 · balancer/bal-voting-power · GitHub

3 Likes

After looking into a few options, I believe that this setup makes the most sense based on our new governance setup outlined in [BIP-919]. The new configuration incl. the new strategy elegantly puts this into place. I personally like that one can now vote with BAL from any chain.
In full support!

https://snapshot.org/#/s:balancer.eth/proposal/0xeb3d43a0e527fb7bbe9f5090d52dcae336c8904aea6d0b0237b65862157bc208

Quorum requirements are tricky to get right. Too high and nothing passes. Too low and small groups can push through self-serving proposals. Dynamic quorum based on proposal impact seems like the right approach.

Restaking is creating interesting dynamics. The ability to use the same staked capital to secure multiple protocols is capital-efficient but introduces correlated risk. The tradeoffs need careful analysis.

To add another perspective: one thing that gets overlooked in governance discussions is voter fatigue. When there are too many proposals, participation drops. Batching related proposals or having sub-committees handle routine decisions could help.