Oracles Are Upgrading

Oracles are essential to a well functioning DeFi ecosystem, and we’re witnessing the nature of Oracles and the market’s understanding of these critical pieces of infrastructure change as the space evolves. 

DeFi 1.0 was primarily focused on solving for security and “trust” within execution environments that were slow in terms of block times and latency. But the primary focus has changed in DeFi 2.0 where speed is of paramount importance. 

We believe speed is the defining characteristic of modern financial systems. As we laid out in a previous report, 

“as financial markets grow and trading volumes increase, speed traders capitalize on a growing number of latency arbitrage opportunities. Exchanges benefit from increased transaction-based revenues that arise from speed trading, and then orient their venues and technologies toward speed traders. This activity persists due to positive externalities, as all traders are ultimately benefactors of the deeper liquidity and the narrower spreads that come with increasing volumes driven by faster markets.”

This dynamic is increasingly prevalent over the past 24 months, where nextgen chains like Solana, Sui, Aptos, Arbitrum, MegaEth, and Monad, and the countless nextgen DeFi apps built on top of them, are pushing the limits of throughput and speed in crypto to new heights. 

This need for speed has resulted in a new era of Oracles built for lightning fast updates by way of minimizing aggregating layers. Instead of pushing price updates through multiple aggregating layers based on deviation thresholds in DeFi 1.0, DeFi 2.0 uses pull oracles that send first-party-sourced prices directly to onchain applications, on demand, at ultra low latency.

Total Value Secured

Historically and to this day, Total Value Secured (or TVS) has received outsized attention from market participants. However, due to these evolving dynamics, Total Value Secured is no longer an effective metric for evaluating oracle fundamentals or gauging market share. 

At its core, TVS calculates how much value is secured by each oracle, which is the equivalent to the total pool of value that would be lost if an oracle malfunctioned or reported incorrect prices in a worst case scenario. DeFi Llama calculates this metric per oracle by summing the TVL of each protocol that uses that oracle as its primary price provider. For instance, since both GMX and Aave are secured by Chainlink oracles, Chainlink’s TVS will be GMX TVL + Aave TVL + TVL of all other protocols using Chainlink as a primary oracle. This number represents the maximum amount of value that could be drained from a protocol in a worst-case oracle attack.

It's crucial to emphasize that each DeFi protocol has a responsibility to implement measures that protect against oracle downtime or manipulation, and the industry has largely moved in this direction. For example, Kamino cross references price data from both Pyth and Switchboard while also maintaining its own oracles to protect against a single point of failure. This proactive approach ensures that even if Pyth were to fail or suffer a hack, pricing could still be provided, and protocol losses should be minimal. 

Problems with TVS

While TVL is useful for reasoning about worst-case security risk, it is completely orthogonal to oracle price demand. TVS, at best, measures a pool of financial assets associated with an oracle’s services, but completely eschews the application’s activity associated with an oracle. Oracles are assessed by DeFi teams on their ability to service activity, and oracles get paid by protocols as a function of the amount of activity they secure, not as a function of the size of the asset pool. 

In sum, we see TVS as overstating the importance of asset pool size, and greatly understating oracle activity. This deficiency is visible in TVS across and within sectors, all of which obscure the market’s understanding of oracle demand and market share. 

Price Updates Across DeFi Sectors

The nature of oracle updates varies widely across DeFi sectors, as different application types cater to different risk profiles that interact with their risk management systems with different time horizons and frequency needs. Said another way, an application that caters to high frequency traders, who make trading decisions based on sub-second price and volume signals, will have a different demand profile for oracle price updates than an application focused on stablecoin loans to small businesses in emerging markets. 

For example, a borrow/lend protocol may price its TVL and outstanding borrows only when a certain price deviation threshold is met. As a consequence, the need for oracle price updates might not exceed over a few hundred per day. In contrast, a perps DEX on an app chain or nextgen blockchain like Solana or Sui may require tens of thousands of price updates per day to continuously price trades of sophisticated risk managers. 

We illustrate this stark contrast in oracle price update frequency with the Pyth oracle contract on Base, which you can see here. To conduct our analysis, we’ll delineate between internal and normal transactions coming from this contract. Internal transactions shown by block explorers are transactions executed by the contact. In contrast, normal transactions are executed through EOA addresses (i.e., wallets). Because lending protocols using these Pyth contracts typically run what we call “price pushers” (you can learn more about them here and here), they must do normal transactions via EOAs every time they update prices. But since most perps DEXs typically bundle gas and oracle price updates, and pass these on to the end user, a perps DEX can use smart contracts to execute price updates, making internal transactions an appropriate proxy for high-frequency derivatives DEX oracle price updates. 

