stETH vs wstETH: One Stake, Two Prices

stETH and wstETH are two receipts for the same Lido stake. They differ in what stays fixed. With stETH the token count moves: balances grow at each daily rebase while each token is designed to track one ETH. With wstETH the token count stays put while the amount of stETH behind each token rises. Both describe one staking position. A pricing or accounting system that treats one as the other is off by the whole accrued reward ratio, so the mix-up is an operational risk and not a matter of taste.

stETH: the balance moves

stETH is a rebasing ERC-20. Once a day the protocol’s oracle reports the balance of its validators on the Consensus Layer. Every stETH balance is recalculated in that single step, at around midday UTC. Five of nine oracle daemons must agree on the data before the report reaches the contract. Finalized epochs alone are reported. A report can be skipped when the quorum is not reached. The next successful one then includes the periods that were missed.

A rebase can in principle be negative if validators are penalized or slashed. Lido’s documentation notes that daily rebases had not been negative as of its writing.

Under the surface the contract does not store balances. It stores shares and derives each balance from them:

balanceOf(account) =
  shares[account] * totalPooledEther
  / totalShares

When rewards lift totalPooledEther, every balance rises while every share count stays where it was. Shares change on transfers, mints and burns. That distinction drives most integration trouble:

• The contract does not emit a Transfer event at a rebase, so a wallet or ledger that caches balances goes stale. Lido’s guide says not to keep a cached stETH balance for more than 24 hours.
• A transfer of stETH can arrive one or two wei short of the amount sent, because of rounding between shares and balances.
• Lido recommends that integrators store and operate on shares instead of public stETH balances.

wstETH: the balance holds, the rate moves

wstETH is a wrapper around stETH. Wrapping locks the stETH in the wstETH contract and mints wstETH equal to the share count of the locked amount. Unwrapping burns the wstETH and releases the stETH. Because the token count is a share count, one wei of wstETH equals one wei of its balance, with no rounding gap.

Nothing in a holder’s wstETH balance changes at a rebase. What changes is how much stETH it unwraps to. Lido’s own illustrative figures make the point: a holder wraps 1 stETH and receives 0.9803 wstETH. After the pooled ether grows by 5 percent, unwrapping those 0.9803 wstETH returns 1.0499 stETH. The amount unwrapped differs from the amount wrapped whenever a rebase falls in between.

The conversion rate is the same for everyone at a given moment and steps once a day with the rebase. Four view functions expose it: stEthPerToken(), tokensPerStEth(), getStETHByWstETH(uint256) and getWstETHByStETH(uint256). Each one is a direct read of stETH’s share functions. stEthPerToken() returns the wei-denominated amount of stETH behind one wstETH. Sampled over four consecutive days in October 2026, the rate stepped once per day with no movement in between.

The same day we compared the block before and after that day’s rebase. The stETH balance held by the wstETH contract rose, while its share count and the wstETH supply did not move. That is the whole mechanism in one block: the rewards land in stETH and the wrapper token passes them on through its rate.

Why protocols and bridges use wstETH

Lido’s documentation describes wstETH as a compatibility layer for systems that do not support rebasing tokens, bridges to other chains in particular. Two reasons stand out.

• Bridges. Most cross-chain bridges have no way to handle a rebase. Bridged stETH would see its rewards accrue to the bridge contract, where they stay locked. Lido’s contributors encourage bridging wstETH, the non-rebasing form, instead.
• Accounting. A lending market or exchange pool that records fixed balances can need a custom adapter to hold a rebasing token. Lido’s guide advises integrating stETH directly when an application deliberately supports share and rebase semantics. In every other case it advises wstETH.

The result is a token that lives on many chains. wstETH exists on Arbitrum, Optimism, Base, Linea, BNB Chain and Unichain. On most of them it is a bridged ERC-20 that cannot be unwrapped locally and cannot report its own rate, because it has no share bookkeeping behind it. Lido publishes rate feeds for those networks. A system that reads wstETH there has to take the rate from one of them.

Staking and wrapping can also happen in one step: sending ETH directly to the wstETH contract stakes it and returns wstETH.

Where the mix-up happens

The rate answers “how many stETH is this wstETH”. It never answers “how many dollars”. The two questions fail in different ways. A short list of the places a unit can slip:

• A wstETH balance valued as stETH. The error equals the whole accrued ratio. Because the rate drifts upward as rewards accrue, the position is undervalued and the error grows with the age of the token.
• A stETH balance treated as fixed. A ledger that records a balance once and trusts it for weeks drifts from the chain by every rebase since.
• The wrong asset’s price on a balance. A dollar price of stETH applied to a wstETH balance, or the reverse, carries the same ratio error as the case above.
• A bridged wstETH asked for its rate. On a chain where the token cannot unwrap, the call that works on mainnet reverts.
• Rounding reconciliation. A stETH transfer can come up one or two wei short, so an exact-match check against the amount sent can fail while nothing is wrong.

For a risk or treasury team the practical habits follow from the list. Record the token address and unit next to every balance. Convert units with the rate and value the result with a price, as two separate steps. Take both readings at the same block. Where possible reconcile on shares and not on balances.

What one stETH is worth in the market and how that relates to the protocol’s own rate is a separate question: how liquid staking tokens are priced covers it.

Which one fits which system

“Should I hold stETH or wstETH” has no answer without the system in mind, so here is the question reframed. A wallet or application that supports rebasing and wants rewards visible as a growing balance fits stETH. A contract, bridge or protocol that needs fixed balances fits wstETH. Because a trustless wrapper converts between them at any moment, the two share liquidity. Moving from one to the other changes the bookkeeping and not the position.

Reading both on ML Data

Each token has its own page: stETH/USD and wstETH/USD are priced separately, each in its own units. The ETH ratio board groups staked ether tokens by whether they rebase or accrue. The liquid staking token hub lists the family together. Each reading carries a block time, so it can be lined up with an on-chain rate call made at the same block. The API page covers programmatic access. How the underlying on-chain measurement works is covered in DEX-native price feeds, explained.

Sources

• Lido Tokens Integration Guide, Lido documentation
• wstETH, Lido documentation
• Lido contract: Rebase, Lido documentation
• AccountingOracle, Lido documentation
• WstETH.sol, tag v4.1.0, lidofinance/core on GitHub
• Deployed contracts, Lido documentation