How rebasing tokens keep rewards attached across bridges

A rebasing token changes holder balances to distribute rewards, but a standard bridge can leave those rewards in its escrow contract. The issue is where the token’s balance changes: on the source chain, while the bridged representation on the destination chain may have fixed balances. A bridge must account for that change or carry a representation whose value updates without changing its balance.

A bridge commonly locks tokens on one chain and mints a corresponding token on another. For a Polygon Bridge overview and transfer walkthrough, see this guide to moving tokens through Polygon Bridge. The key question for rebasing assets is whether the source escrow and destination token share the same reward accounting.

Why can a standard bridge strand rebasing rewards?

Rewards can accrue to the bridge’s escrow rather than to the user’s destination-chain balance. In a rebasing token such as stETH, a holder’s balance changes when the protocol reports an updated amount. If the bridge locks stETH on the source chain and mints a fixed-balance token elsewhere, the escrow may receive the rebase while the destination token does not. The user still holds the bridged token, but its balance no longer reflects the original token’s reward changes.

This is a mismatch between two accounting models. A conventional ERC-20 balance changes through transfers, minting, or burning. A rebasing token can also change a holder’s balance through a rebase, without a transfer. Systems that track only transfers may miss that change.

How does wrapping keep rewards attached?

A wrapper converts a rebasing balance into a fixed balance that represents a share of the underlying token. With stETH and wstETH, the wstETH balance stays constant while its exchange value in stETH rises as rewards accrue. A user can bridge this non-rebasing representation through a standard token flow, then unwrap it where the underlying asset is supported.

The trade-off is usability. The destination token may not be directly redeemable for stETH on that chain, and users may need a local wrapper contract or a return bridge to unwrap. The wrapper preserves the economic claim through its conversion rate; it does not make the destination token’s displayed balance rebase.

Can a bridge support the rebase directly?

Yes, but the bridge must coordinate token accounting across both chains. A dedicated design can send the underlying token’s rate or rebase information to a destination oracle, then use that data to update the bridged token’s balance or conversion rate. Lido’s cross-chain design guidance describes dedicated bridge endpoints, a destination token, and rate updates for supported stETH flows.

That design keeps a rebasing representation available on the destination chain, but it adds contracts and cross-chain messages that must stay in sync. If rate updates are delayed or the destination token applies them incorrectly, displayed balances can diverge from the intended value. Bridge operators and integrators need to understand which contract supplies the rate and how the destination token applies it.

Which representation should users choose?

For most users, a supported non-rebasing wrapper is the simpler choice. It fits bridge flows that expect balances to change only when tokens move, while preserving rewards through an exchange rate. A direct rebasing representation is appropriate when the bridge explicitly supports rebase data and the destination applications understand that accounting.

• Check the exact token contract on both chains; matching names or symbols do not prove matching accounting.
• Confirm whether the destination representation rebases or accrues value through a rate.
• Check where and how the destination token can be unwrapped.
• For direct rebasing support, verify that the bridge updates the destination rate and identifies its source.

The practical test is whether the destination balance itself changes with rewards or whether each token’s redeemable value changes instead. Choose a route whose accounting model is explicit, so rewards remain attached to the holder rather than accumulating in bridge escrow.