Proposal BTCUSD Oracle (Set Protocol, dYdX)


Back in September of 2019, the Maker Foundation published a blog post introducing the Oracle V2 architecture that would launch alongside Multi-Collateral Dai, and recommending a series of governance proposals.

These proposals were published in the Maker Forum for review by the MKR Governance community as well as discussed on the Governance Calls on September 5th and September 12th.

MKR Governance subsequently ratified the proposals through a sequence of Polling Votes (1, 2, 3, 4).

As a result of these proposals, MKR Governance gained several new capabilities, among these:

  • Launch Oracles for new assets (even if those assets aren’t collateral types in the Maker Protocol)
  • Regulate who can access the Oracle prices through a whitelist
  • Setting an Oracle Fee, the proceeds of which go to MKR token holders.

Proposal Summary

The Oracle Team, in accordance with its responsibilities outlined in the Oracle Team Mandate, is proposing the creation of a BTC/USD Oracle. With the DeFi ecosystem’s rapid innovation and expansion into tokenized Bitcoin (WBTC, tBTC, RenBTC) and synthetic Bitcoin derivatives (dYdX, Synthetix), there is significant demand for a BTC/USD Oracle.

Furthermore, should this proposal be accepted, Set Protocol and dYdX will be added to the whitelist as the initial set of customers for the BTCUSD Oracle.

Oracle Type: BTCUSD

Oracle Address:
0xe0F30cb149fAADC7247E953746Be9BbBB6B5751f (Medianizer)

Customers: Set Protocol, dYdX


0xbf63446ecF3341e04c6569b226a57860B188edBc (Set Protocol)

0x538038E526517680735568f9C5342c6E68bbDA12 (dYdX)

Date of Proposed Inclusion: 2020-04-17

Fee: In accordance with the Responsible Oracle Migration Proposal, fees are waived for the first year and determined by MKR Governance after that.

Data Models

Data Models describe the data sources and transformations for calculating the canonical price of an asset.


  • Source - The data source for the Oracle Feed
  • Asset Pair - a price quote of the exchange rate for two different assets traded on the source.
  • Quorum - The amount of Feeds needed to reach consensus on a price.
  • Feed Model - Model for how a Feed processes all sourced data into a singular price
  • Oracle Model - Model for how an Oracle processes all Feed data into a singular price

BTC/USD Data Model

|    Source     |  Asset Pair   |Quorum | Feed Model  | Oracle Model |
| :------------ | :------------ | :---: | :---------: | :----------: |
|   Bitstamp    |    BTC/USD    |   13  |    Median   |    Median    |
|   Bittrex     |    BTC/USD    | 
|   Coinbase    |    BTC/USD    |
|   Gemini      |    BTC/USD    |
|   Kraken      |    BTC/USD    |

Supporting Data Model(s)

The USDT/USD Supporting Data Model has been removed after feedback from community (see thread discussion)


|    Source     |  Asset Pair   |  Feed Model  |
| :------------ | :------------ | :----------: | 
|   Binance     |    BTC/USDT   |    Median    |
|   BitFinex    |    BTC/USDT   |
|   Huobi       |    BTC/USDT   |
|   Kraken      |    USDT/USD   |
|   OKEx        |    BTC/USDT   |

Technical Deliverables


  • Deployed, configured, and verified BTCUSD Medianizer on Ethereum mainnet at address 0xe0F30cb149fAADC7247E953746Be9BbBB6B5751f
  • Reviewed Set Protocol and dYdX contracts and verified Oracle price access is permissioned
  • Created spell to whitelist Set Protocol and dYdX contracts (WIP)



  • added support for the BTCUSD Data Model
  • added support for the USDT/USD and KRW/USD Supporting Data Models


  • updated Feed configuration files with asset pair details
  • updated Relayer configuration files with contract details


Removed Upbit as Data Model source
Added Bittrex as Data Model source
Removed KRW/USD Supporting Data Model
Removed Binance and Bitfinex from Data Model source to remove USDT based pairs.
Removed USDT Supporting Data Model


@NikKunkel thanks for this proposal.

Are you sure that it’s necessary to take the complex approach of using the two BTC/USDT sources and then scaling them by a separate inferred USDT/USD feed? (also, from the way it is written here it kind of looks like the two data models have a dependency loop, so I’m not completely sure how USDT/USD is calculated)

In general though, I feel like taking the simpler approach of only using BTC/USD pairs from reputable exchanges like Coinbase, Bitstamp, Bittrex, Kraken, Gemini, ItBit, and LMAX is a more robust approach. For reference, compare the methodologies used by major derivatives exchanges (which also require robust price feeds) like FTX [1] and Deribit [2].

I also don’t see a strong reason to bother with the BTC/KRW Upbit feed given the complexity involved in KRW/USD scaling as well as the historical tendency for those markets to trade at a premium/discount to USD markets.

[1] - (n.b. that FTX doesn’t use any /USDT markets though they do use some /USDC and /TUSD markets, which is more sensible IMO.)
[2] - and (only /USD markets from reputable exchanges)

P.S. another interesting idea to consider from FTX and Deribit index methodologies is that they use median of [last price, bid, ask] and average of bid and ask, respectively. If I’m not mistaken, I think setzer only uses last price, so these approaches are woth considering. Obviously this applies to all oracle data models.

1 Like

As you pointed out there is a a recursion loop with BTC/USD requiring USD/TUSD requiring BTC/USD. We’re considering two different solutions for this. The simple approach is to remove any USDT pairs for BTC. The more complex and somewhat hacky solution is to use coinmarketcap for the USDT/USD value the first time BTC/USD is queried. Subsequent queries for other asset pairs will calculate the USDT/USD price using the USDT/USD model and cached BTC/USD price and therafter cache the calculated USDT/USD price. From this point forwards BTC/USD is calculated using the USDT/USD model rather than coinmarketcap. I digress, it’s a bit of an odd method and we’re still evaluating whether the added complexity is worth it.

