LSTs and LRTs: Liquid Staking and Restaking

Liquid Staking Tokens (LSTs) represent staked ETH (or other PoS assets) in liquid, transferable form. Liquid Restaking Tokens (LRTs) extend the idea: LSTs are deposited into restaking protocols (EigenLayer, Symbiotic, Karak) whose purpose is to securely "rehypothecate" stake to additional services. Each layer adds yield and risk.

By 2026, LSTs and LRTs together account for a large fraction of staked ETH and a meaningful slice of overall DeFi collateral. Auditing them is unavoidable for any protocol that uses ETH-correlated assets.

LST Architectures

Lido (stETH)

The largest LST. Users deposit ETH; the protocol distributes the ETH across a set of node operators; users receive stETH, a rebasing ERC-20. stETH balances grow over time as staking rewards accrue (the supply rebases daily based on the protocol's reported beacon-chain balance).

Variants:

  • wstETH: a non-rebasing wrapper (the standard form used in DeFi integrations).
  • WithdrawalQueue: users withdraw by joining a queue; settlement is in epochs.

Rocket Pool (rETH)

A more decentralized model: node operators must run their own validators by staking RPL (the governance token) as insurance against penalties. rETH is non-rebasing; its exchange rate to ETH increases over time.

Coinbase, Binance, Frax, others

A range of centralized and semi-decentralized LSTs. Each has its own governance, validator set, slashing tolerance, and exchange-rate mechanism.

Native Restaking / Solo Staker LSTs

Newer designs (Puffer, EtherFi) let solo stakers run their own validators with capital efficiency, with the LST as a wrapper around their staking activity.

LRT Architectures

EigenLayer

Operators register; they can opt into "Actively Validated Services" (AVSs); restakers delegate ETH (or LST) to operators who run those services. The restaked ETH is slashable by the AVSs for misbehavior.

Built on top of EigenLayer are LRT protocols:

  • EtherFi (eETH): liquid restaking position; eETH is a rebasing token.
  • Renzo (ezETH): liquid restaking on top of EigenLayer.
  • Kelp (rsETH): another LRT layer.
  • Puffer (pufETH): restaking with anti-slashing tech.
  • Swell, Mantle, others.

Symbiotic, Karak

Newer restaking platforms with different parameter spaces. The LRT layer is still emerging.

What Makes LSTs/LRTs Hard to Audit

1. Exchange Rate Manipulability

An LST's exchange rate to its underlying asset is the central piece of state. Protocols that consume LSTs read this rate. Common manipulation vectors:

  • Rebase-timing manipulation: rebasing LSTs (stETH) have a discrete reporting event; protocols that read balance immediately before vs. after see different values.
  • Reward distribution timing: non-rebasing LSTs accumulate value as the exchange rate increases; the timing of rate updates is observable.
  • Validator misreporting: if the protocol's reported balance comes from validator-controlled data, a malicious node operator can lie temporarily.

A protocol using an LST as collateral must use a manipulation-resistant price source for that LST. The LST's own internal exchange rate is not always sufficient — for stETH in particular, the "fair" price can deviate from the on-chain quoted rate during periods of low liquidity (the 2022 stETH depeg).

2. Depeg Risk

LSTs trade at variable premia/discounts to their underlying:

  • stETH traded as low as 0.93 ETH during the 2022 LUNA/3AC crisis.
  • rETH and others have had smaller depegs.
  • LRTs in 2024 had multiple depeg episodes during withdrawal-queue stress.

A lending protocol that treats stETH = ETH is exposed to depeg-induced bad debt: borrowers who deposited stETH and borrowed ETH can have their collateral underwater while the protocol's view of their position is healthy.

Defenses:

  • Use market price for collateralization, not internal exchange rate.
  • Lower LLTV (loan-to-value) for LSTs than for the underlying.
  • Specific oracle that accounts for the redemption / market spread.

3. Withdrawal Delays

LST withdrawals are not instant. Lido's withdrawal queue can take hours to days; EigenLayer's restaking withdrawals have multi-day delays for slashing resolution.

Protocols that integrate LSTs must account for the fact that liquidity is asymmetric: you can buy any LST on a DEX instantly, but you can only redeem at exchange rate by waiting.

Audit implications:

  • A liquidation that requires redeeming LST will be delayed.
  • A protocol that promises "instant withdrawal of LST" is implicitly relying on DEX liquidity, which can fail.

4. Slashing

The LST/LRT is backed by validators who can be slashed for misbehavior. Slashing on Ethereum is rare (~0.5% of validators ever slashed, with median losses around 1 ETH) but can be larger in correlated-failure scenarios. Restaking adds slashing conditions from each AVS, multiplying the risk surface.

Audit implications:

  • Does the LST/LRT pass slashing losses through to holders, or absorb them via an insurance fund?
  • For LRTs, what is the aggregate slashing exposure across all AVSs the underlying restaker is opted into?
  • Is the slashing transparency adequate for downstream protocols to model the risk?

5. Composability of Stacked Risk

When ETH → LST → LRT → DeFi position, the risk is cumulative:

  • The LST's smart-contract risk.
  • The LRT's smart-contract risk.
  • Each AVS's slashing risk.
  • The DeFi position's smart-contract risk.

A user holding 1 LRT-ETH in an Aave-style lending market is exposed to all four. Documentation and risk disclosure are usually incomplete; audit reports should surface the full risk stack explicitly.

LST/LRT-Specific Findings That Recur

1. Hardcoded 1:1 Assumption

function getValueInETH(address asset) returns (uint256) {
    if (asset == stETH) return balanceOf(stETH, msg.sender);  // ❌ assumes stETH == ETH
    if (asset == rETH) return balanceOf(rETH, msg.sender);    // ❌ same
}

Should be:

function getValueInETH(address asset) returns (uint256) {
    uint256 balance = balanceOf(asset, msg.sender);
    uint256 priceInETH = oracle.getPriceInETH(asset);  // accounts for depeg
    return balance * priceInETH / 1e18;
}

2. Read-Only Re-entrancy via stETH

stETH's rebase mechanism interacts with Curve and other integrations in non-obvious ways. The Curve stETH/ETH pool had a famous read-only re-entrancy issue in 2023 that was exploited via several integrating protocols. Any contract reading from such pools must use the pool's re-entrancy-guarded view function or take a price observation that can't be manipulated during the call.

3. Reward / Yield Accounting Errors

LSTs report yield via:

  • Balance rebase (stETH).
  • Exchange-rate update (rETH, wstETH).
  • Both, in some hybrid designs.

A protocol that integrates an LST and tries to "extract yield" must handle the accounting correctly. Common bugs:

  • Treating the LST as non-yielding and accruing yield to the wrong party.
  • Double-counting yield (once in the LST, once in the integrating protocol).
  • Missing the rebase entirely (if the LST is held as a wrapped balance with no harvest call).

4. LRT-Specific: AVS Composition

LRTs let restakers opt into multiple AVSs. The aggregate slashing exposure must be tracked; a restaker over-exposed to many AVSs can be slashed beyond their stake.

LRT contracts must:

  • Track AVS opt-ins per restaker.
  • Calculate aggregate slashing exposure.
  • Limit composition where appropriate (an LRT issuer might cap how many AVSs its underlying restakes into).

This is a new audit category with limited prior art; LRT audits in 2025-2026 are surfacing novel bugs frequently.

5. Bridge / Cross-Chain LST Wrappers

LSTs and LRTs are often bridged to other chains as wrapped versions. The wrapper:

  • Must accurately track the underlying balance.
  • Must handle exchange-rate updates atomically.
  • Must reconcile in case of bridge failure.

Bridged LST/LRT positions are exposed to the bridge's risk and the LST/LRT's risk. The wrapper contract is usually small but is a load-bearing piece of the entire bridge.

Audit Checklist for LST/LRT Consumers

For any protocol that holds, accepts as collateral, or values LSTs/LRTs:

  • The LST is not assumed to be 1:1 with its underlying.
  • Pricing uses a manipulation-resistant oracle (chainlink rate provider, Pyth, market price, etc.) rather than just the LST's internal exchange rate.
  • Collateralization parameters (LTV, liquidation threshold) accommodate realistic depeg scenarios.
  • Withdrawal latency for the LST is accounted for in liquidation logic.
  • Read-only reentrancy in pool integrations (especially Curve) is guarded.
  • Yield accounting is consistent — no double counting, no missed rebases.
  • If using an LRT: AVS exposure is documented and the slashing model is understood.

For LST/LRT issuers themselves:

  • Exchange rate update mechanism is manipulation-resistant.
  • Withdrawal queue is fair (FIFO, no priority for insiders) and capable of unwinding under stress.
  • Validator slashing is correctly socialized.
  • Insurance fund (if any) is solvent under realistic slashing scenarios.
  • Reward distribution is auditable and consistent.

A Note on Maturity

The LST sector is mature; bugs in major LSTs (Lido, Rocket Pool, Frax) are rare and well-monitored. The LRT sector is new; bugs are still being found, and the economic dynamics (yield expectations, slashing tolerance, withdrawal queue behavior) are not yet stress-tested.

A 2026 audit of an LRT-integrating protocol should:

  • Explicitly enumerate the LRTs supported.
  • Document each LRT's specific risks.
  • Recommend conservative parameters until the LRT ecosystem matures further.

This isn't paranoia — multiple 2024 LRT-related incidents have been due to LRT immaturity rather than integrator code bugs. Conservative integration is the only defensible posture.