Rebasing tokens can invalidate cached balances

A rebasing token's displayed balance can change without an ordinary transfer into the wallet. An event-only balance cache can therefore drift from the token contract's current balanceOf result.

Lido's contract documentation explains stETH's relationship between shares and pooled ether. It provides a concrete example of why a token's accounting model can differ from a fixed quantity ledger. Do not generalize its exact mechanics to every rebasing asset.

Revalidate before spending

Read the current balance near the execution boundary, especially after a long review or approval delay. A Max amount captured earlier may no longer equal the spendable balance. If the amount changes, obtain a new compatible quote and update the review.

Allowance and balance are separate. A sufficient allowance does not guarantee the account still holds the requested units. Keep both checks tied to the actual owner and current chain context.

Reconciliation needs token-aware evidence

A simple before-minus-after calculation can mix swap movement with a rebase occurring between reads. When exact accounting matters, use the token's documented shares or conversion model and the relevant transaction context. Record the method used rather than calling every balance difference a trade fill.

Wrapped non-rebasing representations may offer different accounting behavior, but wrapping is a separate action with its own contract and route. The application must not substitute the wrapper silently.

Fixture cases

Simulate a balance change without a Transfer event and verify that a fresh read updates the form. Include a decreasing balance before submission and a rebase between reconciliation snapshots. Those cases test cache assumptions directly, without claiming that a particular token will rebase in a particular direction or at a fixed time.