Liquid Staking Tokens: Understanding the Oracle Perspective in DeFi’s Evolving Landscape
Liquid staking tokens (LSTs) of Ethereum, like stETH (Lido’s staked ETH) and rETH (Rocket Pool’s staked ETH), have gained popularity as they allow users to earn staking rewards on the Ethereum network while maintaining liquidity. However, yield is never risk-free, after all there’s no such thing as a free lunch, right? And this is especially true in crypto as it presents a number of additional risks. As the popularity of Liquid Staking Tokens (LSTs) like stETH and rETH grows, so do the complexities in integrating them into DeFi protocols, especially for oracles providing price feeds. We at Tellor aim to shed light on these challenges, highlighting the risks from an oracle’s perspective.
Liquidity Risk
The value of liquid staking tokens is usually closely pegged to ETH, but it’s subject to market dynamics. There could be situations where the trading price of the LST (liquid staking token) deviates from the value of underlying ETH, particularly in times of high market volatility or liquidity crises. A quick look at coingecko for the top LST protocols shows the distribution of liquidity and trading volume. Excluding CEX based LSTs, (which one would expect to be mostly on the exchange), LST liquidity distributions are as follows:
LST ranked by total staked eth (at the time of writing)
| LST | Sources | % vol on single exchange | % vol on dex |
| Lido | STETH | 90% | 98% |
| Rocket Pool | RETH | 52% | 100% |
| Frax Ether | SRFXETH | 88% | 100% |
| StakeWise | SETH2 | 98% | 100% |
| Swell | SWETH | 56% | 100% |
| Stader | ETHX | 76% | 100% |
| Origin Protocol | OETH | 90% | 100% |
Decentralized oracle data reporters (like tellor reporters) depend on api sources from the internet. When there are fewer sources, the data can be manipulated more easily. Since LSTs are largely new and unlisted on centralized exchanges (that are competing with their own LSTs) there are really only 1 or 2 sources that reporters can use for price data. This leads to:
Oracle Risk
Oracles act as middleware between data sources (apis) and the on-chain world (this is something we are trying to push the oracle space to move away from, incorporating subjectivity to add robustness). But, given you are using an API as a data source for something, it’s vital for robustness that you have multiple sources which allows for additional measures to be put in place, for example using a median. Well, many of these LSTs, having only one market, have oracle feeds with a single point of failure (the source). There are things that can mitigate your oracle risk here in the case of a single data source, like, use time-weighted-average-prices (TWAPs) or using the the price on a delay – but in a DeFi world competing for slim margins, efficiency and yield sometimes trump risk mitigation, sadly.
Governance Risk
You might say, well, if the LSTs are all lower liquidity on single markets, then why not just use more than one LST, or even a basket of them as collateral. This is a good idea on the surface. But can your protocol handle a depeg of one of its collateral assets? You’ll need to have governance in place to handle the onboarding and removal of accepted assets and this opens the protocol up to an entire world of governance risk. Most of it amounts to decentralized theater, where under the hood things are really quite centralized. For example, even the largest protocols struggle to get 2% participation in governance votes, so it comes down to one or two entities (typically the team themselves) who push these votes through.
Apart from the risks outlined above (one’s that more directly concern us as an oracle), LSTs still face additional existential challenges. If we were foraying into the world of building an LST or a protocol that uses LSTs in some way, we’d gravely consider how we’d handle these situations:
Mass (or Minor) Slashing Event
Since these tokens represent staked ETH, they inherit the risks associated with Ethereum staking. This includes potential penalties and slashing. If the validator node(s) associated with the staked ETH perform poorly or act maliciously, it could lead to a reduction in the staked value. These protocols may have things in place to protect users from losses due to slashing events but can they handle a mass slashing event? What would happen to oracle feeds? How would the price react? Nobody knows exactly how that would play out. But it’s not hard to imagine that one day we might find out.
Native Enshrining of Liquid Staking
Vitalik Buterin has discussed openly the topic of enshrining more things in the Ethereum protocol natively, including liquid staking. If this were to happen it would kill many if not all other liquid staking protocols. Can your protocol switch LST’s?
Vampire Attacks
What happens when you copy paste a protocol, but add in greater financial incentives (air drops, higher yield, etc). Liquidity will move to capture that opportunity, as made famous by the AMM Sushiswap back in 2020. This same thing is happening with LST protocols.
Social Slashing
“Social Slashing” is the concept of some coordinated effort by the ethereum community to reduce Lido’s influence and power. For example, Ethereum could fork and remove Lido, or there could be a coordinated effort of validators to start ignoring activity from Lido validators leading the protocol to slash them due to inactivity. The power in these is more in the credible threat of doing them as opposed to the feasibility of actually doing it, as the level of coordination would be no small feat, but similar to the native enshrining or mass slashing event considerations, social pressure could be very destabilizing for LSTs.
Conclusion
In conclusion, the interplay between LSTs and oracles in the DeFi space is a balancing act between the pursuit of capital efficiency and the imperative for robust, reliable systems. The journey through liquid staking tokens is fraught with complexities, from the ever-present risk of social slashing and potential native enshrinement of liquid staking, to the strategic movements akin to vampire attacks. These factors not only affect the underlying assets but also significantly influence the reliability and accuracy of oracle feeds. As we navigate through these challenges, it’s imperative for oracles to adapt and evolve. This includes enhancing mechanisms to handle single-source dependencies, especially for LSTs with limited market presence, and actively participating in the governance processes that shape the protocols they serve. Oracles are not just passive observers in this landscape; they are key players in ensuring the integrity and stability of DeFi ecosystems. The thirst for capital efficiency and seamless user experiences must be balanced against the need for overcollateralization, acceptance of latency for security, and minimal yet effective governance. As oracles, our role is pivotal in this evolution. We must continuously refine our approaches to ensure we are not only providing accurate, timely data but also contributing to the broader conversation around risk mitigation and protocol resilience. Yes, we are still in the early stages of this revolutionary financial landscape, and caution must be our guide. However, with careful navigation and a commitment to innovation, the potential of what we can achieve together here is boundless.
