Proposal: Oracles Incentives Restructuring

Oracles Incentives Restructuring Proposal

For context for this proposal, please view the Oracle V2 Announcement. This proposal was already addressed on the Governance Calls on September 5th and September 12th.

To further decentralize the Maker Protocol, this proposal aims to create an incentive model that fundamentally aligns the different agents of the Oracle ecosystem to create a decentralized, sustainable, and secure Oracle network. The three agents that comprise this system are MKR token holders, Feeds, and Data Consumers. Their relationships are outlined in the figure below.

Feeds are individuals and organizations who submit asset prices to the Oracles smart contracts. They are compensated for this service by MKR token holders through a monthly Feed Stipend (see diagram). Currently, the Feed Stipend is being funded by the Maker Ecosystem Growth Foundation. In the future, the Feed Stipend is expected to be sourced from the Stability Fees generated by the Maker Protocol. Formal acceptance of this proposal does NOT change the Feed Stipend to be sourced from Stability Fees. As such, governance cannot change the Feed Stipend amount until governance changes it to be sourced from Stability Fees.

Feeds act as data inputs to the Oracles so the Oracles can provide a canonical price for an asset. This canonical price can be read and utilized by smart contracts on the Ethereum blockchain such as the Maker Protocol. The ability to read this price is regulated by a whitelist. The whitelist is a list of smart contract addresses which are permitted to read the canonical price from the Oracles. This mechanism enables MKR token holders to monetize the Oracles in order to recoup their costs for administering them.

Data consumers who want to read prices from the Oracles pay an Oracle Fee in Dai to MKR token holders in exchange for being added to the whitelist. The Oracle Fee can be realized by MKR token holders in the form of a surplus auction or a subsidy to future Feed Stipend payments. The default monthly Oracle Fee is zero Dai until MKR governance votes to raise it.

This mechanism closes the loop between data producers (i.e., Feeds), data consumers (i.e., dapps), and capital providers (MKR token holders). In doing so, it provides the necessary incentive for MKR holders to engage Feeds to support Oracles for all kinds of assets that dapps require, rather than just the collateral types in the Maker Protocol. In combination with the blockchain-agnostic architecture of Oracles V2, this system of incentives enables the Oracle service to expand to other non-Ethereum blockchains in the future.

If this proposal is accepted, the following will occur:

  • The monthly Feed Stipend that each Feed receives will be set to 1000 Dai. This will be funded by the Maker Ecosystem Growth Foundation.
  • A whitelist will be integrated into the Oracle V2 smart contracts which will determine which entities can read the price.
  • MKR governors will gain the ability to add/remove entities to/from the Oracle whitelist.
  • MKR governors will gain the ability to set the monthly Oracle Fee that entities must pay to be whitelisted (the default fee will be set to zero Dai).
  • MKR governors signal their intent to fund Feed Stipends through Stability Fees once the functionality for this has been added to the Maker Protocol.

Generally sounds great. Some specific questions below.

Message received. Don’t vote to spend the Foundations money :wink:

Will the Dai Credit System be paying the monthly Oracle Fee to the Oracle contract as a white-listed feed consumer? Or is it on some magic ‘uber-whitelist’ that gets free access in perpetuity?

What will happen to this fee on the initial implementation? I feel like we are a little light on details here. The Foundation is paying the stipends for the time being, assuming the fee was changed to be non-zero, who would receive the money? The Foundation? Or would it be used to burn Stability Fees?

This is hard to agree to. We are currently unable to use Stability Fees to pay for anything and my understanding is that this will still be true at the launch of MCD. We also have no control of the Foundation dev team or their priorities (not saying that we should do, currently we don’t pay them!)

I don’t believe we should signal intent for things that we are unable to control. We can signal that we intend to turn the sky green within a year, but it isn’t a credible statement of intent because we have no way to achieve it.

Can this statement change to something like: ‘MKR governors signal their intent to fund Feed Stipends through Stability Fees once the functionality for this has been added to the Dai Credit System’?

One last point was that several times on the call you mentioned an intention to provide the oracles for free for one year. Could you clarify which of the following this is:

  • A ‘one time only’ 1 year delay on collecting any fees from anybody.
  • A perpetual ‘first year free’ offer for any actor that wishes to use the oracles.

Personally I like the idea of the second option. Could this be clarified and potentially included as part of this proposal?

If you think about it, it doesn’t make a lot of sense to do this. If the Maker Protocol is charged for its usage of Oracles it comes out of the Stability Fees. Those payments would go directly back to the Stability Fee buffer and get entered into a Surplus Auction. You end right back where you started. There is no uber-whitelist. Governance is just trusted to not shoot itself in the foot by delisting the Maker Protocol contracts.

