Oracle Infrastructure: The Backbone of Lending Protocols

This comprehensive report covers the oracle infrastructure behind top onchain money markets.

Introduction

Oracles are the backbone of Decentralised Finance (DeFi) Infrastructure and play an essential role in the onchain economy. Without them, the systems would struggle to exist, as they serve as the bridge between real-world information and smart contracts. To refine the definition, smart contracts run on blockchains, which are void of any data which cannot be calculated onchain. This is where oracles come in, serving as a source of data outside the blockchain you are interacting with.

The primary use case for oracles is to provide the latest price data for digital assets. They also serve other data needs, covering real-world events, commodities, stocks, and more.

To understand their impact and importance, we continue our previous report on onchain money markets, with an exploration of the oracle functionalities and infrastructure used by lending protocols, including Aave, Morpho, Euler, and Fluid.

This report will be instrumental in establishing benchmarks for building a robust oracle infrastructure, ensuring the protocol remains stable and healthy. It is also important to note that exploits involving oracles are not only about the oracle’s malfunctioning, but also about the protocol’s infrastructure utilised by the oracles that didn’t account for various edge cases during development.

To emphasise their importance, here are a few issues that could trigger if an oracle falls short in its output, within the context of lending protocols:

• Protocols can accrue Bad Debt.

• Unfair Liquidations of users’ positions.

• Unfair Arbitrage Opportunities, as exploiters might utilise inflated collateral value to take bigger loans than they should be able to.

• Protocol Failure and Insolvency.

To conduct our research, we run a comparative analysis of lending protocols based on how they run their oracle infrastructure. We begin by highlighting the major oracle providers in the space, covering their core architecture, decentralisation, and the value they deliver, to provide an overview of how these vendors operate and the services they provide. Then, we move on to the different lending protocols mentioned above and explore how they handle the price feeds for the protocol’s health and sustainability.

---

Comparing Different Oracle Providers

Oracles are the trust layer of DeFi, and for this reason, new competitors often face high barriers to entry. As a result, the market is led by a few key players, including Chainlink, which holds the majority of TVL, followed by Chronicle, RedStone, Pyth, and others.

Additionally, some teams run their own oracles and maintain their own infrastructure to support price feeds for their protocols, known as “Internal Oracles”.

We will compare the different Oracle providers based on three factors:

• Total Value Secured (TVS): TVS value represents the value secured by the oracle and can also be considered a proxy of the amount of trust placed in that single provider.

• Oracle Models: The model that oracle utilises, either a push/pull model or both. Each model has its tradeoffs, depending on the specific conditions.

• Oracle Performance and Decentralisation: Oracle Performance measures the latency of different oracles and the frequency of data updates, while also shedding light on recent incidents affecting some of these oracles. Additionally, decentralisation focuses on the network’s reliance on multiple actors and the absence of a single point of failure.

Total Value Secured (TVS)

Chainlink dominates the oracle market with $91.53 billion in TVS, followed by Chronicle, RedStone, and Pyth, securing $11.19 billion, $8.47 billion, and $7.93 billion, respectively.

Chainlink: Chainlink was launched in 2019 and, through its market timing and continuous product innovation, has achieved dominance. While a total of 476 protocols utilise their oracle services, Aave alone represents over 70% of Chainlink TVS’ ~70% share. Due to Chainlink’s robust infrastructure, most market leaders prefer it, as oracles help sustain the system during significant market fluctuations.

Chronicle: Chronicle was launched in 2017 and was built primarily to serve Sky (formerly MakerDAO) as an oracle provider. It only became public and began offering its services to other protocols in September 2023. It currently supports 10 protocols and wants to provide its services to high-impact products. Being the early provider for Sky, Sky Lending and related products, such as SparkLend, accounts for ~90% of their TVS share.

Pyth: Pyth debuted in August 2021 and has since grown to support 288 protocols with a focus on Solana. Unlike the providers mentioned above, Pyth TVS is fairly distributed, and the dominant protocol utilising its oracle is Kamino Lend, which represents ~18% of the TVS.

RedStone: RedStone was also launched in parallel with Pyth and has witnessed significant growth over the last year, growing its TVS from $3.47 billion to $8.47 billion (140%+ growth). It currently supports 87 protocols, with Venus (a money market on BNB) accounting for ~35% of TVS.

