CIP#3 - Add SmartWalletWhitelist with DAO maintained whitelist

I have reviewed the proposed contract and tested it using Brownie with Ganache in --fork mode.

The tests can be found here:

The contract itself is well written and fairly straightforward. I didn’t run into any bugs when testing, and I see no potential issues from integration. The design is in no way exclusive to, it potentially saves us time in the future when approving other protocols. For these reasons I’m in support of this proposal.


I believe the yearn contract has one of the largest amounts of vested preCRV tokens among the liquidity providers and already have a smart wallet contract in place. Probably the main reason to whitelist them first.

1 Like

I have multiple issues with this, all of them economical - not technical:

1) How can we justify whitelisting only certain smart contracts but not everyone? Why is yearn allowed to earn on top of Curve but i cannot just write my own contract to do the same? Why do i need to pay middlemen fees to automate this to YEARN who have NOTHING to do with curve.

If Curve wants to allow this kind of autofarming into USD why can Curve not launch their own product, this is trivial, fees earned can be distributed to veCRV holders and liquidity providers - big win for curve. People will buy and lock curve to receive rewards. YEARN just sells, curve could have an autobalancing product that sells some, keeps some and locks up always enough to have a max multiplier going - a good long term scenario for the whole project.

There’s a reason other such products locked out Yearn, they don’t add any value, they just farm where it brings most money.

Curve doesn’t need Yearn, Yearn needs Curve.

2) Are these products good for CURVE long term holders? No, i doubt it. All they do is sell for USD, they have no incentive to do anything else. If this goes through you are better of just selling your CRV and join one of the yVault farms without locking up CRV yourself, for the ones who already locked up CRV well, they might get pissed off.
There’s nothing stopping yVault to do the same with SBTC/RENBTC etc - they will just setup one Vault after another.

3) Chicken & Egg problem, they started this vote before the multiplier was active, no one has veCRV locked in yet, no one can vote against it.
If people think yVault will win this one then holders might sell off their CRV and just use yVault for farming, there’s no one who can vote against this.
I suspect this was the plan and is also the reason why Yearn was so pissed when Curve founder locked in his votes - because now curve founder could and maybe should prevent this. I however won’t lock up my CRV to vote as the incentives are not there, i might just join yVault instead and sell of my CRV - what am i not getting?


I can answer the “why do we need a whitelist?” question with a simple copy and paste from the voting contract

#Checker for whitelisted (smart contract) wallets which are allowed to deposit
#The goal is to prevent tokenizing the escrow


That wasn’t my question tho, i asked how we can justify Yearn to be allow doing this but not everyone else if we do?


think the point is you can allow everyone else too. anyone could be whitelisted. but there are technical problems with leaving it open. thus you have to audit the contracts before whitelisting. so yes, you could make your own thing and ask people to whitelist you. but you have to realize there are technical dangers that must be avoided, thus the need of a whitelist process.


There’s literally zero chances peasants get whitelisted, super unfair to give yearn an edge. Of course they sneaked their address in first in this proposal. If there’s something to be whitelisted first it should be an actual useful service like

1 Like

First of all, the whitelisting is there at all to prevent creating a transferable version of VotingEscrow. Those who vote should think whether their decisions are good for their CRV in escrow in the long run. Multisigs like Gnosis Safe, or even Argent can be transferred to other persons, so they are not good for votelocking.

Farming products like yearn are different. The rationale here is not to bar them from participating in the protocol, but to provide them an incentive to lock some CRV, not simply dump. They, of course, gain some political influence, too, by doing so.


Brownie is such a great tool :smirk:!


I tend to agree with this viewpoint, at least in the early stages of governance. Whitelisting the Yearn vaults is incentivising an accelerated dump program since they would be granted the boost. It would also make it more difficult for individual LP’s to reach boost.

I would suggest that whitelisting external contracts is a good idea in the medium term once governance is more stable, although maybe not for any fund/vault that is programmed to dump. I’d probably prefer to see whitelisting conditional on no auto dumping of CRV rewards.


Our goal is to create a fair system to ensure the long term viability of Curve.
Whitelisting yearn first because they’re the largest could benefit yearn at the expense of everyone else.


Balancer implemented a whitelist - this isn’t new and specific to yEarn.


THIS proposal IS specific to yearn, it whitelists ONLY yearn and not actually useful smartwallets like

This whole proposal should be thrown out by curve founder veto and replaced with a MORE GENERAL ONE that whitelists or not, a list of services.

Now no one can vote against it because no veCRV were locked up at the time andre launched it, which was totally on purpose.


its not like you just add zapper’s name to a list. they have to make a specific contract that interacts with curve.
so they have to make the contract, then apply to be whitelisted.

as explained before, there is a technical reason for a whitelist. anyone can come and ask to be whitelisted. is it an extra hurdle? yes. but it’s also unavoidable.


What the smart contract does is

  1. It’s a general Smart Wallet Whitelist contract where any contract address can be whitelisted by DAO Vote and also if the address is not whitelisted, it checks against a checker contract which allows for more complex checks(checking code hashes for example), that checker is also controlled by DAO

  2. At the same time whitelists yearn’s voting vault contract

The idea behind whitelisting yearn’s voting vault contract automatically is so there’s no need to wait 7 more days to whitelist that contract.

Also, the contract has a revokeWallet function which allows DAO to revoke a whitelisted contract.


I agree that it’s a bit early to push this one through where most people have no vote. It will significantly reduce CRV rewards for individuals and increase sell pressure.

At the moment I don’t see the benefit for CRV or veCRV holders.

But I think that those involved with CRV also have their fair share of YFI because it was farmed first through the y pool, so they probably don’t mind if YFI leverages CRV. The CRV-only holders will probably not be strong enough to prevent this…

1 Like

We are all aware of that man…

Yes there’s a technical reason for the whitelist, and there’s also a reason this was rushed through before everyone else could vote.

This proposal should not be rushed through, once it is it will be hard to get rid of it.

Sufficient time should be given to and co to add functionality for curve too and then include them as part of a general proposal.

How would it be hard to get rid of? We could literally put a proposal through to vote to remove the whitelist tomorrow.

The only thing is that nobody wants to do so it’s not going to happen.

The territorial behaviour isn’t helping anyone. Curve isn’t interested Yearn and Yearn isn’t interested in hurting Curve. Just because a handful of users from both sides like to pretend it’s the case doesn’t make it true.

Yearn I believe will introduce proposals to support CRV instead of farm and dump and we have plenty of proposals to give a bright future to the CRV token, one of them being voted on right now.

I suggest we stop the counter productive arguing and focus on what’s ahead.


This proposal has to be applied with a new vote so if anyone didn’t have a say, can do so now, vote snapshot is from 31/08/2020 19:21:30 UTC -

1 Like

Can you explain why a new vote is applied?