[Discussion] Replace Gauge Weight Voting With A Performance Weighted CRV Distribution


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.


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.)


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.


  • 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.


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?


  • 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


Why does there need to be an Oracle? Since the fees are now being directed to purchase CRV on the market can we not just track the CRV inflow over a period of time from each pool from the admin fees and allocate accordingly?

Haven’t voted yet as this seems to be a sensitive subject in the Curve community.

  • I would like to see CRV allocation be based more on performance somehow if it’s possible (what stops wash trading in small pools, after all, Curve is cheap to trade in and reward ratio could be very high)
  • I really believe it’s a great and powerful tool for the DAO to have, it’s misunderstood but it is and will be a huge drive for the demand in the future

I will let this poll be but due to manipulation on multiple votes that shall not be named, we cannot use them for signalling purposes.


@ne1k0 good point, as half of all pool fees will be sold for CRV and distributed to veCRV holders, we can determine the fees accrued across pools in the common currency.

@charlie_eth agreed that the poll result isn’t trustworthy. Just whether it gets votes or not tells us if people care about this issue

Hey @WormholeOracle! I don’t have a lot to weigh on the topic - I’m guessing that the boost + weight voting is designed to be a self-reinforcing mechanism to continuously lock up more and more tokens, with the fee accrual added on top as an extra incentive, and I’m interested to see how it plays out. I just want to say a big thank you for taking the time to write out a very thoughtful and well-written proposal. This DAO needs more of that. <3

1 Like

I agree wholeheartedly with the assertions of the author. a pool performance metric would help align the incentives with the protocol growth.

Michael, considering you have voted against any changes in this poll, can you please elaborate on your position on the matter?

1 Like

I think one of the use-cases of Gauge Weight Voting that keeps me from jumping at this proposal is that it can be used to incentivize third parties to “sponsor” a new pool. I know a lot don’t like the way the hBTC pool came to a giant allocation right away, but honestly if a third party needs to go buy that CRV on the open market to then lock in order to sponsor a new pool this way natively (not in their own token), I think that’s a huge use-case for keeping part of this system in place.

@ne1k0 That’s a good point that the voting is a way for organizations to purchase liquidity. If people are willing to pay for that promotion, they should have the means to do it. And it is interesting that the way this is currently achieved involves a temporary token burn via the veCRV lockup.

The team brought up (in Telegram) an interesting way to keep the gauge voting, and introduce a performance based weighting. Apparently, gauges don’t have to be a Curve pool. You can have an insurance fund gauge, for example, or in this case a performance weighting gauge. So the vote weighting is still the driver, but there can be more options made available for how the CRV actually distributes.

My understanding is that by voting on the performance weighting gauge, you’re allocating a certain amount of CRV to distribute based on relative pool performance. For example, I could allocate 50% of my voting power to y pool, and 50% to the performance weighting. Half of my voting power is then adding CRV to y pool directly, and half will be distributed across all pools based on the calculation of relative pool performances for the week.

It would be helpful if a team member could clarify how gauges can be created to allow these kind of expanded usecases. I’m really starting to like the idea of building onto the voting system with more options on how to allocate the inflation. It gives the DAO more control and allows experimentation without having to make any hard changes to the system. The less popular options just don’t get votes and everyone moves on without disruption

@WormholeOracle that’s an interesting concept of having “meta” gauges that impact the distribution based on some function, this one potentially being pool “fee performance” based.

It reminds me of the teams aspect to FOMO3d where you can weight different goals with your keys, some of them being more selfish than others.

First off, thanks for writing a well thought out post. I am not opposed to the idea of allocating CRV to pools based on performance but I don’t think it is the right choice currently. I say this because about 15% of veCRV supplied was used to vote last week and about 8.5% so far. Given that we don’t have that much participation in the system, making this decision currently is not wise (we are making a decision based on only a small representation of the data).

I think ideally, we have to incentivize individuals to vote and participate in the system. I am not sure how we do that but I think that the fees in the ethereum network definitely represent a barrier to entry for many. Until we solve this (perhaps we give folks a small amount of CRV proportionally to their veCRV when you vote?), making these types of decision might have to be delayed until curve sees more participation.

Back to the original proposition, I think a hybrid approach where we allocate 50% of the CRV distributed on a weekly basis to pools based on performance would work well (this can be done as you proposed). The other 50%, I think should be allocated via the current voting system. In my opinion this works better because we still give veCRV holders a say in the matter. These individuals do have skin in the game (i.e. have invested in the system by locking their CRV) and I don’t think it would be fair for us to take that away.

1 Like

One thought I had was to reduce the weight of “late” votes; if starting at the 24 mark, the impact of votes were reduced until t=0, this would make more expensive “last-second” gauge vote gaming.

You can only vote for a gauge once every ten days as is. I see no problem with weighting at the last minute other than force LPs that are willing to hop pools to wait till after the vote completes.
What choices would anyone make differently if they were to know the outcome of the weighting ahead of time? Weighting the same pool as the last minute whale?

The idea is to discourage the constant “rejiggering” every week as the shifting yields + gaming cause a lot of re-allocating and redistributing capital across pools. This is deadweight loss to Curve and its LPs (its just money paid to miners).

I think I’d probably champion even stronger mechanisms to dampen the gauge weighting process as, to me, its just noise + waste of my time as an LP.

I’d like it if you could just set and forget the gauge weighting, but there are issues that make it hard to use. I think you have to recast a vote every week, if you cast a vote and lock more veCRV, you have to revote to apply the new voting power, have to 0 out your vote if you want to vote on a different gauge. 10 day wait time to vote with new veCRV but not an obvious way to show if your veCRV is eligible to gauge vote with.

There’s just a lot of things that could be changed to make it easier to use. But I also don’t think the voting power should be less close to the execution time because liquidity can move between pools pretty quick. Will be even easier if we have metapools for simple jumping between pools

1 Like

I would expect that all things remaining the same, (all current votes stay where they are) that as time goes on this “rejiggering” will be harder and harder because the sheer amount of already weighted CRV has no reason to “rejigger” and there hasn’t been really that much new CRV minted in the last week.