Updated on July 12th: proposal to move forward as below, no modifications proposed during RFC.
Background
We’re now approaching a couple of months into the V2 Liquidity Mining Program, and everyone’s been learning what’s good about it, as well as where improvements could be made to make the most of every BAL token we allocate. Since the launch, we’ve added a new Tier 4 (following a governance vote), and introduced liquidity mining rewards on Polygon. We’re quickly gaining traction on Polygon, and created a lot of excitement around Balancer, which has been awesome.
Over the coming weeks, there’s plans for launching on Arbitrum (although we need to be mindful of spreading liquidity mining rewards too thin + liquidity fragmentation), new stablecoin pool deployments, and a number of dual incentive partnerships.
While all very positive and exciting, these plans create additional pressure on the limited number of liquidity mining slots we have, and it’s becoming difficult to envisage how everything will fit in without further changes to the tiers and slots. We also have some potential partnerships with smaller projects where weekly BAL rewards as low as 250-500 BAL may make sense, which the committee doesn’t currently have the power to grant (the smallest we currently have available to us is a Tier 4 slot, at 1,000 BAL per week).
Core Proposal
I propose that moving forward, the Liquidity Mining Committee would be given the freedom to flex the number of Tiers, BAL per week for each pool in each tier, and number of pools in each tier. Tier 1 would continue to be locked in place, and be unchanged.
In addition to this, the Commitee would have the ability to operate a different LM Tier structure on each network we incentivise, such that tiers could be different on Matic to Ethereum for example.
To illustrate with hypothetical examples, this would mean:
-
The Liquidity Mining Committee would have the ability to decide that Tier 2 pools should now receive e.g. 4,500 BAL per week rather than 5,000 BAL per week per slot, then allocate the additional BAL to newly created slots.
-
The committee could introduce an entirely new Tier 5 for 500 BAL per week with 10 slots. To give an example of a use-case for such a tier, we have been discussing the idea that the majority of Balancer LBPs for legitimate projects should be able to expect 500 BAL/week in incentives for a 2-token pool for 8 weeks after their launch. We would then seek to work out dual incentives on those pools where possible, with the intention they bootstrap liquidity with us rather than e.g. Sushi.
Due to the nature of Matic and the fact we have double, sometimes triple rewards on pools, we may benefit from being able to go as low as 250 BAL/week + equivalent matic for e.g. partnering with a Polygon native project on a single 80/20 pool, in a context where we may often have to move quickly to beat a competitor to it.
What would the Liquidity Mining Committee not have the ability to do?
-
Change Tier 1 in any way, without a wider governance vote.
-
Change the total amount of weekly BAL rewards: this is fixed at 145,000 in total, across all networks.
-
Provide any amount of liquidity mining rewards to a new network (e.g. Arbitrum), without a wider governance vote.
-
Change the amount of weekly BAL rewards any currently incentivised network receives in total, without a wider governance vote. So the 25,000 BAL per week going to Matic pools would be fixed, as would the current 107,500 per week going to V2 on ETH and 12,500 going to AAVE on V1 on ETH.
All changes to Tier structure or pools would need to be voted on and approved by the committee.
Dependencies
None that I am aware of. The frontend liquidity mining script has already been updated to be more flexible, such that we could allocate any amount of BAL to any pool.
Risk Assessment
Firstly, I see no greater risk that Committee Members could “go rogue” and mis-manage rewards than they could with the current structure. As it stands, we can allocate multiple slots to an individual pool, for example.
Probably the biggest risk is that the committee changes the structures too quickly/frequently and LPs find it difficult to keep up. This can be addressed by the committee announcing changes clearly, planning major changes well in advance (with consideration for LPs, especially on Ethereum Mainnet where gas fees can be high for smaller LPs) and using phased transitions when rewards for pools are being reduced (e.g. no shift from 5,000 BAL per week this week, to 0 BAL per week next week, unless e.g. a token in a pool fails).
The user interface accurately showing rewards makes it easy for people to tell in V2 if the rewards for their pool have changed, reducing this risk in comparison with V1. The flexibility afforded to us by this new proposal passing would also make both phasing pools in & out easier, as more granularity would be available to us.
Another risk is that managing the liquidity mining program takes too much time for committee members. Given that it’s a core part of our marketing currently, and so important, it’s reasonable there should be time, effort & debate involved in managing it correctly. If managing the program becomes too time consuming for a member, we can work on improving processes, hiring additional committee members, or remove a member if they (or the rest of the committee) don’t believe they can perform their role any longer.
Any committee member would be able to bring up concerns within the committee each week, where the rest of the committee can work with the member to try to resolve the problem.
In the future we may want to go further and look at creating specific roles for committee members, to define responsibilities & spread workload formally.
As the program progresses, there will likely be fewer weekly changes, so while there could be more slots in the future, fewer will likely be changing each week. We will also continually learn what works and what doesn’t work, which should make things easier over time.
Governance would continue to have the power to halt the powers of the committee at any time, or remove members from the committee if it deemed such an action appropriate. The need for committee votes to pass changes each week would provide several days for governance to intervene, were such an intervention deemed necessary for some reason also.
Open Questions
Are the current members of the committee all happy with increasing this flexibility? If not, why?
Are there any risks or concerns that wouldn’t apply to the committee’s current powers, that would become concerns if this greater flexibility was introduced, that I have not thought of?
Next Steps
I would like to propose that the RFC runs through to Saturday 10th July, with a proposal published early the next week so we can take the proposal to a vote starting July 19th, unless there are major concerns raised which introduce the need to delay. The reason for wanting to move quickly with taking this to proposal is the opportunity cost of each week delayed on Polygon in particular.