Custodial and exchange handling failures for Lido's stETH and wstETH represent a distinct and recurring operational risk category, separate from smart contract exploits. These incidents are not caused by vulnerabilities in Lido's core protocol but by integration errors in off-chain or centralized systems that fail to correctly model the token's mechanics. The root cause is almost always a misunderstanding of stETH's rebasing nature—where balances change daily via a balanceOf update—or a failure to use wstETH's non-rebasing share-based accounting for internal ledger systems.
Protocols
Custodial and Exchange stETH/wstETH Handling Failures
Documents security incidents at centralized exchanges and custodians resulting in loss of customer stETH/wstETH due to incorrect balance tracking, rebase handling errors, or withdrawal-processing bugs. Exchange and custody teams use this to validate their integration logic.
introduction
EXCHANGE AND CUSTODIAN INTEGRATION FAILURES
Incident Overview
A recurring class of incidents where centralized exchanges and custodians lose or incorrectly account for customer stETH/wstETH due to flawed rebase handling, balance tracking, or withdrawal processing.
The operational impact of these failures is severe and direct: customer funds become locked, are incorrectly credited, or are lost entirely when a flawed system allows one user to withdraw another's balance. In some cases, exchanges have halted stETH/wstETH withdrawals for extended periods while rebuilding their accounting logic. The pattern often involves a system that records an initial deposit amount and fails to update it during rebases, or a withdrawal process that calculates the ETH redemption value using a stale or incorrect balance. These errors are particularly dangerous in high-throughput environments where automated reconciliation can propagate a bad state across millions of user accounts before detection.
For builders and operators, these incidents underscore that stETH is not a standard ERC-20 and cannot be treated as one. A safe integration requires a deliberate architectural choice: either use wstETH for all internal accounting and unwrap it only at the point of user withdrawal, or implement a rigorous, rebase-aware balance reconciliation system that tracks shares rather than static amounts. Chainscore Labs provides integration audit and rebase-handling verification services specifically designed to identify these failure modes before they result in a loss event, reviewing the full lifecycle of deposit tracking, reward attribution, and withdrawal processing against Lido's token mechanics.
CUSTODIAL AND EXCHANGE HANDLING FAILURES
Incident Quick Facts
A structured breakdown of common failure modes, affected parties, and required actions when centralized platforms incorrectly handle stETH/wstETH accounting, rebases, or withdrawals.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Rebase Accounting | Failure to update internal balances to reflect daily stETH rebases, leading to a growing discrepancy between on-chain shares and credited user balances. | Custodians, Centralized Exchanges | Verify that internal ledger logic queries |
wstETH Unwrapping | Incorrectly treating wstETH as a static-value token rather than unwrapping to the underlying stETH balance, causing withdrawal shortfalls. | Wallets, Exchanges, Bridge Operators | Audit unwrap logic to ensure it uses the live |
Withdrawal Request Fulfillment | Prematurely crediting users with ETH before the Lido withdrawal queue finalizes, or failing to claim the | Custodians, Institutional Stakers | Implement a state machine that tracks request status from submission through NFT claim to final ETH distribution. |
Oracle Dependency | Using a stale or manipulated stETH/ETH price feed for internal accounting instead of querying the Lido contract directly. | DeFi Protocols, Exchanges | Replace secondary market price oracles with direct on-chain share-rate queries for internal bookkeeping of principal balances. |
Slashing Event Reconciliation | Failing to adjust user balances downward after a slashing event reduces the stETH share value, effectively socializing the loss incorrectly. | Custodians, Staking-as-a-Service Providers | Design a reconciliation process that can apply a negative rebase across all affected user accounts in proportion to their holdings. |
Deposit Finality | Crediting user accounts with stETH before the deposit is processed by the Lido Staking Router and the corresponding shares are minted. | Exchanges, On-Ramp Services | Wait for transaction finality and the |
Cross-Chain Representation | Bridging wstETH via a canonical lock-mint bridge but failing to account for the asynchronous finality of the destination chain. | Bridge Operators, L2 Integrators | Model the end-to-end latency and finality risk, and do not credit users on the destination chain until the canonical bridge attestation is complete. |
technical-context
RECURRING FAILURE MODES IN CENTRALIZED stETH HANDLING
Technical Root Cause Patterns
Analysis of the common technical failure patterns that lead to loss of funds when centralized exchanges and custodians incorrectly handle Lido's rebasing stETH token.
Custodial and exchange losses involving Lido's stETH and wstETH are rarely the result of novel smart contract exploits. Instead, they almost universally stem from a failure to correctly model the token's core mechanic: the daily rebase. The root cause is typically an off-chain accounting system that treats stETH as a static balance, recording an initial deposit amount and failing to update it with the daily rebase increments reported by the Lido oracle. When a user withdraws, the system releases the full, updated balance from the hot wallet but only debits the stale, smaller amount from the internal ledger, creating an accounting hole that is exploited by repeated deposit-withdraw cycles.
A second, related pattern involves the misuse of wstETH, the non-rebasing wrapper token. Teams sometimes integrate wstETH to avoid the complexity of rebases but then incorrectly unwrap it to stETH for internal accounting at a stale rate, reintroducing the very problem they sought to avoid. Other failures occur during the withdrawal process itself, where a custodian's smart contract or manual process incorrectly calculates the ETH redemption value of stETH, often by using a cached or manipulated oracle price from a secondary market instead of the protocol's canonical share rate. In each case, the technical flaw is an impedance mismatch between a centralized, batch-processed ledger and an asynchronous, continuously accruing token balance.
These failures are preventable through a rigorous integration architecture that treats stETH balances as a function of sharesOf(address) multiplied by the current pooledEthByShares, rather than as a static uint256. For teams operating custodial or exchange infrastructure, Chainscore Labs provides integration audit and rebase-handling verification services that stress-test the accounting reconciliation logic, withdrawal state machines, and oracle consumption patterns against these known failure modes before funds are put at risk.
IMPACT ANALYSIS
Affected Systems and Actors
Exchange and Custody Impact
Centralized exchanges and custodians that offer stETH/wstETH services are the primary affected actors. Failures typically originate from incorrect internal balance tracking, especially when systems treat stETH as a static balance rather than a rebasing token.
Critical failure modes include:
- Rebase Misaccounting: Failing to update internal ledgers during stETH rebases, leading to a slow divergence between on-chain and off-chain balances.
- wstETH Unwrap Errors: Incorrectly calculating the stETH redemption value of wstETH, especially when using stale or manipulated stETH per token ratios.
- Withdrawal Finalization Bugs: Mishandling the Lido withdrawal queue NFT (unstETH) or claiming ETH on behalf of users incorrectly.
Action Items:
- Audit the rebase-handling logic in your internal ledger.
- Verify wstETH conversion uses a manipulation-resistant on-chain oracle.
- Simulate the full withdrawal request and claim lifecycle in a test environment.
Chainscore provides integration audits specifically for exchange and custody stETH/wstETH handling logic.
implementation-impact
EXCHANGE AND CUSTODY RISK
Integration Failure Impact Areas
When centralized exchanges or custodians mishandle stETH/wstETH, the blast radius extends beyond the institution to affect stakers, DeFi protocols, and the peg itself. These are the critical failure domains that integration teams must harden against.
01
Rebase Accounting Errors
The most common failure mode. If a custodian's internal ledger does not correctly apply stETH's daily rebase, customer balances diverge from on-chain shares. This creates a fractional reserve scenario where total customer liabilities exceed the actual stETH held. Teams must implement an off-chain balance tracker that atomically updates all user balances using the post-rebase getSharesByPooledEth ratio, verified against the Lido oracle report timestamp. Chainscore can audit this reconciliation logic.
02
wstETH Unwrap Slippage and Liquidity Crunch
Exchanges that treat wstETH as instantly redeemable 1:1 for ETH create a solvency illusion. Unwrapping large positions requires routing through the stETH/ETH Curve pool or the Lido withdrawal queue, both of which can impose significant slippage or a multi-day delay during high exit demand. A bank-run scenario where all customers attempt to withdraw 'ETH' against wstETH collateral can freeze operations. Integration logic must model worst-case exit liquidity, not just the instantaneous stETH/wstETH exchange rate.
03
Withdrawal Queue NFT (unstETH) Mismanagement
When a custodian initiates a withdrawal from Lido, they receive an unstETH NFT representing a claim in the queue. If this NFT is lost, mishandled, or its claim window is missed, the principal ETH is permanently locked in the protocol. Custodians must implement a multi-signatory claim process with automated checkpointing of request IDs and claim deadlines. A failure here directly translates to a 1:1 loss of customer funds with no recovery mechanism.
04
Cross-Chain Bridge Dependency Failures
For exchanges holding stETH/wstETH on L2s or sidechains, the canonical bridge becomes a critical dependency. A bridge upgrade, pause, or exploit can trap assets, break deposit/withdrawal paths, or create a depegged representation of the token on the destination chain. Custodians must monitor bridge contract states and have a contingency plan for delayed settlement. Chainscore provides bridge risk assessments that model these multi-chain failure scenarios.
05
Oracle-Triggered Liquidations on Loaned stETH
Custodians offering yield products by depositing customer stETH into lending markets introduce oracle risk. A brief stETH price deviation below 0.99 ETH, even if the market price recovers quickly, can trigger cascading liquidations if the custodian's health factor is not aggressively managed. This is not a Lido protocol failure but an integration failure to account for the latency and deviation parameters of the specific oracle used by the lending protocol.
06
Governance Action Response Lag
Lido DAO governance can pause deposits, withdrawals, or the entire protocol via Easy Track motions. An exchange that does not monitor governance events in real-time may continue to accept customer stETH deposits that cannot be staked or process withdrawals that cannot be fulfilled. This operational blind spot creates a liability mismatch. Integration teams need a direct feed of DAO contract events to halt exchange-level operations within minutes of an on-chain governance action.
CUSTODIAL AND EXCHANGE FAILURE MODES FOR stETH/wstETH
Risk and Detection Matrix
Operational risk areas, failure modes, and detection signals for centralized exchanges and custodians handling Lido's stETH or wstETH.
| Risk Area | Failure Mode | Affected Actors | Detection Signal | Mitigation Action |
|---|---|---|---|---|
Rebase Accounting | Internal ledger fails to apply daily rebase, causing incorrect customer balances and potential double-spending on withdrawals. | Exchanges, Custodians, Accounting Teams | Discrepancy between internal stETH balances and on-chain share counts; customer withdrawal requests exceeding protocol balance. | Implement balance reconciliation using |
wstETH Unwrapping | System treats wstETH as 1:1 with ETH instead of using | Exchanges, Wallets, Bridge Operators | Abnormal trading volume or arbitrage flow immediately after wstETH listing; internal ETH liability exceeding on-chain reserves. | Audit token conversion paths; use on-chain rate queries for every unwrap operation. Chainscore offers integration audit for wrapping logic. |
Withdrawal NFT (unstETH) Handling | Custodian loses or mismanages the unstETH NFT during the withdrawal queue process, permanently locking customer ETH in the protocol. | Custodians, Institutional Stakers | Unclaimed ETH in the Withdrawal Queue contract linked to custodian addresses; customer complaints about stuck withdrawals. | Automate NFT custody and claim logic with multi-sig controls. Chainscore can design secure withdrawal-queue monitoring. |
Oracle or RPC Data Staleness | Exchange relies on a stale or forked RPC node for | Exchange Operations, DevOps Teams | Internal rate lagging behind on-chain oracle reports by more than one epoch; failed transaction simulations. | Query share rates directly from the Lido contract on a quorum of nodes. Chainscore can assess oracle dependency architecture. |
Transfer Fee Misconfiguration | Smart-contract-based custodian applies a fee on stETH transfers, breaking the rebasing invariant and bricking internal accounting. | Smart-Contract Wallet Teams, Custody Platforms | Reverted transactions when interacting with stETH; unexpected balance changes after internal transfers. | Ensure raw token transfers do not invoke fee-on-transfer logic. Chainscore can review smart-contract wallet compatibility. |
Governance Upgrade Blindness | Custodian integration breaks after a Lido DAO governance upgrade changes the staking router or token contract address without notice. | Integration Engineers, Risk Managers | Failed deposit/withdrawal transactions post-upgrade; event log mismatch. | Monitor Lido DAO governance proposals and Easy Track motions for contract changes. Chainscore provides governance-monitoring services. |
Cross-Chain Bridge Assumption Drift | Custodian uses a canonical bridge for wstETH that is later deprecated or exploited, stranding bridged assets. | Multi-Chain Exchanges, Bridge Operators | Liquidity fragmentation between canonical and third-party wrapped tokens; bridge security advisories. | Validate bridge canonical status with Lido DAO; avoid hardcoding bridge addresses. Chainscore offers bridge-risk assessments. |
CUSTODIAL AND EXCHANGE HANDLING FAILURES
Integration Remediation Checklist
A structured checklist for custodians and exchanges to validate their stETH/wstETH integration logic following handling failures. Each item identifies a common failure mode, why it matters for asset safety, and the specific signal or artifact that confirms correct implementation.
What to check: Confirm that your internal balance-tracking system correctly maps stETH balances to the underlying share count, and that rebases are applied atomically across all customer accounts at the moment the oracle updates the total pooled ETH.
Why it matters: The most common failure mode is a mismatch between the internal ledger and on-chain shares, where a rebase is applied to some accounts but not others, or applied at the wrong timestamp. This creates an immediate solvency gap where customer liabilities exceed on-chain assets.
Readiness signal: Run a reconciliation script that compares the sum of all customer stETH balances (as tracked internally) against the total shares held by your custody wallet multiplied by the current share price. This should return zero delta within one rebase period. Automate this check to run after every oracle report.
resource-links
LIDO INTEGRATION REFERENCES
Canonical Resources
These resources are the primary references custody, exchange, wallet, and risk teams should use when validating stETH and wstETH balance handling. They are especially relevant for preventing rebase-accounting errors, wrapper conversion mistakes, and withdrawal-processing failures.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
INTEGRATION SAFETY
Frequently Asked Questions
Common questions from exchange and custody teams investigating stETH/wstETH handling failures and hardening their integration logic.
The most frequent root cause is incorrect handling of the stETH rebase mechanism. Exchanges that track stETH balances using a static internal ledger without accounting for daily rebases will see a drift between their internal liability and the actual token balance. This leads to an effective shortfall where customer withdrawals exceed the exchange's actual holdings. Other common causes include:
- Share-based accounting errors: Treating wstETH as a 1:1 peg with ETH instead of tracking its accruing value via
stETH.getPooledEthByShares(). - Withdrawal queue mismanagement: Mishandling the unstETH NFT or finalization step in the Lido withdrawal flow, causing ETH claims to fail or be front-run.
- Cross-chain bridge assumptions: Assuming bridged versions of stETH on L2s rebase identically to mainnet, when many L2 representations are non-rebasing.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.