Wormhole bridge has six main paths: Wrapped Token Transfers for broad token coverage, CCTP for native USDC, Native Token Transfers for issuer-managed assets, asset-specific routes for canonical output, Settlement for a quoted outcome, and Messaging for data without a token transfer. The deciding question is what the receiving app must get: a wrapped token, a native token, a specified output asset, or an instruction.
- Wrapped Token Transfers: Best for a supported token when the destination accepts its Wormhole-wrapped form; unsuitable when the app requires a canonical token.
- CCTP: Best for native USDC between CCTP-enabled chains; unsuitable for other assets or unsupported chain pairs.
- Native Token Transfers: Best for tokens whose issuer has deployed the framework across both chains; unsuitable for an arbitrary token without that setup.
- Asset-specific routes: Best when a supported route delivers canonical ETH, wETH, wstETH, or USDT; unsuitable outside its listed assets and chains.
- Settlement: Best when the required outcome includes a swap or a specified minimum received; unsuitable when the app needs a particular bridge representation.
- Messaging: Best for a cross-chain contract instruction without moving a token; unsuitable as a token transfer by itself.
For a live task, pin down the source chain and token contract, destination chain and recipient, then check the exact asset the receiving app accepts. Once those details are set, Wormhole bridge moves the token or message between connected chains, including Solana and Ethereum. If you bridge tokens with Wormhole, retain the source transaction hash until the destination action is complete.
Which Wormhole bridge route works for an ordinary token?
Wrapped Token Transfers (WTT), called Token Bridge in the SDK and contracts, is the general route for supported fungible tokens. It locks an original token on its home chain and mints a Wormhole-wrapped representation elsewhere; on the return trip, it burns that representation and releases the original. Use it when the receiving app recognizes the wrapped token’s contract address, rather than merely its symbol.
Suppose you hold 0.5 ETH on Ethereum and need the Wormhole-wrapped ETH accepted by an app on Solana. The source transfer locks the asset and emits a message; Guardians observe it, and a supermajority of 13 of 19 signs a Verified Action Approval (VAA). Submitting that VAA on Solana verifies the transfer and mints the wrapped asset to the specified recipient. This is why a confirmed source transaction alone does not mean the recipient has been paid.
Before sending, verify that both chains support WTT for the asset and that its metadata has been attested on the destination; a first transfer may require that registration. WTT normalizes transfer amounts to eight decimal places, so an amount with finer precision can lose dust beyond the eighth decimal. Manual redemption needs a destination transaction and gas there; an available automatic relayer submits it for a quoted fee. If delivery stalls after a valid VAA exists, inspect redemption status before initiating another transfer.
When should native USDC use CCTP?
CCTP fits when both chains support it and the input is native, issuer-issued USDC. The source USDC is burned and an equivalent amount minted on the destination after attestation, so the recipient gets native USDC rather than Wormhole-wrapped USDC. That distinction decides the route when a destination app checks the USDC contract address.
For example, moving 250 native USDC from Ethereum to a CCTP-enabled destination involves a source burn, an attestation and a destination mint. Automatic delivery pays a relayer to finish the destination action; manual delivery leaves that transaction and its gas to you. Check both chain support and the source token contract first: a token labelled “USDC” may be a bridged representation, and sending it through WTT produces a different destination asset.
When do Native Token Transfers fit?
Native Token Transfers (NTT) fit a token whose issuer has deployed and connected NTT managers on the relevant chains. The managers burn or lock on the source, pass an attested message through their configured transceivers, then mint or unlock the issuer’s token on the destination. The issuer retains control of token contracts and can configure peers, access controls and transfer limits.
For a holder, that setup is a prerequisite, not an option to turn on for any ERC-20 or SPL token. An NTT transfer can queue when it exceeds available outbound rate-limit capacity, or fail if queueing is disabled. If your receiving app requires the issuer’s native deployment, verify its contract and the specific NTT route before comparing delivery time or fees with WTT.
When do asset-specific routes preserve the target token?
Asset-specific routes fit supported chain pairs where the destination must receive a canonical asset such as ETH or USDT. The ETH and USDT bridge routes use liquidity and destination execution to deliver the designated asset instead of leaving the user with its ordinary WTT representation. Their narrower asset and chain coverage is the trade-off for that output.
Read the route’s quoted output token, minimum received and total cost before committing. Liquidity-based execution can introduce price impact alongside source gas and relayer costs, especially for a large amount relative to available liquidity. Chain presence in Wormhole’s network is insufficient: route availability also depends on the asset, both endpoints and current integration support.
When is Settlement the right route?
Settlement fits when the task is defined by an outcome, such as sending one token and receiving another on a different chain. A solver accepts a quoted intent, supplies destination liquidity and settles the cross-chain obligation using Wormhole messages. This can remove a separate swap from your workflow, but it makes the quoted minimum output more useful than comparing bridge fees alone.
Check the destination token contract, minimum received, quote expiry and any fallback terms against what the app needs. A fast quote may depend on solver inventory and available liquidity, while another path may wait for chain finality. Settlement does not fit if your app specifically needs a WTT-wrapped token or an issuer’s NTT token and the quote delivers something else.
When should an app send a message instead of tokens?
Wormhole Messaging fits when the destination contract needs verified data or an instruction, with no asset transfer required. A source contract publishes a payload, Guardians sign its VAA, and a relayer or caller submits it to the destination contract for verification and execution. The destination contract must check the expected source chain and emitter and prevent replay before acting on the payload.
Delivery takes a source transaction, Guardian attestation and destination execution, so budget for gas and any quoted relay charge. A stronger finality setting waits longer before Guardians sign, while a faster setting accepts more reorganization risk; destination execution can also fail even when the VAA is valid. Your next step is to confirm the exact destination asset or contract action, then choose the matching Wormhole bridge route and check its live quote and completion status.