Wow what a thread, I love it lol!
Tbh, I’m a bit confused by the uproar against this proposal. I think it’s completely fair to restrict the allocation of rewards a pool can earn based on their contribution to the protocol, why would you want anyone to be able to extract significant amounts of value from the protocol in return for little to no benefit?
While I agree that bribes bring value to an ecosystem, I don’t think bribes are something a protocol should optimise for in the long-run. Who knows how long they last?
In my opinion bribes just make the principle-agent problem worse in DAOs.
Optimising for revenue in the long-run should be the number one goal and I think using BAL emissions to incentivize positive behavior that increases revenue and Balancer’s competitiveness is what it should be used for.
How do we maximize protocol revenue?
- Increase trading volume
- Increase the absolute value of pools with yield bearing assets
1.1. Increasing trading volume:
(Base level) Provide more efficient swaps → trades get routed through aggregators → trading volume increases → more fees
Metrics to achieve this:
TVL and assessing optimal fee structures
2.1 Increase the absolute value of pools with yield bearing assets
Incentivize pools to utilize yield bearing assets + BIP-19 → increased fees
Metrics to achieve this:
TVL of yield bearing assets
With these ideas in mind I thought of an alternative model that may reduce some frictions based on voting for gauge allowances, caps etc.
An alternative model:
I like solarcurve’s model as its pretty simple and straightforward. However, I think constantly adjusting caps and gauges will get annoying at least for existing pools.
Alternatively, we can move more to a more programmatic approach similar to dYdX’s LP reward formula:
(I wish i had some time to do modelling, hopefully someone who is better at math than myself can also point out a better form or highlight issues with these formulas)
Model 1:
Max_gauge_weight = pool_score = (Overall_factor^a) x (Revenue_factor^b) x (TVL^c)
Where,
a + b + c = 1 (Constant returns to scale)
Overall_factor = lowest_mcap_factor^(weighting_factor)
Revenue_factor = as described, does it include rev generated if it’s a boosted pool? (e.g. aDAI)
TVL = Total value locked in pool
Max_gauge_weight determines the maximum amount of BAL emissions a pool is eligible for and is a function of inputs that are beneficial for Balancer.
Rational:
Firstly, I think including a TVL metric on top of a market cap metric makes sense. Large protocols might be on balancer but have bad TVL making swaps more efficient elsewhere. TVL in its base form just increases the efficiency of swaps and could promote smaller projects to focus on Balancer with majority of their liquidity as an easy metric to improve.
Secondly, a model like this provides a quick feedback loop between improving a pool’s performance and its eligibility for more rewards reducing the constant re-evaluation of pool caps.
Thirdly, using a cobb-douglas function with constant returns to scale rewards protocols equivalently to the input they provide and how the DAO values such inputs. The DAO will have full control over the a,b,c parameters and can place heavier weights on protocol rev etc.
Model 2:
Max_guage_weight = Pool_Score = (Overall_factor^a) x (Revenue_factor^b) x (TVL^c) x (Bribe_revenue^d)
*Where, *
a + b + c + d = 1 = Constant Returns to Scale
Bribe_revenue = Amount of bribes in $ value earned by the pool per epoch
Rational:
This is the same as model 1 but at least tries to capture the value bribes bring to the ecosystem. Once again, the DAO/community can decide on its weight/value
Model 1 + 2 - New entrants:
We can also introduce a scaling variable that is dependent on time, which allows new entrants to have automatic access to x% of emissions so that they can have time to build up some exogenous liquidity.
After x amount of time, the scaling variable turns off or decays.
How it works:
Similar to dYdX, we would need per-minute random snapshot of each metric over the entire epoch to 1) avoid gaming, 2) incorporate a change in metrics. At the end of the epoch max_gauage_weights are calculated and used for the following epoch to determine the maximum BAL emissions a pool can achieve. All additional votes will be distributed to other pools in proportion to their vote weight (similar to Convex).
Considerations & Structural changes:
Clearly such a change would require significant engineering work, however, I think this is a suitable alternative when thinking about future options. e.g. implementing the formula + random sampling
Selecting the correct weights is also very important, as we still don’t want to run into the same issue where a pool earning $x for balancer is eligible for $y rewards (where y >> x) but i think for the most part this is mitigated with such variables.
There are also some nuances that need to be worked out. Is score proportional to the rest of Balancer? Does it just simply scale? Do we normalize it in a certain way etc?