Four checks before swapping a rebasing token

A pending rebasing-token swap should be checked against four things before signature: the asset being quoted, how its balance changes, whether the route supports that accounting, and which limits protect execution. A rebase changes token balances according to the token’s rules, so the amount shown in a wallet or quote can shift without a normal transfer. That makes a swap different from one involving a conventional fixed-supply token, where a quoted number of units usually stays the same while the transaction waits.

What exactly is the swap quoting?

First, confirm the token, network and unit shown in the quote. A token balance may represent units that can change, while a wrapper or share token may represent a claim whose unit count stays fixed and whose value tracks the underlying asset. Those are different assets for routing and settlement, even when their names are similar.

Read the input and output amounts as quantities of the named tokens, not as a promise about their future value. A positive rebase can increase the number of units in a holder’s balance; it does not by itself guarantee that each unit is worth more. A negative rebase can reduce the count. The quoted output depends on the swap route and its price at execution, while the rebasing mechanism determines the balance represented by the input token.

Check the token contract address against a reliable source for that network, especially if the interface offers several similarly named assets. If the route uses a wrapped version, identify what conversion occurs and whether the wallet must hold the wrapper or the underlying token. For cross-chain routes, also check which asset is expected on the destination chain. The overview of thor swap gives more detail on the single-flow integration context that this distinction can affect.

Can a rebase change the amount while the swap is pending?

Yes: if the token’s rules trigger a rebase before the transaction executes, the holder’s displayed balance may change. Whether that changes the swap depends on how the transaction specifies its input. A fixed quantity of token units remains a fixed quantity in the transaction, even if the wallet’s total balance moves; a share-based representation can behave differently because its unit is designed to track a portion of the underlying asset.

Look for the token’s stated rebase mechanism and any information about when it applies. Some tokens adjust balances through protocol events, while others use a wrapper to keep a stable share count and reflect changes in the underlying exchange rate. Do not assume the rebase schedule, direction or effect on a pending quote unless the token’s documentation explains it.

This is also why a wallet balance and a swap quote can appear to disagree. The wallet reports a balance under the token’s accounting rules; the swap interface estimates an exchange using the route’s supported inputs and current market conditions. Refresh the quote after a balance change, and verify that the transaction still has the intended input amount before signing.

Does the route support rebasing-token accounting?

It must support the token’s balance behavior at each step, including any pool, router, wrapper or bridge involved. Some swap paths assume that a token’s balance changes only through transfers. A rebase can break that assumption: the token balance held by a contract may no longer match the balance it recorded earlier, affecting how much the next step can use or account for.

That does not mean every automated market maker or cross-chain route will fail with every rebasing token. Support depends on the token and the route’s implementation. A wrapper can make a rebasing asset easier for ordinary contracts to handle by presenting fixed share units, but it introduces a conversion step and the risks and costs of that wrapper. A direct route can avoid that conversion but is suitable only if its contracts explicitly handle the asset’s behavior.

Before signing, inspect the route preview for intermediate assets, conversions and destination-chain output. A short route may be easier to understand, but it is not automatically better if it lacks support for the token. A longer route can offer another supported market or wrapper, while adding more contracts, fees and points where execution can stop.

Which execution limits should you check?

Check the minimum output, slippage setting, deadline and transaction status before approving the swap. The minimum output sets a floor for what the transaction will accept; it does not guarantee that the swap will execute. A tighter floor limits price movement but can cause a revert if the market changes, while a looser floor makes execution more likely at a worse price.

For a cross-chain swap, distinguish the source-chain transaction from destination settlement. A source transaction can be accepted while the destination transfer is still processing, and the quoted destination amount may be affected by the route’s fees and execution conditions. Check the interface’s status details and the chain selected for the destination asset before treating the swap as complete.

Use this short checklist at the final review:

• Confirm the token contract, network and quoted unit.
• Refresh the quote after any balance change and recheck the input.
• Verify that the route supports the token directly or through its wrapper.
• Set a minimum output you can accept and check both transaction status and destination asset.

The main trade-off is between simplicity and compatibility. A direct swap has fewer conversion steps, but only works cleanly when the route accounts for rebases. A wrapper can give the route more predictable units, at the cost of an extra dependency. The next useful signals are whether the token’s balance changes before execution, whether the route documents support for that token or wrapper, and whether the final quote remains within the limits you set.