I also don’t see a strong reason to bother with the BTC/KRW Upbit feed given the complexity involved in KRW/USD scaling as well as the historical tendency for those markets to trade at a premium/discount to USD markets.

I see your point with Upbit. Due to capital controls, there appears to be quite inefficient arbing between Korean and mainstream western exchanges, with the KRW/USD exchange rate applying extra uncertainty. I had originally approached this from a pov of “the more exchanges with substantial volume, the better the security model”. However, getting consistent outlier data as a source strikes me as an odd tradeoff. For certain tokens such as BAT where it’s difficult to find a handful of legitimate exchanges that can’t be easily manipulated due to lack of orderbook depth I think it makes sense to use Upbit. In this case however, where as you point out there’s other quality options, I’m inclined to agree with you. I’ve changed the BTCUSD Data Model to replace Upbit with Bittrex BTC/USD.

P.S. another interesting idea to consider from FTX and Deribit index methodologies is that they use median of [last price, bid, ask] and average of bid and ask, respectively. If I’m not mistaken, I think setzer only uses last price, so these approaches are woth considering. Obviously this applies to all oracle data models.

The team was already implementing a midpoint of the spread but a median which includes the last price is something we hadn’t considered but sounds interesting. Definitely a change we would apply to all past and future Data Models.


On the mutually dependent USDT feeds: I haven’t thought about it much yet but it’s definitely something to be cautious about. Vaguely speaking, you probably can’t increasing robustness by making feeds that depend on eachother circularly so I would suspect that there are some very weird dynamics there that could occur, especially in an adversarial context where we imagine someone might be manipulating the price. My gut feeling is that sticking to /USD only markets is better, since at the end of the day there are plenty of great, liquid BTC/USD markets on very reputable exchanges available to choose from.

:+1: on all other points.

1 Like


I just watched the Governance call and it left me with some questions about Oracles: @NikKunkel I’d like to summarize what you said in the initial post of this thread to see if I understand correctly.

  1. Governance can vote to create an oracle regardless if it is an approved collateral type.
  2. Oracle access is not public, or can be granted by a whitelist.
  3. Oracle access can be “monetized” for other platform’s usage.

I don’t know much about the aspect of technical implementation, looking at this current situation where collateral needs to be added rapidly, is there a set of pre-built oracles already? Would it be prudent to have out of the box oracle solutions for “probable” asset types? If they ended up not being implemented, can this still be an additional revenue stream for the platform?

In summary, is it possible to pre-build the $*it out of some oracles, that are on stand-by for onboarding collateral? My thinking in this is the notion of being prepared for situations rather than fighting fires. It seems like collateral onboarding since I’ve been participating in the platform has been the result of fighting fires. I personally place high value on being prepared, and it seems to me as though some “ready to go” answers might serve the DAO well. Both practically and in a sense of building confidence in the Ecosystem.

Thoughts, comments from any and all are appreciated.

1 Like

Hey Adrian,

I think you bring up a very great point. It’s better to plan ahead and have things ready to go than implement them on-the-fly for collateral onboarding. If you take a look at setzer-mcd which is the tool we use to query prices for assets, we’re actually already doing this.

We have a bunch of asset pairs ready to go on the technical side. We could go a step further and have Feeds start pushing price updates for these assets to smart contracts, however I think that would be taking it a step too far as the gas costs involved in updating the Oracle smart contracts are not insigificant.

In the next few months I expect us to onboard a bunch of Oracles relatively quickly as we have a lot of interested parties and collateral-onboarding seems to be ramping up quickly.


100% Agree we should be taking cues from existing exchanges pushing hundreds of billions of dollars worth of trading. They know what they are doing.

More sources does not equal better security our reference prices when those sources are more volatile and unpredictable. Strongly suggest completely removing USDT pairs.

edit: Also clearly the USDT pairs are adding more complexity and therefore give a higher chance of bugs and outages


Thanks for the feedback @BrendanChou and @equivrel I’ve changed the BTCUSD Data Model to remove the USDT pairs (Binance and Bitfinex). I’m really happy to see the community not blindly follow the Oracle Teams suggestion, but really study the proposal, weigh the risks, and collaborate on solutions. This is exactly what this process should look like.


Thanks Nik,

Shall we try and add any more reputable sources such as LMAX? Today our team learned that Gemini has weekly 4-hour maintenance which reduces the number of sources to 4 pretty reliably.

My team has already gotten in touch with them. We’ll see if we can come to an agreement to get access to their data.

Do I understand correctly that a feed is able to select the price sources it uses?
Even if this is not the case, how will you ensure that all feeds update setzer so that it matches your latest changes, f.e. removing USDT pairs?
I ask this in order to understand how you will control that the feed sends the price from the sources described in approved proposal. I think when they begin to receive a fee, it become important.

No Feeds do not select their price sources. They use setzer which is configured with the specific sources approved by governance. When Feeds publish prices to the p2p network the messages have metadata attached that show the version of omnia they are running as well as the individual source prices that reduced to the published price. It’s very simple to verify on the network which version Feeds are running. If Feeds don’t update in a timely manner, they are warned, after a series of warnings, they are relieved of their responsibility as a Feed. Fortunately we haven’t had this occur yet and all Feeds have exhibited good behavior.

I think when they begin to receive a fee, it become important.

Feeds are already receiving a Feed Stipend, however it is currently covered by the Foundation. In time this responsibility will be transferred to MKR governance.

1 Like

@NikKunkel Thanks for the update with you and your team’s efforts. Doin’ a great job! Keep it up.