TL;DR:
- Automation for core pool incentives. See code here and results from last round here.
- Reduction of threshold to receive voting incentives for an epoch from $5000 in accumulated fees to <$1000.
- Equal handling of incentive disbursements for Mainnet and L2s
- Core Pool incentives always flow to the pools that generated the fee, no handling by TVL.
- Mainnet pays 50% of protocol fees to core pools independent of the pool fee source which results in a 20% increased fee flow to core pool voters
Motivation
The Core Pools program was first initiated in July 2022. The original proposal underwent many iterations, making it less and less reproducible. As more chains have been added, the current system has too many moving parts and manual touch-points to maintain well. This BIP seeks to consolidate learnings and the current state of the incentive program, while simultaneously introducing a new automated system for handling fee redirection.
History and Context
The Core Pools program fundamentally specifies that certain pools would have the portion of protocol fees due to veBAL holders being redirected as vote incentives. By incentivizing voters for voting on such pools through the fees generated, the proposal aligned short-term incentives with the sustainability of the protocol, creating a flywheel fueled by incentives for veBAL holders to direct BAL emissions to the most lucrative pools on Balancer.
The designation of Core Pools has generally been defined in various governance matters and through ongoing operations as pools that have at least 50% of their allocations containing yield assets with rate providers and paying protocol fees. Additionally, a number of pools have been explicitly added to the list by governance.
The degree to which fees have been directed has varied but as of BIP-371 they stand such that L1 Core Pools & L2’s pay 50% of their collected protocol fees to support Core Pools on the chain they originate from. In the case of L1’s this has always been paid to the pool that generated the fees. In the case of L2’s various strategies were used, but often much of the available voting incentives have been allocated based on the relative TVL of the pools in each chain.
As the calculation of core pool voting incentives has so far been a manual process completed on a spreadsheet, the addition of “whitelisting” pools has been done by the Balancer Maxi’s prompted by a mixture of biz dev conversation and discovering new pools that were generating large enough fee-flows to work within the program.
Related to this manual calculation, the Core Pools program has so far not worked well for smaller pools. Currently, fees are only swept from pools if they amount to more than $5,000 USD. As a result, pools that generate under 5k USD per 2 week fee collection epoch often would have to wait a number of weeks or even months before enough fees accumulated to place a single voting incentive lasting 2 weeks.
Work has been ongoing to automate the calculation of these flows, and the system is in good shape to start being used. This BIP introduces and specifies the new automated system for allocating core pool voting incentives, and describes:
- The logic it follows
- The relevant configurations involved and where they can be found/how changes to them are controlled.
Core Pools 2.0
Most of the changes below pertain to automation. Additionally:
- L2s are moving from distributing fees based on relative TVL to based on relative fee generation.
- As with L2s, 50% of all fees generated on Mainnet will be paid into the core pools voting incentive.
- This simplifies/unifies the core pool process
- Measured over the last few rounds, this results in around 5% to 20% of the current USDC flowing directly to veBAL being redirected to vote incentives on Mainnet Core Pools).
- Better attribution and more frequent sweeping/swapping of fees results in a more accurate fee distribution.
Fee Epoch Process:
- Fees are swept and sold for USDC and BAL on a regular basis by Mimic.
- Every other Friday, aligning with Aura voting epochs, all available USDC is bridged to the Fee Handling multisig on Mainnet.
- The automation script will run and generate csv outputs and a multisig payload in this directory
- The payload will be loaded into the fee sweeper multisig, reviewed by the Maxis and then signed/executed.
Fee Automation:
100% of all $BAL fees earned are sent to veBAL as direct incentives. The below handling pertains to remaining USDC:
Allocation of collected protocol fees:
vote_incentive_pct percent of the total protocol fees collected on each pool will be allocated to voting incentives daoPct percent of the total protocol fees will be sent to the DAO.
vebal_share_pct percent of the total protocol fees will be flowed to veBAL over 2 weeks along with the BAL specified above.
Allocation of Voting Incentives:
Allocation of voting incentives occurs per chain. The following logic is applied on each chain, pertaining to the total available fees collected for voting incentives on the same chain:
Each pool on the chains Core Pools List will be assessed for the USD value of total fees collected over the 2 weeks preceding the fee collection epoch. Pools will be allocated a portion of the available voting incentives based on their relative fee generation.
Any pool that has less than min_vote_incentive_amount in voting incentives will be excluded from the round, and its voting incentives will be distributed to the remaining core pools.
The Voting Incentive amount will be split between veBAL and vlAURA voting markets based on the auraBAL’s total capture of veBAL. If there is less than min_aura_incentive available to allocate voting incentives to AURA, all voting incentives will be shifted to either BAL or Aura in a way that tries to maintain auraBAL capture split across the entire set.
Voting incentives will be placed on one or more voting incentive markets such that the allocated fees flow to the proper set of holders, and are all paid out for votes that generate emissions over the following 2 weeks. Currently Hiddenhand is integrated, but we are happy to explore additional integrations such as Paladin, VoteMarket or other emerging voting markets.
Final Payload
All of the transactions to place incentives and pay fees to the DAO and veBAL are packaged up into a multisig payload to be used in the process above.
Specification/Configuration:
The processes above will be used for generating and adding payloads going forward. The following initial parameters will be set:
| Parameter | Value |
|---|---|
| vote_incentive_pct | %50 |
| dao_share_pct | %17.5 |
| vebal_share_pct | %32.5 |
| min_vote_incentive_amount | $500 |
| min_aura_incentive | $500 |
The Core Pools List will be accepted as the current configured list of core pools. Further changes will be made based on payloads approved by governance.
While the system has the capacity to reroute voting incentives from one pool to another in case of a desire to migrate liquidity, none of this rerouting has been configured.
Future Changes to Configuration
Work will continue on voting incentive automation and all changes will not be brought to governance, however basic intentions of the program and the specific parameters above are considered fixed and not to be changed without a further instruction from governance.
There are considerations around total gas cost to voting incentive//vote/claim. The min_vote_incentive_amount values seek to keep this somewhat under control.
min_vote_incentive_amount may be tuned by the Balancer Maxis up to $1000 USD without a vote in response to on-chain gas costs.
min_aura_incentive shall be maintained such that any Aura Voting Incentive always achieves well over the minimum votes required on Aura to register for a veBAL vote. The Balancer Maxis shall be granted the responsibility and authority for maintaining this value.
All changes to any of the configurations specified above should be made by a governance vote that includes a payload PR with the specific changes.