Oracle Models

In oracles, there are two primary models: Push and Pull.

Push Oracles: The oracle network itself decides when to publish new data and pushes it onchain at regular intervals. The oracle network continuously monitors offchain data, such as asset prices, and nodes agree on an updated value periodically or when thresholds are met (e.g., a significant price shift).

They are low-latency and easier for dapps to access, as they can read data from a specific source. On the other hand, they are costly: regularly updating the feeds consumes gas (usually paid by the oracle network or the protocol), even if no one requires the update, and maintaining new feeds across chains becomes increasingly expensive.

Pull Oracles: With this architecture, the oracle updates the data only in response to application demand. That is, it only responds when someone asks for the data onchain. Data is usually aggregated offchain and stored in a fast-access layer (e.g., Pythnet or RedStone data cache). Whenever a dapp or smart contract requires an updated value, it retrieves the latest data onchain. The user or protocol pays for the gas cost of retrieving the data.

Pull oracles are more scalable, cheaper and efficient for multi-chain setups. They come with slightly higher latency, and data freshness depends on the usage. They also have a more complex integration process.

Chainlink and Chronicle utilise the Push model with Chainlink’s newer products, such as Data Streams, using the Pull Model.

Pyth uses the Pull model, while RedStone provides access to both models.

Oracle Performance and Decentralisation

Among low-latency products, Pyth Lazer offers ~1ms latency in its pull oracle. RedStone offers 2.4ms updates through its Bolt, push oracle, currently live on MegaETH and Monad. It is important to note that these oracles are utilised in high-performance environments that require faster price feed updates for specific products and latency-sensitive applications such as High-Frequency Trading (HFT) and perpetual protocols.

Chainlink data streams provide sub-second latency and use a pull model.

Comparing oracle latencies is hard because it depends on the model an oracle is using, the chain it is pushing the price data in and the number of price updates performed/requested (especially in pull models). For example, RedStone updates ETH/USD prices on Ethereum Mainnet 40 to 60 times a day through its push-based model, which is 576 times slower than its low-latency product, Bolt.

The latencies mentioned above are from oracles low-latency products, which are not yet widely adopted because they were launched this year.

In the context of the price source, Chainlink utilises price aggregators for its feeds, getting data from CEXs, Chronicle supports multiple validators and data sources, and Pyth relies on publishers or market makers. RedStone relies on CEXs, DEXs, aggregators, and institutions to provide price-related data.

As Decentralisation is of concern, all these providers pay fair attention to it, with Chainlink utilising thousands of independent node operators; these node operators are required to stake their LINK tokens to become part of the network. The approach of using multiple node operators to retrieve data from various sources eliminates a single point of failure. Chainlink then aggregates these prices as mentioned above.

Chronicle allows for a permissioned set of validators who sign and submit prices onchain. There are currently 24 validators in the network, and their model prioritises gas efficiency. Chronicle utilises an optimistic model on Ethereum, which assumes the price to be correct unless challenged.

Pyth sources its data from its 120 publishers, including institutions, market makers, and major centralised exchanges, which work with them to provide relevant price feeds. Since the data is sourced from the producers, its reliability increases.

RedStone employs a hybrid model with multiple independent data providers. The protocol utilises a distributed network of signers who fetch, validate and sign data before pushing it onchain.

Recent Oracle-Related Incidents

The most recent example of an oracle malfunction occurred with Chainlink, when deUSD depegged according to their feeds. deUSD is Elixir’s RWA-backed stablecoin with a current market cap of $141 million; at the time this incident occurred, May 29, 2025, its supply was $185m. This incident was isolated to the Avalanche network.

For a brief period, the Chainlink oracle reported incorrect deUSD prices, triggering liquidation events on Euler, resulting in a loss of $500k+ across the network.

The reason for this incident was a swap in a Curve Pool on the Ethereum network. Since Chainlink utilises VWAP (Volume-Weighted Average Price), this increment in volume led to mispricing of deUSD. It is also important to note that this is not entirely Chainlink’s fault, as VWAP is a pricing methodology. When assets with lower liquidity need a price feed, these risks cannot be completely mitigated.

VWAP is calculated by weighting each trade price by its traded volume over a specified period. Large trades have a greater influence on the average. A sudden volume spike in a pool can significantly affect the VWAP, which explains why oracle prices based on VWAP can react to abnormal volume events.

