Bridge Swaps Can Account for Transfer Taxes on Stuck Funds

On chains where tokens deduct a fee during transfers, a bridge swap can fail when its contract receives less than the amount the transaction specifies. Bridge designs can address that mismatch by calculating the swap input from the tokens actually received.

That accounting can turn some transfers that would otherwise revert into executable swaps, while making the net amount and minimum output explicit.

Why do transfer taxes leave bridge swaps stuck?

A transfer-tax token changes the amount delivered between addresses: a sender’s balance falls by the nominal transfer, but the recipient’s balance rises by less. A bridge call that assumes those amounts match may try to swap or escrow tokens it does not hold. The result can be a revert, or a transfer that reaches an intermediate contract but cannot proceed through the expected route.

The mismatch can happen at more than one step. A tax may apply when tokens move from the user to the bridge, when the bridge sends them to a swap contract, or when the destination contract delivers them. A quote based on the wallet’s starting amount therefore does not necessarily describe the amount available to trade or the amount the recipient will receive.

For the routing context, see how QuickSwap routes cross-chain swaps. The same integration question applies here: each contract in the route needs to account for what arrived at its address, not only what an earlier call intended to send.

How can a bridge swap use the amount received?

A contract can measure its token balance before and after a transfer, then use the difference as the input amount. If the bridge had 20 tokens before and has 119 afterward, it treats 99 as the new deposit, regardless of the nominal transfer amount. A balance-based input avoids trying to spend the portion removed by the transfer tax.

This method changes the accounting, not the token’s rules. The bridge still needs to pass an amount the swap route can handle, and the route must apply its own minimum-output check. A user should be shown the expected net input and the minimum destination amount, with slippage covering market movement and any supported transfer deductions. The fee is not a bridge fee unless the bridge itself charges it; it is imposed by the token’s transfer logic.

What should integrators check before supporting taxed tokens?

Support depends on where the tax is applied and whether it can change. Integrators should test the actual token contract and route, including source deposit, any intermediate swap, and destination delivery. They should also distinguish a transfer tax from a bridge’s own fee and from swap price impact, since each reduces the final amount through a different mechanism.

• Read the balance delta at each transfer boundary instead of assuming the requested amount arrived.
• Set minimum received and minimum output values that users can review before signing.
• Check whether the token can alter its tax, exempt selected addresses, or impose transfer limits.
• Record the amount actually received so failed downstream calls can be investigated and recovery rules can use verifiable balances.

Can balance-based swaps recover every stuck transfer?

No. They can address a shortfall caused by a transfer tax when the tokens are already held in a contract that can safely route them. They cannot make an unsupported token tradable, reverse a completed transfer, or guarantee that destination delivery will succeed. For existing stuck funds, recovery depends on the bridge’s deployed contracts and authorization rules; a new balance-based path does not automatically change an older transaction.

For most integrators, the better default is to reject taxed tokens unless the full route has been tested and the net amounts are visible to users. Where support is deliberate, balance-delta accounting plus explicit minimums gives the swap a measurable input and the user a defined floor for delivery.