Fee-on-Transfer Tokens Need Balance-Based Bridge Accounting

Bridge a fee-on-transfer token only through a route that measures the amount actually received and pays out against that amount. A standard ERC-20 transfer can deliver less than its stated amount because the token diverts a portion to a fee, burn address or treasury. That breaks the usual bridge assumption: the amount requested is the amount delivered. Compared with a regular token, a taxed token needs accounting at every transfer, not just a correct transaction quote.

That difference matters on both sides of a bridge. If a bridge issues destination tokens based on the amount a user tried to send, it can promise more than it received. If it pays out a requested amount, the destination transfer tax may leave the recipient short. A swap before bridging can avoid those mechanics when it converts the token into a standard asset, but adds swap fees, price movement and liquidity risk. A direct bridge route can preserve the token, if its contracts explicitly handle the token’s transfer behavior.

Why can a fee-on-transfer token break a bridge?

A fee-on-transfer token can make the requested amount differ from the amount that reaches the bridge contract. Many bridge designs start with a nominal amount: the user calls a deposit function with a number, and the bridge locks or burns that number before a corresponding claim is created on another chain. With a taxed token, the bridge may receive less than the number in the call. If the destination claim still reflects the full number, the bridge’s backing and its obligations no longer match.

The same mismatch can happen on the way out. A bridge may hold enough tokens to cover a claim, yet the token’s transfer tax reduces what the user receives. This is separate from a bridge fee or a swap’s price impact. A displayed “amount out” is useful only if it reflects the token’s actual behavior at the payout address.

Some routes fail cleanly because a contract checks its balance or the token’s transfer reverts. Others may complete while delivering less than expected. For a closer look at the swap-and-bridge path, Paraswap’s guide to moving crypto across chains with a swap covers the route’s broader mechanics. The key question for a taxed token is whether the bridge measures each transfer’s result, not just whether the interface lists the token.

How should a bridge account for the actual amount?

A bridge should base deposits on the balance change it observes, then make its destination claim from that received amount. For an ERC-20 deposit, the contract can record its token balance before the transfer, request the transfer, and compare the balance afterward. The difference is the amount actually received. This approach addresses the inbound tax; the bridge still needs explicit logic for outbound taxes and for any token rules that can change over time.

At payout, a route should define whether the destination amount means the bridge’s debit or the recipient’s net receipt. These are not always equal. A bridge that promises a net amount needs to account for the transfer tax, or use a token-specific process that verifies the recipient’s balance change. If it cannot guarantee a net amount, its interface should state that the recipient may receive less.

This accounting is different from ordinary slippage protection. A minimum-received condition can protect a user from getting less than a threshold, but it does not fix a bridge that credits more than it holds. Balance-based accounting protects the bridge’s solvency; a clear minimum output protects the user’s expected delivery. A route needs both where the token’s mechanics affect both sides.

These checks also need to match the actual token contract and chain. A token with the same name or ticker may be a different asset, and a tax can vary by transaction type or be changed by an administrator. A route that worked for a small transfer may behave differently when limits, exemptions or fee settings apply.

Which route is safer: direct bridging, wrapping or swapping?

A direct bridge route is the simplest when the bridge explicitly supports the token and measures real balance changes. It avoids an extra swap and its market-price exposure. Its trade-off is narrower support: a token can be technically transferable and still be incompatible with a bridge’s accounting or payout process.

Wrapping can make a non-standard token easier for other contracts to handle by exchanging it for a wrapper with more predictable transfer behavior. It adds another contract and a dependency on how the wrapper is backed and redeemed. The wrapper’s market value may also differ from the original token’s value. It is useful only when the wrapper is recognized by the route and its redemption terms are clear.

Swapping into a standard asset before bridging can reduce transfer-tax surprises if the output token has conventional transfer behavior and the bridge supports it. In return, the user pays for the swap and may face price impact or thin liquidity. Paraswap can be part of a swap-first comparison, but an aggregator quote does not establish that the bridge will accept or safely account for the resulting asset. Check each leg separately.

For most users, the better choice is the supported route with clear net-received terms, even if it adds a visible fee. A cheaper quote that assumes the nominal transfer equals the received transfer can hide a shortfall. Before signing, check:

• The token’s exact contract address on the source and destination chains.
• Whether the bridge names the token as supported, including its fee-on-transfer behavior.
• Whether the quoted destination amount is gross or net of token and bridge fees.
• Whether the route sets a minimum received amount and shows the spender and approval amount.

For a new route, a small transfer can reveal basic compatibility, but it does not prove that future transfers will use the same tax or limits. Avoid granting a larger allowance than needed where the wallet or route permits a smaller one. Do not raise slippage simply to force a transaction through: that changes the amount you are willing to accept, not the bridge’s accounting.

What should users watch before sending?

Watch for support wording that distinguishes “token accepted” from “fee-on-transfer supported,” and compare the quoted output with the recipient’s likely net amount. Check whether the token’s fee can change, whether the bridge or token has transfer limits, and whether the destination chain has a compatible version of the same asset. A quoted route is an estimate; the contracts’ actual behavior determines what is locked, minted or paid out.

The practical test is straightforward: the bridge should account for what it receives and explain what the recipient will get. If support, accounting or net output is unclear, swapping into a supported standard asset may be easier to assess, though it carries its own execution costs. The signals worth watching are updated token support, changes to transfer fees or limits, and a persistent gap between quoted output and observed recipient balances.