YIP-60: Airdrops to Yearn Vaults

Authors

@lehnberg

Summary

Formalize how airdrops to Yearn vaults are handled: Tokens that are worth the effort, are sustainably claimed and donated to the affected vault as its want token in order to boost the returns of vault depositors.

This, in order to be aligned with what is the fundamental proposition for end users and third party integrators alike: Having a gas efficient, frictionless, set-it-and-forget-it way of earning compounding returns through Yearn’s vaults.

Background

The Ellipsis airdrop[0] and the resulting eligibility for the yveCRV to receive tokens over the course of a year has resulted in Yearn governance discussions[1] about how this should be handled.

While this is the first airdrop of its kind, it is unlikely to be the last. It would be beneficial to agree on a general approach that outlines how these situations are to be handled.

Airdrop factors

  • Cost to claim. Claiming airdrops can involve manual work, sometimes on different chains than Ethereum, for uncertain rewards.
  • Time periods to claim. Claiming may at times be done in one go, and other times over multiple times, sometimes lasting as long as a year or more.
  • Relationships and image. Acting in bad faith, i.e. “claiming & dumping” can lead to exclusion from future airdrops, bad publicity, and being labeled as an adversary rather than a partner.
  • Tokenomics. Depending on the protocol design, there can be lucrative farming opportunities or heavy penalties to incentivize good actors in the airdrop protocol. Considering these can lead to better rewards.

Motivation

The rationale for this proposal is motivated by the following objectives:

  • Do right by the vault’s depositors. In principle, airdrops belong to whoever holds the private key. Practically, many vault depositors expect to benefit from airdrop proceeds. Yearn should do right by them, which in turn does good for Yearn’s reputation and attracts more users of its products.
  • Set expectations straight. At the moment, it is unclear what will happen in airdrop situations. Vault depositors should have clarity about what they should expect to happen.
  • Do not overload Yearn’s resources. Yearn’s vaults are different, and airdrops are different. Subjective judgement about which airdrop to claim, and what the best way for realising it, is unavoidably going to be required. Airdrops should not end up becoming an effective Denial-of-Service attack on Yearn teams and distract them from delivering on existing roadmaps and priorities.
  • Keep it simple. Yearn is meant to make DeFi simple, and should try to live up to that. Depositing a token into a Yearn vault shouldn’t come with expectations of potentially having to deal with the handling of other unrelated tokens, possibly even accessible from other blockchains.
  • Keep it composable. Yearn vaults are being used by end users, defi protocols, businesses, and other intelligent life such as smart contracts and robots. They should benefit from airdrops automatically, without no additional effort, letting rewards compound. This avoids unexpected behaviour and edge cases, making Yearn’s vaults easier to integrate with.

Specification

  1. A decision is made whether the effort to claim a specific airdrop is worth while given other current priorities.
  2. Specific claiming, farming, and token exchange strategies are determined on a case by case basis, depending on prevailing airdrop terms and market conditions, with the objective to maximize risk-adjusted returns.
  3. Returns are used to boost the returns of the affected vault for the benefit of its current depositors. This is done by converting the returns into want tokens, and donating them to the vault in question, boosting the returns of each current tokenholder as a result.
  4. Decisions on the details of the above steps are left to be taken by the Operations, Engineering, and Finance teams with the instruction to meet these instructions as best as possible. Decisions can be overruled as usual through the existing Multi-sig and Governance processes. Both groups should be kept up to date on airdrop claims as they progress.

Vote

  • Yes, I support this proposal.
  • No, I’m against this proposal.

0 voters

Non-binding poll

Poll: Snapshot

References

  1. Introducing Ellipsis.finance. Ellipsis.finance is an exchange for… | by Ellipsis.finance | Mar, 2021 | Medium
  2. [Discussion] What to do with EPS airdrop?
11 Likes

The single guiding principle for Airdrops (and all other unforeseen events other than smart contract errors) must be:

No yearn depositor is worse off than had they executed the same strategy as an individual.

In general yearn depositors should get:

  • The same or greater value from any investment Edit: (as an individual)
  • Lower fees due to socialization of costs
  • Less effort exerted to socialization of effort

Any other practices will inevitably destroy Yearn.

2 Likes

Some things are in conflict here.

This is a good guiding principle, however by pooling capital, Yearn acts as a single individual entity, not like a thousand smaller depositors who make individual decisions on how to act (e.g. dump or hold airdrops). For example, by acting as a single large entity, we have outsized impact on future airdrops deciding to include us if we always take the “dump it” route, because it means we are always going to hurt their airdrop prices:

So, that puts this part of your principles in direct conflict:

The socialized aspect of investing means that Yearn necessarily needs to take a longer-term view, and find ways to build relationships for the long-term instead of being the most profit-seeking short-term.


I would say what is best for Yearn is what is best for depositors long term: stronger, more-positive relationships builds value that is greater than the sum of the airdrops we can farm and dump in the short term (until people stop including us in their airdrops to preserve their token’s value)

15 Likes

This proposal vote seems to just be asking for permission for the Ops/Engineering/Finance Teams to do whatever they deem best.

As they’re the ones who would have the best insight into those decisions that makes sense to me.

I do have a question regarding airdrops on other chains. Would farming proceeds on other chains return to Ethereum, or would those be stuck on the farmed chain?

1 Like

I would also go for a kind of cliff-vesting period in order to avoid dumps and incentivize partecipation

1 Like

I’m in full support of this - Governance can always intervene in scenarios where viewpoints are drastically different than the team’s

1 Like

That’s not governance. That’s not procedure. That’s not process. That’s the way you handle the office party kitty, that’s not how you handle hedge fund with more than a billion dollars.

This proposal is too squishy. To vote yes it needs to be more clearly articulated. IMHO, In the case of the EPS airdrop (at current prices), the airdrop over 1 year is worth as much or more than the current price of yvecrv. For that amount of money we need something better than do whatever seems best.

3 Likes

I think the proposal actually lays out what the plan is for the EPS in a form that generalized the process for all future circumstances. All EPS + profits derived from EPS (ie:farming) will be converted into vecrv (want token) and donated the yvecrv vault. What this doesn’t address is the variable path that can be taken to generate those proceeds. Should the EPS be unlocked/farmed? immediately sold?
For example if all the EPS was unlocked/dumped and turned into vecrv, EPS might stop airdrops to yearn and that would not be value maximizing. It gives discretion on the paths to generate those proceeds given the circumstances with the caveat that all proceeds from that activity should also be donated to the yvecrv vault (or more generalized, the respective vault whose token got the airdrop) as a fundamental principle.

How do yvecrv holders benefit from this? Now if you own 1 yvecrv instead of being unable to withdraw 1 crv you are now unable to withdraw 1.5 crv???

yvecrv holders are IMHO extremely undercompensated relative to other Yearn participants. The yield is extremely low, you can never withdraw, the gauge bonus of 2.5X are supplied to other vaults who only return 10% of the 2.5X boost they have gotten, and there is no effort to maintain a peg to crv. Now you are suggesting that the airdrop that should benefit yvecrv holders is again used to disproportionately benefit other vaults at the expense of yvecrv holders.

AM I REALLY THE ONLY PERSON WHO SEES IT THIS WAY?

2 Likes

I think part of governance is setting procedures and policies for how to handle situations.

@lehnberg is trying to facilitate a discussion so we can set the policy for what Yearn should do when a vault receives an airdrop.

If you’ve followed the other threads linked in the OP you’d see there is a lot of debate going on about how to handle the current airdrop.

This policy we’re discussing is to prevent us having to recreate the wheel for future airdrops.

If you think the proposal needs something, please suggest what additions you’d like to see made. “Too Squishy” doesn’t add a lot of value to the discussion.

One thing that I do think would be good to add, would be some kind of notification (Either from the Yearn Twitter, or on the Yearn vault page) that says what the decision for the air drop was

Another question I have is after the airdrop farming strategy was created would Yearn be able to leverage that design work and create a standalone vault for the token that was air dropped?

That could potentially incentivize teams to airdrop to yearn vaults because they’d know they’d be able to get some liquidity from Yearn. This could help pave the way for Yearn going multi-layer/chain

3 Likes

Imho this would be very bad for Yearn long-term as CRV would flow to other outfits that have better terms for dealing with airdrops. Who would lock their CRV in the backscratcher vault permanently and forgo the potential of all future airdrops when they have other options?

2 Likes
  1. Agreed.

  2. Agreed.

  3. This makes sense when the snapshot is at the same time as the airdrop. But quite often there’s a time delay between the snapshot date for the airdrop and the time of the airdrop itself. Is there a way of ensuring that people cannot then come and deposit into the vault who weren’t in the vault at the time of the snapshot and unfairly benefit from the airdrop? Appreciate sometimes the amount may be immaterial and not worth doing in more detail.

  4. Longer term it would be good to get some independence in the decision making – appreciate that’s difficult because the number of people who are interested enough to follow each case, and don’t have YFI (for example) is going to be quite small. But we could try and set a small group of clever DeFi people who like solving these types of problems and give them some principles (e.g. treating depositors fairly after considering all stakeholders). Their view could be considered advisory. This would take the pressure off the team who are trying to run the day-to-day operations.

