There are a lot of considerations when picking oracles for LRTs, with options ranging from Chainlink to the correlated asset price oracle (CAPO) and killswitch from Aave. Let’s review some of the tradeoffs of these choices.

Because LRTs can be redeemed for the underlying, they have an intrinsic value that is tied to the price of the base asset. Changes in intrinsic value can occur from

• slashing

• loss of assets by operators e.g. hacks

• redemption freezes or changes in capacity or waittime of withdrawal queue

LRTs can also be traded in the open market on exchanges where they have a market price. These prices have natural volatility and can fall substantially in the event of panic selling or market manipulation.

Arbitrageurs are incentivized to keep the market price in line with intrinsic value, but, similarly to liquidators, if their costs are not sufficiently covered by the profits, they are content to do nothing and let these values deviate.

Whereas most liquidations are transactions that atomically guarantee profit within the block, arbitrageurs often have significantly more uncertainty in their trades that stem from adverse selection, longer holding periods (e.g. tying up capital for a week in an LRT withdrawal queue), basis risk, opportunity cost and other factors.

As such, traders have risk limits and checks that often require human judgment to override, ensuring systems are not erroneously detecting market opportunities—a critical safeguard to avoiding blowups like Knight Capital. Response times tend to be longest during events that are both infrequent and high in dollar impact (e.g. LRT depeg) due to the unfamiliarity and stress on risk management systems.

Recursive borrowers using LRTs as collateral against the underlying asset find liquidations acceptable when driven by changes in intrinsic value but not when caused by drops in market price if the intrinsic value remains unchanged.

While overcollateralized lending protocols like Compound III are likely more risk-averse than leveraged borrowers, holding loans that are underwater when marked to market price—while remaining solvent when marked to intrinsic value—poses relatively low risk. We assume this is acceptable to the protocol for short durations e.g. on the order of a few blocks.

In essence, if both the protocol and borrowers want LRT looping loans to persist when intrinsic value is stable, arbitrageur inattentiveness or failure within the oracle update window should not lead to the forced closure of these loans via liquidation.

The most common type of oracle is a market rate oracle that aggregates node responses based on market data, typically prices across exchanges. This works well when prices are kept in line by arbitrageurs but can pose challenges for assets with lower liquidity.

As seen in the mainnet Chainlink ezETH / ETH oracle,

the sudden rate spikes and reversions were likely due to liquidity being primarily concentrated in this Balancer V2 stable pool, which had limited ezETH bid liquidity. When coupled with the 10% drawdown in ETH on Jan 13 or the 20% drop within an hour on Feb 2, this led to delays in arbitrageurs correcting the deviation.

In particular, ezETH is a ~1B market cap asset that usually only trades 5-10M a day and dislocating the price 10% might only cost ~500k. Using a market rate oracle for ezETH for a WETH lending comet would put users at significant risk of forced liquidations.

An increasingly popular choice for LRTs is to use a staking rate oracle, which tracks the intrinsic exchange rate between the LRT and the underlying asset. By removing the noise from market illiquidity, we could expect the plot of such a rate to look like the following:

a monotonically increasing trend with drawdowns occurring only due to slashing events. This is ideal for meeting the needs of both recursive borrowers and the lending protocol, as any liquidations that occur would be as expected.

Staking rate oracles typically pull data directly from smart contracts specific to a given LRT. For example, the Compound III ezETH / ETH oracle queries the Renzo RestakeManager. Unlike market oracles, which are standardized by organizations like Chainlink or Pyth—and trusted due to their network design and brand reputation—staking rate oracles are custom written and must be audited individually.

In the case of ezETH, the oracle used by Compound III computes the ezETH/ETH rate using the getRate function of the BalancerRateProvider. This function derives the rate by dividing the output from the calculateTVLs function of the RestakeManager by the total supply of ezETH. If there is any lapse in accounting on deposits, withdrawals, claims, mints or redeems when tracking the outstanding LRT supply vs the TVL of the LRT across base asset and rewards, this could lead to an incorrectly reported rate, potentially resulting in unintended liquidations.

Regardless of whether a market rate oracle or a staking rate oracle is used, the primary risk comes from a malicious actor manipulating the oracle’s output by exploiting vulnerabilities in its computation logic.

Since market rate oracles provide an aggregated response based on exchange activity, a protocol using such an oracle is at risk of attack when the cost of market manipulation is lower than the potential profits from an economic exploit. When liquidity is scarce, this can lead to significant dislocations between market price and intrinsic value.

For reference, below is a comparison of the ezETH/ETH Chainlink oracle and the staking rate during the ezETH depeg last April, illustrating how large the deviation can become.