We take a look at the number of transactions associated with this contract over time, and split them between internal and normal transactions on a daily basis. We see that frequency of internal transactions, typically associated with derivatives DEX activity, exceeds normal transactions, associated with borrow/lend and CDP activity, by anywhere from 10x to over 60x daily. 

Even on the Mode blockchain, where lending protocols represent 80% of Pyth’s TVS on that chain today, internal transactions exceed normal transactions by 3x to 250x over the past month. You can view this contract here. 

Armed with this perspective, we have a much better understanding of demand for oracle pricing and oracle revenue opportunities. For example, Chainlink, which has primarily focused on push-based price updates and price deviation thresholds, primarily services the low frequency borrow-lend market as a consequence of this technical choice. Today, just 3% of Chainlink’s $25B TVS is servicing high frequency derivatives trading protocols, amounting to just $781M in TVS for derivatives DEX protocols as of September 27th. This puts the protocol in-line with Pyth, which services $797M in derivatives DEX TVS, or 16% of its total TVS. 

Over/Understating Application Demand

TVS can also drastically overstate or understate the demand for oracle pricing coming from any one particular application. Let’s consider Synthetix and dYdX v3. Both protocols are secured by Chainlink price feeds. Synthetix has $282M TVL, whereas dYdX is smaller, with only about $177M in TVL, making Synthetix a larger contributor to Chainlink’s market-leading TVS. However, dYdX v3 volumes are over 4.5x larger than trading volume in Synthetix, understating dYdX’s true demand for Chainlink price feeds, and overstating Synthetix’ demand from a transaction volume perspective.

Total Transaction Value

We believe Total Transacted Value is a more accurate measure of oracle fundamentals, as it is more strongly correlated to frequency of oracle price updates and therefore oracle revenue. 

To calculate Total Transacted Value, we can simply sum the periodic volume of derivatives DEXs that use oracle updates for pricing, which are mainly perps DEXs. We’re comfortable excluding lending, CDP, restaking protocols, and other low frequency applications from this measure as 1) the 10x-60x greater frequency of price updates coming from DEXs we calculated above implies only 2-9% of oracle price updates come from low frequency protocols, which is a very small number in the context of crypto, where volubility of fundamental measures is very high, and 2) frequency of price updates is what most closely correlates with an oracle’s potential revenue and sustainability as a protocol. 

Recalibrating The Oracle Market

Moving from TVS to TTV meaningfully recalibrates oracle market share. Using the historical favorite TVS, Chainlink is dominant, with 45% percent market share today, maintaining a very strong lead in market share terms since 2021. 

However, TTV tells a different story, with new leaders and emerging trends. The top 5 in oracle market share changes meaningfully, with Edge, Chronicle, and Redstone dropping out of the top 5, and Chainlink dropping to number 4. Pyth moves into the top spot for the month of August with over $43B in TTV in August, with Stork and Edge entering top 5. TWAP, that is, where applications use their own internal time-weighted average price algorithm for oracle price updates, is the second most popular oracle method, with over $34 billion in transaction volume priced in August. 

 

From a TTV perspective, three things stand out. First, Chainlink has lost significant market share by failing to cater to higher frequency partners. We’ve watched Chainlink’s higher frequency Data Stream product come to market in an attempt to correct this. 

Second, an unsung leader in the oracle space is Pyth, who has steadily won market share as the demand for high frequency price updates has expanded to new apps and new chains. Leveraging the SVM for high throughput/low latency feeds and Wormhole for easy integration of price feeds across chains was not only a technical advantage but also enabled a rapid go-to-market where Pyth now sits as one of the most integrated oracles in DeFi. 

Third, there’s an increasing trend where derivatives DEXs are running their own proprietary Internal (pink below) and TWAP (yellow below) oracles. We think this implies a relatively high price sensitivity amongst derivatives DEXs, where up and coming leaders in the space, like Hyperliquid and Jupiter, are opting to build their own oracle systems in house instead of paying Chainlink, Pyth, or other competitors. With Pyth at essentially zero fees today and Chainlink’s data stream now on the market, it will be interesting to monitor TTV of internal and TWAP oracles TTVs, alongside Pyth and Chainlink pricing, to gauge the potential for commoditization of the oracle space.

Lastly, for DEXs to compete with CEXs on market share, oracles will need to compete on offering blazing fast price feeds so that DEXs can compete with CEXs with single servers and high performance matching engines. When we look at the DEX landscape today, none have reached CEX scale, but clear leaders are emerging. 

Final Thoughts

We think the flaws in TVS, combined with the increasing demand for speed in DeFi ecosystems, and the necessity of DeFi to compete with centralized exchanges, makes TTV the most useful, publicly available key performance indicator for assessing oracle fundamentals today. This focus on TTV will not only provide a more accurate reflection of oracle demand but also drive more efficient allocation of investor capital as oracles strive to meet the high-speed demands of the evolving DeFi landscape.