In terms of the proposal, how much overlap is there between the Operations, Engineering and Finance teams? Also, how much overlap between those teams and the Multi-sig?

I think it’s a good idea to come up with a specification so that these issues can be dealt with more efficiently in the future, but it would be easier to vote yes to the proposal as stated if I knew the outcome of the EPS airdrop which seems to have divided opinion – in particular those who think yveCRV holders deserve the lion’s share versus those that don’t.

I appreciate and respect the effort by @lehnberg to clarify an unforeseen situation. That is to be applauded. I recognize that handling individual airdrops can be challenging, but Yearn finances are already opaque and letting an anonymous unaccountable dev ops team “do whatever seems best at the time” is the opposite of policy,

I must respectfully disagree. This is NOT a school PTA, there are over 2 BILLION DOLLARS TLV in Yearn, that generates a lot of fees, plenty to pay people to do things right.

It is my job, as a small investor, to point out that the governance is too squishy, and request that any proposals be fleshed out with specific policies and procedures where ever possible. That means people should have a pretty good idea of what will happen to an airdop by reading policy, they shouldn’t have to wait til the team makes up it’s mind.

The discussion in yvecrv specific thread where @banteg proposes different ways to calculate how to assign the airdop is the perfect example of what should not happen in the future. This is the sort of thing that should be detailed in any proposal on how to handle future airdrops.

As a small investor all I can do is encourage people to vote no, and to ask for a more fleshed out governance proposal. Were this posted as a draft, great we can all discuss how to improve it, but it was posted as a vote.

If Yearn wants to hire me (or anybody) to work on governance, GREAT, but governance is hard work, and I don’t have time to spend writing governance docs for free free for a fund with 2 Billion dollars under management.

As an aside: I also think the whole “Yearn’s image” and being left out of airdrops is nonsense. Yearn has a great deal of influence with Curve and Curve does with Ellipsis. Frankly Yearn has a great deal of influence with EVERYONE, creation of a Yearn product using a token or protocol is very valuable to the people who run that protocol. Ellipsis set up their Airdrop and their tokenomics (to charge people a 50% penalty, if they sold early) telling a single individual (Yearn) holder (representing many, many individual yvecrv holders) that they will be excluded from Airdrop if they want to sell, that’s not kosher, and Yearn need not be exploited that way.

5 Likes

I think the only feedback I have on this proposal as it relates to the current situation with yveCRV is that I would prefer for proceeds from airdropped tokens to be distributed in the following manner:

  1. If yveCRV price < CRV Price: buyback and burn yveCRV
  2. if yveCRV price > CRV Price: buy veCRV and donate

This will help maintain the yveCRV - CRV ratio which has been the biggest struggle with the vault

Snapshot vote is live!

https://snapshot.org/#/ybaby.eth/proposal/QmNqAqRKMFcoRjaRYAKCVETij6sjJ4S1293kbpYDMVvcjB

2 Likes

agree with some points disagree with tone

  • there should probably be a policy in place to deal with future airdrops
  • there isn’t one, this is defi after all
  • banteg is providing solutions
  • yearn, as a management fund for crypto, seems to be managing these funds fairly
  • agree it is unlikely for yearn to be excluded from future drops based on this, unless it gets dumped real bad

I wasn´t able to vote with YFI held at Bancor. I can´t even see current results.

Errors in the console:

Access to fetch at 'https://api-geth-archive.ankr.com/' from origin 'https://snapshot.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

snapshot.ts:102

