Jump Crypto's first column for CMC Research dives into price oracles, the issues at a foundational level and how it can move forward.
- Price oracles must be both accurate and timely, but often those two goals directly conflict.
- In order to achieve both goals, we propose that price oracles align incentives internally, by having oracle operators stake reputation, collateral, and trading capital on the integrity and timeliness of the data.
- This framework can be applied to the separate cases of the LIBOR index and the on-chain Pyth oracle, to understand which elements are designed well and which elements require further work.
These principles can be applied to understand the (in)famous example of LIBOR. The mechanism to generate LIBOR took only limited steps to align incentives, and this was likely its undoing. A system that deployed skin in the game more extensively could have performed better.
Here at Jump Crypto, we contribute to an oracle protocol known as the Pyth network ("Pyth"). So it should come as no surprise that we’ve helped Pyth operationalize these principles, to distribute data in a low-latency and high-integrity manner. There are many real-world constraints that preclude Pyth from doing this perfectly, and that force it to add some additional defenses. But the importance of skin in the game in Pyth’s implementation and whitepaper alike excites us.
What is a Price Oracle?
A price oracle is a source of price data streamed onto the blockchain. Oracles bridge the off-chain world with the blockchain, by publishing off-chain price information on-chain.
In many cases, this may seem unnecessary, as price information often already exists on-chain. For instance, one can figure out prices by querying decentralized exchanges (DEXes). Integrating the on-chain source requires no extra lift from an infrastructure or coordination perspective, and the risk of a delay or an off-chain failure is minimized compared to an oracle.
However, DEXes often have relatively low liquidity compared to centralized exchanges (CEXes). Thus, DEX prices may not be representative and are often more easily manipulated than CEX prices. Using an oracle resolves these issues, as the oracle brings the high-quality information from CEXes onto the chain.
Oracles, though, introduce their own vulnerabilities. As the many examples of oracle failures illustrate, they can be manipulated and they can make mistakes. This issue is the heart of samczsun’s piece and ours alike.
Delays and New Attack Vectors
This is a feature, but perhaps also a bug. When the price falls because of legitimate reasons (e.g. increased selling pressure), the oracle price will lag the "true" price of the asset significantly. Any protocol dependent upon the oracle will be using stale prices for its logic. Thus, delays are reasonable when the asset class is stable, and unreasonable when the asset class is volatile.
But crypto, of course, is still a volatile asset class, with frequent intraday spikes and drops. This problem gets worse when certain tokens face sudden squeezes, crashing or skyrocketing in price. Delayed oracles in this context can be disastrous.
The twenty-four hour oracle may be an extreme and admittedly stylized case, but surprisingly this assessment even holds for shorter and seemingly reasonable timeframes. For instance, consider the price of ETH in mid-August 2022. Even using a fifteen-minute TWAP leads to a significant lag of the oracle price behind the price on a centralized exchange, as the graph below shows. In this example window, there is an average difference of 6.35, i.e. 0.40%. Arbitrageurs thus can earn outsized profits, particularly during tumultuous periods, entirely from LPs that finance pools using delayed oracles.
To be clear, samczsun’s motivation for introducing delays is reasonable, given the plethora of oracle price manipulation exploits in DeFi. But the cure can be worse than the disease here, particularly in markets with high volatility.
Staking and the Integrity of Information
This is known as "skin in the game," which we also refer to as "staking." Crypto users are likely familiar with staking in its canonical form: some party posts funds as collateral that can be seized if they perform maliciously or poorly, to align incentives. Staking is common to how Layer 1 networks manage their validators. But the broader principle of staking — wagering something valuable to commit credibly to good behavior — can extend to oracles in three ways: reputational staking, staking of collateral, and staking by trading.
But an oracle operator that is powered by a collection of data providers can implement this mechanism on its upstream contributors more successfully. In particular, oracle operators can make provider contributions transparent, so that individual contributors that perform poorly will do so in full public view (presumably without affecting the aggregate price substantially).
This is a powerful mechanism, if it can be operationalized successfully. However, it requires an adjudication mechanism that punishes incorrect contributors and operators automatically. As it is, most Layer 1 networks have not implemented this feature yet for their validators — and oracle networks may face similar development challenges. Such an adjudication mechanism requires some independent or least robust notion of ground truth to score oracles on.
Indeed, samczsun does note this solution in the context of individual protocols or traders: "the best way to know for sure the exchange rate between two assets is to simply swap the assets directly." But this principle can be extended to oracles operator directly. By "staking" capital (under this much broader definition), there is a natural synergy between traders and oracle operators to enhance data quality, without compromising on its speed and usefulness.
As always, the trick is operationalizing this successfully. In particular, traders do not want to give up their edge, and so they may want to publish that data after first executing trades. If that lag is long, the oracle risks becoming high latency again. Second, there needs to be some enforcement mechanism to ensure that oracle operators do not misrepresent their contributions as true prices when they are not. Thus, this mechanism best works when coupled with the other ones.
Case Study: LIBOR
Aligned incentives are not only desirable for a low-latency product — they are necessary. Indeed, misaligned incentivizes in information reporting can bedevil even the most storied of financial oracles. In particular, the manipulation of the London Interbank Offered Rate (LIBOR) — once the most consequential global benchmark for interest rates — offers a cautionary tale.
As a quick refresher, LIBOR represented the (theoretical) rate at which the largest banks could obtain short-term unsecured loans from one another. Everyday before 11:30am GMT, approximately sixteen reputable banks with operations in London were polled. They were asked the following question, across multiple currencies and maturities: "At what rate could you borrow funds, were you to do so by asking for and then accepting interbank offers in a reasonable market size just prior to 11am?" The results went through a light layer of post-processing, in which the highest and lowest four responses would be culled. The averages of the remaining submissions were published at 11:30am GMT as that day’s LIBOR benchmark.
The importance of LIBOR cannot be understated. At its peak, LIBOR served as the benchmark rate for upwards of $300 trillion notional in contracts — ranging from conventional auto loans and household mortgages to more complex instruments like swaps and futures. Many saw the rate as the center of finance, which added to its sense of invulnerability. Inasmuch as there were concerns about individual banks gaming it, the layer of post-processing was considered a suitable defense.
Case Study: Pyth
Oracles that have high latency or misaligned incentives are worrisome. But can oracles pull off the balancing act of low latency and high-quality data?
Returning to the forms of staking, Pyth actually implements all three forms. Of course, Pyth does so imperfectly, constrained by real-world factors.
• For staking via reputation, Pyth does a moderate job. On the plus side, Pyth is highly public with the aggregate set of its publishers. However, Pyth does not doxx individual addresses, which limits the public attention and press that bad contributors may suffer. It is possible that this mechanism may weaken in the long run, if Pyth transitions to permissionless publishing.
• Similarly, for staking via trading, Pyth’s mechanism has high potential but must further develop. On the plus side, many of Pyth’s data providers are high-frequency trading firms who contribute prices as a byproduct of their trading operations. But there are two potential vulnerabilities. First, such firms must be willing to report those prices to Pyth sufficiently quickly. Currently, these firms trade so quickly that it is reasonable that they can execute their trades first and deliver their prices to Pyth second in the same block. (Even the fastest block speeds in crypto — four hundred milliseconds, on Solana — is considered very slow by high-frequency trading firms, which can execute trades within a few milliseconds.) But if crypto block speeds improve, this may become an issue. Second, there needs to be a mechanism — either via incentives or penalties — to validate those self-reported prices. Otherwise, Pyth runs the risk that publishers misrepresent publicly-collected prices as the ones that they traded on.
This is but one example of the complex realities that an oracle network must face. Skin in the game can go a long way to deliver high-quality and low-latency data. But in practice, any network must add several further defenses and failsafes.
Given the large sums in DeFi, a good price oracle needs to be accurate and timely. For too long — both before and after samczsun’s article — oracles have suffered on accuracy. Delays ease that, but the lack of timeliness introduces its own vulnerabilities.
Instead, we believe successful oracles will go back to the fundamentals of crypto, and align incentives correctly. Between staking reputation, collateral, and trading capital, oracles can achieve those twin objectives of accuracy and timeliness in parallel.
Good oracles, of course, won’t stop there. They must think through the aggregation approaches, the robustness to market stress, and the ultimate guardrails in case of failures. Good oracles understand that many of these choices are highly context-dependent (e.g. asset class, frequency of updates, etc). And in turn, protocols that integrate with oracles must think about these core principles and additional safeguards alike too. If done correctly, then the end users of crypto can harness the power of DeFi coupled with the speed and reliability of traditional markets.
Please let us all know what we got wrong or missed, as we would like to understand this subject matter thoroughly and correctly. Thanks to the research team at Jump Crypto and especially to Jayant Krishnamurthy, Michael Setrin, Jeff Bezaire, and Ben Huan for feedback. This note does not constitute financial advice.
1. There are other solutions mentioned, e.g. M-of-N reporters. These are more promising, although they require some trust assumptions or suitable incentive alignment. Indeed, this article discusses the latter as a fairly powerful principle, which can be utilized directly without necessarily needing "N" reporters.
2. We compute prices from Binance based on one-second candlestick bars, which in turn comes from tick-level data. The closing price of the candlesticks are used to construct this graph, although using the opening or average price yields similar results.
3. There are additional concerns around TWAP-based oracles that price ETH following the transition to proof of stake. In particular, the increased predictability around block assignment will allow adversarial miners to sustain manipulated prices for longer periods of time, weakening the security guarantees of TWAPs.
4. In some ways, participants did stake collateral after the fact, given the large fines that banks paid for misreporting rates. However, this collateral staking was done on an ex-post rather than ex-ante basis.
5. Admittedly, the secrecy did serve some other purpose. In particular, the British Bankers Association kept this information secret so that the public could not speculate on a bank’s solvency risk.
6. Pyth further plans to build an insurance mechanism, which will add further capital to this staking mechanism and better compensate users affected by incorrect prices. However, these plans remain more nascent than the mechanism that binds directly on publishers.
7. This may pair well with Pyth’s anticipated rewards mechanism. With such a mechanism in place, publishers are directly incentivized to publish the prices they actually traded at, to maximize their share of the rewards. This is because their trade prices are the most indicative source of price information at their disposal and would help them boost their rewards.