While the depeg was driven by panic selling and cascading liquidations—triggered by disappointing airdrop news and exacerbated by the absence of a redemption mechanism for ETH at the time—rather than outright manipulation, the existing market illiquidity for ezETH suggests that a similarly adverse price path could be deliberately orchestrated. Had Compound III been using the Chainlink oracle instead of the Renzo staking rate oracle, it likely would have experienced a substantial amount of undesired liquidations and insolvent debt.

Attacking staking rate oracles typically involves targeting smart contract logic rather than manipulating the market. Some common exchange rate manipulation attacks are described in this Euler blog post. Previous Renzo audits have identified vulnerabilities in earlier smart contract versions, including this ezETH exchange rate attack vector.

As the scale and likelihood of manipulation increase, larger insolvency buffers are needed to shield the protocol from losses. Features like the rate change safeguards in the EzETHPriceCapAdapter used by Aave help limit the magnitude of such attack vectors. This, in turn, allows for the protocol to reduce its insolvency buffer requirements and increase collateral factors.

A secondary consideration is natural variability in oracle output. If the variance is high relative to the liquidation factor, highly levered users may face significantly higher liquidation risk than anticipated.

Below is a plot of the Compound III ezETH oracle, sampled for the past 90 days.

No slashing events occurred during this period, but some non-monotonicity can be attributed to the variability of LRT rewards that are not denominated in the base asset. Tracking these in the TVL require oracle lookups, where the RestakeManager makes a call to the RenzoOracle here, which queries Chainlink here. These market rate oracles exhibit higher volatility, and the assets themselves may have worse liquidity profiles.

As such, features like a killswitch—which automatically intervenes during large price movements or liquidity degradation—could help limit adverse effects on the protocol. Consequently, this would help facilitate an increase in collateral factors while maintaining protocol stability.

The choice of oracle is a key determinant of both the leverage that can be safely offered to borrowers and the insolvency risk faced by a lending market.

For LRTs, oracles should rely on the staking rate rather than market rates like Chainlink, due to the unreliability of arbitrageurs being incentivized to keep markets in line in a timely fashion. This necessitates custom oracle feeds, which should undergo individual audits and incorporate necessary safeguards, such as CAPO.

Since LRTs accrue rewards that are valued based on their own market rates, additional features such as a killswitch are useful in mitigating the effects of market anomalies. Bounding the magnitude of tail risks allows the protocol to offer higher collateral factors.

There are a lot of considerations when picking oracles for LRTs, with options ranging from Chainlink to the correlated asset price oracle (CAPO) and killswitch from Aave. Let’s review some of the tradeoffs of these choices.

Because LRTs can be redeemed for the underlying, they have an intrinsic value that is tied to the price of the base asset. Changes in intrinsic value can occur from

• slashing

• loss of assets by operators e.g. hacks

• redemption freezes or changes in capacity or waittime of withdrawal queue

LRTs can also be traded in the open market on exchanges where they have a market price. These prices have natural volatility and can fall substantially in the event of panic selling or market manipulation.

Arbitrageurs are incentivized to keep the market price in line with intrinsic value, but, similarly to liquidators, if their costs are not sufficiently covered by the profits, they are content to do nothing and let these values deviate.

Whereas most liquidations are transactions that atomically guarantee profit within the block, arbitrageurs often have significantly more uncertainty in their trades that stem from adverse selection, longer holding periods (e.g. tying up capital for a week in an LRT withdrawal queue), basis risk, opportunity cost and other factors.

As such, traders have risk limits and checks that often require human judgment to override, ensuring systems are not erroneously detecting market opportunities—a critical safeguard to avoiding blowups like Knight Capital. Response times tend to be longest during events that are both infrequent and high in dollar impact (e.g. LRT depeg) due to the unfamiliarity and stress on risk management systems.

Recursive borrowers using LRTs as collateral against the underlying asset find liquidations acceptable when driven by changes in intrinsic value but not when caused by drops in market price if the intrinsic value remains unchanged.

While overcollateralized lending protocols like Compound III are likely more risk-averse than leveraged borrowers, holding loans that are underwater when marked to market price—while remaining solvent when marked to intrinsic value—poses relatively low risk. We assume this is acceptable to the protocol for short durations e.g. on the order of a few blocks.

In essence, if both the protocol and borrowers want LRT looping loans to persist when intrinsic value is stable, arbitrageur inattentiveness or failure within the oracle update window should not lead to the forced closure of these loans via liquidation.

The most common type of oracle is a market rate oracle that aggregates node responses based on market data, typically prices across exchanges. This works well when prices are kept in line by arbitrageurs but can pose challenges for assets with lower liquidity.

As seen in the mainnet Chainlink ezETH / ETH oracle,

