YIP-55: Formalize the YIP Process

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

Great initiative @dudesahn! But I think the first comment in this thread is very important. I’m all for a more formalised YIP process, the proposed process is good but the proposed timings are too short.

The time frames indicate a lot about the what kind of YIPs are expected from the community. Short timeframes -> proposals for smaller issues and potentially even micro management. Nothing stops innovation as much as micro management! As I wrote in the strategic framework for Yearn under efficient governance:

In most democracies we have a four year voting process. What happens in between is delegated. Four years might be overkill for Yearn :slight_smile: But I would say absolutely minimum one week of forum discussion, followed by at least one week of Snapshot voting. If it was up to me, I would propose one month of discussion and then maybe 2 weeks of voting.

Things that go to voting should be so important that it requires contemplation, and if the vote swings one way provide time for the other side gather votes. Voting should be for important strategic questions, not operations imho.

edit: typo

Do you think that if we had delegated voting this voting time could be shortened?

1 Like

I don’t think so. I think it boils down to the question of what we want to enforce by formal YIPs and voting processes, and what should be considered part of ongoing operations.

Governance is a hard question. I don’t think there is a right answer :slight_smile: My starting point is that I think the most important thing for governance is to elect the right people for important operational roles, and provide limited resources to the people and teams that provide the best value to Yearn. At the same time, governance can also provide high level direction, so that initiatives and actions support each other.

Voting on this YIP passed with 99.1% For.

The YIP that ultimately passed included 3 days for discussion, and 5 days for voting.

Reasons behind the choices

3 days discussion: this is a minimum, and realistically discussions should last for much longer than 3 days. Primarily, proposals would only be moved to a vote after 3 days if there had already been substantial planning beforehand and it is very well accepted (minor changes or good, positive consensus), or if it is a proposal that has been previously discussed and refined.

5 days voting: We want to keep this relatively short, so as not to unreasonably delay enacting of well-received proposals, but also wanted this to be long enough to prevent malicious or poorly-constructed YIPs from being passed through. This was also a compromise on removing the quorum requirement. Realistically, I would argue that the support for or against a YIP that we will get in 5 days of voting (after it has already been discussed for at least 3 days) is pretty much everyone who is at least remotely engaged in governance.

As governance/Yearn is currently structured, the core team and the community has broad authority to upgrade the protocol as they see fit—it’s one of the wonderful benefits of being an open-source project. YIPs are targeted to ideas and proposals that require feedback or may be controversial, but realistically for Yearn to be able to iterate quickly and fine-tune our system, there needs to be a lot of leeway on what the team and community can do without needing a YIP.

1 Like

Thanks for providing more reasoning behind the timelines. I think we have a very similar point of view. We should embrace the organic development in an open source movement, voting and formal governance is best for proposals that need feedback or can be controversial.

My point with the timings are just that 3 days is a very short time. No matter how well planned a proposal is, how can you know it is well received after only 3 days? I think the majority of people with a potential interest in Yearn governance are like me, at best we check up on things during the weekends :slight_smile:

My main point is that with short timings like this, I think that governance on smaller issues are encouraged. Personally I just think longer timings would naturally filter out a number of proposals that should not be made into YIPs, but should be part of ongoing operations or the open source movement.

As this vote has passed, there is no point in arguing around the specific time periods. It’s fine, timings can always change later if a change is needed.

1 Like

It’s definitely something worth considering. I think if you or others notice that there are proposals that you feel like you didn’t have time to interact/engage with, then it might be worth revisiting in the future. Again, I’m hopeful that most proposals will naturally see a discussion period of around a week or so, but we’ll have to see moving forward.

1 Like

This is completely backwards.

Look at how EIPs progress, some take years to even be put to a vote.

3 Days of voting is completely one-sided: at minimum it should be a full week ( 7 days ).

Voting on this YIP passed with 99.1% For.

I demand a recount.