It’s 2020, beginning of February. Our protagonist, let’s call him Bob, has a large tank of gas sitting in his backyard, enough to fill up his Ford a few times over. Unfortunately due to Covid-19, he’s kind of sidelined from using it for the foreseeable future.
Fortunately for him though, his buddy Jim doesn’t believe in this whole self-quarantine thing and is getting ready to go on a long road trip in May, so he says he’ll buy the whole tank at the end of April. Afraid Jim might flake and hesitant to lock in a price during this level of uncertainty, Bob proposes they lock up the money now and pay the price of oil when the delivery happens. Jim agrees to it.
Conveniently for our story, they are both phenom ETH devs. They spin up an escrow contract that holds 60 DAI each (current price of the gas) and then set it up to transfer the money on April 20th based upon the price of oil. For simplicity, they use the standard oil benchmark in the US, namely the CME crude oil contract (the usual benchmark for oil prices) and off they go.
. . .On April, 20th 2020, the price of crude oil according to the CME’s future contracts hit an all time low, -$37. Now instead of Bob just giving Jim the oil for free, the ETH contract is broken because it likely didn’t allow for negative numbers¹, and technically now is underfunded since the seller owes $37. ²
But what happened?
If you went to the gas station, oil was far from free. In fact, it went down just a small amount. What gives?
The problem is that even though the solidity contract may have been sound…
They picked the wrong settlement price.
Instead of basing it on the price of gas at a local store, the contract used the CME’s crude oil price, which unfortunately did not behave as expected.**The CME contract is technically the cost of 1,000 barrels of oil ready for delivery at Cushing, Oklahoma on a specific date.
Although the changes usually correlate with the price of gasoline, due to COVID-19, you had an odd situation where the normal buyers of the oil didn’t need it anymore. Demand was down and since they would have to foot the bill to store the oil somewhere, you’d actually have to pay them to take more….in fact, you’d have to pay them $37 per 1,000 barrels.
. . .This scenario was of course a rather silly example, but it’s far from being an unrealistic example of financial contracts gone wrong because the settlement price isn’t what you think it is.
Similar to the specifics of an oil settlement price, there’s a difference between the price of Bitcoin, the price of Bitcoin according to an API, the price of Bitcoin at a specific exchange, the price of Bitcoin at a specific exchange at a specific time, and the price of 1,000 Bitcoin to be hand delivered on a ledger in Cushing, Oklahoma.
Knowing which price your fancy DeFi contract settles to is a game changer and too many parties making stablecoins or derivatives are relying on sub-par pricing information for their settlement.
Settlement Price Considerations
Besides the general security of the oracle (which we talk about here), the settlement price of DeFi apps needs to be conscious of three things:
- Appropriateness (is this the correct metric for my needs)
- Manipulability (How hard is it for someone to manipulate this feed)
- Availability (How fast and how sensitive do I need this feed to be)
Appropriateness
Back to the original story, it’s a little exaggerated and easy to see that the price of 1,000 barrels of crude oil in Oklahoma is likely a bad metric for the price of a small tank of gasoline. Even though the appropriateness of a specific data feed might be more nuanced than this, DeFi still has these problems. Is the spot price of ETH/USD on a KYC/AML’d exchange really appropriate for a stablecoin?
Appropriateness and settlement price considerations are far from a DeFi or blockchain problem. All financial contracts must deal with these issues and on this point specifically, regulatory bodies have created a whole suite of considerations and recommendations for financial products that every DeFi protocol creator should go through and follow. ³
When creating a derivative product for example, you want to be explicit on what you’re creating a product for. If the goal is a stablecoin and you need an ETH/USD price, you should be wary to just use a current price from an exchange. Does your protocol care for instance if the price of ETH spikes up in price for 10 seconds after a massive buy order? Maybe. Or maybe not. Will the protocol collapse or lose it’s peg if the price is not updated every 30 minutes? How important is an exact peg?
There are not right or wrong answers, but the specific data that one protocol chooses can change the entire functioning of the system during periods of stress.
Manipulability
Parties on Ethereum are often highly focused on the robustness of the oracle (how to get prices on-chain without a centralized point of failure), but they often overlook the basics of choosing a good data series to use.⁴
Many protocols for stablecoins of derivatives often utilize the current price or last traded price on a given exchange as the official settlement price. An easy example would be the current uniswap price for USDC/ETH as the ETH/USD price. A project needing the ETH/USD price might be tempted to use this; but the problem (besides appropriateness correlating USDC to USD) is that it’s highly manipulatable. If a whale comes in and buys up the orderbook, he could move the price significantly and this could put your whole protocol at risk.
The problem is not just uniswap or DEX’s either. All of crypto has this problem and its prevalent even for coins as large as Bitcoin. In fact, the whole reason that the SEC has so far denied ETF applications is on the ground that Bitcoin is ‘subject to manipulation’ or in laymen terms, whales can and do throw the price on a frequent basis.⁵
Protocols in DeFi need to be wary of using even CEX prices as the manipulation of these prices is much less expensive and more frequent than most crypto users like to admit.⁶
Like the research on appropriateness, DeFi applications should also follow common best practices in the traditional finance world. Between the LIBOR scandal⁷, the Hunt brothers fiasco⁸, or a litany of other examples, manipulation of spot prices happens frequently and the economic incentives and total exposures tied to a single cash price should be known and thoroughly thought out before utilizing a specific feed.⁹
Availability
The last consideration for your protocol should be availability. This tenet actually goes in contrast to the robustness generated by manipulability considerations.
All else equal, the more sensitive and/or faster you want updates, the easier it is to manipulate the data.
It makes sense. It is far easier for a malicious party to change the price of Bitcoin for one second than it is for them to change the price for an hour or even a day.
You need to make sure that your settlement price is accurate and up to date only specific to the task you’re trying to accomplish.
If you want to know the price of Bitcoin for a bet ending in three weeks, it likely doesn’t make sense to need the price on a second-by-second basis. If however, you run an options protocol where a large price movement (even for a few minutes), can mean the world to your protocol in terms of liquidations, you would want something more sensitive.
Oftentimes, DeFi protocols fall into a false trap where they are afraid of lagging behind real prices and feel they need to be fully in sync with the real world in order to be relevant. But this is a false problem created by a design error in the system. Enabling the system to handle slower feeds is a feature, not a bug. Latency based arbitrage opportunities happen, and oftentimes DeFi solutions to eliminate them lead to a protocol’s own downfall.
Defi Specific Solutions
So now onto the solutions for what you can do to make yourself a more robust feed.
The idea is simple, make it very hard to throw the price that is being reported. Whereas traditional finance has laws in place that prevent malicious data reporters and non-representative settlement prices, Ethereum and DeFi does not.¹⁰ A protocol needs to be far more robust and anything that can make an attack more expensive is a win.
Solution 1: Take a median or average across venues.
Afraid one exchange can get hit with a big market order? Use ten. This is a simple principle, but it’s key. Especially in the DeFi world, where certain KYC/AML restrictions and/or data laws could result in an exchange blacklisting or even suing your application for using its data feeds, multiple data feeds should almost be a requirement..
Solution 2: Volume weighted average price (VWAP)
Related to the first solution, if you take the price of an asset at ten exchanges, you weight the price on each exchange by the volume traded (or orderbook depth) over the last hour or day. The only caveat to this solution however is that volumes don’t really mean a whole lot in crypto these days, so be careful which exchanges you give this privilege.
Solution 3: Time weighted average price (TWAP)
A more robust method that can be included with any of the above is the TWAP. An example of this method would be to take an average price over the last 24 hours. Now instead of just blowing through an orderbook with a massive market buy or sell, any party who wanted to move this price would need to sustain a price move. This is actually very powerful in the crypto space as the prevalence of arbitrageurs mean that if the specific exchange you’re getting the price from is well connected, moving the price on that exchange over time would entail moving the prices on almost all exchanges.
It can create a much more robust system, but obviously at the cost of sensitivity. If your protocol needs frequent updates, this might not be a good option for a robust price, but for all other scenarios, should be used as leniently as possible.
Solution 4: Abstract price definition
Lastly, another great solution is just using a more abstract definition of the price. If you’re tied to a specific exchange, that means that no matter what, a whale can throw the price or the exchange itself can alter the API result. For specific hedging needs, this might be desired, but you may just want a more flexible system, ergo — just have parties say what the price is. If you have a more manual system (or one where parties are not tied directly to specific API’s), it might be slower and less sensitive to change, but the robustness and censorship resistance of the value may be what you want.
Conclusion
So what should you use?
In terms of our example at the beginning, our two participants would definitely have been better off just using “the price of gas” or any sort of TWAP to avoid the situation that arose. When your goal is a more general hedge like this (which is the case for most stablecoins and non-professional traders in the crypto space), getting exchange specific or extremely high frequency results is simply adding complexity and risk to the system.
But in general for DeFi protocols, I honestly can’t say what you should use. It will be dependent upon the specific use case and any change to the underlying settlement can change the details and security of your protocol. The thing you need to do though, is think through it and look into these protocols if you’re a user. A lot of the crypto space has little experience or knowledge of the traditional finance world and there are definitely pieces that we should not throw away.
Tellor has various robust settlement prices available (time weighted averages, medians, end of day prices, etc.) and we’d love to help you choose or develop one that works for your protocol, so reach out anytime if you want to talk it over.
. . .[1] Ethereum allows negatives (int) but a data type allowing only positive numbers would likely have been used, since prices are generally expected to be positive numbers.
[2] https://www.nytimes.com/article/negative-oil-prices-facts-history.html [3] https://www.iosco.org/library/pubdocs/pdf/IOSCOPD589.pdf [4] https://medium.com/tellor/best-practices-for-oracle-users-on-ethereum-1ad9e2a43c3b [5] https://www.investopedia.com/tech/bitcoin-vulnerable-sec-manipulation/ [6] https://www.coindesk.com/the-mechanics-of-market-manipulation [7] https://en.wikipedia.org/wiki/Libor_scandal [8] https://en.wikipedia.org/wiki/Silver_Thursday [9] https://www.cftc.gov/sites/default/files/2019-05/onur_reiffen_Manuscript_ada.pdf [10] https://www.sec.gov/rules/final/34-45956.htm
