MIP10c9-SP14: Subproposal to Whitelist Yearn Finance on YFIUSD Oracle


MIP10c9-SP#: 14
Author(s): Artem K, Daniel L
Type: Process Component
Date Proposed: 2020-11-19
Date Ratified:



Yearn’s core product is Vaults. A vault takes a specific base asset as deposit, which is then delegated to Strategies that farm and recycle rewards back into the specific base asset of the Vault in question. A more complex product is a Delegated Vault, which leverages a certain base asset to borrow another asset that is then delegated to a Vault.

We are currently building our third Maker-based vault, taking YFI as a base asset and leveraging it in a similar manner as our existing yWETH and yWBTC Vaults. It will maintain a Maker Vault and delegate the drawn DAI to the Yearn DAI Vault. To make the strategy able to rebalance and unwind, we require access to the next OSM price.

We’ll be using a permissioned proxy contract should new strategies requiring the OSM emerge. It is controlled by Yearn’s Governance.

Oracle Name



yearn finance - Andre Cronje ([email protected])


yearn finance - 0x208EfCD7aad0b5DD49438E0b6A0f38E951A50E5f - OSM


For each customer address to be whitelisted:
- Is the contract source code verified on etherscan? yes
- Is the Oracle data used in a permissioned manner that would prevent parasitic behavior? yes
- Is Oracle data written to storage? no
- If Oracle data is stored, is it stored in a private variable? not stored
- If Oracle data is stored, is the value accessible on-chain exclusively by the protocol? not stored


yearn finance - ROMP


The Oracle Domain Team has reviewed the contract and verified that the Oracle data is handled in a private scope. The Oracle Domain Team will submit a copy of this proposal to the MIPS github repo, as well as create the markdown for a Polling Vote that will go out Monday, November 30th. Normally this would mean the proposal would go to an Executive Vote on Friday December 4th. However, with the Governance chief migration happen around that time, it is likely this proposal won’t be included until the following Executive Vote on December 11th.


When does Maker start to charge for oracles and why not sooner?

I would love for us to work on beginning to charge fees for the Maker Oracles, it’s just not very high priority right now given all of the other items we’re responsible for. Right now in parallel we’re working on:

  1. Development of the Maker Oracle Protocol which includes:
  • Oracle client development (omnia & ghost)
  • Oracle price tooling development (setzer & gofer)
  • Transport Layer development (secure scuttlebutt & libp2p)
  • Transaction Management development (hera)
  1. Collateral Onboarding
  • Oracle Assessments for collateral types
  • adding support for new collateral types to the Maker Oracle Protocol
  • creating, testing, staging, and deploying to production a new Oracle release every time Maker Governance wants to add a new collateral type to the Maker Protocol
  1. Oracle Governance:
  • scheduling Governance Votes
  • informing the community of Oracle related governance proposals on the Governance & Risk call
  • reviewing and implementing Oracles for non-collateral types
  • reviewing Feed proposals and assisting them with deploying their Feed
  • reviewing Oracle whitelisting proposals (like this one)
  1. Bespoke Oracle smart-contracts for “special” collateral types:
  • Uniswap V2 LP Token Oracles
  • RWA Oracles
  1. Layer 2 integrations for the Maker Oracle Protocol

  2. Collecting invoices and Distributing the monthly Oracle Feed Stipend

I’m really looking forward to new Oracle Domain Teams to emerge who can start to assist in some of these area as well as work on entirely new ones. Now all that said, I think coming up with a model and governance process around Oracle Fees is something perfectly suited for the community to tackle. The community would need to answer questions like:

  • Is it important to profit off of the Oracles?
  • Should we prioritize market-share or revenue/profits?
  • How much should we charge customers?
  • Should all customers get charged the same? If not, what metrics should we use for determining price?
  • Should price be dependent on how frequently the customer uses the Oracle?
  • Should price be dependent on how much value the customer derives from the Oracle?
  • Does it matter how many customers are using the same Oracle?
  • Should customers get discounts if they use more than one Oracle?
  • Should Oracles with tighter spreads (more gas fees) cost more?
  • Should customers who are running Light Feeds get a discounted rate?
  • Should customers who switch from a competitor like Chainlink get a discounted rate? For how long?
  • Can customers “fix” a price for an extended period of time?
  • How do we go about changing the price?
  • How long after a price change is decided before it goes into effect?
  • What if gas prices increase to 500 gwei and our gas costs to run the Oracles increase by 10x? Does the price change? How much? Is this fair to customers?
  • Does cost increase if a customer Oracle is especially complex and/or time-consuming (read expensive) to implement?
  • Do customers whose Oracle usage generates significant stability fees for the Maker Protocol get discounted or even free Oracle access?

Thanks for your answer and the detailed info!

That’s too bad. Based on the LINK mcap, it’s a big market and a very high entry barrier for new players.

Yes, I realize now that it is more complex than I thought but it would be worth to hire a dev full time for a month or so to work on those questions and suggest a solution as simple as possible to begin with. I am against using the surplus for unspecified dev work, but I’d support using the funds for a clear purpose like this one.

The question is, of course, do we have a surplus or not because if we cannot spend it (a reserve for bad loans) then we don’t have it.


The idea of the surplus buffer is very much about using it to fund protocol initiatives. This can be in the form of grants for one-off initiatives or continuous funding as is the case for Domain Teams. Now we just need a willing victim participant.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.