Lido stETH balances rebase without incoming transfers when oracle reports update accounting

Updated · 2026 Oct 7

Lido stETH reflects staking rewards and losses through balance rebases that do not create incoming token transfers. The protocol recalculates balances when it applies an oracle report, using each address’s underlying shares. That makes transaction history alone an incomplete record of staking returns, even when the wallet shows a higher balance.

Shares connect balances, transfers and staking exposure

stETH combines transferable staking exposure with balance accounting that follows the ETH recorded by the protocol. Its share system connects those functions. Each address holds an underlying number of shares, and the contract converts them into the displayed token amount. An address’s stETH balance equals its shares multiplied by total pooled ETH and divided by total shares. A rebase can change a holder’s displayed balance without changing that holder’s shares.

Transfers move shares between addresses, whereas a staking deposit creates additional shares and corresponding stETH. A rising balance therefore needs interpretation: it might reflect a rebase, an incoming transfer or newly minted tokens. The token’s transfer functions make the staking exposure usable elsewhere, including applications that explicitly support rebasing. Once another contract holds the stETH, that application’s accounting determines how its users receive the benefit. A growing contract balance alone does not establish what a depositor can withdraw.

When does an stETH rebase reach a wallet?

An stETH rebase reaches the on-chain balance when the protocol applies its accounting report, normally on a daily cycle. AccountingOracle gathers the information, and Accounting applies the resulting changes. The report needs agreement among oracle participants and must pass validation. Ethereum finality supplies another dependency because the reporting process uses finalized data. A delay in finality, failure to reach agreement or rejected report can prevent the expected update. Opening a wallet at a particular hour does not trigger the process.

The report’s reference point and its application time describe different moments. A late report still accounts for its designated reporting period. If a reporting period is missed, a later report can cover a longer interval. These conditions make a fixed daily payment time an unreliable assumption. They also affect comparisons with annualized return figures: a larger update after a reporting gap may cover more elapsed time. The gap alone does not establish that validator earnings stopped or that the eventual balance change will be positive.

The chain records a delayed balance update at the block where the protocol actually applies the report.

Separate the rebase amount from staking performance

Growth from a rebase reflects the net accounting outcome after protocol reward fees. The protocol collects its reward fee by minting shares to fee recipients. That changes the denominator that converts shares into stETH, alongside changes in accounted ETH. The fee is a share of staking rewards; governance can change its configuration. Applying another assumed fee deduction to an already rebased wallet balance would misstate that balance.

Validator rewards and penalties contribute to the same accounting period, so earnings can offset losses before the holder sees an update. A negative net change can reduce stETH balances when the protocol recognizes losses. A positive change does not establish that every validator performed without penalties. Deposits and withdrawals also change aggregate accounting, which makes total token supply growth unsuitable as a standalone measure of staking income. Tracking the change in ETH represented by each share separates holder returns from expansion or contraction of the overall token supply.

Match contract balances across the same rebase

Historical contract balances provide information that a transfer-only export leaves out. An stETH rebase does not emit a Transfer event for each holder’s balance change. The protocol records a TokenRebased event for the accounting update instead. For an address, balanceOf gives the token amount and sharesOf gives its underlying shares. These readings need matching block references. Combining an earlier share count with a later balance can confuse a transfer with a rebase, particularly when both happen within the chosen reporting interval.

Does a higher stETH balance mean more spendable ETH?

A higher stETH balance increases the token amount held, while spendable ETH depends on the chosen exit and its conditions.

A market sale uses the available exchange rate and trading liquidity, which can value stETH differently from its protocol accounting. The sale’s actual output and any separately charged transaction costs determine what the holder retains. The protocol withdrawal queue provides another path, with finalization and claiming required before ETH reaches the recipient. Tokens committed to that queue do not earn additional staking rewards for the requester while they wait. The ETH claim is capped at the stETH amount submitted and can be reduced by losses before finalization. Keeping a growing stETH balance, completing a sale and claiming ETH from a finalized withdrawal are therefore different states. A rebase alone completes neither exit.

How does wstETH change reward tracking?

wstETH reward tracking follows the amount of stETH represented by the wrapped balance. A wstETH balance does not rebase when an oracle report updates stETH accounting. Rebases alter the underlying stETH that the wrapper holds, which changes the amount represented by each wstETH. A comparison also needs the same wrapped holdings on both sides; purchases or transfers change the position independently of the conversion rate.

Open full-size image

Wrapping accepts a specified stETH amount and issues wstETH; unwrapping burns wstETH and returns the corresponding stETH. The wrapper’s getStETHByWstETH function supplies that conversion for a given wrapped balance. This conversion measures token representation, separate from the market rate available when selling. Unwrapping returns stETH, so obtaining native ETH still requires an applicable exit.

The stable token count suits applications whose accounting expects balances to change only through transfers, minting or burning. Direct stETH integrations can instead use share accounting to handle rebases explicitly. A lower stETH-per-share rate reduces what a wrapped position represents, even though its wstETH count stays unchanged.