the sudden rate spikes and reversions were likely due to liquidity being primarily concentrated in this Balancer V2 stable pool, which had limited ezETH bid liquidity. When coupled with the 10% drawdown in ETH on Jan 13 or the 20% drop within an hour on Feb 2, this led to delays in arbitrageurs correcting the deviation.

In particular, ezETH is a ~1B market cap asset that usually only trades 5-10M a day and dislocating the price 10% might only cost ~500k. Using a market rate oracle for ezETH for a WETH lending comet would put users at significant risk of forced liquidations.

An increasingly popular choice for LRTs is to use a staking rate oracle, which tracks the intrinsic exchange rate between the LRT and the underlying asset. By removing the noise from market illiquidity, we could expect the plot of such a rate to look like the following:

a monotonically increasing trend with drawdowns occurring only due to slashing events. This is ideal for meeting the needs of both recursive borrowers and the lending protocol, as any liquidations that occur would be as expected.

Staking rate oracles typically pull data directly from smart contracts specific to a given LRT. For example, the Compound III ezETH / ETH oracle queries the Renzo RestakeManager. Unlike market oracles, which are standardized by organizations like Chainlink or Pyth—and trusted due to their network design and brand reputation—staking rate oracles are custom written and must be audited individually.

In the case of ezETH, the oracle used by Compound III computes the ezETH/ETH rate using the getRate function of the BalancerRateProvider. This function derives the rate by dividing the output from the calculateTVLs function of the RestakeManager by the total supply of ezETH. If there is any lapse in accounting on deposits, withdrawals, claims, mints or redeems when tracking the outstanding LRT supply vs the TVL of the LRT across base asset and rewards, this could lead to an incorrectly reported rate, potentially resulting in unintended liquidations.

Regardless of whether a market rate oracle or a staking rate oracle is used, the primary risk comes from a malicious actor manipulating the oracle’s output by exploiting vulnerabilities in its computation logic.

Since market rate oracles provide an aggregated response based on exchange activity, a protocol using such an oracle is at risk of attack when the cost of market manipulation is lower than the potential profits from an economic exploit. When liquidity is scarce, this can lead to significant dislocations between market price and intrinsic value.

For reference, below is a comparison of the ezETH/ETH Chainlink oracle and the staking rate during the ezETH depeg last April, illustrating how large the deviation can become.

While the depeg was driven by panic selling and cascading liquidations—triggered by disappointing airdrop news and exacerbated by the absence of a redemption mechanism for ETH at the time—rather than outright manipulation, the existing market illiquidity for ezETH suggests that a similarly adverse price path could be deliberately orchestrated. Had Compound III been using the Chainlink oracle instead of the Renzo staking rate oracle, it likely would have experienced a substantial amount of undesired liquidations and insolvent debt.

Attacking staking rate oracles typically involves targeting smart contract logic rather than manipulating the market. Some common exchange rate manipulation attacks are described in this Euler blog post. Previous Renzo audits have identified vulnerabilities in earlier smart contract versions, including this ezETH exchange rate attack vector.

As the scale and likelihood of manipulation increase, larger insolvency buffers are needed to shield the protocol from losses. Features like the rate change safeguards in the EzETHPriceCapAdapter used by Aave help limit the magnitude of such attack vectors. This, in turn, allows for the protocol to reduce its insolvency buffer requirements and increase collateral factors.

A secondary consideration is natural variability in oracle output. If the variance is high relative to the liquidation factor, highly levered users may face significantly higher liquidation risk than anticipated.

Below is a plot of the Compound III ezETH oracle, sampled for the past 90 days.

No slashing events occurred during this period, but some non-monotonicity can be attributed to the variability of LRT rewards that are not denominated in the base asset. Tracking these in the TVL require oracle lookups, where the RestakeManager makes a call to the RenzoOracle here, which queries Chainlink here. These market rate oracles exhibit higher volatility, and the assets themselves may have worse liquidity profiles.

As such, features like a killswitch—which automatically intervenes during large price movements or liquidity degradation—could help limit adverse effects on the protocol. Consequently, this would help facilitate an increase in collateral factors while maintaining protocol stability.

The choice of oracle is a key determinant of both the leverage that can be safely offered to borrowers and the insolvency risk faced by a lending market.

For LRTs, oracles should rely on the staking rate rather than market rates like Chainlink, due to the unreliability of arbitrageurs being incentivized to keep markets in line in a timely fashion. This necessitates custom oracle feeds, which should undergo individual audits and incorporate necessary safeguards, such as CAPO.

Since LRTs accrue rewards that are valued based on their own market rates, additional features such as a killswitch are useful in mitigating the effects of market anomalies. Bounding the magnitude of tail risks allows the protocol to offer higher collateral factors.