[Franklin DAO] Request for comment on: Market pricing vs. exchange rate pricing for LSTs and potential oracle implementations

Request for comment on: Market pricing vs. exchange rate pricing for LSTs and potential oracle implementations


This proposal is a temperature check on which pricing mechanism is desired by the community for liquid staking tokens (LSTs) on Compound – exchange rate pricing or market pricing. We aim to present the data made available regarding the two different pricing mechanisms and allow the community to vote on how to proceed forward. This comes in light of our collaboration with Lido to add wstETH as collateral on Base ETH Market, USDC Market on Arbitrum and Ethereum Mainnet.


FranklinDAO encourages the community to agree on price feed preferences for LSTs to help clarify the desired ubiquitous pricing mechanism for such assets as Compound continues to scale its support of staking assets such as wstETH.

Exchange rate vs market pricing

Gauntlet shared insight about the present and future liquidity of LSTs. Current data doesn’t indicate any negative price trends in LST liquidity over recent months. Although, as liquidity starts shifting to restaking protocols, and other lending protocols, LST liquidity is at risk of shrinking. Lower liquidity levels may introduce risk of market price manipulation.

To mitigate these liquidity risks, Compound could move toward exchange rate based oracles for LSTs within Comet markets – particularly correlated Comet markets.

Market pricing

In market rate pricing, the value of an asset is determined by its trading activity in the open market. It reflects demand and available liquidity in the market.

Market pricing has been the status quo, utilizing robust Chainlink price feeds in the process.

However, because of the dual sided relationship of the base asset (ETH) between its staking token (LST) and the USD value, the LST → BASE feeds may experience volatility / price fluctuations.

Exchange rate pricing

In exchange rate pricing, asset prices represent the exchange rate for redemption between a staking asset and its base.

By using the exchange rate, borrowers will have less capital at risk, and can operate with higher capital efficiency. On the other hand, using this rate could increase insolvency risk in LST/Base depegging scenarios. More information can be found here.

Risks and Mitigation

Although we do acknowledge the risks, we are confident in the robustness of Lido’s validator set and their credibility for reporting wstETH’s exchange rate. To increase trustless support of exchange rate pricing, we’re curious about the interest of the community in exploring risk mitigation strategies such as those mentioned by Gauntlet:

  • Mitigate through severe Dislocation Mechanism: Protocols may take steps such as halting new supplies or setting collateral factors (CF) to zero to prevent an increase in LST supply during rare and unpredictable market dislocations.

  • Mitigate through oracle feed threshold mechanism: Deploy a smart contract on asset Oracle feeds, especially for those reliant on exchange rates, to cap prices at a specified ratio. This safeguards against upward price manipulation and secures protocol deposits.

In addition to these risk mitigation strategies, we anticipate the risk of slashings will continue to decrease in the future as node operators become more sophisticated and adopt new technologies such as DVT and TEEs.

Proposed oracle implementation

@zetaproject proposed an oracle implementation which borrow’s from AAVE’s capped price oracle idea.

Proposal announcement

The community should discuss the details of this proposal in depth. As ideas and opinions come forward, the proposal will be amended until it reaches a final state that the community has verified and agreed on. Then it will be put it to a vote.

  • An example of options to vote on for the pricing mechanism would be:
    • Exchange rate pricing on correlated and un-correlated markets
    • Exchange rate pricing on correlated markets and market pricing on un-correlated markets
    • Market pricing on on correlated and un-correlated markets
  • For oracle implementation:
    • Exchange rate pricing oracle implementation 1
    • Exchange rate pricing oracle implementation 2
    • Market pricing oracle implementation (could be new or can just default to standard)

Considered in the conversation for this proposal should be a standardized oracle implementation that can scale with the markets for the mechanism selected (one that we can utilize for the deployment of wstETH in the aforementioned markets as collateral) with minimal exposure to price manipulation risks.

We look forward to hearing back!


Thanks for kicking off this discussion, I think you covered all the points well.

