Wormhole bridge support depends on the asset route

A wormhole bridge transfer depends on more than whether the source and destination chains appear on a supported-networks list. The selected asset must have a transfer route between those chains, and that route determines what token arrives and which contracts take part. A pair can support one asset or transfer method while offering no route for another.

That distinction matters because a bridge can move a message without making every token available on every chain. Before sending, identify the source token, the destination chain and the form of the token you expect to receive. Once those are settled, use the wormhole bridge for the transfer; it is a crypto bridge for Wormhole, a cross-chain protocol that moves tokens and messages between Solana, Ethereum and many other blockchains.

How does a Wormhole bridge transfer work?

For Wrapped Token Transfers (WTT), Wormhole’s Token Bridge uses a lock-and-mint flow in one direction and a burn-and-release flow in the other. On the source chain, the Token Bridge contract locks the original asset, or burns a Wormhole-wrapped asset, and emits a message describing the transfer. Wormhole Guardians observe the source-chain event and sign a Verified Action Approval (VAA), the message that can be submitted to the destination chain.

The destination Token Bridge verifies the VAA and completes the corresponding action. If the source asset was locked, it mints the destination chain’s Wormhole-wrapped version. If the source token was already a Wormhole-wrapped asset, it releases the original token from custody on its home chain. The wrapped token represents a claim backed by the locked original; it is not the same contract or asset as the original token.

That mechanism requires more than general messaging support. The relevant Token Bridge contracts must be deployed on both chains, and the destination must have the token representation needed to complete the transfer. For a token not yet represented there, an attestation process establishes its relationship to the source token. A chain pair can therefore be usable for one already-attested asset but not immediately ready for a new token.

Does Wormhole support my chain pair and token?

Check the exact combination of source chain, destination chain, asset and route. A network may support WTT while lacking a relayer route, or support a specialized route for one asset that does not apply to other tokens. A generic list of chains answers only whether a protocol component exists on each network; it does not prove that the selected token can travel between them by the method you want.

• WTT: Both chains need Token Bridge support. The destination asset is generally a Wormhole-wrapped token, unless the transfer returns to the chain where the original is held.
• Automatic WTT: Both chains need the required relayer support, and the relayer must support the selected source token. The relayer submits the destination transaction on the user’s behalf.
• Native USDC: A Circle Cross-Chain Transfer Protocol (CCTP) route applies only when both chains support CCTP and the asset is native Circle-issued USDC. That route burns USDC at the source and mints it at the destination.
• Native Token Transfers (NTT): The token issuer must deploy NTT contracts for the relevant token and chains. NTT is not the same as WTT’s lock-and-mint representation.

Wormhole Connect’s route selection makes this distinction visible by considering the source chain, source token and destination chain together. It can present different methods for the same pair, depending on the asset. Some methods need two transactions: one on the source chain and another on the destination. An automatic route lets a relayer execute the second transaction, but its availability depends on the route and token meeting the relayer’s conditions.

What should I verify before sending?

First, check the route for the exact asset rather than assuming that another token’s successful transfer proves this one will work. Then confirm what the destination representation will be: a Wormhole-wrapped token, native USDC through CCTP, or an issuer-managed NTT token. The distinction affects what you hold after arrival and how that asset can move again.

Also check whether the selected route is manual or automatic. A manual transfer can require a separate destination-chain transaction to redeem the VAA; an automatic transfer delegates that transaction to a relayer when supported. If the destination step is manual, the transfer is not complete just because the source transaction succeeded. Keep the transaction details and follow the transfer until the destination action is confirmed.

The practical rule is simple: treat support as a property of the full route, not just the chain pair. For the broadest compatibility, WTT provides a general wrapped-token path where its Token Bridge contracts and token representation are available. If the asset has a native route such as CCTP or an issuer-configured NTT deployment, that method changes what is minted or released, so verify its conditions before signing.