YIP-55: Formalize the YIP Process


The purpose of this proposal is to standardize the Yearn Improvement Proposal (YIP) introduction, voting, and implementation process that governs the Yearn Finance protocol.


This proposal formalizes the process for introducing, voting, and implementing YIPs. Valid proposals are to be discussed for at least 3 days on Yearn’s governance forum and include a forum poll to gauge sentiment. If after three days there is a 25% “For” vote in the forum poll it will then move to formal voting via Snapshot. In order for a vote to pass it must have a majority support (> 50%) after at least five days of voting. Following a successful vote, necessary changes will be implemented by Yearn’s protocol or operations team and signed by the multi-sig, if necessary. Changes to this policy, including quorum requirements or what constitutes a majority vote, can only be enacted by a valid YIP that overwrites this policy.


Although there are several informal standards governing the YIP introduction, voting, and implementation process there is no single, clear policy. Recent proposals have not followed the quorum requirement defined in YIP-12. Additionally, no YIP or formal policy has been implemented that specifies votes conducted via Snapshot are formal and binding. This YIP would define and formalize the process in order for proposals to be valid and binding, and reduce any confusion in the YIP introduction and voting process.


Introducing the YIP

In order to submit a potential YIP for voting a user must first create a thread for the proposal on the Yearn governance forum (http://gov.yearn.fi). Complete the auto-populated fields that appear when creating a proposal on the forum. A screenshot of these fields are below:

Additionally, the thread should include a poll from the governance forum to gauge interest from the wider governance community. After the thread has been on the governance forum for at least 3 days and has received over 25% “For” votes it can proceed to formal voting via Snapshot. This allows the community to suggest potential changes to the proposal before it moves to the formal voting phase on Snapshot. Please do not assign your proposal a YIP number; numbers will be assigned by moderators prior to a vote taking place.

If a proposal was introduced on the governance forum and achieved at least a 25% “For” from the poll but is not submitted to Snapshot within 30 days, the author of the proposal must re-submit the proposal to the governance forum and restart the process. This ensures that proposals that previously received support from governance still retain support from the community.

Formal Voting Phase

Snapshot is used for formal, binding votes. The user who authored the YIP will also create the Snapshot proposal using this link (https://snapshot.page/#/yearn). Snapshot requires 1 YFI in a user’s wallet to create a proposal. If the author does not meet this requirement then contact a moderator who will submit the proposal on your behalf. Before creating the Snapshot vote, please wait for a moderator to assign your YIP a number and begin your Snapshot title with it.

A previous version of this proposal called for a minimum of 72 hours for voting, and a 20% quorum requirement. In response to feedback that a quorum requirement might be difficult to quantify and could lead to time-consuming rallying of apathetic voters, we have instead opted to extend the minimum voting window to 120 hours (5 days), with a maximum length of 7 days. This extension period, coupled with an active communication of YIPs via the governance forums and on social media should help ensure that no YIPs slip by, or malicious ones are approved. 5 days is sufficient time for the wider community to participate.

The block selected for the Snapshot vote should be a block close to the Snapshot submission. In order for a vote to pass it needs to have a majority approval (>50%) by eligible voters. The eligible vote is defined as YFI held in the governance staking contract and the yYFI vault at the time the vote is proposed on Snapshot. If the Snapshot vote does not meet a 50% majority approval then the vote is rejected and no changes will be enacted. Authors of proposals that are rejected may resubmit their proposal, but should include significant changes that address issues that may have prevented the YIP from passing during the initial vote.


This specification aims to clarify which proposals should move to the YIP stage, how long they should be discussed for, and how long the vote should be open for. By only allowing proposals to move to YIP/voting after several days of discussion, we ensure that everyone’s voice is heard, and proposals should more accurately reflect community consensus.

Additionally, while some may think that three days is too short to adequately discuss a proposal, this is simply the minimum requirement. We expect most discussions to last for significantly longer than this (as they have in the past), with only a select few well-planned and researched proposals with near unanimous approval moving through so quickly. This proposal also will not stifle the open source protocol improvements that are made daily by dozens of Yearn’s contributors. It only aims to govern those proposals that seek community feedback and ratification as YIPs.

Other Uses for Snapshot
Snapshot may still be used for informal signal voting, including community contests, but its primary purpose will be to conduct formal, binding votes.


  1. All proposals must be discussed for at least 3 days with a forum poll before they will be assigned a YIP number and move to Snapshot voting.
  2. The Snapshot vote will be binding, and must be open for at least 5 days. At least 50% must vote “For” the proposal for it to pass.
  3. Most open-source protocol updates do not require YIPs; this process only governs those changes or proposals that wish to be discussed and enacted as YIPs.

For: Formalize the YIP introduction, voting, and implementation process as specified above

Against: Do not formalize the process. No changes made.

Update Jan 16, 2021: This post was updated to reflect the final version of the proposal that was voted on via Snapshot. Additionally, a typo was corrected, changing 96 hours to the intended 120 hours (5 days).

  • For
  • Against
0 voters


A binding vote is now live on Snapshot and can be found here.


@franklin @dudesahn

I am for, but 3 days is not enough. A week should be required.


This is exactly what I was asking about the other day.

But I agree with @WrongNebula a week at least as I assume many members are not active daily and their votes and opinions matter.


I think the governance process should be flexible and nothing should be a hard requirement.

The best things Yearn has didn’t come out of proposals, but rather from collaborative efforts. We surely don’t want to hinder this creativity.

As far as I know, Snapshot doesn’t have a quorum feature. Looking at numbers, only one of the most recent polls would’ve been defeated by the quorum requirement. Thinking of reintroducing quorum as a hard requirement and spending time on rallying people to vote gives me nightmares.

A few counter-examples to the usual process:

  • @aliatiia has proposed yAcademy in September and has been quietly working on it for two months. A new refined proposal went straight to voting.
  • My proposal has been in research for weeks before I posted the initial version. It was enough for community to take over it and split it up into smaller and more refined proposals. The smaller proposals have included the feedback and went straight to voting.

I would like to see ALL forum polls move to snapshot, and make a clear distinction between polls and binding votes. I can see how this could be confusing so we could clearly label polls in snapshot as forum polls and YIPs as core, possibly. We moved polls to snapshot because polling on the forum isn’t a good measure and now it seems like we are moving back?

Who are the responsible parties for moving proposals to YIPs? I will assume this is just forum admins?


It’s not about making the governance process rigid or strict, but clearly defined. It is also being true to the spirit of governance and how things are enforced. There was and still is a quorum requirement, nothing has changed that. If we get in the habit of just not enforcing, or selectively enforcing YIPs it breaks down the sanctity of governance, and then what is the point?

Quorum is an important part of consensus and governance and ensures that frivolous or unintended proposals do not slip by. The quorum above isn’t restrictive, and in fact is less restrictive than the current quorum requirement, as it specifies only eligible YFI is in the quorum pool, which is YFI held in staking contract and yYFI vault.

We don’t want to have ambiguity or subjectivity in the governance process. It should be objective, clear and verifiable. Did the majority vote? Yes. Was quorum met? Yes. Was sufficient deliberation made to incorporate potential changes? Yes.

This proposal doesn’t hinder any creativity it merely defines the governance process.

@WrongNebula Do you mean for the time on the forum?


Like @Franklin said, we didn’t write this to try and slow down governance or make it into a bureaucratic nightmare. We just want a more well-defined outline of what we think governance should look like for YIPs.

Realistically, the reason we wanted to bring back the idea of quorum is to make sure that proposals/votes don’t sneak by. While this obviously is not the case currently, and theoretically we have a multisig (and admins, among others) to protect us from any nefarious proposals/votes, building in redundancy here I think is still advantageous.

Perhaps there could be a sort of compromise based on feedback from @banteg and @WrongNebula.

The reason behind implementing quorum is to ensure that enough governors are participating, and so that bad votes can’t be quickly pushed through. Perhaps instead of requiring a quorum, we could implement a mandatory time from proposal -> vote of 5-7 days (pick one) and then extend the mandatory vote window to 5-7 days. As a side note, with a proposal like @banteg’s that was split into separate parts, this clock would start from the time of the original proposal, which I think is more than fair and wouldn’t unnecessarily slow it down.

To address @banteg’s other concerns, this wouldn’t cause good proposals to fail due to quorum, and there would be plenty of time to discuss things like @WrongNebula and @Ceazor mentioned. If a vote is being discussed for a week and then voted for a week (or 5 days and 5 days), and someone still doesn’t care enough to engage or vote, then I don’t think a quorum requirement is going to change their mind.

This YIP also isn’t saying that every time we change a single thing about Yearn we have to wait two weeks to do so and vote on it—it’s just saying that if you want for something to be a binding YIP that is approved by the community, we should give the community enough time to weigh in and approve that vote.


I think that if people want yearn to innovate quickly, you can’t have voting take weeks or even a week. Have we thought about allowing delegated voting? Then we could change the voting time to 3 days, and it would be the delegate’s job to make sure they vote on time or people will switch to someone else. I think this might help with the avg person not checking in to vote every few days. Also, if someone’s delegate votes in a way they disagree with then they can vote on their own and change their vote. Maybe something we could look into.


With the way things are structured, the quorum is way too low. 20% of the current locked YFI in governance is only 432 YFI. (20% of 2156 YFI) So currently the quorum is 432/30 000 or 1.43% of the total YFI, that can’t be good!

I disagree on this point, and think it’s important to emphasize the difference between normal changes to the protocol and YIPs. We’re not using YIPs to vote on every single new strategy or PR, we want to use them for major shifts that affect how Yearn functions, and especially changes that the author wishes to receive feedback on.

Realistically, Yearn’s core dev team has leeway to do as they see fit, as long as the multisig doesn’t oppose them on it. This allows us to iterate quickly on issues that we need to such as emergencies like shutting down earn calls on the GUSD/TUSD/DAI vaults, but also not drowning voters in minor changes such as updating the Curve yVault icons.

But if we use the most recent mega-proposal as an example: it was first proposed 12 days ago, and received significant feedback that it needed to be split up so that it was multiple, more granular proposals. The first of these proposals went live four days later, with the third of four currently being voted on.

My point being that while the authors of that proposal had been thinking and working on it for a while, it still got better with community feedback! And to give good feedback, you may need more than a few hours to think about something and to iterate on the proposal. And realistically, since all of Yearn’s governance is happening off-chain, this is the only real benefit that Yearn’s DAO can provide currently—ideas and feedback. So if we’re not open to giving time for feedback and input on YIPs, then what’s the point of governance?


Agree with @dudesahn that it is important to keep in mind the distinction between YIPs and open source protocol improvements.

I do not see any real downsides to codifying the YIP process. It will prevent scammy/spammy proposals, of which we have seen many.

As @banteg anteg said, it is important that we do not stifle creativity and innovation but I don’t think codifying the process will do that. We implemented requirements for making snapshot propisals for similar reasons. Anyone who wants to create and/or innovate around/with/for Yearn is free to do so, and the only people who really get blocked from participating due to hard requirements around length of dicsussion etc are people who want their ideas pushed thru with minimal discussion. Not much value to be lost there, imo


YIPs are already formalized, look at GitHub

This seems completely unnecessary

1 Like

Formalizing the process doesn’t make it less flexible. Anyone will still be able to participate with any idea. It will not hinder creativity in any way, it will enhance it, as the community will add value to the original ideas.

There should exist at least some requirements for making a YIP. Quorums are established for a reason in governance, there are risks associated with not having one. As for the time requirements, this gives the opportunity to other community members to analyze data if needed, or validate the data included in the proposal.

A clear and structured process, with well established rules will maintain a solid governance.

1 Like

While the YIP creation/PR process itself is formalized on GitHub, there is nothing regarding which proposals should move to the YIP stage, how long they should be discussed for, and how long the vote should be open for.

This proposal is aiming to fill that gap with a tangible framework. By only allowing proposals to move to YIP/voting after several days of discussion, we ensure that everyone’s voice is heard, and proposals will be better for it.

Again, this is not preventing Yearn’s core team from doing anything; they already choose the changes that they consider large enough to be discussed and voted on publicly. This is simply adding an extra layer of clarity so that poorly thought out or malicious proposals are less likely to make it to or pass a vote, while making sure that everyone is certain what does and doesn’t count as a YIP on Snapshot. Ultimately we have the multisig to protect us in situations like this, but realistically we don’t want to be relying on the multisig to veto passed YIPs unless we absolutely have to.


This doesn’t change the process documented on Github, in fact it largely follows that with the specifications above.

I don’t agree it is “completely unncessary”, in fact I can’t even count the number of times people have asked me if Snapshot is binding or not, or what is the current governance process. The governance process has been ambiguous. What YIP overturned the quorum requirement? What YIP certified that Snapshot votes are binding?

In response to some of the feedback in this thread, we are going to modify the proposal prior to submitting it to Snapshot as follows:

  1. Remove the quorum requirement as indicated it may be difficult to quantify via Snapshot at the time of the proposal;
  2. To help mitigate malicious, or frivolous proposals slide by governance we are going to extend the voting period to be 5 days. This extension period, coupled with an active communication of YIPs via here and on social media should help ensure that no YIPs slip by, or malicious ones are approved. 5 days is sufficient time for the wider community to participate.

To be fair I’m talking about voting time on proposed YIPs not how long they take to form. They should have already been discussed before being put up for a vote. I’m all for people taking time to talk about things.

I think this should be changed to a snapshot poll. That way people vote in the poll with their YFI.

1 Like

The proposal that we’ll be putting forward later today on snapshot shortly is a bit of a compromise—remove the quorum requirement and establish the voting-time minimum at 5 days.

This should give plenty of time for Yearn governance to rally any votes needed to strike down poorly-designed or malicious proposals, but not so long that it’s slowing down process.

Again, we’re not making the requirement that every single change go through a YIP, but those that do should have adequate time for discussion and voting.

We’re updating the language in there to use either Snapshot or the forum polls. I’ve been talking to Klim about if there’s a way to hide sentiment polls from the front page on Snapshot and only have them viewable via direct link which would really help limit confusion about what is a YIP and what isn’t. TBD on that, but we’re certainly not outlawing Snapshot to be used for sentiment.

1 Like

Voting on this YIP is now live on Snapshot and can be found here.

@dudesahn Great news thanks