An unsupported token contract is a token the swap protocol has not integrated into its routes. The key condition is the exact asset identity on the exact chain: a familiar ticker or a working transfer does not make a token interchangeable with another token that shares its name.
A token’s name does not identify its contract
On Ethereum, an ERC-20 contract keeps track of balances and defines how its tokens transfer. Two contracts can both call their token “USDT” yet represent different assets, with separate balances and rules. On Solana, the corresponding identity is the token mint, and token accounts hold balances for that mint.
For a route to accept a token, its systems need to recognize that specific contract or mint as an asset. They also need to handle its units correctly: for example, Chainflip’s documentation lists BSC USDT with 18 decimals, while USDT on several other supported chains has 6. A ticker alone cannot safely determine how much value arrived.
Routes need working deposit and payout handling
A cross-chain swap has to recognize the incoming deposit, account for the amount, trade it against available liquidity, then send the requested asset to the destination chain. Each stage needs to support the token’s chain-specific behavior. A token that taxes transfers, can freeze balances, or uses nonstandard transfer logic may not behave as the route expects.
That integration also requires a way to custody and move the asset safely. For a Solana token, for example, the vault must be able to manage the relevant token accounts and sign the necessary transactions. Chainflip’s official documentation describes support for selected SPL tokens as well as SOL; Ethereum.org explains how ERC-20 contracts define token operations.
Consider someone who holds a community token on Ethereum and wants SOL. Even if the token appears in a wallet and transfers normally, a route cannot infer from its name which contract to monitor or how to value and deliver it. If a supported USDC-to-SOL route is available, how Chainflip swaps BTC for ETH or SOL explains the separate native-asset example; the same route logic depends on each asset being explicitly identified and handled.
Unsupported deposits can be difficult to recover
A token might technically be sent to an address associated with a swap, but that does not mean the protocol will recognize it as the expected deposit or process it as part of the route. Recovery depends on the chain, address, token behavior, and available tools, so sending an unsupported token can leave funds stranded or require manual intervention.
Before sending, check the asset by chain and contract or mint against the protocol’s current supported-asset information; do not rely on the ticker shown in a wallet. Chainflip lists both the chain and asset for supported routes, including individual token variants. If your exact asset is absent, use a route that accepts it through another supported method, or first exchange it for an asset the route recognizes.