CIP#3 - Add SmartWalletWhitelist with DAO maintained whitelist


Add SmartWalletWhitelist with DAO maintained whitelist & upgradeable SmartWalletChecker


VotingEscrow supports the addition of a SmartWalletChecker, this allows applications such as Instadapp, Zapper, and to participate in governance via proxy. The proposed contract starts off as a whitelist maintained by the DAO, but can be upgraded to include more generic checks (such as for Instadapp’s multi contract factory)


Allowing access to DAO managed smart contracts allows pooled participation as well as further integration strategies;


The proposed deployment is available at;, this implements;

def check(address) returns (bool)

As well as allows the following function calls;


The first proposed smart wallet to add is 0xF147b8125d2ef93FB6965Db97D6746952a133934 which is’s voting vault. This is agnostic to strategies and used as a voting proxy.


Allow for DAO managed whitelisted smart contracts with the ability to add or revoke participation. This will allow smart wallet based systems to interact with the Curve DAO


Do not allow smart wallet solutions to integrate favoring single managed accounts instead



A no brainer for me, DeFi will grow out of collaboration between different protocols!


Sounds great. Let’s run tests with VotingEscrow in ganache-cli first though. But the code seems good and clear!


It’s well written proposal and the code is super simple. It’s going to push unstoppable creative force with new ideas and integrations :fire:


Does this proposal give preference to one member of the community over and above another?

The abstract mentions “Instadapp, Zapper, and” and yet the proposal seems to call for only providing access to

Is that right?
Does that seem fair?
Or does it favor the prettiest child?


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.