Error: missing response (requestBody="{\"method\":\"eth_call\",\"params\":[{\"to\":\"0xeefba1e63905ef1d7acba5a8513c70307c1ce441\",\"data\":\"0x252dba4200000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000aab0000000000000000000000000000000000000000000000000000000000015560000000000000000000000000000000000000000000000000000000000001560000000000000000000000000000000000000000000000000000000000000156a0000000000000000000000000000000000000000000000000000000000001574000000000000000000000000000000000000000000000000000000000000157e00000000000000000000000000000000000000000000000000000000000015880000000000000000000000000000000000000000000000000000000000001592000000000000000000000000000000000000000000000000000000000000159c00000000000000000000000000000000000000000000000000000000000015a600000000000000000000000000000000000000000000000000000000000015b000000000000000000000000000000000000000000000000000000000000015ba00000000000000000000000000000000000000000000000000000000000015c400000000000000000000000000000000000000000000000000000000000015ce00000000000000000000000000000000000000000000000000000000000015d800000000000000000000000000000000000000000000000000000000000015e200000000000000000000000000000000000000000000000000000000000015ec00000000000000000000000000000000000000000000000000000000000015f60000000000000000000000000000000000000000000000000000000000001600000000000000000000000000000000000000000000000000000000000000160a0000000000000000000000000000000000000000000000000000000000001614000000000000000000000000000000000000000000000000000000000000161e00000000000000000000000000000000000000000000000000000000000016280000000000000000000000000000000000000000000000000000000000001632000000000000000000000000000000000000000000000000000000000000163c00000000000000000000000000000000000000000000000000000000000016460000000000000000000000000000000000000000000000000000000000001650000000000000000000000000000000000000000000000000000000000000165a0000000000000000000000000000000000000000000000000000000000001664000000000000000000000000000000000000000000000000000000000000166e00000000000000000000000000000000000000000000000000000000000016780000000000000000000000000000000000000000000000000000000000001682000000000000000000000000000000000000000000000000000000000000168c000000000000000000000000000000000000000000000000000000000000169600000000000000000000000000000000000000000000000000000000000016a000000000000000000000000000000000000000000000000000000000000016aa00000000000000000000000000000000000000000000000000000000000016b400000000000000000000000000000000000000000000000000000000000016be00000000000000000000000000000000000000000000000000000000000016c800000000000000000000000000000000000000000000000000000000000016d200000000000000000000000000000000000000000000000000000000000016dc00000000000000000000000000000000000000000000000000000000000016e600000000000000000000000000000000000000000000000000000000000016f000000000000000000000000000000000000000000000000000000000000016fa0000000000000000000000000000000000000000000000000000000000001704000000000000000000000000000000000000000000000000000000000000170e00000000000000000000000000000000000000000000000000000000000017180000000000000000000000000000000000000000000000000000000000001722000000000000000000000000000000000000000000000000000000000000172c00000000000000000000000000000000000000000000000000000000000017360000000000000000000000000000000000000000000000000000000000001740000000000000000000000000000000000000000000000000000000000000174a0000000000000000000000000000000000000000000000000000000000001754000000000000000000000000000000000000000000000000000000000000175e00000000000000000000000000000000000000000000000000000000000017680000000000000000000000000000000000000000000000000000000000001772000000000000000000000000000000000000000000000000000000000000177c00000000000000000000000000000000000000000000000000000000000017860000000000000000000000000000000000000000000000000000000000001790000000000000000000000000000000000000000000000000000000000000179a00000000000000000000000000000000000000000000000000000000000017a400000000000000000000000000000000000000000000000000000000000017ae00000000000000000000000000000000000000000000000000000000000017b800000000000000000000000000000000000000000000000000000000000017c200000000000000000000000000000000000000000000000000000000000017cc00000000000000000000000000000000000000000000000000000000000017d600000000000000000000000000000000000000000000000000000000000017e000000000000000000000000000000000000000000000000000000000000017ea00000000000000000000000000000000000000000000000000000000000017f400000000000000000000000000000000000000000000000000000000000017fe00000000000000000000000000000000000000000000000000000000000018080000000000000000000000000000000000000000000000000000000000001812000000000000000000000000000000000000000000000000000000000000181c000000000000000000000000000000000000000000000000000000000000182600000000000000000000000000000000000000000000000000index.js:166)
at h.throwError (index.js:175)
at index.js:169
at Generator.throw (<anonymous>)
at s (index.js:6)

runtime-core.esm-bundler.js:225

TypeError: Cannot convert undefined or null to object
at Function.keys (<anonymous>)
at Proxy.isZero (Votes.vue:96)
at Proxy.s (Votes.vue:3)
at St (runtime-core.esm-bundler.js:710)
at runtime-core.esm-bundler.js:4269
at Object.n [as update] (reactivity.esm-bundler.js:42)
at R (runtime-core.esm-bundler.js:4164)
at N (runtime-core.esm-bundler.js:4098)
at v (runtime-core.esm-bundler.js:3712)
at L (runtime-core.esm-bundler.js:4414)

runtime-core.esm-bundler.js:225

TypeError: Cannot read property 'totalBalances' of undefined
at Results.vue:72
at Array.sort (<anonymous>)
at Proxy.choices (Results.vue:70)
at Ue.n [as effect] (reactivity.esm-bundler.js:42)
at Ue.get value [as value] (reactivity.esm-bundler.js:827)
at Object.get [as choices] (runtime-core.esm-bundler.js:5783)
at Results.vue:6
at n (runtime-core.esm-bundler.js:1460)
at Wt (runtime-core.esm-bundler.js:1422)
at Proxy.i (Block.vue:32)

Ge @ runtime-core.esm-bundler.js:225

The results don’t load for me either, someone seems to have spammed it with a lot of dust votes. The API returns 2732 votes, but tallying them by hand will need some work since the space also uses vote delegation.