Lidofi wstETH keeps stETH staking exposure in a non-rebasing token

Oct 11th, 2026 - last updated

Lidofi wstETH is Lido’s wrapped stETH token, whose balance stays unchanged by staking rebases. Each token represents a share of the underlying stETH held by the Ethereum wrapper. When staking accounting increases that share’s stETH value, the same wstETH amount converts into more stETH. A negative rebase can reduce the conversion value. Wrapping changes how the staking position is counted; it doesn’t create a separate reward stream. Unwrapping returns stETH at the contract’s current rate. The fixed balance suits applications that can’t accommodate rebasing tokens, while conversion quotes, market prices and bridged representations each have distinct limits.

stETH backing, shares and the wrapper

stETH provides the backing, shares measure proportional ownership and the wstETH contract connects that ownership to an ERC-20 balance. Lido’s staking accounting determines how much stETH a share represents. The wrapper holds stETH collectively, so its backing also reflects the underlying rebases. wstETH records the share quantity in a transferable token format. An accounting update can therefore increase the wrapper’s stETH balance without minting more wstETH for existing holders. Protocol reward fees affect that share value through the underlying staking accounting, so wstETH retains exposure to those fee deductions.

An unchanged wallet balance alone doesn’t indicate missing rewards. The wstETH count describes the account’s share quantity, while its stETH equivalent includes the current value of those shares.

Wrapping and unwrapping change the token form

Wrapping exchanges existing stETH for newly minted wstETH within the Ethereum wrapper contract. It calculates the minted quantity from the current stETH share rate, so the stETH input and wstETH output needn’t have identical token counts.

wrap() needs a sufficient stETH allowance for the wrapper itself, so approving another application won’t authorize it. An existing sufficient allowance can meet this prerequisite.

Unwrapping reverses the representation: the contract burns the caller’s wstETH and releases the corresponding stETH. The returned amount follows the current share value; the wrapper doesn’t preserve an account-specific original stETH deposit for later repayment.

The Ethereum contract also accepts ETH through its staking shortcut. Its receive() function submits ETH to Lido and mints wstETH from the resulting shares. Staking and wrapping happen within that call, and underlying staking limits still apply. This ETH route differs from wrap(), whose input is existing stETH.

Both conversion directions require an on-chain transaction and incur network gas costs. They change the token representation without making a secondary-market trade. Additional approval transactions can add gas costs. The share conversion determines the token output; gas pays for transaction execution.

What does the wstETH conversion rate measure?

The conversion rate expresses how much stETH corresponds to one wstETH at the current Ethereum contract state. stEthPerToken() exposes that relationship. getStETHByWstETH() calculates the stETH amount for a supplied wstETH quantity, while getWstETHByStETH() calculates the reverse conversion. The helpers return integer token units, so displays must apply the token’s decimal scaling. These values describe token conversions without quoting a sale price in ETH or a cash currency.

A wrapped balance’s stETH equivalent equals its wstETH amount multiplied by the stETH-per-wstETH rate, subject to integer rounding. A smaller wstETH count than the original stETH amount follows whenever one wstETH represents more than one stETH. A conversion preview reads the contract state at the time of the query. If accounting changes before execution, the later transaction uses the updated rate.

A positive stETH rebase increases the stETH represented by each wstETH token. Accepted accounting updates drive these changes through reports that normally arrive daily, although lack of Ethereum finality can delay them. The conversion rate doesn’t increase continuously just because a wallet display refreshes.

Lidofi wstETH: What does the wstETH conversion rate measure? - illustration

View image file

Ethereum conversion inputs and spending limits

The Ethereum wrapper requires positive conversion amounts, sufficient token balances and, for wrapping existing stETH, an allowance that permits the wrapper to collect the selected amount. These requirements apply to direct wrap() and unwrap() calls. Amounts use the input token’s units; an stETH quantity and a wstETH quantity aren’t interchangeable.

Parameter	Required value	Applies to	If the requirement fails
Wrapping amount	Greater than zero	stETH input to wrap()	Zero input causes a revert
Wrapping allowance	At least the requested stETH amount	Sender’s stETH allowance for the wrapper	The wrapper can’t collect the requested stETH
Wrapping balance	At least the requested stETH amount	Sender’s stETH balance	The sender lacks enough stETH for the call
Unwrapping amount	Greater than zero and within the caller’s balance	wstETH input to unwrap()	Zero input or insufficient balance causes a revert

