Overview
We support the addition of ETH as a borrowable asset within the rsETH/wstETH E-Mode on Base instance.
Our assessment includes a detailed examination of rsETH’s technical architecture, redemption dynamics, backing composition, liquidity conditions, node operator and client diversity. We also evaluate updated supply caps to ensure consistent risk management across supported networks.
The analysis below outlines our findings and rationale behind each recommendation.
rsETH
Technical Overview
rsETH is the liquid restaking token issued by Kelp DAO, a restaking protocol built on top of EigenLayer that enables users to restake their ETH or existing LSTs such as stETH, ETHx.
Kelp DAO follows a hybrid approach. ETH deposits are used to spin up Ethereum validators for native restaking, while deposited liquid staking tokens are directly restaked on EigenLayer.
Withdrawal durations depend on multiple factors, including Ethereum validator exit times for native ETH, EigenLayer’s unbonding periods for restaked LST positions, the backing asset requested by users (ETH, stETH, ETHx, etc.), withdrawal delays set by the Kelp DAO team at the contract level, and on-chain liquidity within Kelp DAO’s withdrawal buffer reserves.
To ensure secure validator operations across both the beacon chain and EigenLayer environments, Kelp DAO partners with node operators, including Kiln, Allnodes, and Luganodes. Kiln and Luganodes manage both beacon chain validators and EigenLayer AVS infrastructure, while Allnodes supports Kelp’s Ethereum staking operations.
Market Capitalization
rsETH has been live on Ethereum mainnet since December 2023. The market capitalization of rsETH expanded rapidly throughout 2024 and early 2025 and reached approximately $2 billion at its peak. Recent months have shown a contraction to around $1 Billion. This reduction has been driven primarily by weaker Ethereum price performance rather than significant supply redemptions or structural changes within Kelp DAO.
The total supply of rsETH reached an all time high of approximately 600,000 in April 2025. Since then the supply has trended downward and is currently near 330,000.
wrsETH on Base launched in April 2024. Its circulating supply historically reached approximately 7,000 tokens but has declined to about 1,100 in recent weeks. The majority of this supply is deployed in the main liquidity venues on the network, particularly the Aerodrome pool against wstETH, as well as lending markets such as Compound, Morpho and Moonwell. On Base most wrsETH remains actively used as liquidity or collateral rather than held passively.
Asset Backing
As mentioned rsETH follows a hybrid restaking architecture, meaning it incorporates both native ETH and LST restaking. As a result, the token is collateralized by a basket of restaked assets, including natively staked ETH and LSTs such as stETH and ETHx. These assets are either restaked directly to EigenLayer or routed through Ethereum validators operated by Kelp DAO’s partner node operators.
The composition of the backing has evolved over time. Over the past year, restaked stETH has consistently represented the largest share of rsETH’s collateral base. As of the latest data, approximately 33% of rsETH’s backing consists of restaked stETH. Natively staked ETH accounts for 42%. The remaining share is primarily composed of restaked ETHx.
Users are able to mint rsETH by depositing any of the supported collateral types, including native ETH, stETH or ETHx. Similarly, they may request redemptions into any of these underlying assets, subject to availability and queue dynamics.
Liquidity
Onchain liquidity for wrsETH on Base is centered in a single major pool on Aerodrome paired against wstETH. This pool currently holds approximately $1.6 million total liquidity and serves as the primary venue for routing swap activity. Although minor pools may exist elsewhere, they do not contribute meaningfully to effective market depth.
Liquidity in the Aerodrome pool supports swaps of up to about 230 wrsETH ($750k), into ETH while remaining below a 5% price impact threshold.
Redemptions
The redemption process for rsETH is implemented through the LRTWithdrawalManager contract on mainnet Etheruem, which manages user withdrawal requests and coordinates asset settlement via the LRTUnstakingVault.
Users initiate redemptions by calling the initiateWithdrawal function on the LRTWithdrawalManager contract. During this call, they specify the amount of rsETH they wish to redeem and the preferred backing asset to receive, such as stETH, ETHx, or native ETH. Upon submission, the rsETH is transferred to the contract and escrowed. Each withdrawal request is assigned a unique nonce, which serves as an identifier within the queue for that particular asset.
The duration of a redemption depends on two key factors: (1) the chosen backing asset and (2) the availability of that asset within Kelp DAO’s liquidity buffer. The LRTUnstakingVault contract holds a reserve of each asset to service redemptions. If the asset is available in sufficient quantity, requests are generally serviced within hours. Conversely, if liquidity is insufficient, the request remains pending until assets are made available through validator exits or Eigenlayer unbounding flows.
Over the past 12 months, the liquidity buffer held in LRTUnstakingVault has been predominantly composed of stETH.
Users requesting native ETH as their withdrawal asset are subject to the longer of two constraints if there is no available ETH liquidity in the buffer: (1) the Ethereum beacon chain validator exit queue or (2) EigenLayer’s unbonding period. Following the introduction of slashing in December 2024, EigenLayer’s unbonding period was extended from 7 days to 14 days. Technically, these two timelines can partially overlap, as sophisticated restaking protocols like Kelp DAO can estimate the ETH to be received from validator exits and begin the EigenLayer escrow process concurrently. Therefore, the actual redemption time for native ETH is governed by the maximum of the beacon chain withdrawal queue and the 14 day EigenLayer escrow.
As of recent months, the beacon chain’s exit queue has been congested, resulting in estimated validator exit times of approximately 30 days. This makes the expected redemption time for native ETH close to 30 days under current conditions. In contrast, users requesting LSTs such as stETH or ETHx are only subject to the 14-day EigenLayer unbonding period, as these assets do not require validator exits.
Should the beacon chain queue normalize and exit times decrease below 14 days, the EigenLayer escrow will once again become the dominant delay factor for both native and LST redemptions.
To service redemptions, the Kelp DAO team periodically calls the unlockQueue function for each asset. This function specifies a firstExcludedIndex that determines the upper boundary of withdrawal requests to be unlocked. Requests are processed sequentially, starting from the current nextLockedNonce, until either the specified index is reached or the available liquidity for that asset is exhausted. Only requests that have passed the required withdrawalDelayBlocks can be unlocked.
Historically, Kelp DAO maintained a withdrawal delay of 1-7 days. In June 2025, this parameter was updated and set to zero, effectively allowing immediate servicing of eligible redemptions when liquidity is available.
When redemption requests are serviced, an equivalent amount of rsETH is burned, and the underlying backing asset is transferred from the LRTUnstakingVault to the LRTWithdrawalManager, making it available for user claims. If a user’s nonce is now lower than the most recently processed firstExcludedIndex, the user can finalize the redemption by calling completeWithdrawal and receive their asset.
Redemptions Performance
Onchain data of rsETH redemption activity over the past year reveals clear patterns in user preference and protocol fulfillment efficiency. The majority of redemptions, more than 70%, have been serviced through stETH, while approximately 23% have been processed via native ETH. This preference aligns with Kelp DAO’s asset buffer strategy, which tends to maintain higher available liquidity in stETH to ensure faster servicing of redemption requests.
Queue data further confirms this operational behavior. Requests for stETH are typically processed within hours, with minimal accumulation in the withdrawal queue. In contrast, native ETH redemptions are more prone to short-term queue buildup, particularly when beacon chain exit congestion limits the ability to replenish the liquidity buffer quickly. However, even in these cases, congestion has been contained to modest levels in both size and duration.
The most notable instance of redemption queue stress occurred in late June 2024. During this period, approximately 15% of the total rsETH market size was requested for withdrawal. At the time, the protocol maintained a smaller liquidity buffer across backing assets, which constrained its ability to fulfill redemptions immediately. As a result, it took approximately 10 days for the queue to be cleared, and rsETH experienced its largest historical depeg, trading more than 1% below parity. The episode highlighted the importance of adequate buffer sizing in ensuring timely redemptions and peg stability.
Overall, outside of this exceptional period, rsETH redemptions have been processed in a timely manner, with most queues cleared efficiently, particularly for stETH-based requests, reflecting the effectiveness of Kelp DAO’s redemption and asset allocation mechanisms under normal conditions.
Node Operator & Client Diversity
As highlighted in our research post Staking Penalties on Ethereum’s Consensus Layer: Implications for wstETH and Other LSTs and LRTs, node operator and client diversity are essential to ensuring operational resilience in Ethereum staking. Concentration among operators or reliance on a single consensus or execution layer client introduces material risk in the form of correlated slashing, inactivity leaks or validator compromise, whether from client-side bugs or endogenous factors such as key leakage.
These risks are particularly important for both LSTs and LRTs, where user assets are pooled across shared validator infrastructure. In this context, both the number of unique entities who run the validators and what clients they run are key risk variables for evaluating the safety of the underlying backing.
As discussed in the Asset Backing section, approximately 33% of rsETH is backed by stETH. This portion benefits from the distributed and curated node operator set of Lido. According to Lido’s latest VaNOM report, 93% of Lido’s stake is allocated across 37 curated node operators. The remaining 7% is distributed across Lido’s Simple DVT and Community Staking modules, which include over 300 additional node operators.
This means that each curated Lido operator is responsible for, on average, only 0.9% of rsETH’s total backing, reflecting strong decentralization and limited operator level exposure within this portion of the collateral base.
On the consensus layer, Lido exhibits healthy client diversity. Lighthouse is the most used client, accounting for 26.7% of validator usage, lower than the Ethereum network-wide share of over 55%, as tracked by clientdiversity.org.
Another component of rsETH’s backing comes from ETHx which accounts 25% of the backing. ETHx operates under a dual-validator model:
- Permissioned validators, which account for 64% of ETHx stake, are currently limited to five node operators. Among them, Stakin and Stakely collectively account for roughly 40% of total stake in ETHx.
- Permissionless validators make up the remaining 36%.
Client diversity data for ETHx shows that the dominant consensus clients are Prysm (39%) and Lighthouse (28%) and the leading execution client is Geth (44%), indicating moderate concentration risks on both layers.
The remaining 42% of rsETH’s backing consists of natively staked ETH. This portion is managed by Kelp DAO in collaboration with a set of professional node operators. Currently, five operators manage these validators, with P2P.org alone responsible for nearly 70% of the stake. This implies that P2P operates approximately 30% of the entire rsETH collateral base, including the amount that they run as Lido node operators
Despite this concentration, risk is mitigated through infrastructure design. Validators are operated using DVT via SSV and are WAD enabled. SSV sharding splits validator duties across 3 out of 4 operator clusters, often deployed across multiple geographical regions. WAD enables the dynamic selection of CL–EL client pairs based on attestation performance, favoring the most accurate and consistent combinations. Together, these design choices reduce the likelihood of validator failure or correlated slashing arising from client specific bugs or infrastructure outages.
While some concentration exists, particularly in the native staking portion, the underlying setups employ best in class decentralization techniques such as SSV and WAD.
Overall, this multi-collateral structure, combining stETH, ETHx and natively staked ETH, results in a highly diverse node operator and client composition for rsETH. Each collateral source brings its own set of node operators and client distributions, contributing to a broad and heterogeneous security foundation. The stETH portion benefits from Lido’s curated and community based operators with balanced client usage, ETHx introduces a separate set of permissioned and permissionless validators, while the native ETH component is operated through DVT enabled infrastructure with WAD based client selection and fallback mechanisms.
Staking Penalty Risk
To assess the potential severity of the risk of staking related penalties on Ethereum based on the client and node operator diversity of rsETH, we simulate one of the most damaging edge case failures in Ethereum staking: a Consensus Layer Majority Client Bug that prevents finality and triggers an extended inactivity leak. This edge case and methodology are explained in detail in our Staking Penalties on Ethereum research.
In this scenario, a critical bug in Lighthouse, the majority consensus client (currently exceeding 55% network share per clientdiversity.org) causes the chain to lose finality and enter an inactivity leak state. For finality to be restored, 2/3 of the total validator set must be operating on the non faulty chain. There are two mechanisms through which this recovery can occur simultaneously:
- Immediate exits by validators running the faulty client, followed by reentry into the network with non faulty client. This reduces the faulty client’s share but is strictly bounded by exit and deposit churn limits.
- Faulty validators remaining offline and absorbing inactivity leak penalties until their collective stake falls below 1/3 of the network.
Both the beacon chain churn limits and the initial market share of the faulty client directly determine the duration of the inactivity leak, in essence, they dictate how much ETH must be lost by the faulty majority before the non faulty clients regain 2/3 of the network. Early exiting validators are not subject to these penalties, but the bulk of the faulty majority remains exposed to inactivity leak penalties due to constrained churn limit of beacon chain. Based on current churn constraints and a 55% client share, each faulty validator (assuming 32 ETH stake) is expected to incur approximately 13.5 ETH in penalties before finality can be restored.
Under these assumptions, the network would remain in an inactivity leak for approximately 19 days. Given rsETH’s client composition, where 28.7 percent of its backing is tied to Lighthouse validators, the estimated penalty for the portion of rsETH’s backing running the faulty client would be approximately 42,659.69 ETH including missed attestations. This corresponds to a 12% reduction in backing.
This level of drawdown would result in a significant deviation from rsETH’s intended ETH parity. While penalties accrue progressively throughout the 19 day window, market participants would likely price in the anticipated backing deterioration immediately, creating reflexive pressure on rsETH’s market price. Without safeguards, users could borrow against overvalued rsETH collateral and exit with higher value assets, potentially resulting in bad debt. A staking penalty aware Risk Oracle capable of detecting and responding to such events could mitigate these impacts by freezing the reserve when abnormal penalty dynamics are observed.
It is important to note that Lighthouse’s current dominance (55%) is unusually high and unlikely to persist. The recent increase stems in part from the mass withdrawal of validators operated by Kiln, which skewed client distribution. Another contributing factor is the recent bug affecting the Prysm consensus client following the Fusaka upgrade, which accelerated the shift toward Lighthouse. Historically, Lighthouse has maintained a majority share closer to 40%, a level more representative of long-term equilibrium.
Under the historical Lighthouse dominance of 40%, faulty validators would incur approximately 5 ETH in penalties over an estimated 10.5 day inactivity leak period. For rsETH, this would result in an estimated 15,612.35 ETH in losses, corresponding to a 4.4% reduction in backing. This represents roughly one third of the losses seen in the elevated dominance scenario, illustrating how network wide client diversity has a direct and material impact on staking penalty risk exposure for LST and LRT issuers.
Supply and Borrow Caps
As part of this review, supply caps for rsETH have been evaluated across supported networks. These adjustments are recommended to align protocol risk parameters with observed onchain behavior and ensure that rsETH’s usage remains within safe and scalable thresholds.
Specification
E-mode (rsETH/wstETH) - Base
| Parameter |
Value |
Value |
Value |
| Asset |
wrsETH |
wstETH |
WETH |
| Collateral |
Yes |
No |
No |
| Borrowable |
No |
Yes |
Yes |
| Max LTV |
93.0% |
- |
- |
| Liquidation Threshold |
95.0% |
- |
- |
| Liquidation Bonus |
1.0% |
- |
- |
| Instance |
Asset |
Current Supply Cap |
Recommended Supply Cap |
| Prime |
rsETH |
65,000 |
15,000 |
| Linea |
wrsETH |
140,000 |
30,000 |
Disclaimer
Chaos Labs has not been compensated by any third party for publishing this recommendation.
Copyright
Copyright and related rights waived via CC0
