A rebasing staking token can update your token balance without sending a separate reward payment to your address. The token calculates balances from its accounting state, rather than requiring a transfer for every update. First identify whether you hold the rebasing token or a non-rebasing wrapper; their wallet numbers can behave differently.
Three numbers that a wallet can display
Do not use token quantity, protocol accounting value and market value as if they were the same measure. The token quantity is what a balance query reports. A protocol conversion can express what that position represents in another unit. A wallet's currency estimate usually introduces a market price as well. Any of these can move without the other two moving in the same way.
Ethereum's pooled-staking overview describes receipt tokens issued by some staking services and the additional third-party risks involved. It does not prescribe one accounting model for every token. This article uses Lido's stETH and wstETH as documented examples, not as a recommendation to stake or an assertion that all liquid staking tokens work alike.
| Measure being checked | Rebasing token example | Non-rebasing wrapper example |
|---|---|---|
| Token quantity | Can change when protocol accounting rebases balances | Does not change merely because the underlying token rebases |
| Underlying accounting relationship | Balance reflects the holder's share of accounted backing | Each wrapper unit can represent a changing underlying quantity |
| Transfer history | May contain no incoming reward transfer for a rebase | Still records actual wrapper transfers, not a payment for every rate update |
| Market estimate | Depends on quoted market price as well as quantity | Depends on wrapper quantity and quoted price |
| Support question | Why did balance change with no transfer? | Why is token count flat while the underlying rate changed? |
Why a rebase need not create an incoming transaction
Lido's stETH contract reference describes share-based accounting and dynamic balances. A holder's position can be recalculated when protocol accounting changes, while that holder's shares remain unchanged by the rebase itself. You should therefore inspect balance state as well as the list of token transfers.
The integration guide specifically notes that stETH does not emit a Transfer event for each holder on a rebase. A transfer-only history can consequently fail to explain a balance change on its own. That gap is not automatically a missing transaction, a hidden sender or evidence that someone accessed your wallet.
A historical stETH mechanics explanation makes the same distinction between a rebase and a payment to the holder. Use current contract and integration documentation for the present mechanism. Do not turn an old article's clock time or reward description into a promise that every future report arrives at that minute.
A fictional reconciliation with no new sender
Consider a simplified fictional pool, not a quotation of current Lido contract calculations. A holder owns 10 shares out of 1,000 total shares. The accounted backing is 1,000 token-equivalent units, so the position displays 10 units. Later the backing becomes 1,002 with the same total shares. The same 10 shares now represent 10.02 units.
No new sender is needed in this simplified example. The position changed because the conversion from shares to displayed units changed. If the accounted backing instead decreased, the calculation would go in the other direction. Real protocols include their own fees, deposits, withdrawals and accounting rules, so this arithmetic explains the model without providing a production accounting formula.
| Fictional snapshot | Holder shares | Total shares | Accounted backing | Displayed position |
|---|---|---|---|---|
| Before the update | 10 | 1,000 | 1,000 | 10 |
| After the illustrative increase | 10 | 1,000 | 1,002 | 10.02 |
| What changed | No change | No change | Increase of 2 | Increase of 0.02 |
The current stETH help page identifies the token as rebasing. That is not a guaranteed positive return. The integration documentation discusses possible decreases from penalties or slashing and explains that reporting can be delayed. A flat balance at an expected time needs verification of the report and wallet state, rather than an immediate conclusion that rewards were stolen.
Why wstETH can stay flat while stETH does not
The wstETH contract documentation describes a non-rebasing wrapper: the holder's wrapper balance does not change with each oracle report, while the amount of stETH represented by it can change. A count of 5 wrapper tokens can remain 5 even as the conversion into underlying units changes. That is different bookkeeping, not by itself a failure to accrue.
Do not assume one wrapper unit equals one underlying token. Check the current protocol conversion and exact token contract. Also distinguish wrapping from a market trade: a protocol conversion relationship is not a guarantee that a quoted exchange price, payout amount or immediate redemption proceeds will match a headline ratio.
Bridged representations introduce another question. The wstETH documentation notes that rebases do not automatically work for bridged assets by default. A ticker or logo on another chain is not enough to apply Ethereum stETH's exact balance behaviour. Identify the bridge, representation and receiving application's accounting before reconciling that position.
Reconcile the wallet and receiving platform using the same units
- Confirm the chain and token contract. Separate stETH, wstETH and any bridged representation rather than relying on a display symbol.
- Record the balance at a specified block or other consistent snapshot. A present balance is not the historical balance at deposit time.
- Check actual transfers, minting, burning and wrapping activity over the interval. Do not attribute every change to a rebase.
- For a rebasing position, inspect the relevant accounting update. For a wrapper, compare its underlying conversion at the same snapshot.
- If a platform received the token, ask how it records rebases and conversion units. Do not assume its internal ledger mirrors a self-custody balance query.
- Provide support the contract, network, transaction hash if relevant, snapshots and the units being compared. Do not invent a reward transaction hash.
Small differences can also arise from integer conversion and display precision. The integration guide documents rounding when amounts are converted into and out of shares. A tiny discrepancy should be measured in base units before it is labelled a missing reward. Conversely, a large unexplained movement should not be dismissed as rounding just because the token rebases.
For the broader distinction between an asset and its representation, see wrapped tokens explained. Keep the underlying native asset separate with the ETH page. If you later use a no-account swap, check the actual asset, network and quoted amount in the order; this accounting example does not establish that a particular staking token or wrapper is supported by that order.
FAQ
What does a rebasing token mean for my staking balance?
Its displayed token balance can be recalculated through protocol accounting without an incoming transfer for each holder. The exact rules depend on the token, so identify the contract and accounting model first.
How do rebasing tokens change balance without a transfer?
In a share-based design, unchanged shares can represent a different quantity after the accounted backing changes. stETH documentation explains that its rebases do not emit a Transfer event for every holder.
Is a non-rebasing staking token missing its rewards?
Not necessarily, because a wrapper can keep the same token quantity while its underlying conversion changes. Compare the protocol rate and token units before looking for a separate reward payment.