Fixed balances in DeFi and bridged tokens

A fixed wstETH balance lets compatible decentralized finance (DeFi) applications track token quantities without recalculating them after every stETH rebase. That reduces the extra accounting required by a rebasing token. Lending applications can use wstETH as collateral, and compatible pools can hold it as liquidity. Acceptance belongs to the particular application and network, whose contract determines how deposits, withdrawals and any additional rewards work. The fixed quantity doesn’t establish an application’s collateral limits, price feed or redemption terms.

Bridges also benefit from quantities that remain stable between transfers. A bridged wstETH token represents assets through that bridge’s contracts. On many destination networks, the token has no native method that converts it into local stETH. Its valuation can rely on a delivered rate feed. The Ethereum contract’s methods don’t automatically accompany a bridged token.

OP Mainnet and Unichain also support local stETH through a separate conversion design. The local stETH contract locks wstETH when it mints stETH, reversing the Ethereum wrapper’s relationship. A method’s direction comes from its input token and contract, so wrap() doesn’t always describe stETH becoming wstETH. This local conversion remains subject to the destination implementation and its bridge dependencies.

Staking losses and trading prices remain separate risks

Staking penalties can lower wstETH’s stETH conversion value even though its token count stays fixed. Wrapping preserves exposure to Lido’s staking accounting, including losses. Secondary-market prices follow a different relationship: liquidity and demand can produce discounts or premiums. An exchange quote also reflects trading conditions and potential slippage. A higher stETH conversion rate doesn’t guarantee a higher sale value in ETH or currency. Bridge failures and application liquidation rules add risks where those services hold the position.

Unwrapping ends in stETH, while withdrawals release ETH

Unwrapping returns stETH within a successful Ethereum transaction; protocol withdrawals require a request, finalization and an ETH claim. The withdrawal queue can accept wstETH and unwrap it internally, so separate manual unwrapping isn’t always necessary. Its permissions, amount limits and pause state still govern the request. A completed unwrap() call establishes a change in token form. It doesn’t establish that ETH has reached the holder or that a withdrawal request has finalized.

Practical questions about Lidofi wstETH

Can buying existing wstETH give me rewards earned before the purchase?

Buying existing wstETH doesn’t create a separate claim to rewards earned before the purchase. All holders use the same Ethereum conversion rate at the same contract state. That rate already reflects the token’s staking history. The price paid determines the entry cost, so accumulated stETH conversion value isn’t a free reward for the buyer. Subsequent staking accounting changes affect the newly held position.

Why can wrapping and unwrapping produce a tiny rounding difference?

Converting between stETH amounts and underlying shares uses integer arithmetic that can round down. The stETH transfer involved in wrapping or unwrapping also translates between shares and token amounts. Small differences can therefore appear between a displayed amount and the amount actually transferred. Their size depends on the share rate and quantities involved; a fixed rounding loss doesn’t apply to every conversion.

Does signing a wstETH permit transfer tokens by itself?

Signing a valid ERC-2612 permit for wstETH authorizes a spending allowance update without transferring tokens. The token contract must accept the signature, nonce and deadline before recording that allowance. The signed message also identifies the spender and amount. An application can use the accepted allowance in a later or combined token transfer. The deadline limits when the contract can accept the permit; it doesn’t automatically revoke an allowance that has already taken effect.

Will sending stETH directly to the wstETH contract mint wrapped tokens?

A plain stETH transfer to the Ethereum wrapper doesn’t invoke wrap() or mint wstETH. Wrapping existing stETH uses wrap(), which collects approved tokens. The contract’s ETH receive function is a distinct staking shortcut; its ability to accept ETH doesn’t apply to arbitrary token transfers. A successful stETH transfer receipt confirms token movement without establishing that the wrapper minted wstETH for the sender.

Is a wstETH allowance also an approval to spend stETH?

A wstETH allowance authorizes spending only wstETH. stETH maintains a separate allowance under its own contract, and each allowance names a particular spender. Approving a DeFi application to transfer wstETH therefore doesn’t grant it permission to transfer unwrapped stETH. Token identity, spender and authorized amount remain separate parts of the permission. Different token operations can consequently require different approvals, even within the same application.