You’re correct that it’s a bit light on details right now. We haven’t implemented a specific mechanism for collecting Oracle payments yet. If the Oracle Fee was changed to be non-zero, MKR token holders would receive the money in the form of a Surplus Auction which burns MKR. Please see the Responsible Oracle Migration Proposal I just put up. It proposes waiving the Oracle Fee for 1 year for users. It’s a great way to bootstrap the customer ecosystem while buying the MKR Governance community some time to think about what a reasonable Oracle Fee would even look like. Are there bulk discounts if you purchase 1 Oracle vs 5 vs 20? Monthly vs annual subscriptions? We’re taking the first step here, but the road ahead is long.

I agree with you, this makes a lot of sense. Governance needs time to to be introduced to their powers and build governance processes around these as a precursor. I’ll change the language to yours.

Please see the Responsible Oracle Migration Proposal

It is indeed the second option where the 1 year interval is specific to each actor.

1 Like


Is the 1000 Dai feed stipend per market? Or is the stipend for reporting Eth and Mkr prices I.e. two markets?

Is the stipend expected to be increased once more markets needs to be feeded
With MCD? Do we have an idea about the size of expected expenses going toward feeds in the future I.e. how much would we need to rake in on oracle fees to match expenses?

The reason I am asking these questions is to get a better idea of the expected size of revenue stream from oracles and hence if monetizing the oracles is worth the effort. It might very well be worth the effort it is just (at least for me) a little difficult to assess currently.

Also if I remember correctly the feeds are currently reporting prices from centralized exchanges. Would it not be reasonable to expect that these exchanges would want a cut if we start monetizing their data?

The Feed Stipend is not per market. Each Feed reports prices for every asset and is reward for that service.

This is not something I can answer with certainty. It’s important that the governance community creates models to quantitatively asses Feed Stipends, before it starts changing the Feed Stipend. This one of the responsibilities delegated to Oracle Teams should the Oracle Team Mandate be accepted. My inclination is to say that Feed Stipends should not change in the immediate term as we have more pertinent issues to address with respect to Oracles. This proposal would continue to have Feed Stipends funded from the Maker Foundation. Governance would not have a direct say in changes to the Feed Stipend until it agrees to fund Feed Stipends from stability fees. That’s not to say community discussion and rhetoric won’t influence changes in the Feed Stipend, rather that the mechanism at the moment is not through a governance vote.

The Responsible Oracle Migration proposal is relevant here. It basically defers short term revenue in favor of acquiring a large customer-base. The Oracle marketplace is still evolving, so the fees per customer are still a bit of an unknown. Another responsibility of the Oracle Teams should they be accepted is to produce Oracle pricing models. That being said, the Oracle expenses scale well in that serving N customers for a particular asset costs the same as N + 1 or N + 100. With an Oracle for a new asset, the difference in expenses is only the gas costs. Given this, it makes sense to scale the customer-base as much as possible.

1 Like

I agree this makes little sense, but I don’t understand how the mechanism works. Are those on the contract whitelist charged using a smart-contract or is the fee collected off-chain? If on-chain, what mechanism prevents the DCS from paying this fee. If off-chain, why is it off-chain?

Is it that there is a boolean toggle to determine which of the whitelist addresses are being charged? And this related to the implementation of the ‘first year free policy?’ If this is the case, is the ‘first year free’ policy not enforced by the oracle v2 contract?

Fair enough.


Also great. I’ll dig into this more in the migration proposal.

With smart contracts, the goal in their design is to always make them as simple as possible. It is really easy to open yourself up to security bugs as you add more complexity especially once the concept of pulling/pushing $ comes into play.

In this initial version of the Oracle smart contracts there is no mechanism for extracting payment from a customer or verifying that a customer has “paid”. Neither is there a flag for the “first year free” idea introduced in the Oracle Migration Proposal. There is simply a whitelist which MKR Governors have the authority to add and remove from.

While seemingly over-simplistic it allows a lot more flexibility. For example, what if we had a customer that was willing to do a quid-pro-quo when it comes to Dai in place of payment? This mechanism gives MKR Governance the ability to consider this type of proposal. With an integrated Oracle Fee mechanism, it adds even more complexity to handle this type of exception.

At the moment, Oracle Fees could be handled through a secondary smart contract that is authorized to deposit Oracle Fees into the Stability Fee buffer for a pending Surplus Auction. The payment function would include an argument for which contract address the customer is paying for. So the payment is done on-chain, but the verification of which members of the whitelist have paid and which ones have not would be administered off-chain.


Your points all make sense to me. Thanks for taking the time to clarify this!

The Oracle Incentives Restructuring Proposal has been submitted to the Governance Portal for a Polling Vote. Please go vote on the proposal here.