An efficient mitigation for these kinds of incidents is utilising PoR (Proof of Reserve) price feeds, which price the assets based on the reserve backing them. If the reserve falls short, the asset will depeg and lose value. This direct connection to backing doesn’t rely on the token’s onchain liquidity profile, while also ensuring the asset is fully backed and solvent.

Other oracle incidents include Pyth experiencing 40 minutes of downtime on 16th May 2025 across various feeds, including BTC. This downtime led to wrongful liquidation on Jupiter Perps and other platforms.

---

Comparative Overview of Lending Protocols

Upon covering different providers, this section will analyse the core components of some of the biggest lending protocols, which together hold over 67% of the lending market, with Aave leading the way, followed by Morpho, Fluid (Juplend), Euler, and others.

In particular, the focus will be on Oracles and their functioning in various lending protocols, aiming to understand the following:

• The types of Oracles utilised by protocols to serve different assets: Crypto assets divide mainly into two categories: volatile assets, such as ETH and BTC, and pegged assets, which are pegged to any volatile asset in the first category or to a specific stable asset, such as the US dollar. Each protocol may utilise different types of oracles, depending on the assets listed and how it chooses to handle them, to achieve greater stability and resilience against short-term volatility.

• What would happen if the oracle fell short or provided stale prices for a while?: Oracles are a key component of lending markets; a malfunction could disrupt the entire protocol. As such, this is a crucial question for analysing how each protocol handles situations in which oracles go stale or fail to provide prices for a while.

Aave

Aave traces its origins to 2017, when it launched as ETHLend. Fast forward to today, when it is soon going to release its v4. Through continuous upgrades and a focus on blue-chip assets, Aave has established itself as a vital component of the DeFi ecosystem, becoming the largest protocol by total value locked (TVL), with deposits exceeding $74 billion, representing over 50% of net lending deposits in DeFi.

Aave follows a pooled-liquidity model, with each reserve asset having its own set of configurations, including the Liquidation Threshold, Loan-to-Value (LTV), Interest Rate Model (IRM), and others. For this reason, every reserve asset needs an oracle and is associated with a particular price feed.

These oracles provide the price of specific assets, such as WETH, WBTC, wstETH, etc, in the BASE_CURRENCY, usually USD. Chainlink utilises two types of feeds:

Chainlink Price Feeds

Chainlink Price feeds are the primary and only source of price on Aave. It is usually the primary choice for every protocol because of its proven track record and the level of decentralisation it provides, as also highlighted in the section above.

CAPO (Correlated Assets Price Oracle)

This is a special feed to cap the protocol’s risk by limiting correlated asset price appreciation. This is in place because these assets are easier to manipulate and more risk-skewed due to their lower liquidity profile, while the assets backing them remain locked in contracts.

For example, wstETH, a yield-bearing token by Lido, is expected to appreciate to a specific limit by Aave. Moreover, CAPO also serves for stablecoins. To cater to both these asset categories, it utilises two types of adapters:

1. RatioCapPriceAdapter: These adapters are designed specifically for LSTs (Liquid Staking Tokens), as they are highly correlated with their underlying assets.

Three key parameters are taken into account while building this adapter to provide upper-side protection when the volatility is high:

• Snapshot Ratio: The ratio of the LST value relative to the underlying asset.

• Snapshot Timestamp: The timestamp at which the above snapshot was taken.

• Max Allowed Ratio Growth in Yearly %: The maximum yearly % growth LST is allowed to have.

For example, let’s consider wstETH (No actual values are used except the prices):

• Snapshot Ratio: 1.19 wstETH/ETH (wstETH price on January 1, 2025, data from coingecko)

• Snapshot Time: January 1st, 2025 (Time considered far off to evaluate the parameters in the maximum capacity)

• Max Allowed Growth: 5% (500 bps)

• Minimum Snapshot Delay: 7 days (Minimum Delay between the snapshots)

At the time of writing, 281 days have elapsed since the snapshot, and the yearly growth rate is 3.84% (281/365 * 5%).

Hence, the dynamic ratio cap can be calculated as 1.19 * (1 + 0.0326) = 1.235

