Why a bridge may block a token transfer

A bridge destination can reject a transfer when the bridge cannot deliver that token there, or when its route rules do not allow the amount or transaction. A chain being available does not mean every token can move to it. Each transfer depends on a specific combination of source chain, destination chain, token and bridge.

Why does a bridge support some tokens but not others?

A bridge must have a way to create or release the right token on the destination chain. Some systems lock tokens on one chain and mint a matching version on another; others use pools of tokens already held on each chain. Either way, the bridge needs contracts and a token mapping for that route.

That is why a token with the same name or ticker on two chains may still be a different asset. Its contract address can differ, and a bridge may not treat the two versions as interchangeable. Across’s route documentation, for example, specifies both the source and destination token addresses. A guide to how ParaSwap bridges and swaps across chains covers more of the process. The key point is that a bridge needs a supported route for the exact token pair.

Why can a destination chain be available but a route unavailable?

A bridge may connect to a chain without supporting every token pair on it. The destination token contract must be deployed or otherwise reachable by the bridge, and the bridge’s software must know how to handle it. If either side is missing, the route may not appear in a quote.

The destination token may also have rules of its own. A token contract can pause transfers or block certain addresses. In that case, the bridge may be able to submit a transaction, but the token’s rules can prevent delivery to the recipient.

Why do bridges set amount limits?

A route may only handle transfers within set limits because it needs enough destination-side funds or capacity to complete them. In a pool-based bridge, a small pool can limit how much can be delivered at once. A route may also set minimums, maximums or fees that change what amount it will accept. Across’s documentation describes route support in terms of the chain pair and tokens, with limits and fees available for individual routes.

• Check both chain names and the token on each chain.
• Compare the token’s contract address, not just its ticker.
• Check the route’s minimum, maximum and quoted output.
• Confirm the recipient address can receive that token on the destination.

What should you check before sending?

Get a fresh quote for the exact route and amount before signing. The quote can show whether the bridge currently accepts that pair and what it expects to deliver. If the route is missing, try a supported token pair or a different amount only after checking the bridge’s route details. Do not send tokens to a bridge address based on a similar ticker or an old route.

The practical rule is simple: check the full route, not just the destination chain. A bridge can deliver only what its contracts, token support and available capacity allow.