Introduction
On Monday afternoon, during a knowledge-sharing session between Balancer Labs’s engineers, we realized that the veCRV smart contracts that form the basis of the veBAL system operate differently from our initial expectations.
No user funds are at stake, nor is any immediate action from Liquidity Providers required. The veBAL contract also remains safe and will continue to allow current and future holders to vote on the allocation of weekly BAL emissions for Balancer pools.
Our initial understanding was that the gauge type weights (_get_type_weight
) in the Gauge Controller contract would allow us to implement classes of gauges, such that the share of emissions directed to each class (a “gauge type”) would be controlled by Balancer governance (see the Gauge types section of the veBAL Tokenomics proposal[1]).
The intended outcome was for BAL emissions to be allocated as follows:
- 10% to veBAL holders
- 56% to Ethereum Pools
- 7% to Arbitrum Pools
- 17% to Polygon Pools
- 10% to the Liquidity Mining Committee, for partnerships
veBAL holders would then vote on-chain on how to distribute the 56/17/7% allocations among Liquidity Pools in those networks.
In reality, such implementation is not possible in the original veCRV system. Implementing this would require substantially changing the system, reducing compatibility with apps built on top of Curve’s ecosystem - one of the key expected benefits outlined in the veBAL proposal.
What this means for the veBAL system as currently deployed is that:
- mainnet gauges have been minting ~100% of weekly emissions instead of 56%; and
- contrary to our original intent/expectations, no other gauges will be able to mint any significant amounts of BAL on April 14th.
We’ll be conducting a thorough post-mortem to identify what we could have done differently, and make changes to our internal processes so as to prevent this from happening again. In the meantime, the Balancer community must now make a decision.
Specification
This proposal provides two options below for how governance can proceed. In both options the LM committee is proposed to be eliminated as everyone showed support for this (even the LM committee itself).
Option 1: keep the system as it is
This means that through the on-chain gauge voting mechanism, veBAL holders have full control over the allocation of weekly BAL emissions. Gauges would be created so that veBAL holders would be able to direct incentives to themselves (that is, to all veBAL holders) or to pools on Polygon and Arbitrum, in addition to the existing gauges on Ethereum mainnet.
A 10% cap would be imposed on weekly emissions to veBAL holders, with any excess being sent to the Balancer DAO treasury.
Pros:
- No redeployment or migration necessary: LPs wouldn’t have to take any action.
- The system would become more similar to Curve’s, which has no weekly allocation to veCRV holders. Balancer would still have this options available, but the amount would be defined directly by veBAL voting (up to the 10% cap) instead of being fixed at 10% as initially proposed.
Cons / Risks:
- The original fixed weight distribution to veBAL holders won’t be possible. It will still be possible to achieve this through veBAL votes, but the outcome would no longer be predictable. The veBAL gauge may get less than 10% of the votes, leading to fewer tokens being allocated to veBAL holders, or more than 10%, reducing the size of liquidity incentives for Pools (funding the DAO treasury in the process).
Option 2: deploy a new version of the gauge system
This is the closest we can get to a system that behaves as described in the veBAL proposal without significant changes to the veCRV system.
- The current BAL Minter contract would have its minting permission revoked.
- Three new BAL Minter contracts would be deployed, enforcing that 10% of emissions are allocated to veBAL holders, and 90% are controlled by veBAL holders through the on-chain gauge voting mechanism.
- A new GaugeController and a new GaugeFactory for mainnet pools would be deployed.
- The existing veBAL contract would have voting power over this new GaugeController: no migration is needed on the part of veBAL holders.
It would still not be possible to implement the 56/17/7% split between mainnet/Polygon/Arbitrum as outlined in the veBAL proposal. The distribution across the 3 networks (and any additional network Balancer may be deployed to in the future) will be fully defined by veBAL voting power (this is also true in option 1).
Pros:
- The original fixed allocation to veBAL holders in the veBAL proposal would be achieved: veBAL holders would get 10% of weekly emissions.
Cons / Risks:
- This will require a migration of staking positions. New gauges would be deployed on mainnet to replace the existing ones. Liquidity providers would be required to unstake from the current gauges and stake into the new ones in order to continue to receive incentives (as part of this proposal, the Balancer treasury would reimburse the gas costs of these operations).
Liquidity providers that don’t migrate before a transition period finishes would not get BAL until they do so. - Current votes would be lost and veBAL holders would have to recast their votes to mainnet gauges (the impact of this could be low, assuming most would recast anyway when L2 gauges were to be released).
- The gauge for the wstETH/WETH pool is also receiving LDO on top of BAL from the veBAL program. As LPs unstake from this gauge to stake in the new one, they would lose any potential LDO for the remainder of the week.
An airdrop of BAL through a Merkle Orchard (the legacy LM distribution system) would happen for those who did not claim their BAL from LM in the current system before the migration, along with a reimbursement for migration gas costs. LPs that migrate to the new gauges will be accounted for as if they had not unstaked from the current gauges.
Implementation
The governance multisig needs to call the authorizer[2] with the following inputs: authorizer.grantRole(0x0000000000000000000000000000000000000000000000000000000000000000, coordinator)
, which means it will grant full admin powers to the coordinator smart contract.
Since the coordinator hasn’t been deployed yet, its address is not known. However, the Balancer community will be able to verify the coordinator address by that date on Balancer’s github in the deployment output folder[3]. This link will point to a json file with entry veBALGaugeFixCoordinator
followed by the coordinator’s address on mainnet:
{ veBALGaugeFixCoordinator: 0xabced...., }
After applying the necessary changes voted, the coordinator will renounce all given permissions and will not be usable anymore.
Coordinator Actions
The actions to be performed by the coordinator depend on the option chosen by the community.
Option 1
The coordinator will mint the missing 98.6k BAL meant for veBAL holders, as well as Polygon and Arbitrum LPs. These tokens will be sent to the recipient contracts of the gauges, resulting in the same outcome as if the gauges had minted the tokens.
Then, the gauge type weights for all types will be set to the same value, making votes for all gauge types have the same relative weight. veBAL holders will need to vote for the veBAL gauge in order for it to receive tokens.
The coordinator will also set the gauge type weight for the Liquidity Mining Commmittee type to 0 and kill the gauge.
Option 2
The coordinator will mint the missing 98.6k BAL meant for veBAL holders, as well as Polygon and Arbitrum LPs. These tokens will be sent to the recipient contracts of the gauges, resulting in the same outcome as if the gauges had minted the tokens.
Additionally, it will mint all unminted BAL tokens that correspond to L1 LPs in order to airdrop them as part of the migration. Then, it will revoke minting permission from the current Balancer Minter contract, effectively disabling the Liquidity Mining program in its current configuration and preventing any further minting from the existing gauges.
With the old minter contract disabled, it will grant minting permissions to three new contracts: one that will always mint 10% of weekly emissions for veBAL holders, one that will always mint 10% of weekly emissions for the Liquidity Mining Committee (unless the community decides to not continue with this initiative), and one that will distribute the remaining percentage to liquidity gauges. A new GaugeController will be connected to this minter, meaning veBAL holders will need to recast their votes, and new liquidity gauges will in turn be connected to the GaugeController, meaning LPs will need to unstake from the old gauges and stake in the new one (this gas cost would be later reimbursed).
The coordinator will also set the gauge type weight for the Liquidity Mining Commmittee type to 0 and kill the gauge.
Keeping promises
Liquidity providers on Polygon and Arbitrum have been expecting to receive 24650 BAL and 10150 BAL per week for liquidity provided between April 4 and April 17. Similarly, veBAL holders have been expecting 14500 BAL per week starting on April 7.
Until this proposal has been discussed and voted on, those amounts would be honored. Governance would mint 98.6k BAL to be retroactively distributed to veBAL holders and liquidity providers on Polygon and Arbitrum, covering the period between April 4th and April 21st.
No minting would be required to cover the Liquidity Mining Committee’s share of emissions for the week between April 7 and April 13, as no commitments were made regarding distributions for that week. If needed, 14.5k BAL could be minted if there’s a need to allocate BAL through the committee for the week between April 14 and April 20, but given that a gauge migration is one of the possible outcomes of this proposal it would be best to avoid allocating additional reward tokens to the existing gauges.
References
[1] Introducing veBAL Tokenomics
EDIT: I swapped the LM percentages of Polygon and Arbritrum by accident, now they are correct.
EDIT 2: Added “Implementation” section. LM committee is now eliminated in both options.