Signal Request: Should we fast track MIP10c9-SP6: yEarn ETH/USD OSM Whitelisting?

Recently there was a proposal from the yEarn (YFI) community to get whitelisted on the ETH/USD Oracle Security Module in order to create delegated vaults. These delegated vaults allow users to allocate their ETH capital to borrow Dai through the Maker Protocol and execute profitable Dai yield strategies. The key takeaway here is that delegated vaults will stimulate Dai generation and likely liquidity. Because of this I’d like to fast track the whitelisting of yEarns proposal to be included in a Polling Vote this week that would end in time for inclusion in next Friday’s Executive Vote.

This is not something I can unilaterally decide so I want to get a signal from the community on whether they approve of this fast tracking. I think a simple majority should suffice, but would like to see a relatively high quorum of 40 votes as this is a big break from our normal governance process and shouldn’t be taken lightly.

EDIT: Due to @LongForWisdom’s response I’ve changed the Signal Request to indicate fast-tracking would be for inclusion in a Polling Vote this week rather than directly into the Executive Vote. I’ve also changed the Signal Request poll to conform to the standards set out in the practical guide. If you’ve already voted, you’ll have to vote again.

  • Fast-track MIP10c9-SP6 to Fridays Executive Vote
  • Do not fast-track MIP10c9-SP6

0 voters

  • Fast-track MIP10c9-SP6 to Mondays Polling Vote
  • Do no fast-track MIP10c9-SP6
  • Abstain

0 voters


Hey Nik,

Looks like most people are on board. For future reference make sure to have “show on vote” checked so we can see who is voting for this for transparency sake.



I voted YES, mostly because I read your (nik) opinion and that of Mariano Conti (both positive), and I trust your technical judgment.

Just out of curiosity, would it be possible to summarise again, for the less experts among us, what are the risks involved in whitelisting some entity (like Yearn) to the Oracle Security Module? I.e.,

What could go wrong?


The last vote we expedited was the ETH-A debt ceiling increase last week, which was recommended by Cyrus, and we ended up doing an on-chain poll before adding to the executive. Maybe that will be a good path forward until we can have a formal emergency/urgency procedure in place.

We have the monthly MIPs cycle ending in the first half of the week, so if we do end up adding this to Friday’s executive, I don’t think it would be conflicting with anything other than base rate adjustments.

You meant “Show who voted” :smile:


Whitelisting on the Oracle Security Module just allows someone to read the price from the Oracle Security Module so in that sense not much. As for the potential of delegated ETH Vaults they have the potential to become Vault mega whales as anyone with ETH will be incentivized to deposit their ETH into yEarn’s delegated vault to maximize their yield. This means if this vault were to ever be liquidated we could see a huge amount of ETH get liquidated at once. Though the risk of this is mitigated by the fact that the delegated vault uses the property of the OSM of knowing an hour in advance when the Vault “would” get liquidated to actively pay down Dai debt at the expensive of yield.

The delegated vault will constantly switch to whatever the most profitable yield strategy is. In the short term this will likely provide a big boost in Dai generation which will help stabilize the peg and increase liquidity. However the long term repercussions could see increased Dai volatility when the delegated ETH Vault changes its yield farming strategy.

If the delegated ETH vault works well, I could see the YFI community expanding this to include this to many of the collateral types supported in Maker not just ETH.

Huge potential for Dai supply.


Interesting how fast things can get done around here when Foundation members have a stake in the success of the outcome #speculation.

1 Like


Full disclosure I have ~10 YFI staked in YFI Governance, but I can confidently say the reason I put forward the proposal to fast track this is due to the potential for Dai generation which is critical to fix the peg divergence. I made this decision independent from any influence of other Foundation members.


I have no problem with the expedition of this proposal as I agree with its intent and thank you for being transparent. I just wanted to call to attention the nature in which we as humans will prioritize that which is in line with our own incentives and hope that we can do the same with growing the Maker ecosystem.

1 Like

@Nik please read the practical guide to the signalling process. There is a list of requirements that weren’t met below. There is plenty of time before Friday, please make the changes and replace the poll (apologies to those who have already voted.)

Be limited to a single issue
This keeps the topic from becoming a confused mess of different conversations. This is not to say that there must be only one poll, only that all the polls should seek signals on the same issue.

Specifically, the title of this thread is misleading. You are polling on whether to fast-track the yEarn whitelisting proposal, not modify whitelisting processes generally. In fact I’m not sure whether that is mentioned explicitly in the text anywhere.

Have the correct tags
Using the same tag across the forum makes it easy to find all the signaling topics, it helps keep everything organised, it helps the community see if there are things to signal on, etc etc. The two tags that should be attached to a new signal are signaling and active-signal .

Use the following settings for any polls:

  • Results : Visible On Vote
  • Show who voted : Enabled
  • Automatically Close Poll : Disabled

Include an 'Abstain option
There are several advantages to including an abstain option in a signal request. Firstly, it allows voters to signal ambivalence or protest in a active way. It also allows the Governance Facilitators to check the results of the vote in-progress while remaining neutral.

Arguments against doing this in this way