Compare the ratio cap with the current mark price, which is 1.215. Since this value is less than the dynamic ratio cap, the adapter will return the mark price 1.215. To put it simply, if the market price is greater than the dynamic ratio cap, it returns the dynamic ratio cap; otherwise, it returns the market price.

This is in place to prevent any short-term manipulation of LSTs that could compromise the platform’s stability.

2. FixCapPriceAdapter: This adapter is designed for assets that are not volatile and are pegged to a stable currency. For example, USDC is pegged to the US dollar, and since there is no continuous growth, hardcoding it to $1 reduces the risk of unfair liquidations during periods of lower onchain liquidity.
   
   This was also witnessed during the recent liquidation event, when Aave set the price of USDe, a yield-bearing stablecoin issued by Ethena, to USDT on the protocol. While the token’s liquidity profile was changing onchain and across specific offchain venues, the protocol didn’t trigger any liquidations, which would be unfair given that Ethena reserves still back the token.

Morpho

Morpho is the second-largest lending protocol by market size. At the time of writing, the assets supplied to the protocol are valued at over $12 billion. Morpho was first introduced as an optimiser layer on Aave and Compound via V0, and later evolved into Morpho V1 in the summer of 2024. They are built with permissionlessness and immutability in mind while fostering a modular architecture.

One crucial aspect of Morpho design is its immutable nature: once deployed, contracts cannot be altered, which adds a layer of security and enhances trust in the system. Any market once created cannot be modified later. Whenever a market is deployed, market creators provide information about the loan token, the collateral token, the IRM, the Liquidation Threshold, and, most importantly, the oracle used.

Morpho enables market creators to select their oracle based on their specific market requirements and is oracle-agnostic by default (supports multiple oracles). The oracle returns the price of 1 unit of collateral token, quoted in the loan token.

For example, a cbBTC/USDC (CollateralAsset/LoanAsset) output here will be 114k USDC scaled to 1e36 for higher precision in price.

Morpho utilises three types of Oracle implementation based on the market:

• Price Feed Oracles: Utilising external price feeds to calculate asset exchange rates (providers include Chainlink, RedStone, API3, Pyth, Chronicle)

• Exchange Rate Oracles: Specialised for LSTs (monitoring value accrual or rebasing) like wstETH, stETH, LBTC, cbBTC

• Fixed-Price Oracles: Used for assets with known exchange rates, such as stablecoins.

These three types of Oracles enable market creators to ensure they can provide the most updated and relevant prices for their markets.

Fluid

Fluid also features in the newer generation of lending protocols and has experienced significant growth in recent times. The launch of Jupiter Lend, in collaboration with Jupiter Exchange, and its recent deployment on the Plasma chain have boosted its net market size to over $6 billion, making it the fourth-largest lending protocol by market size.

Fluid is built on the principles of capital efficiency and serves across three important segments in its ecosystem, which are:

• Lending Protocol: Simply supply assets and earn lending interest.

• Vault Protocol: Lend and Borrow assets with the highest LTV and lowest liquidation penalties.

• DEX Protocol: Enables features such as Smart Collateral, which allows users to earn both the trading APR and lending APR simultaneously, and Smart Debt, which reduces the borrowing interest rate using the trading APR.

The Vault Protocol provides users with an efficient liquidation model, and to develop such a model, a resilient oracle is needed. To build such a system, Fluid combines Uniswap and Chainlink price feeds to deliver the most accurate and reliable pricing data.

Fluid’s oracle combines Uniswap’s Time-Weighted Average Price (TWAP) with the Chainlink price. These data points are compared, confirming that the value falls within a specific range and has not been manipulated.

TWAP is calculated by averaging an asset’s price over a defined time interval, weighting each price by the time it prevailed. It smooths short-term volatility and mitigates price manipulation by averaging prices across a period rather than relying on a single spot value.

By utilising this comprehensive oracle system, the Vault protocol can rely on the most recent and accurate DeFi prices for liquidations. This enhances the protocol’s security and minimises the risk of price manipulation, providing users with a more transparent and trustworthy borrowing experience.

Fluid also uses a different methodology for LSTs and correlated assets. Since they can lead to short-term depegs due to lower onchain liquidity, the protocol verifies the asset backing at the contract level, preventing unfair liquidations during periods of increased volatility.

Euler

