Proposal to add CRV/yCRV gauge to the Gauge Controller

Curve Governance Proposal

Proposal to add yCRV gauge to gauge controller

Pool: 0x453D92C7d4263201C69aACfaf589Ed14202d83a4
Gauge: 0x5980d25B4947594c26255C0BF301193ab64ba803

References/Useful links:

• Website:

• Documentation: 
• Github Page:

• Communities:

Protocol Description:

yCRV is the latest generation of Yearn’s liquid veCRV wrapper product. It is an upgrade to the yveCRV/yvBOOST system that exists today, and will feature improved liquidity, yield, and the ability for users to cast votes on gauges.


The obvious home for yCRV liquidity is on Curve. With CRV incentives, this pool will become the main source of liquidity for yCRV - an improvement over the situation today with yveCRV/yvBOOST where liquidity is split across multiple DEXes. If approved for CRV emissions, users can choose to increase their LP or choose to lock additional CRV into the yCRV system to enjoy the incentives while furthering the veTokens.


  1. Governance: yCRV is designed to be a trustless system with limited governance powers reserved to veYFI users.
    Yearn’s governance multisig: 0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52
    Yearn’s whitelisted voter contract: 0xF147b8125d2ef93FB6965Db97D6746952a133934

  2. Oracles: The yCRV system does not depend on any oracle systems.

  3. Audits: yCRV was audited by ChainSecurity link here

  4. Centralization vectors: Similar to all other veCRV liquid wrappers, the whitelisted contract utilized by Yearn to lock CRV is owned/operated by the protocols’ governance multisig. Yearn’s multisig has a 6 of 9 threshold.

  5. Market History: yCRV is the successor to yveCRV which has tracked loosely to the price of CRV over time. The new yCRV tokenomics has a number of clear benefits over the old system which give us confidence that will bring the price closer to peg.


Can you elaborate on how this will work or have links? If yearn has made any public statements about this product, I havent been able to find them.


this is the only part of the system that isn’t fully completed yet. there is still some final development + audit work to do on the voting system. but it will be fully permissionless + on-chain voting that requires a short-term lock.
docs describing the tokenomics and mechanics of system should be out soon.


What will be the protection mechanisms to avoid vulture governance? Will there be a locking period for vl-yCRV?


vl-yCRV will not permit users to participate in DAO voting - only gauge votes. Yearn governance is highly aligned with Curve’s success and the multisig will retain Curve DAO voting rights.

Still, there will be a lock on vl-yCRV. This lock mechanism is designed to prevent users from voting on gauges and then immediately leaving to another yCRV position to enjoy yield. The goal of this system is to separate the veCRV perks into distinct tokens, and allowing users to hop to/from vl-yCRV opportunistically would break this design.


hi! some comments


“It is the final piece of the yCRV system and is currently in the final stages of development, not yet ready for production.”

so why does this have a gauge at all? we don’t know what kind of governance attack vector this poses. why should we give this a gauge without know the governance risk it poses? to me, this is falls under rejection rounds.


“Users in this position will not earn weekly admin fees or bribes, and will be subject to a minimum 14-day lock (21-day maximum). Once the lock period is over, user is free to withdraw to yCRV if they choose and move freely within/without the yCRV ecosystem.”

this is unacceptable. we (cryptorisksteam) had an extensive debate with the stakedao crew and convinced them to have a longer lock duration (please check their docs): at the very least, yearn’s ycrv MUST have similar lock duration but not lower. because this would eventually lead to continually regression lock durations and hence increase governance attack vectors.

Based on these two comments, the DAO should hold voting for this proposal.


Humbly think it would make sense to wait for the product to be shipped and the pool to have a bit of TVL and volume before rushing into this.
That’s my two cents on the matter.


It is certain that to accept such a decision it would be necessary that the information on the mechanisms and risks preventions be more concise. it is surprising that this proposal has been posted without us having a complete overview of the finished product.

I agree on the lock duration point raised by bout3fiddy, 14-21 days lock is not being “highly aligned with Curve’s success” The lock is to ensure that those with the most power are those most invested in the long-term success of Curve. At the moment the duration suggested is obviously too short in comparison to what Convex & Stake DAO did and would open Curve up to even more short term stakeholders. This delay should definitely be re-viewed and re-aligned with what is being done now.


Very dangerous proposal and technical implementation contains multiple dangerous edge cases such as claiming the 3crv weekly reward for example. Also locking mechanism is far from being fair and in line with sdCRV and CVX implementations. At this stage, a strong Curve Gauge Risk Assessment on yCRV is highly required. Similar to the one that Stake DAO went through for example Asset Risk Assessment: Liquid Lockers & veSDT to understand each aspect of the risks (mint, claiming rewards, vulture governance, locking etc) associated with current implementation of yCRV.

In current form of proposal it’s too dangerous for CRV and Curve as whole hence I would highly recommend the DAO to not vote for it.


Hey guys. First off, great feedback. Let me share our thinking on what seems to be a couple hot topics…

vl-yCRV 14+ Day Lock Duration

To be super clear, this duration is for gauge voting rights only. DAO voting rights (i.e. adding gauges, approving protocol changes) which are much more sensitive will not be extended to yCRV users. Further, if ever in the future they were extended, a significant lock time increase would be justified and implemented to protect the security of Curve DAO.