I’m also not at all sure that the quoted benefits justify fast-tracking this proposal. The fact that this will increase Dai generation is a great argument in favour of whitelisting the vaults. But it isn’t an argument to implement the change more quickly than the regular weekly cycle. The current Dai price is roughly 1.005. There is no emergency, I’m not sure I’d even argue there is an urgency at the current time. Are we really saying that whitelisting this a week earlier is critically important? Why are we saying that?

We absolutely should not be skipping agreed upon processes outside of emergency (or at the very least urgent) situations. It sets a bad precedent. Maybe this particular change is something you agree with, great, I agree with it too. In fact, whitelisting contracts for the oracles is rarely controversial and is almost always pure win.

The problem is that the next change that someone tries to fast track might be something you disagree with strongly. The more quickly something goes through governance, the less time people have to express their opinions on the change. The more governance normalizes actions like this, the more likely it is that at some point you’re going to be looking at a change you disagree with that has already been implemented because you weren’t paying attention 24/7 and didn’t have a chance to express your opinion.

This would be a better solution, and I would prefer the sequence of events looked like this:

  1. Signal Request to expedite as an emergency action.
  2. On-chain poll (probably lining up to finish at the same time as the others) if the signal passes.
  3. Inclusion in the executive if the on-chain poll passes.

Thanks for your response @LongForWisdom. I believe I’ve incorporated your changes into the Signal Request, and have created a new poll. If you could please confirm that everything conforms to our standardized processes correctly now I would be very appreciative.

If you’ve already voted in the previous poll, you’ll have to vote again in the new poll.


Yep, looks much better, thank you.

1 Like

I voted yes, because what we do doesn’t really impact yEarn work. Whitelisting them allows for a better product on their end and maybe less liquidation risk on our end.

Nevertheless, I think that in all this excitement, we might miss a risk perspective. Should the foundation use its own resources (in lack of MakerDAO resources) to audit the yEarn code? Should Maker have the ability to blacklist/limit some vault owner? Who’s working on the impact such new contracts can have on Maker ecosystem and proactively provides a response framework? I.e. is a single 100M DAI ETH vault manageable or even desirable?

There is still an 80 million limit left to reach ceiling for Dai from Eth, however I’m expecting Yearn’s Eth vaults to explode at launch as there’s a lot of idle Eth around.

Be ready to increase the ceiling :rocket:

oh my…

No. Too much effort for current limited resources.

  • afaik, this is not currently possible (protocol)
  • it’s also bad idea, at least with current governance model (2 or 3 whales could, at least temporary, trigger denial of service)

Again, you can’t really prevent external actor (contract) to open multiple vaults.


Thanks LFW for your post.

After some thinking, I am persuaded by your argument: while the whitelisting appears to be a sound thing to do, there is no apparent urgency. So I am against the fast track.

I appreciate very much your post. In this exciting field of DeFI, where every day brings a new brilliant and ‘pumpy’ project, it is important for MakerDAO to keep calm and follow tested and trusted procedures.


So I didn’t initially notice that the poll option specified a poll on Monday. Looks like we’re probably going to be too late for this to go out with the rest of the polls (even assuming it hits 40 participants today.) If It’s still winning with over 40 participants tomorrow (and @NikKunkel provides poll wording), then I will add a poll on Tuesday that will end the same time as the others.

1 Like

Yea I noticed that as well but was unfortunately too late and didn’t want to reset the poll again. If (pending quorum) it goes live Tuesday and ends before the Governance and Risk call we should be good. I’ll submit a PR for the polling vote markdown today.

1 Like

I’m in favor of this proposal. There’s the debt ceiling which can be set defensively should the yETH vault become too popular. All the stars align here in my opinion: good for Dai, good for Maker, good for yearn, good for people to put their ETH to work.

In fact, this yETH vault could lead to further exploration of smart accounts that handle people’s investments for them.



The oracle whitelisting poll has now been submitted. It is set to start at 16:00 UTC for a duration of two days, to end with the other weekly polls. If this passes, the whitelist proposal will be included in the executive on Friday.

For what it’s worth, I think that it was completely unnecessary to fast-track this proposal. Even if the yEarn’s delegated vaults turn on the second this goes through they aren’t going to meaningfully impact the Dai price in the short term (though they may lead to more ETH-A usage.)

This statement is support for this proposal, but not for fast-tracking it. By my current understanding of how the yEarn Vaults work (which admittedly, may not be completely correct.) They allow usage of ETH-A to generate and lock Dai in other protocols to gain the most yield. So while Dai may be generated, it’s unlikely to significantly or quickly affect the Dai price unless it all ends up in an AMM pool like curve.

Putting it in curve is dangerous, because the purpose of the vault is to chase the best yield, if all the Dai is traded away via curve, then the capital can’t be removed from curve as Dai to chase other yield opportunities for Dai. This also makes it unavailable for deleveraging in emergencies. So I would be surprised if it ends up in curve or any other AMM.

This is a good move on the medium-long term, because it encourages vault usage which Maker has the ability to charge for, additionally, it dilutes yield farming opportunities. However, there is unlikely to be an immediate benefit, and therefore there was no reason to break ratified governance processes to approve it a week earlier than it otherwise would have been.

Why are you in favour of fast tracking it? All the arguments you made are in favour of the proposal, not in favour of breaking process to deliver it one week earlier.

Why break ratified governance process in a non-emergency situation for something that has no impact?