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

[pennblockchain]

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

Summary

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.

Motivation

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!

[zetaproject]

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.

[mattgurbiel]

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.

[Gauntlet]

Gauntlet would like to thank FranklinDAO for starting this discussion about the pricing oracles for liquid staking tokens (LSTs). Gauntlet is supportive of having a community-approved strategy for Oracle implementation moving forward. At this current time, Compound is utilizing market rate based oracles that price LSTs via market exchange liquidity sources. There are concerns within the community that this can be problematic for certain LSTs that have low liquidity and might experience further deterioration in liquidity.

LSTs 2% Depth USD

ETH-staked assets have continued to indicate stable liquidity, while LRTs have continued to exhibit significant growth, with a total supply of 2.9M (~$10B).

LRT Supply Growth

Future Oracle Implementation

Gauntlet supports implementing exchange rate oracles for correlated Comets. Utilizing an exchange rate oracle would allow the correlated Comets to optimize risk parameters and allow the protocol to optimize for future lower liquidity staking assets that might be more at risk of market price manipulation and volatility.

During a de-pegging market event of an LST, an exchange rate oracle can provide stability and protection to the protocol and suppliers. As shown in the chart below, during the stETH price dislocation event, there was a substantial decrease in liquidity once the price started to dislocate. If Compound were to have their market rate oracle during a similar event, liquidations would have failed to happen while bad debt would be realized once the stETH market begins to repeg.

stETH Dislocation

Prior to the adoption of exchange rate oracles, Gauntlet recommends implementing mechanisms to handle dislocation and oracle feed manipulation as discussed in this forum post. This would mitigate risks associated with exchange rate oracles.

For non-correlated Comets, the capital efficiency unleashed by an exchange rate oracle is minimized compared to correlated assets, so Gauntlet recommends maintaining market rate oracles.

Gauntlet supports the following path forward for the Compound community when deciding on future Oracle implementations:

Correlated Comets

• Primary Option: Exchange Rate Oracle*
• Secondary Option: Market Rate Oracle

Non-Correlated Comets

• Primary Option: Market Rate Oracle

*Gauntlet encourages the community to work to develop the required oracle mechanisms prior to implementing the exchange rate feeds.

[Gauntlet]

To add to this Oracle discussion, Gauntlet aims to highlight the differing risk parameter recommendations when utilizing a Market Rate oracle versus an Exchange Rate oracle (ERO). We will be highlighting our recent recommendations for LRTs and how utilizing an exchange-based Oracle could help drive higher capital efficiency.

Market Rate Base Risk Parameters

Gauntlet has been conducting listing due dilligences for various LRTs and has recommended the below based on market rate oracles:

weETH

Parameter	Value
Collateral Factor	80%
Liquidation Factor	85%
Liquidation Penalty	8%
Supply Cap	22,500

rsETH

Parameter	Value
Collateral Factor	80%
Liquidation Factor	85%
Liquidation Penalty	10%
Supply Cap	5,000

Market Rate based formula

The recommended market rate based parameters factor in a sufficient buffer to account for the potential delta between prevailing market rates and exchange rates. The Liquidation Factor is derived from the following formula:

Liquidation Factor = 1 - (Liquidation Penalty + 90D Volatility)

Exchange Rate based Risk Parameters

In contrast, when utilizing Exchange Rate Oracles, the insulation from markets/liquidity conditions can drive higher capital efficiency. Gauntlet can recommend more risk-on recommendations. The Liquidation Factor formula simplifies to: :

Liquidation Factor = 1 - (Liquidation Penalty)

Since the market volatility component is removed, the Liquidation Factor can be set higher, allowing for more optimal capital utilization while still maintaining an appropriate liquidation penalty. The risk recommendations for weETH for example, can tend to be more optimal:

weETH

Parameter	Value
Collateral Factor	87%
Liquidation Factor	92%
Liquidation Penalty	8%
Supply Cap	> Current

It’s important to note that we advocate employing Exchange Rate Oracles only for assets with enabled withdrawals to mitigate risks effectively. Additionally, our risk management strategy involves deploying a Guardian module to pause markets during extreme tail-end scenarios, providing an added layer of protection for the protocol and an Oracle price feed cap to protect against Oracle manipulation.

[pennblockchain]

After many in-depth discussions with other delegates and collecting community feedback, we have decided to move forward on implementing a hybrid exchange rate oracle for pricing LSTs that optimizes security and scalability.

We’re thrilled that the Chainlink Labs team has proposed an implementation for this oracle design, and we are actively seeking feedback from @Gauntlet.

The high-level overview of the proposed implementation is a Chainlink decentralized oracle network (DON) that would track the amount of underlying collateral backing an LST, which in this case is the amount of ETH actively staked on the beacon chain. For increased security assurances for the Compound protocol, the results from the DON could be combined with comparison check conditions against the LST issuer’s onchain calculated primary exchange rates and or secondary market rates. Note that this design is subject to change based on feedback from Compound service providers.

While the hybrid exchange rate oracle implementation is under development, @Gauntlet has suggested that we move forward and deploy wstETH as collateral on all three chains with exchange rate pricing for the time being. The objective would be to swap the pricing oracles after development and audits are complete, allowing for an acceleration in supporting wstETH to grow Compound’s TVL and revenue once enabled as collateral.

We’re excited to collaborate with Chainlink Labs and Gauntlet on implementing a new oracle to help Compound securely expand in the LST space. Stay tuned for more updates!

[Gauntlet]

Gauntlet supports advancing with an exchange rate oracle for liquid staking and restacking tokens once withdrawals are enabled. We have been in discussions with Chainlink and FranklinDAO regarding their proposed implementation of a Decentralized Oracle Network (DON), and we are excited about its potential to help Compound minimize the risks associated with using an exchange rate-based price feed.

To ensure Compound remains competitive in the LRT/LST space and to mitigate significant risk from price dislocations, Gauntlet supports progressing with an exchange rate oracle while CL/FranklinDAO are developing this hybrid oracle. We propose setting up a snapshot vote to allow the community to make a final decision on how we price LRTs/LSTs moving forward.