I’ll just add that slashing/validator issues aren’t the only risks if using an exclusively exchange-rate based oracle. A full exit queue (due to rotation into LRTs for instance) could easily lead to a (probably small) depegging of LSTs (especially if fears about liquidity are realized). If a downtrend in ETH price leads to LST liquidations the depeg could be exacerbated and even lead to un-liquidatable debt.

For the ETH comet this risk is less severe as the LST would likely repeg to ETH over time. However, for the USDC comets this could lead to bad debt for USDC suppliers.

If the community agrees that this is a realistic risk it may suggest that a capped oracle would be safer than a pure exchange rate oracle.


Hello everyone,
Matt from RedStone Oracles here.

It’s definitely a great initiative to bring this topic to the forum for an open discussion.
To offer some insights from our experience as an oracle provider, below we are diving deeper into the approaches we have already implemented with other protocols to tackle this issue:

Pure Market Price
Historically most popular approach as it gives access to the true liquidation price.
This is also the solution selected by the vast majority of the lending protocols that partner with us. For that reason, at RedStone, we have prepared the methodology dedicated to LST/LRT assets, where the on-chain liquidity is constantly monitored and it’s possible to disconnect data sources in real time when slippage increases above the safe level.

The concern with using a Pure Market Price with less liquid assets is the possibility of a sudden price dip, which can cause a cascading liquidation. For less liquid assets, a solution to that can be using a TWAP price instead of the spot one. The usual timeframe for TWAPs we have done in the past is 30 mins, but this is subject to per-asset analysis.

Pure Exchange Rate
An Exchange Rate Feed taken from the asset’s contract is naturally protected against spot price dips and liquidation cascades stemming from it but brings its own set of risks.

In an ideal world where the assets freely move between the beacon and execution chain without any friction, the Exchange Rate will be indeed an optimal solution. However, in practice, removing the Ether from staking nodes takes time and the LST protocols usually offer only a 7 days redemption period. In a scenario, when the price of Ether drops rapidly, and there is a selling pressure, the liquidity crunch caused by redemption delay can significantly reduce the market value of staked tokens.

There is a common argument that depegs are just a temporal aberration and the real value of the underlying assets remains unchanged. It’s often overlooked that relying on a contract rate when the secondary market offers assets at a discount could bring in another type of risk. A malicious actor will be able to buy the depegged asset at discount and use it to borrow other tokens. This could lead to a bad debt if the market value of borrowed assets is higher than the collateral. Although this could only happen if the difference between Market and Exchange Rate exceeds the collateral ratio, if it happens nothing will block protocol from a large-scale exploit.

That being said, RedStone has done integrations with protocols opting for a Pure Exchange Rate, usually in sectors other than classic lending. We deliver such feeds for Pendle, Balancer and a few other protocols for their idiosyncratic use cases.
This type feed is usually needed for integrations on L2s and alt L1s where it is not possible to simply access the state of a given asset contract deployed on Ethereum Mainnet.

If Compound decides to use this pricing method at chains other than Ethereum Mainnet, we also be able to deliver the needed Exchange Rates.

Combining the two above - Hybrid Price Feed
A solution taking the best from the two approaches is to use the market price as a signal that something unusual is happening on the market and as a trigger to disable deposit to protect against exploits. A possible implementation could automatically block deposits for an asset whose market price and contract price differs more than a certain threshold.

As our data provider nodes have access to both smart contract and market price they can pass an additional flag to a price feed when both values deviate significantly. We leave the freedom to interpret this signal to protocols, who can adjust their reaction based on their risk assumptions.

In our view, utilizing the Market Price, either in a Pure Market Price feed or a Hybrid variation, is still the most robust approach for lending markets if it comes to pricing most of today’s big LST assets.

That being said, whatever the final choice of pricing methodology is, the RedStone team is here and we are happy to work closely with Compound Labs, OpenZeppelin, Gauntlet, AlphaGrowth and all other parties involved in setting up the right price feeds both for assets with existing markets as well as new ones.