Decoupling gauge voting rights and DAO voting rights is part of the yCRV product design.
DAO voting rights will be retained by the Yearn governance multisig and will commit to vote in accordance with Risk Team guidance.

Does yCRV add any risk?

We think no. The only changes being made to upgrade from Yearn’s legacy token, yveCRV, are inherently meant to simplify, not add complexity. Disagree? Happy to chat more and reply to specific concerns/questions below.

Yearn’s view is that gauge voting alone does not present systemic risk to the Curve DAO. If influencing gauge emissions was a danger, then bribe markets would present a risk. In fact, many bribe markets require zero lock time for bribers. With vl-yCRV, we propose a minimum lock of 14 days, and maximum of 28 days.

Some history on Yearn’s veCRV wrapper tokenomics:

Yearn was the first protocol to offer a liquid wrapper token: yveCRV (as well as a wrapped version of that called yvBOOST). It was created exactly 2 years ago, and the design has proven imperfect. In fact it suffers from two fatal flaws due to the complexity of the code including its internal snapshot mechanism:

  1. Token transfers are very expensive
  2. Users lose their 3CRV rewards if ever they deposit into an LP position

The yCRV system solves for these key problems, making the upgrade strictly better for users. How? The new token contract is simply a stripped-down version of yveCRV (bare-bones ERC20) and will be mintable 1:1 for yveCRV users when they migrate. From there, a user can deposit into a standard Yearn vault (called st-yCRV, aka “staked yCRV”) to earn their 3CRV yield again. Conversely, they can elect to deposit their yCRV into vl-yCRV where they can vote on gauges.

There is only one fundamentally new contract (the simple yCRV ERC20), and all contracts involved have been audited.

Is the yCRV Product Unfinished?

While there is still work being done to finalize the vl-yCRV code, we are ready cut-over admin fees stream from yveCRV to yCRV and allow users to begin the migration process. The yCRV system, in its current state, is already an objective improvement over yveCRV, and will immediately allow users to enjoy an improved UX while becoming untrapped from the legacy system.

The motivation to launch and acquire an incentivized gauge asap is two-fold:

  1. Consolidate liquidity and trading away from Uni/Sushi onto Curve protocol
  2. Update from the legacy token design which has prevented composability and blocked Yearn’s ability to grant more rights to users of the system.

Ok sorry for this but this is a bit of a bizarre comment so gonna have to call it out here.

1.) It was a community discussion and effort. not sure why it’s “we convinced them”
2.) The final consensus was to have linear weighting over a 1 month time period, not “longer duration”. In fact, sdcrv has 0 lock duration.
3.) If you followed the discussions you would know that one of the conditions that seemed to have support was for stakedao to keep governance proposals/voting and only give sdcrv gauge votes. It was then changed to the linear weighting idea in order to let sdCrv keep gov rights.
4.) The ycrv docs state vlycrv has no governance control and that will be retained by Yearn/YFI. Which is what was considered as a possible solution to sdcrv.

Therefore it seems all the checkboxes from the sdcrv debate are currently checked.

That being said though, I do agree that the system should be released, running, and verifiable as well as general users should be able to mint/redeem and join liquidity pools before incentives are started. I know having it all connected will make a smoother launch or whatever but we should be strict in the stance of not gauging unreleased projects.

I have communicated with some members of the Yearn team about the concerns with this timing and suggest they delay the gauge vote until after their official release.

(Also as a side note when asking their team about the lock duration, if a user votes in the current cycle their lock is extended to the following cycle end. Thus it’s not 28 days and then freedom to vote and run etc. They have to stay locked when they vote.)


Hmmm, apologies for the inaccuracies! Will be more diligent next time :relieved:


Believe @C2tP summed everything up pretty well, don’t see the ability to vote for gauges with a locked CRV stake more of an attack then a bribe - especially since each yCRV will be given a voting power of 1 veCRV.

The gauge for the yCRV-CRV pool also makes sure that the weekly 3crv fee claim for all of yearn’s veCRV gets reivested in CRV contributing to fees (same for whatever bribes they collect) instead of leaking trading fees to other protocols. This is a very simbiotic relationship and the emissions may end up being almost entirely offset.


I am currently voting “no” with the sole reason stated above in my previous post. I believe we shouldn’t cut corners if we wish to apply the same rules to other gauges. I do not believe we should gauge unreleased projects (ex.mochi).

I welcome a resubmission of the proposal though once it’s all up and running.


I see a new proposal was put up. Is this one real and ready to go?

1 Like

Looking forward to see the product when it’s live!
Shall we wait for it to be in prod before pushing the gauge?
Also, A factor seems quite high to start with. I think starting with 25 would be wiser.

1 Like

yCRV has been live :smile:

  • Official tweet with yveCRV/yvBOOST deprecation notice (link)
  • UI is live for migrations + swaps (link)
  • Migrations have been live for almost a week (see here).
  • Yearn’s 3CRV admin fees are flowing to st-yCRV users (see here).

Sorry ser, was outdated.
Personnally voted in favor of the proposal.