Euler V2 was launched in September 2024, and since then, the protocol has experienced tremendous growth, now boasting a market size of over $3.5 billion.

Every market on Euler is configurable and offers numerous customisation options for deployers. While deploying these markets, the market risk curators define the liquidation threshold, the oracle feed, and IRM. Choosing a price mechanism is within the curators’ discretion, who can decide which mechanism best suits their market based on the assets it serves.

Euler utilises the ERC-7726 (Common Quote Oracle) standard API for its oracle implementation, which provides asset values relative to one another. The reason for choosing this ERC for the oracle implementation is its simplicity and compatibility with already existing solutions.

Euler’s system consists of two main components: Adapters and Routers.

Adapters are immutable, ungoverned smart contracts that implement the IPriceOracle interface defined by ERC-7726. Euler support adapters for various vendors and are vendor-agnostic. Supported providers include Chainlink, Chronicle, Pyth, Restone, Uniswap V3, Balancer Rate Provider, and others.

Routers are similar implementations, but they are governed and can change providers based on requirements, offering more flexibility.

Euler utilises three types of pricing mechanisms:

• Market Oracles: Use trading activity and liquidity from both decentralised and centralised exchanges to determine asset prices. They aggregate prices from multiple sources, making the system more resilient by reducing its reliance on a single source. However, it still leaves the vaults vulnerable to short-term price fluctuations and, at the same time, reduces their impact, which would have been relatively larger with a single source.

• Fundamental Oracles: Provide fixed prices, such as one for the stable assets. They are generally hard-coded and do not reflect actual market changes. This is useful for assets like USDe, which, if dependent on Market oracles for prices, could lead to unfair liquidations during market turmoil, even when the assets backing USDe remain present and the protocol is solvent.

• Exchange Rate Oracles: Determine the prices of derivative assets, such as LSTs. It establishes prices based on built-in exchange rates between derivative assets and their underlying tokens.

These three pricing mechanisms ensure that risk curators have access to the oracle of their choice, which is specifically designed for their market.

Among the oracle infrastructure behind these top lending protocols, one common feature is the use of different oracle types depending on the asset type. As the asset type and its backing change, the respective oracle handling its price updates and its implementation also deviates.

What mechanisms are in place if the Oracles go stale?

After introducing oracles at the protocol level, it is essential to understand that most oracle providers have systems in place and are relatively decentralised to keep their systems running smoothly without downtime. The majority of the hacks or exploits involving oracles are due to the poor implementation of the oracle services in the protocol.

The most common form of exploit occurs when oracles are directly dependent on spot prices and implement changes across the exchange based on them. As a vector of attack, an exploiter can take a flash loan, create a short-term price discrepancy in a Uniswap Pool, exploit the target protocol by utilising the same price feed directly for their markets, siphon liquidity, repay the flash loan, and leave the protocol with bad debt.

A recent example occurred during the October 10-11 liquidation event, when USDe was depegged on Binance because it was dependent on the exchange’s spot prices, which had lower liquidity concentration, leading to unfair liquidations of users’ positions. The exchange eventually paid out over $280 million in reimbursements to users affected by this and other similar incidents, including assets such as BNSOL and WBETH.

Poor implementation of oracle can have crippling effects on protocols and lead to the loss of users’ funds. This section of the report aims to answer how lending protocols implement their oracles and whether they have mechanisms to protect users when oracles are unable to provide accurate data feeds.

Aave: Aave introduced a PriceOracleSentinel in its V3 contracts to detect whether the price oracle is functioning correctly. Aave utilises Chainlink’s L2 Sequencer Uptime Feeds, which returns a boolean value to reflect if an L2 sequencer is up or not. Once the oracle/chain is active again, users can utilise a grace period to ensure their positions are healthy on the platform. These contracts are not currently deployed on Ethereum, and the grace period is 60 minutes.

Morpho: Morpho have isolated markets and each market is represented by a pair of collateral and a loan asset. Every market includes an oracle address during deployment, which is immutable and cannot be changed once the market is deployed onchain. Morpho is oracle-agnostic in nature, meaning vault creators can choose from multiple oracle providers.

Since the market creators set up the oracle, the responsibility for verifying its legitimacy and quality falls on the end user. If the plugged-in oracle fails, it can harm market participants through unfair liquidations and bad-debt accruals.

