Underwriting LRTs: Balancing High Yield with Novel Risks
Underwriting the risk of Eigenlayer liquid restaking tokens within the DeFi ecosystem
Introducing Liquid Restaking Tokens
The advent of Eigenlayer gives rise to a novel exotic collateral type: liquid restaking tokens (LRTs). LRTs are to restaking what liquid staking tokens (LSTs) are to staking—tokenized representations of Eigenlayer restaking positions. LRTs bear novel risks at the promise of higher yields paid for by the protocol-level applications (actively validated services or AVSs) that use EigenLayer to rent Ethereum's crypto-economic security.Â
LRTs lean into the composability of public blockchains, fostering the financialization of EigenLayer’s pooled security —allowing users to not have to choose between liquidity and yield. Put simply, why would a user forfeit DeFi yield opportunities to lose liquidity and restake their ETH or vice versa, when instead they could forgo opportunity cost and chase yield through both.Â
Much like LSTs, LRTs will be the collateral of choice for many crypto users across lending protocols, CDP stablecoins, DEXs, perpetual futures applications and more. EigenLayer views LRTs as a financial buffer that safeguards EigenLayer and AVSs from external financial risks associated with LRTFi.
As with any novel collateral, the question arises: "How can DeFi protocols underwrite LRT risk profiles to adopt them properly?". This understanding is essential for building sustainable and capital-efficient protocols.
More Risk, More Reward
An LRT’s risk profile is composed of the incremental risk from restaking ETH into EigenLayer, and the risks associated with the implementation of the LRTs.Â
ETH restaked into EigenLayer is delegated to an operator. An operator performs validation services for Ethereum and for the AVSs they choose to secure. By opting to restake with a particular AVS, stakers and operators receive rewards from AVSs paying for EigenLayer security, and also accept the risk that their deposited assets may be slashed (taken away as a penalty) according to the rules in the AVSs slashing contract.
LRT providers deploy a set of smart-contracts on Ethereum that enables users to deposit/withdraw ETH/LSTs, and mint/burn LRTs. The risk profile between LRTs will vary depending on the LRT's operator set and which AVSs are being secured.Â
To start, the incremental slashing risk from restaking will be low given EigenLayer's slashing veto committee and screening of AVSs. But, in a future world with infinite AVSs, there are 2n-1 permutations of AVSs that can be secured by an operator, n AVSs secured. So, there can be lower-yielding, conservative LRTs and higher-yielding, risky ones —analogous to why there are bond credit ratings.
Overview of LRT Risk Profile
This section will introduce the risks inherent in LRTs, given their architecture, and the risks created by introducing LRTs into the broader crypto-economic landscape.Â
AVS Slashing
An AVS is any system that requires its own distributed validation semantics for verification. The design space for what protocols can create outsized value as AVSs is infinite (overview of first 12 major AVS). So, in the long run, the biggest risk that LRTs will bear will come from novel AVS slashing conditions.Â
One major value proposition of LRTs is enabling users to outsource risk management to the LRT provider i.e. the LRT provider chooses an operator set and underwrites which AVSs to secure. When choosing an LRT provider, users should consider:
Does the LRT provider have a comprehensive understanding of the protocol risks associated with each validated AVS?
What is the LRT provider’s delegation strategy? Is it open source or proprietary? Does the LRT provider’s community have input in delegation?
Operator MalpracticeÂ
Operators are tasked with managing validators that run the Ethereum client and software provided by the AVSs that are being secured. Operators register in EigenLayer and allow restakers to delegate ETH to them. On EigenLayer testnet we see institutional validators. Figment, Blockdeamon, Chorus One, P2P, Google Cloud, Kiln, etc, that will likely only secure the most robust AVSs, and smaller operators who will aim to differentiate by supporting more AVSs to improve potential restaking rewards to delegates.
Slashing is fundamental to Ethereum and EigenLayer's crypto-economic security model; it deters malicious acts by levying economic penalties against validators who act against the interest of the network. This article sheds light on the real vs perceived risks of slashing in the context of Ethereum and EigenLayer.
When evaluating EigenLayer operator slashing risk, the following considerations should be made:
Who is the operator(s) for the underlying EigenPods?
Does the operator have a proper risk mitigation strategy in place to avoid slashing and downtime?
Does the operator’s dev-ops team have enough bandwidth to combat unforeseen circumstances relative to the number and complexity of AVS being secured?
Does the operator have off-chain insurance to compensate for potential slashing events?
What is the commission structure of the operator?
Supported Deposit Assets
As of time of publishing, LRT providers can choose to accept ETH (to natively restake) and the following LSTs (to liquid restake) as depositable assets: ankrETH, OETH, LSETH, rETH, stETH, cbETH, osETH, swETH, mETH, ETHx, wBETH, sfrxETH.
LSTs create value by enabling users to earn ETH staking yields and maintain liquidity without having to run a validator node, which requires 32 ETH. LSTs bear risk from Ethereum slashing, exploits, and secondary market volatility. If the LSTs node operators act maliciously or unreliably, users can have their funds slashed. Security risk arises from relying on the node operators to secure their private keys and trusting the robustness of the LST protocols smart contracts. Finally, LSTs, not pegged to their underlying assets, can face price fluctuations; market events and lower trading volumes can significantly affect their stability compared to the underlying assets.
If LST(s) are accepted by LRT providers, then the LRT will bear the risks of the underlying LST(s).Â
Is the LRT composed of natively restaked ETH, or restaked LSTs
If restaked LSTs, who are the node operators for those LSTs?
What percentage of the overall deposits does each type of accepted collateral make up?
Access to Liquidity
All funds unstaked from EigenLayer go through a 7-day escrow period before being able to be withdrawn, creating duration risk for LRTs. Furthermore, many LRT providers have not enabled withdrawal functionality.
What is the TVL of the LRT?
Is there a healthy amount of secondary market liquidity for the LRT?
What is the redemption process for the LRT?
What are the short-term liquidity incentives LRT providers are offering?
Smart ContractÂ
What protocol architecture risks exist for the LRTs?
How are rewards being paid out? Rebasing or value accrual?
What is the fee structure of the LRT provider?
How are admin multi-sig permissions structured? What permissions are involved in transferring assets and pausing withdrawals?
The following risks are not inherent to the LRT but arise due to the LRTs' adoption across the broader crypto-economic landscape.
Oracle
Are there reliable and robust price oracles in place to ensure accurate pricing of the LRTs?
Governance
What governance risks exist for the LRTs?
How are AVSs chosen to be secured?
To what extent can governance be used to ‘king make’ AVSs? What incentives does this dynamic create?
Cross-Chain
In the case of cross-chain LRTs, how is bridging implemented? Are canonical or non-canonical bridges being used?Â
In the case of non-canonical bridges, how is the LRT provider approaching issues with fungibility with the L2 enshrined bridge and the tradeoff of batch latency? Â
Centralization Concerns
What is the market structure of LRTs?Â
To what extent do LRTs have a centralizing effect on EigenLayer’s shared security offering?
Looping Risk
In lending markets, looping LRTs can trigger widespread liquidations, a risk confined to specific lending markets without impacting EigenLayer's security. This mirrors the 2022 stETH depeg event, where stETH's price risk was contained within the lending market, leaving Ethereum consensus unaffected.
Addressing The Risks of LRTs
Addressing and managing the risks of LRTs is necessary for them to scale securely and be widely adopted. To do so, it’s required to understand the benchmarks that can be used to underwrite LRT risks and how to incorporate them into DeFi protocols for parameterizing markets since they are quantifiable and endogenous to LRTs.
Benchmarks For Underwriting LRT Risks
LRTs have the work cut out for them when mitigating risks for their users. They must properly underwrite and select a portfolio of AVSs to secure while performing in line with the expectations of their ideal user.
Selecting the right AVSs to opt into requires LRTs to understand the slashing conditions of each AVS as well as the infrastructural design decisions that the AVSs include, one example being the underlying consensus mechanism of an AVS. With each AVS a liquid restaking provider opts into, they add to the set of slashing conditions that the node operators are committed to not violate.
Violating slashing conditions causes LRT holders to incur a direct economic loss to their position. Under traditional Ethereum slashing conditions, slashed validators incur an initial deduction of ETH, followed by a potential correlated slashing penalty after 16 days, and ending with their removal from the beacon-chain after a 38-day period. Typically the ETH lost to a slashing is marginal compared to the total ETH staked with the liquid restaking provider, however if a large sum of validators are slashed within a close period of time they can become subject to a correlated slashing penalty which contributes to a significantly greater loss than in typical scenarios. Under the traditional Ethereum slashing conditions, slashings are not prevalent, and in the context of this paper it should be noted that they are not tied to AVSs in any way. However, AVSs will have their own set of complex slashing conditions, and it’s certainly beneficial to understand the propensity for validators to be slashed under the scope of an AVS’s design as well as the impact each slashing actually has on the slashed validator.
This implies that it’s also important for LRTs to properly configure their validator set profile to minimize the risk of slashing if they are natively restaking. The majority of LRTs will most likely begin by implementing permissioned node operator sets to ensure the quality of validators operating on their behalf. Client and geographic diversity can play a big role here by limiting the centralization risks of a validator set. Distributed validator technology (DVT) and trusted execution environments (TEEs) can be used to improve the reliability and security of a validator set further. DVT further increases the diversity of the validator set while TEEs essentially act as anti-slashing software by protecting the validators using them from violating slashing conditions (for example only allowing the validator to sign off on a block once, avoiding potential double signs). Hopefully in the future we’ll see modular anti-slashers that can be extended to a variety of AVSs that share similar functionalities and slashing conditions making the application of TEEs more extendable to different AVS designs. If LRTs are not natively restaking they can expand the variety of liquid staking tokens that they accept to deposit – selecting those LSTs who’s own validator set meet the aforementioned security recommendations that match the LRTs desired risk profile.
The potential permutations of AVS strategies scales rapidly the more there are: 2n- 1 for n AVSs. This requires them to pick an optimal portfolio of AVSs to fit their desired risk profile and strategy. Some have even called for a standard to be created for a "vanilla" portfolio of AVSs that fits a widely accepted risk profile. In both scenarios, AVSs must identify methods of characterizing the aforementioned risks and quantifying their real impact to the LRT to justify the yield returned to restakers for securing the portfolio of AVSs.
Key Benchmarks
AVS slashing conditions
Propensity of slashing under AVS slashing conditions
AVS consensus mechanism
Validator client diversity
Validator geographic diversity
Validator DVT integration
Validator TEE integration
Permissioned vs Permissionless node operator sets
How DeFi Protocols Can Incorporate Underwriting Methods
Incumbent DeFi protocols are not readily designed to incorporate these infrastructural security benchmarks. They rely more on liquidity, which is another bottleneck for these assets. So, if most of the benchmarks for underwriting LRTs is infrastructural, and if it's not yet been proven that there will be deep liquidity for LRTs then we find ourselves quite limited in the current landscape to facilitate DeFi products for LRTs. That is, if most of our benchmarks are infrastructural, it doesn't make sense to price the risk of these assets according to market price, which is heavily dependent on liquidity. Instead, we might be able to look toward pricing risk based on the soundness and solvency of the asset. After all, LRTs are really just a restaked representation of staked ETH, which is a staked representation of ETH. ETH itself is much less volatile than the rest of crypto. However, suppose LRTs have far less liquidity available. In that case, the market price of LRTs will be much more volatile than that of ETH, exposing restakers to a greater risk of liquidation.Â
DeFi lending is the arena in which the underwriting of risk is most necessary as it's been seen to be the largest DeFi use case for liquid staking tokens and will most likely also be the largest DeFi use case for liquid restaking tokens. The current generation of DeFi lending protocols operate based on liquidity and governance. That is, service providers like Gauntlet parameterize markets by analyzing the liquidity available for an asset and running scenarios to identify conditions that could lead to large scale liquidations and insolvency. As we've already discussed, adopting this underwriting methodology for market parameterization does not account for the inherent infrastructural risks to LRTs. Rather, it exacerbates the liquidity risks associated with LRTs and puts lending protocols at greater risk of bad debt, especially since many of the incumbent protocols utilize pooled lending, sharing risk across the entire protocol/pool. Aave is the most relevant in this generation of lending protocols given their large exposure to LSTs and recent improvements aimed at supporting them in a more capital efficient and secure manner.
Aave
Aave, originally called ETHLend, was one of the first lending markets on-chain. As an open-source and non-custodial platform, Aave allows participants to engage directly with each other without the need for traditional financial intermediaries. Users who provide liquidity to the market by depositing into Aave's liquidity pools can earn interest, while borrowers can obtain loans by over-collateralizing, ensuring the security of the loans. Aave supports a wide range of assets, offering features like variable and stable interest rates, as well as innovative DeFi concepts such as flash loans, which allow for the borrowing of assets without collateral, provided that the loan is returned within the same transaction block. This flexibility and the protocol's emphasis on security and transparency have positioned Aave as a key player in the DeFi ecosystem. When it comes to supporting staked assets and potentially restaked assets in the future, the following factors bear the highest impact.
Governance-Based Market Parameterizations - Aave, advised by service providers like Gauntlet, votes through DAO governance to set market parameters by assessing asset liquidity and potential for large-scale liquidations. However, this approach overlooks the structural risks to LRTs, increasing liquidity risks and the potential for bad debt in pooled lending systems, where risks are shared across all participants.
Aave E-Mode - The High-Efficiency mode feature (or "eMode") is designed to maximize capital efficiency when collateral and borrowed assets, such as ETH, LSTs, and LRTs, are correlated in price. Other assets can be used as collateral, but only assets of the same category can be borrowed in E-mode; otherwise, the user would have to exit the E-mode configuration. Ultimately, it enables a greater LTV for borrowers. However, because it is a more specialized configuration, it takes additional oversight from service providers to properly parameterize the market, especially considering that recursive borrowing is a prominent strategy made more efficient with higher LTVs. This is notable because recursive borrowing is the act of levering up on the collateral asset to increase exposure to it (in this case, levering up on staked assets to increase exposure to the staking yield), which increases the risk of cascading liquidations from price volatility and decoupling of LSTs from the base ETH.
Aave Killswitch - The Killswitch is a framework for Aave to limit LST borrowing power when abnormal conditions arise (i.e. price decoupling of LRTs). It was recommended by Gauntlet that in the such an event killswitch be enabled toÂ
Automate liquidation threshold reduction to liquidate the riskiest positions gradually.
Freezing the LST deposits and making the LTV 0 so there could be no more borrows.
Doubling the slope of the interest rate curve to reduce utilization.
Lower the LTV to non-E-mode LST parameters to further reduce the impact.
However, through the governance process, an option was chosen to only freeze LST deposits and drive the LTV to 0. However, this is concerning because price decoupling occurs in a continuous fashion, so even if it prevents additional insolvencies in the market, it does not reduce the trouble with the existing risk. It kind of just leaves positions sitting to either get liquidated or recover from the decoupling.
A new generation of DeFi protocols is evolving to increase modular and permissionless design, enabling their markets to be more composable to what the free market desires rather than being subject to traditional governance procedures. While many new lending protocols like Ajna and Euler are entering the space, the two we'll discuss here currently support LSTs and LRTs, whereas the others do not. These two protocols are Morpho Blue and Ion Protocol.
Morpho
Morpho Blue is a lending market that recently launched as a follow-up to Morpho's previous product, Morpho Optimizers. It utilizes isolated lending markets, enabling permissionless market creation. This is complemented by externalized risk management, oracle agnostic pricing, and permissionless interest rate modules. Each parameter is selected at market creation and persists in perpetuity (i.e., they are immutable). Like Aave, they must adhere to governance specifications when selecting the liquidation loan to value ratio and interest rate model. In its current form, Morpho Blue is a much more modular version of Aave, with markets siloed and tailored to an individual or entity's desired parameters, which is a difficult task in itself to design. It is hard to say whether users will take advantage of such freedom or whether the responsibilities of curating risk management strategies and designing oracles and interest models will flow to more established service providers.Â
Ion Protocol
Ion Protocol is a lending protocol specifically built for staked and restaked assets. It is currently live on testnet, in the final stages before launching on mainnet. Ion Protocol takes a different approach to market parameterization, by underwriting the endogenous infrastructure risks of LRTs to optimize capital efficiency and minimize the risks of liquidations and protocol insolvency. Ion utilizes isolated markets, solvency-based underwriting, yield reactive interest rates, and partial liquidations to give users direct access to sustainable and efficient ETH-denominated yield.
Solvency-based underwriting - Ion Protocol was designed to be price agnostic. Price-agnostic markets utilize the reserve ratio of LSTs and LRTs rather than their market price. That is, LSTs and LRTs can be valued according to their circulating supply relative to how much ETH is staked or restaked within a token's provider's validator set. By valuing LSTs and LRTs, Ion Protocol creates a scenario where borrowers are only liquidated if a slashing event directly impacts the provider's validator set. This significantly reduces the chances of liquidations and enables greater capital efficiency – Ion can raise LTVs from the industry standards of about 0.8 to 0.9 and above. This is all powered by ZK proof of reserve in partnership with Succinct.
Collateral-specific interest rates - Ion's interest rate model is strictly defined per collateral. It requires that the borrowing rate be less than the staking yield to provide a profit margin to borrowers, enabling them to lever up and continue to earn efficiently. They provide a minimum borrow rate for instances where the staking yield drops too low to sustain the profit margin reasonably. However, if the staking yield increases, the earnings generated get directly passed to lenders and borrowers. Each collateral type's market is unique and parameterized to create an efficient borrowing experience while properly compensating lenders.
ZKML Slashing Prediction - Ion Protocol has partnered with Modulus labs to develop a ZKML model for predicting the propensity of slashing within a validator set. This will help inform the market parameterizations. It acts as a mechanism to unbiasedly quantify the probability that a validator will experience a slashing event and then aggregates that to the level of the validator set.Â
Ion Protocol is becoming the most efficient option for stakers and restakers to participate in DeFi lending. By taking an asset specific approach to their mechanism design, the team has designed the protocol to incentivize the things specifically pertinent to staked and restaked assets.
Concurrently with the new generation of lending protocols, we have seen the rise of new and innovative CDP protocols.
Ebisu Finance
Ebisu Finance is a yield-bearing stablecoin backed by LRTs. Ebisu unlocks capital efficiency for restaked assets by enabling users to draw dollar-denominated credit (ebUSD) against natively restaked ETH and LRTs via a non-custodial, decentralized stablecoin. ebUSD gives users access to a stable store of value while enabling yield generation through AVS rewards and Ethereum staking rewards. By driving demand for LRTs, Ebisu also contributes to scaling the restaking ecosystem, bolstering Ethereum's shared security and economic alignment. Â
With any lending protocol, it is imperative to ensure that bad debt does not accrue in the system. Ebisu lending implements isolated collateral positions so that the system can work smoothly to liquidate the riskiest debt positions. ebUSD can be redeemed against its underlying collateral at face value. eg. 1 ebUSD can be redeemed for $1 USD denominated in restaked collateral. Redeemed ebUSD is used to repay the riskiest debt position, and transfers the respective amount of restaked collateral from the liquidated position to the redeemer.
Additionally, Ebisu will have a stability pool, as is common amongst CDP stablecoins. The Stability Pool, funded by users, safeguards loans by providing ebUSD as liquidity to cover debts from liquidated debt positions. This ensures that the total supply of ebUSD is solvent and adequately backed. Upon the liquidation of any debt positions, an ebUSD amount equal to the debt position’s outstanding debt is eliminated from the Stability Pool to settle this debt. Concurrently, the remaining collateral of the liquidated debt position, net of liquidation fees, is transferred to the Stability Pool. Depositors in the Stability Pool are then eligible to withdraw a portion of this liquidated collateral, pro rata to their proportion of the Pool's total balance. This arrangement is designed to leave a net benefit for depositors, as the value of the collateral is generally higher than the amount of debt that was extinguished. The use of a stability pool enables Ebisu to process liquidations without having to price the LRT collateral.
Future Exploration
So far, we’ve discussed the benchmarks and primitives actively being explored and developed that can be used to underwrite the riskiness of an LRT for its use in DeFi. However, some questions remain.Â
Can we reliably use these benchmarks and primitives to scale restaking, particularly liquid restaking tokens, to the same heights we’ve seen liquid staking tokens scale?
Where can we turn to formalize these concepts further and standardize the metrics so that we can onboard bigger players?
Answering these questions is a challenging feat. Regarding the first question, if LRTs and restaking can be sustainably supported in DeFi, then it’s possible for them to become as ubiquitous of a representation of ETH as LSTs if not more. Getting to this spot requires us to spend more time on the second question, and work on making standards and formalized concepts to help us on the way. At the beginning of this section, we discussed that the risks inherent to LRTs stem from their selection of AVSs, so it makes sense to formalize some kind of portfolio theory for AVS selection. Some have suggested that this could be a function that takes each potential strategy (2^n- 1 strategies for n AVS) and identifies a max loss by summing the max loss of each AVS included in a strategy, with the max loss being defined as the maximum percentage of stake that can be frozen/slashed by each AVS. This makes sense! Although, it may still be too simple to capture all of the benchmarks we mentioned earlier truly. One alternative could be to follow Ion Protocol's lead by utilizing machine learning to create a feature set and objective function similar to the MaxLoss objective function in order to identify the propensity of slashing for each AVS and an expectation of the loss.
After quantifying risk, it also makes sense to create a library of different metrics that can be used to help explain the choices made for a portfolio as well as its performance. One such metric that has been suggested is one that is on par with the Sharpe Ratio, a measurement of risk-adjusted relative returns. For restaking, the risk-adjusted returns could look something like (staking rewards - infra cost) / MaxLoss. Others might include something like a yield beta, or how well the restaking yield tracks the underlying performance of the staking yield for a particular AVS as well as for a particular strategy or portfolio.Â
All in all, we are at the precipice of a boom of newly created products to help further expand the benefits of crypto-economic security and allow more participants to share in the rewards. It's important to understand, benchmark, test, and formalize the kinds of mechanisms and metrics that can help protect against and inform users of the risks associated with LRTs and the market's they are being used in.
Source
Not financial or tax advice. The purpose of this newsletter is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.
Disclosure. All of my posts are the authors own, not the views of their employer.