Summary:
This thread is an initial discussion for the community to share their thoughts about the current gauge weight voting process. We propose an alternative strategy that automates the CRV distribution process.
Motivation:
Michael and the Curve team have put a substantial amount of brain power into making Curve what it is today. At the very least, this discussion should serve to elucidate the intention and effectiveness of the gauge weight voting system. However, we ask that the community and Curve team keep an open mind to this discussion, as we believe there are some strong arguments for pursuing an alternative approach.
===Voting for CRV distribution erodes trust in the process===
Large token holders change the gauge weighting dramatically and unexpectedly, leading many to view the system with suspicion. A system that issues CRV deterministically, based on objective metrics, would build trust.
===The current system can’t account for pool performance ===
By voting on gauge weighting, Curve facilitates competition between self interested actors who seek to maximize their own CRV compensation. We can’t expect these actors to make decisions based on what is “good” for Curve (by choosing to allocate weight toward the best performing pools, for instance). This results in gauge weighting that follows liquidity rather than leading liquidity where it can be most effectively used. An analogy might be a company where employees vote on their wage, not by the quality of their work, but by their current wage. Their votes offset each other, and their wage remains divorced from their work performance.
===A deterministic system based on pool performance will optimize liquidity across all Curve pools===
Our proposal involves comparing the liquidity utilization of each pool and assigning CRV distribution based on the effective use of liquidity. The wide variation in pool utilizations at present time is indicative of an inefficient distribution of liquidity. By tying CRV distribution with performance, we can disincentivize liquidity from gathering in pools with low trading activity (and incentivize pooling into well performing pools) until a relative equilibrium forms across all pools. CRV distribution would thus play a role in optimizing liquidity pools. (Note: Txn fee earnings make up a small portion of total LP compensation. Thus, we can’t rely on pool performance to self-regulate organically.)
Abstract:
Current System
The current gauge weight voting process works (as seen at Curve Gauge Weight) by letting veCRV holders direct their voting power toward any pool or pools of their choosing. This increases the daily CRV distribution allocated to those selected pools. This voting process is repeated on a weekly basis to update the relative gauge weights.
To paraphrase some of the team’s motivations for this design, it encourages participation in governance by incentivizing CRV locked up as veCRV. Large entities, such as yEarn, are required to lock some CRV in order to most effectively execute their yield farming strategy. Also, it can be dynamically used as a promotional feature by the DAO, which can vote to incentivize liquidity formation in a new pool.
Alternative System
Our suggested alternative would replace the voting process with a formula that compares the performance of each Curve pool, and assigns a weighting based on their relative performance. While the specific metrics are up for debate, we have identified the Total Fees and Pool Utilization metrics as most useful for measuring performance.
Total fees is the revenue that the pool earns. Since veCRV holders are now earning a portion of revenue, they have an incentive to prioritize pools that earn the most fees. This metric does have some disadvantages on its own, however. First, it prioritizes large pools over small pools, even if the liquidity in the large pool is less efficient. Second, each pool measures fees in a different currency, so an oracle is required to compare fees.
Pool utilization is useful as a primary performance metric. It is the pool’s Volume / liquidity and is represented as a percent. It measures how much “work” each unit in a liquidity pool did over a certain time period. This metric has the advantage that it does not require conversion between pools. It also does not discriminate between pool sizes. The quantity of liquidity is not as important as the trade volume per unit of liquidity, and this metric lets us reward small pools that demonstrate outsized value to Curve.
Special contingencies need to be accounted for:
-
A new pool may not have the opportunity to attract liquidity unless a certain baseline CRV distribution is allocate for some grace period.
-
A deterministic weighting system must account for wash trading or other attempts to game the system, which may be quite profitable, given that the fees earned are much smaller than the current value of CRV distributions.
Challenges:
-
A sophisticated algorithm for deterministically distributing CRV will almost certainly require an oracle to properly compare performance of pools denominated in different currencies. This introduces a new risk factor and complexity in the system. However, oracles are becoming commonly used in DeFi applications, and integration is becoming simpler and more secure.
-
Malicious actors will almost certainly try to game an algorithm that distributes CRV. Care must be taken so that such an attack is economically infeasible.
-
The algorithm may produce unintended results. For instance, a death spiral might occur, where a poor performing pool loses CRV weighting, which causes liquidity to decline, which decreases performance further. Care must be taken to regulate pools, but prevent this sort of feedback loop.
-
Michael has stated in the chat that the gauge weight voting cannot be removed. In the event that the DAO wishes to take a different approach, a workaround would be implemented to mitigate the influence of the vote in favor of a new system (possibly a hybrid voting/performance based system).
Case Study- y pool vs sUSD pool:
The y pool currently [as of 9/9/20] has a gauge weight around 50%. It has $615,000,000 liquidity, does $66,355,000 in volume, which is around 11% utilization (viewed on 9/9/20).
Compare this to sUSD pool. It has a gauge weight around 11%. It has $141,000,000 in liquidity, does $76,255,000 in volume, which is around 54% utilization (also viewed on 9/9/20).
Notice that the gauge weight roughly follows the amount of liquidity in each pool, but that there is a marked difference in performance between these pools. When viewed from the perspective of pool utilization, the y pool is being overcompensated by 5x. (I’m not trying to target yEarn specifically, and believe it to be a symbiotic partner with Curve. That said, its unique strategy has resulted in a huge influx of liquidity, and CRV overcompensation exacerbates this growth when it should be tempering it.)
A performance based distribution would recognize the higher utilization of the sUSD pool, and decide to allocate a greater proportion of CRV to this pool. It would account for the total trading fees earned by each pool, as well as the quantity of liquidity, to avoid overweighting the sUSD pool. Liquidity would then flow out of the y pool and into the sUSD pool, until the average pool utilizations reach an equilibrium. Once equilibrium is reached, the CRV distribution will remain fixed until market dynamics change that requires another adjustment to distribution.
Conclusion:
We believe Curve should implement a distribution system that builds trust in Curve’s compensation method, deterministically weights by pool performance, and incentivizes liquidity toward utilization equilibrium between pools.
The strategy above is but one humble opinion, hopefully a springboard to open the discussion up to the community. How do you view the current gauge weight voting process? Do you feel there are ways that it can be improved? Do you believe an alternative approach as described here is preferable, and if so, what suggestions do you have to build and refine a formula that will operate reliably and fairly, and bring most value to Curve?
Poll:
- Gauge Weight Voting works well and should not change
- Gauge Weight Voting should be replaced with a performance weighted strategy as outlined in this proposal
- Gauge Weight Voting should be replaced and I have a different approach (describe in discussion)
- Gauge Weight Voting can work in conjunction with another strategy (describe in discussion)
0 voters