When a Bridge Rejects a Token Version, Check Both Chains

Across Protocol’s documentation says a token must be supported on both chains to bridge through its route, so a rejection can mean the token’s chain-specific version is unsupported. Check the accepted asset on each network before sending; a matching ticker or name does not establish that two token contracts are equivalent.

For the transfer steps, see this guide to the AcrossBridge route between crypto chains. Across documentation lists supported tokens by chain, which helps distinguish an asset that is available on one network from one the route accepts on both.

Why does a bridge reject a token version?

A token’s ticker can appear on multiple chains while each version has a different contract address or mint. Across Protocol’s supported-token list is chain-specific, and Wormhole’s documentation describes wrapped transfers as minting a wrapped representation on the destination chain.

That destination representation may not be the same contract as the original asset, even if a wallet displays a familiar name. A bridge may also reject an asset because it has not been registered or enabled for that particular route; the rejection alone does not prove the token is counterfeit.

How can you check which version the route accepts?

Use the bridge’s supported-asset list and compare the network and token contract, not just the ticker. Check addresses against the token project’s official channels or the relevant chain explorer, and confirm the destination asset and recipient network before approving a transaction.

• Confirm the source network and exact token contract.
• Check that the route supports that asset on both networks.
• Confirm what token representation the destination will receive.
• Review the recipient address, fees and displayed amount before signing.

Wormhole’s documentation explains that wrapped token transfers lock tokens on the source chain and mint a wrapped representation on the destination; its native-token transfer model instead supports project-controlled token contracts across chains. These are different transfer designs, so a route that supports one version or model may not accept another.

What is the safer route if the version is unsupported?

Use a route that explicitly supports the exact source and destination assets, or swap on the source chain into an asset that the chosen route lists on both networks. Check the swap output and bridge quote before signing; a two-step route adds a transaction and may add fees or price impact, but it makes the asset conversion explicit.

Do not send tokens directly to a bridge contract to bypass a rejection. The next step is to confirm the supported pair and route in the bridge interface; whether a particular token version will be added remains unconfirmed unless the bridge operator publishes that support.