Euler: It supports two components: adapters and routers, as mentioned above, which are responsible for setting up the oracle provider for a particular vault.

Like Morpho, Euler’s market pricing mechanism is chosen by vault creators and risk curators, and is oracle-agnostic. Since the risk curators manage the oracles, users must assess the risks associated with each oracle before interacting with markets on the platform.

For vaults that utilise pull oracles like Pyth or Euler, Euler considers them stale after 2-3 minutes, and the price needs to be updated before interaction. This is important in the case of pull oracles, as they are demand-based and don’t automatically update after a fixed time period like Push oracles.

Fluid: Fluid relies on Chainlink and Uniswap for its price feeds and regularly cross-verifies them, making the system robust and protecting its users from unfair liquidation and bad-debt accrual.

At any time, Fluid checks both the onchain Uniswap TWAP and the Chainlink price: if the TWAP is within parameters, it uses the former; otherwise, it uses the latter.

To summarise, in most cases, oracles are assumed to be up all the time, and there are fewer fallback mechanisms in place to defend against situations in case the oracle provides stale feeds. Aave does a decent job here by utilising the PriceOracleSentinel contracts to verify whether the chain sequencer is up; however, this is only applicable to L2 networks. Additionally, Fluid relies on both Chainlink and Uniswap TWAP feeds and cross-checks them to defend the protocol when one provider fails. TWAP also comes with a caveat: if the time interval is larger for the price calculation, it avoids short-term price manipulation but, at the same time, reduces price reliability, as the price is averaged over a particular period. Hence, striking a balance between the two is very important.

Potential Attack Vector (Donation Attacks)

Multiple lending protocols, including Morpho, Euler, and Fluid, utilise ERC-4626 for their vault design. This ERC helps developers tokenise their vaults, and upon deposit, users receive shares that can be burnt to retrieve the underlying asset. The number of shares a user gets depends on the amount of assets already deposited in the vault.

Before we begin this section, it is essential to highlight that these attacks are possible when an ERC-4626 vault is used both as collateral and a borrowable asset.

For example, if the vault has 500 tokens backing 20 shares, each share is worth 25 tokens.

To put it in mathematical terms,
Exchange Rate of Shares = Number of Tokens in Vault / Number of Shares in the Pool

Source: https://docs.openzeppelin.com/contracts/5.x/erc4626

So, if the number of shares in the pool remains unaffected and the number of tokens in the pool increases, the exchange rate will be drastically affected and increase in value. This is a potential attack vector known as the Donation Attack.

The Donation Attacks go through several steps, but the end goal is to manipulate the vault’s Exchange Rate. To perform this manipulation, attackers deposit assets into the pool and inflate the value of its shares, as highlighted above. This inflated collateral can now be used to borrow different assets across the protocol, which incur bad debt.

A recent example of such an attack occurred last year, when Venus was targeted in a donation attack that resulted in a $700k loss on ZkSync. It’s important to note that there was no fault in Venus’ implementation; the attack targeted the Mountain’s wUSDM exchange rate oracle, which caused cascading effects, particularly on Venus and SyncSwap LPs. These oracles shouldn’t be used directly in the protocol and should be attested with some guardrails and price caps.

A good way to mitigate donation attacks is to implement internal balance tracking, which records vault deposits and withdrawals to prevent changes in the exchange rate from external donations.

---

Conclusion

Different lending protocols have different oracle structures and practices in place to provide the most up-to-date prices by asset type, without leaving users vulnerable to liquidation or themselves accruing bad debt.

All the onchain money markets use Chainlink Price Feeds, which protect over $90 billion in DeFi TVL, including giants like Aave, which holds over 50% of lending deposits. Each oracle provider offers a suite of products to streamline integration for developers and provide services tailored to their needs.

If any of these oracle providers go stale, protocols might get into trouble and should implement their own mechanisms to prevent users from being unfairly exposed to such situations. No oracle can guarantee 100% uptime, and protocols must either have a fallback oracle or multiple sources simultaneously providing access to the latest prices. Ultimately, it comes down to protocol design choices regarding how robust their system is to external negative momentum that could impact their users.

Lending is the largest category in DeFi and has significant upside potential because it’s easier to understand: anyone can grasp money markets and understand where the yield is sourced. Making this category secure will bring in more users in the long term and ensure the space continues to grow.