Lido Integration: Where Staking Breaks and What the Client Loses
Lido integration breaks not at the connection stage, but in operation: contracts accept transactions, the interface shows a balance, and a week later it turns out that part of the funds is stuck in the withdrawal queue, and the stETH accounting in your system diverges from the on-chain state.
The cost of such a failure is not only blocked liquidity, but also incorrect reporting to users and the regulator.
Lido staking is structured as an exchange with deferred settlement: you deposit ETH and receive stETH, but in return you get not ETH, but a place in the withdrawal queue.
Until the request is processed, the asset cannot be returned to circulation, and if the product logic is built on the assumption "withdrew — immediately received," the first surge of requests will expose the hole.
A separate headache is wrapped wstETH: its rate grows relative to stETH, and accounting that treats wstETH as equal to stETH one-to-one quietly understates the treasury balance.
The Lido withdrawal queue is not an instant mechanism, but a sequence of request processing, where order, limits, and the moment of finalization matter.
Staking integration errors most often live precisely here: a request was created but its status change was not tracked, it was not taken into account that part of the withdrawal may not be closed in full, and idempotent processing of repeated events was not built.
As a result, the same withdrawal is counted twice, and the stETH accounting desync accumulates unnoticed.
Next, we break down how this is closed: where to place reconciliation of the on-chain state with the internal registry, how to design withdrawal queue processing, and which checks catch desync before it turns into a loss.
What correct Lido integration delivers: modes, effect, limitations
Lido integration starts with choosing a mode: it determines crediting speed, accounting behavior, and which failures are even possible. Below are three working modes that we deliver turnkey, along with their measurable effect.
stETH: the base mode with daily rebasing
The balance grows through rebase — the holder earns yield without transactions. It suits treasuries and storefronts where a "live" growing balance is needed.
Limitation: rebase breaks accounting where the balance is fixed in snapshots — integration requires explicit handling of rebase events, otherwise reporting discrepancies accumulate.
wstETH: a wrapper with a fixed balance
The rate grows relative to stETH, while the number of tokens stays the same. This eliminates the class of failures related to rebase: the accounting balance is stable, snapshots and internal ledgers don't "drift".
It suits collateral, liquidity pools, and any place where a constant quantity matters. The limitation is that yield is visible only through the rate, not through the balance.
WithdrawalQueue: direct withdrawal to ETH
A request is placed in the queue, and execution happens as the queue is processed. This is the only correct path from "staking → native ETH" without external exchangers. It suits scenarios where ETH itself is needed, not a derivative token.
Limitation: the execution time depends on queue load, so the interface needs an explicit request status rather than "instant withdrawal".
| Option | When it fits | Limitations |
|---|---|---|
| stETH | storefronts, treasury, growing balance | rebase breaks snapshots and fixed accounting |
| wstETH | collateral, pools, stable accounting | yield only through the rate, not through the balance |
| WithdrawalQueue | withdrawal to native ETH | timing depends on the queue, a request status is needed |
The effect of integration is measurable: stake crediting happens in a single transaction, the share of accounting discrepancies drops to zero thanks to correct rebase handling, and the class of failures where "withdrawal hung without status" disappears along with an explicit queue model.
We build integration on Lido with separate paths for accounting and withdrawal — this allows changing the mode without rewriting the logic.
How we implement the integration: stages of engineering work
Lido integration is not about "connecting a library" but about embedding derivative staking operations into an existing infrastructure: accounting for stETH and wstETH, correct handling of the WithdrawalQueue, and separation of permissions for operations with client assets. Below is the sequence we follow to take a project from audit to handover.
- Audit of the current infrastructure and staking. We examine how wallets and keys are structured, who initiates transactions, how balance accounting is maintained, and whether there is already any handling of derivative tokens. We identify gaps: where stETH balance is treated "as a regular token," where the stETH↔wstETH exchange rate is not accounted for, and where there is no processing of withdrawal requests.
- Designing the scheme. We determine whether to work through stETH or wrap it into wstETH, how the withdrawal path through the WithdrawalQueue is built, and which roles are needed for minting, wrapping, and initiating withdrawals. The output is an asset flow diagram and an access matrix.
- Configuring Lido for the client's infrastructure. We connect the contracts and the service layer, configure the parameters for working with derivative tokens and the withdrawal queue, and bring accounting to a unified logic — so that balances and accruals reconcile with the on-chain state.
- Integration verification. We run scenarios in a test environment: staking, wrapping, withdrawal, partial withdrawal, repeated request. We reconcile calculations with actual network data and check behavior under failures and queue delays.
- Handover of the solution. We deliver the working integration, documentation on the scheme and access rights, operating instructions, and a breakdown of typical incidents — so that the client's team can run the system independently.
Each stage ends with an artifact: an audit report, a scheme, a configuration, a verification protocol, a documentation package. This way, at acceptance it is clear exactly what was verified and on what data.
How does direct staking differ from wrapped wstETH?
Direct staking through Lido returns stETH to the user — a token that reflects rewards daily through balance growth. This is a rebasing model: the number of tokens in the wallet increases on its own, while the rate to ETH stays close to one.
Rewards are accounted for "inside" the protocol, and any external service that holds stETH must correctly react to balance changes.
wstETH is a wrapped version of the same stake. The balance is fixed, and rewards are "baked into" the exchange rate: over time, one wstETH is worth more than ETH.
This mechanic does not break accounting in third-party contracts, so wstETH is accepted without issues by lending protocols, yield aggregators, and bridges. The difference between the tokens lies precisely in the accrual method: rebasing versus a growing rate.
Staking liquidity is the key practical selection criterion. stETH is convenient for simple holding and reward accounting, but it cannot be "wrapped" into a pool or collateral without wrapping.
wstETH was created for DeFi: it is compatible with liquidity pools, collateral positions, and structured products where a predictable balance unit matters. You can wrap stETH into wstETH and unwrap it back at any moment, with no loss of rewards.
There is also a withdrawal nuance. The WithdrawalQueue locks in a request to exchange the stake for ETH at the rate at the moment of execution, and until it is closed the token is locked in the queue — this affects available liquidity.
During integration we account for this scenario: we choose the token form for the client's task, set up correct reward accounting, and verify contract behavior during rebasing and during withdrawal.
Case Study: How We Eliminated Withdrawal Delays and Accounting Desynchronization
The client came to us with a working staking system: the contracts accepted ETH and minted stETH, but withdrawals through the queue were delayed, and the balances shown in the interface diverged from the actual on-chain state.
Users saw one amount, but when they tried to withdraw — a different one; some withdrawal requests hung in a pending status because requests weren't linked to real queue events.
Accounting was built on periodic state polling instead of event subscriptions — hence the desynchronization and load spikes.
What It Was Before
- Withdrawals were processed manually: an operator reconciled requests against the queue state, the average request closure time was hours, and during peak periods — more than a day.
- The share of successful withdrawal operations hovered around 80%: the rest were stuck requests and manual corrections.
- Accounting diverged from the chain: the interface displayed the balance from the last poll rather than the current state, which caused users to re-initiate withdrawals.
What We Changed
We moved accounting to an event stream: subscription to token issuance and redemption, to requests being placed in the queue and to their finalization.
Each event is recorded in a journal with an operation identifier, and the balance state is rebuilt from the journal rather than from periodic polling. A withdrawal request was linked to its position in the queue — the status updates as it progresses, not on a timer.
We added idempotency: a repeated withdrawal request with the same identifier doesn't create a duplicate but returns the current status. This eliminated a class of failures where a user, not having received a response, would submit the request a second time.
Separately, we closed the gap in handling queue-side rejections — the system now distinguishes between "request in processing" and "request rejected" and doesn't show the former instead of the latter.
What It Became
| Metric | Before | After |
|---|---|---|
| Average withdrawal request closure time | hours | minutes |
| Share of successful withdrawal operations | ~80% | consistently above 99% |
| Accounting divergence from the chain | regular | eliminated |
| Manual request corrections | constant | not required |
The desynchronization was eliminated as a class: the state in the interface is rebuilt from the same event journal as on the chain, so "displayed" and "actual" match at any moment.
The load on nodes leveled out — instead of frequent polling, there's an event stream that scales with the number of operations.
We moved the queue and accounting logic into a separate layer with test coverage for withdrawal, repeated request, and rejection scenarios — the things that previously relied on manual actions.
We relied on Lido as the source of events and queue state, without our own interpretation of balances.
If your staking is already running but withdrawals are slow or accounting diverges from the chain — describe your task, and we'll come back with an estimate and a plan.
Compatibility, migration, and access concerns — let's discuss the task
Lido integration almost never starts from a clean slate: the client already has a custodial perimeter, their own position accounting service, or staking running through another operator.
So the first question on a call isn't "how to connect stETH," but "what happens to what's already running." We verify Lido's compatibility with the current stack before work begins: we look at how balance accounting is structured, who holds the keys, whether there's a ready-made transaction signing layer, and how fund withdrawal is organized.
If positions are already deployed somewhere, we plan the staking migration so that operations don't stop: a parallel perimeter, moving positions in parts, reconciling balances at every step.
What if an integration rollback is needed? We design it to be reversible from day one: contracts and withdrawal queues are isolated, state is recorded in a separate storage, and switching between the old and new perimeter is done without losing already accrued positions. A rollback is a return to the previous scheme, not a rebuild from scratch.
How are accesses and roles divided? We separate rights on the principle of least privilege: separate roles for initiating withdrawals, separate ones for managing positions, and separate ones for reading reports.
Keys aren't stored in one place, actions are written to a log, and changing the person responsible doesn't require rebuilding the entire scheme.
Can Lido integration be embedded into an already running service without rewriting it?
Yes, if the current network interaction layer supports standard contract calls. We connect to the existing logic through an adapter: the service keeps working as before, while operations with stETH, wstETH, and the withdrawal queue go through a separate module. There's no need to rewrite the core — only the protocol interaction layer changes.
The client receives not "repository access," but a package that allows the system to be maintained and handed over to another team:
- an integration diagram with fund entry and exit points;
- contract and withdrawal queue configurations with parameter explanations;
- a role matrix and key access policy;
- a position migration regulation and rollback procedure;
- staking documentation: how to read balances, accruals, and withdrawal statuses;
- a reconciliation log and reporting templates for internal control.
Describe your current scheme — where positions are stored, who manages the keys, what's already running. We'll come back with an assessment and a plan: what we'll reuse, what we'll add, and in what order.