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

**URL:** <https://forum.balancer.fi/t/bip-921-1-bal-1-vote-reconfiguration-for-balancer-eth-snapshot-space/7052>\
**Category:** Governance\
**Created:** [May 5, 2026, 8:50am UTC](https://forum.balancer.fi/t/bip-921-1-bal-1-vote-reconfiguration-for-balancer-eth-snapshot-space/7052 "2026-05-05T08:50:48Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![maxyz.xyz](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/maxyz.xyz/32/3806_2.png) [@maxyz.xyz](https://forum.balancer.fi/u/maxyz.xyz)\
**Post date:** [May 5, 2026, 8:50am UTC](https://forum.balancer.fi/t/bip-921-1-bal-1-vote-reconfiguration-for-balancer-eth-snapshot-space/7052/1 "2026-05-05T08:50:48Z")

</div>

# Abstract

Implement the dual voting system from [BIP-919](https://forum.balancer.fi/t/bip-919-bal-tokenomics-revamp/7001). 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](https://github.com/balancer/bal-voting-power).

# 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](https://forum.balancer.fi/t/bip-906-deprecation-of-polygon-zkevm-fraxtal-and-mode/6951)) or does not have canonical BAL deployed (HyperEVM, Monad, Plasma). Polygon/Optimism/Avalanche are “under review” per [BIP-918](https://forum.balancer.fi/t/bip-918-operational-restructuring-for-balancer/7000); they remain included until formally sunset.

[`erc20-balance-of-delegation`](https://github.com/snapshot-labs/score-api/blob/master/src/strategies/strategies/erc20-balance-of-delegation/index.ts) is a default Snapshot strategy which sums raw token balance + delegated balance for that chain. Note that this is a [Snapshot Pro](https://docs.snapshot.box/user-guides/spaces/turbo-plan) strategy, and thus requires the current active subscription for it to remain active. `delegation(contract-call(BalVotingPower))` is a combination of the default [`delegation`](https://github.com/snapshot-labs/score-api/tree/master/src/strategies/strategies/delegation) and [`contract-call`](https://github.com/snapshot-labs/score-api/tree/master/src/strategies/strategies/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](https://forum.balancer.fi/t/bip-838-balancer-dao-governance-process-guidelines/6542), 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](https://forum.balancer.fi/t/bip-521-cap-individual-voter-weight-on-snapshot/5413)) 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](https://github.com/balancer/bal-voting-power/pull/3/changes)

---

<div class="post-metadata">

**Author:** ![Xeonus](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/xeonus/32/3621_2.png) [@Xeonus](https://forum.balancer.fi/u/Xeonus)\
**Post date:** [May 11, 2026, 6:06am UTC](https://forum.balancer.fi/t/bip-921-1-bal-1-vote-reconfiguration-for-balancer-eth-snapshot-space/7052/2 "2026-05-11T06:06:25Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![maxyz.xyz](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/maxyz.xyz/32/3806_2.png) [@maxyz.xyz](https://forum.balancer.fi/u/maxyz.xyz)\
**Post date:** [May 15, 2026, 5:32am UTC](https://forum.balancer.fi/t/bip-921-1-bal-1-vote-reconfiguration-for-balancer-eth-snapshot-space/7052/3 "2026-05-15T05:32:41Z")

</div>

[https://snapshot.org/#/s:balancer.eth/proposal/0xeb3d43a0e527fb7bbe9f5090d52dcae336c8904aea6d0b0237b65862157bc208](https://snapshot.org/#/s:balancer.eth/proposal/0xeb3d43a0e527fb7bbe9f5090d52dcae336c8904aea6d0b0237b65862157bc208)

---

<div class="post-metadata">

**Author:** ![QuantTrader9079](https://avatars.discourse-cdn.com/v4/letter/q/6a8cbe/32.png) [@QuantTrader9079](https://forum.balancer.fi/u/QuantTrader9079)\
**Post date:** [May 15, 2026, 10:08am UTC](https://forum.balancer.fi/t/bip-921-1-bal-1-vote-reconfiguration-for-balancer-eth-snapshot-space/7052/4 "2026-05-15T10:08:03Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![QuantTrader9079](https://avatars.discourse-cdn.com/v4/letter/q/6a8cbe/32.png) [@QuantTrader9079](https://forum.balancer.fi/u/QuantTrader9079)\
**Post date:** [May 16, 2026, 2:08am UTC](https://forum.balancer.fi/t/bip-921-1-bal-1-vote-reconfiguration-for-balancer-eth-snapshot-space/7052/5 "2026-05-16T02:08:14Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![QuantTrader9079](https://avatars.discourse-cdn.com/v4/letter/q/6a8cbe/32.png) [@QuantTrader9079](https://forum.balancer.fi/u/QuantTrader9079)\
**Post date:** [May 17, 2026, 10:10am UTC](https://forum.balancer.fi/t/bip-921-1-bal-1-vote-reconfiguration-for-balancer-eth-snapshot-space/7052/6 "2026-05-17T10:10:25Z")

</div>

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.
