Proposal: ETHBTC Oracle (tBTC)


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 an ETH/BTC 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 an ETH/BTC Oracle.

Furthermore, should this proposal be accepted, tBTC will be added to the whitelist as the initial customer of the ETHBTC Oracle.

Oracle Type: ETHBTC

Oracle Address:
0x81A679f98b63B3dDf2F17CB5619f4d6775b3c5ED (Medianizer)
N/A (Oracle Security Module)

Customer: tBTC



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 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

ETH/BTC Data Model

|    Source     |  Asset Pair   |Quorum | Feed Model  | Oracle Model |
| :------------ | :------------ | :---: | :---------: | :----------: |
|   Binance     |    ETH/BTC    |   13  |    Median   |    Median    |
|   BitFinex    |    ETH/BTC    |
|   Coinbase    |    ETH/BTC    |
|   Huobi       |    ETH/BTC    |
|   Kraken      |    ETH/BTC    |
|   Poloniex    |    ETH/BTC    | 

Supporting Data Model(s)


Technical Deliverables


  • Deployed, configured, and verified ETHBTC Medianizer on Ethereum mainnet at address 0x81A679f98b63B3dDf2F17CB5619f4d6775b3c5ED
  • Reviewed tBTC contracts and verified Oracle price access is permissioned
  • Created spell to whitelist tBTC contract (WIP)



  • added support for the ETHBTC Data Model


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


Removed HitBTC from ETH/BTC Data Model source
Added Bitfinex to ETH/BTC Data Model source


Are the actual fees To Be Determined?

Good catch, fees are waived for the first year and then determined by MKR Governance after that.

1 Like

Hi @NikKunkel, thank you, this is a good proposal.

On the subject of data sources: I would consider not using the HitBTC ETH/BTC market. Even though the reported numbers are high, HitBTC has a long track-record of wash-trading/reporting suspicious data. For this purpose, and for future discussions of cryptocurrency market data, I would like to draw your attention to the famous Bitwise report on exchange volumes for its SEC application [1] [2]. To quote from the section of the report specifically addressing HitBTC:

It is also easy to show that HitBTC volume is almost entirely fake. For starters, the Trade Size
Histogram drops straight down to an eerily flat line, with almost no volume after 0.5 BTC; it also
does not show any of the behaviorally driven spikes at 1, 2, or other round numbers of BTC.
Additionally, the hourly volumes are also completely detached from the reference set of exchanges,
with most of the week’s volume happening between 4/29 and 4/30, suggesting that volume on
HitBTC was not influenced by the same events that influenced every other real volume exchange.
We believe HitBTC’s volume is predominantly wash trading, done in small trade sizes.

Instead, I recommend including an ETH/BTC market from another reputable venue like Bittrex, Bitfinex, or Bitstamp (ordered by decreasing 24hr volume at the time of writing).

[1] - slides Bitwise Asset Management — Analysis of Real Bitcoin Trade … › Research › Bitwise-Asse…
[2] - paper Economic and Non-Economic Trading In Bitcoin - › srnysearca201901-5574233-185408


Why would a new ETH/BTC oracle be better than using existing oracles ETH/USD and BTC/USD? Low gas used and low fee?
As for data sources, even if you create a new oracle, setzer can calculate ETHBTC price through ETHUSD and BTCUSD.

Great questions marcuswin.

Why would a new ETH/BTC oracle be better than using existing oracles ETH/USD and BTC/USD?

Effectively every Oracle has a certain amount of slippage from the market price. This is because updating the Oracle every time the price changes by a fraction of a percent would be prohibitively expensive in the amount of ETH spent on gas. So let’s say both the ETH/USD and BTC/USD Oracle get updated every time the price changes by 1%.

By constructing an ETH/BTC price from the existing ETH/USD and BTC/USD Oracle you’re slippage isn’t capped at 1% since you get the compound slippage of both Oracles. Therefore in order to have a high quality (accurate) Oracle, it’s better to have a specific Oracle for ETH/BTC.

As for data sources, even if you create a new oracle, setzer can calculate ETHBTC price through ETHUSD and BTCUSD.

Not exactly. The sources for ETHUSD and BTCUSD (which are published in MIPS10) center on using pairs that correspond to the USD. This is a good method for isolating their dollar value, but the ratio of ETHUSD to BTCUSD is often not the same as polling ETH/BTC pairs directly like we are doing here. This effect is exacerbated when the market is very volatile and either BTCUSD or ETHUSD is leading a big price change. In this scenario it can lead to significant disconnect between the fiat prices of ETHUSD and BTCUSD where all the price action is happening that the ETH/BTC ratio isn’t being arbitraged quickly enough to keep them in sync.

1 Like

Thanks @equivrel, always value your input.

Todays volume at time of writing:
HitBTC = 24.5M * (.10 || .15) =~ [2.45M, 3.67M]
Coinbase = 3.7M
Kraken = 3.2M
BitFinex = 1.18M
Bittrex = 841k

We’ve read the Bitwise report and are aware that HitBTC has a significant amount of wash-traded volume. We estimate the real volume to be ~10-15% which puts it in the same ballpark as Coinbase and Kraken in terms of real volume and significantly above Bittrex/BitFinex. We use the same philosophy for other Data Models when utilizing exchanges like OKEx and Huobi which are known to exhibit significant levels of wash-traded volume.

While an attack from an exchange that paints the tape is significant for initiating an Oracle attack, so to is the risk of an external actor utilizing the lack of liquidity on exchanges like BitFinex/Bittrex to create sustained pricing irregularities requiring much less capital to manipulate the Oracle price.

Given this would you still advocate for replacing HitBTC with BitFinex/Bittrex?

Thanks for your reply @NikKunkel.

As a general point, I’m not sure I agree with the methodology of taking exchanges with high levels
(i.e. >50%) of suspected fake volume, estimating the non-fake volume, and then considering them ranked by volume alongside reputable exchanges for inclusion. Forgive the analogy, but it sounds like appointing a known liar to an important role on account of the fact that they speak a lot and on occasion speak the truth. More seriously, being an input to the price oracle data model is a critical link in a chain on which huge value potentially hangs, and I don’t think ill-regarded venues deserve a spot there at all. As the Bitwise report mentions, there are sufficiently many reputable trading venues with orderly markets, real users, and real price discovery, that we don’t have to put up with problematic misbehaviour like HitBTC.

To address specifically the point about relative trading volumes: a lot of trading by both retail and professional users takes place on Bitfinex and Bittrex on their other pairs, which means that sustained price manipulation there is likely to be costly. Moreover, if we take a look at some orderbook snapshots:

screenshot2725 screenshot2726
left: bitfinex ETH/BTC; right: hitbtc ETH/BTC

the difference in depth isn’t even that large.

Having said that, I probably won’t continue arguing this point since the ETH/BTC oracle isn’t intended for consumption within MakerDAO anyway (though any users of it should probably weigh in on this point). When it comes to the methodology of discounting vs. eliminating fake exchanges though, as it applies to other oracle data models, I would urge to go with the latter.


Thanks for your feedback Lev, I’ve replaced HitBTC with BitFinex in the ETHBTC Data Model.