Wormhole is a Route Choice That Controls Finalization and Token Recovery

Choosing price before the delivered asset

Two output questions prevent the most common Wormhole route mistake: which token contract arrives and who submits the destination transaction after source confirmation.

Wormhole Connect builds its route set after the source chain, source token and destination chain are selected. Read the quoted destination amount beside the delivered asset, not just the familiar ticker. The same USDC input may end as native USDC through Circle Cross-Chain Transfer Protocol (CCTP) or as a Wormhole-wrapped representation through Wrapped Token Transfers (WTT). Those assets use different contracts and may enter different liquidity pools.

Next, identify the execution party. A manual route leaves a claim step for the recipient wallet. An executor route includes destination submission in the quoted service. Native Token Transfers (NTT), the ETH Bridge, the USDT Bridge and tBTC routes add asset-specific mechanics, so the route label should stay with the transfer record.

Network and recipient checks before signing

Three separate identifiers must agree before a Wormhole transfer: the destination chain, the recipient address format and the exact output token contract.

Wallet network identifiers provide a durable cross-check. Ethereum uses EVM chain ID 1, Arbitrum One uses 42161, Base uses 8453, Optimism uses 10 and Avalanche C-Chain uses 43114. Wormhole's internal message identifiers are different: those five networks use Wormhole chain IDs 2, 23, 30, 24 and 6 respectively. A wallet prompt shows the EVM network, while a VAA and Wormholescan show the Wormhole identifier. Mixing those number systems leads to an incorrect diagnosis even when the transaction itself is sound.

An EVM address contains 20 bytes and displays 40 hexadecimal characters after the 0x prefix. A Solana public key contains 32 bytes and uses a different address format. MetaMask must show the intended EVM network before signing, while a Solana destination needs a compatible wallet such as Phantom and the actual Solana recipient key.

Do I need gas on both chains?

Two gas balances are required for a manual Wormhole route, while an executor route normally requires the user to fund only source-chain execution.

The source wallet pays every source action in that chain's native asset: ETH on Ethereum, Arbitrum, Base or Optimism, AVAX on Avalanche and SOL on Solana. A manual transfer then needs destination gas for redemption. Its protocol flow has two chain transactions, one on each side, although a first ERC-20 allowance may add a separate source transaction. An executor route submits the destination leg and includes that execution cost in its signed quote.

Gas drop-off is a separate choice. The route converts part of the transferred asset into the destination's native gas token, leaving the recipient ready for a later transaction. The displayed output changes when that option or the executor quote changes.

Manual, executor and asset-native route mechanics

Two protocol transactions define a manual Wormhole transfer, while an executor route reduces the user's cross-chain signing burden to one source transfer transaction.

WTT locks an original token or burns its Wormhole-wrapped form on the source chain, then mints wrapped tokens or unlocks custody on the destination. CCTP burns native USDC and mints native USDC when both networks support Circle's protocol. NTT follows the token issuer's configured lock-or-burn mode. Each path creates a different destination state even when the interface starts with the same amount field.

Specialized routes narrow the choice further. The ETH Bridge and USDT Bridge use Uniswap liquidity to deliver canonical assets on supported EVM networks, while Threshold's tBTC route combines WTT with Threshold contracts. Mayan routes may include a swap, making minimum received and destination asset fields part of the confirmation decision.

State changes after source confirmation

One confirmed Wormhole source transaction commits the route's lock, burn or transfer instruction, so recovery must continue from that transaction rather than duplicate it.

Source-side commitment

The source wallet may show more than one prompt. Separate the permission step from the transfer step, because their on-chain effects are different and only the latter emits the cross-chain record.

Allowance transaction

An ERC-20 approval changes the allowance granted to a route contract. It neither locks the selected amount nor starts Guardian observation. Existing allowance removes this extra prompt. The wallet may show an unlimited allowance option, although the transfer amount itself remains separately specified.

Bridge transaction

The bridge call performs the economic state change. WTT locks or burns the token, CCTP burns USDC and NTT calls its manager's configured mode. Save the resulting source hash immediately.

Destination-side completion

The destination contract verifies the relevant attestation before changing supply or custody. WTT mints a wrapped representation or unlocks the original asset. CCTP mints native USDC. NTT mints or releases issuer-controlled inventory. A manual user signs that completion; an executor submits it under the accepted quote.

What does finalization actually prove?

Thirteen valid signatures from Wormhole's canonical 19-member Guardian set prove that the required cross-chain observation quorum agreed on the emitted source message.

Every standard Wormhole VAA reaches validity with a 13-of-19 Guardian quorum, including messages whose source chain uses delegated observation. The destination Core contract verifies those signatures and message fields before the application contract processes the payload. Chain finality comes first, so the waiting interval follows the source network's confirmation policy rather than a universal bridge timer.

CCTP needs a separate distinction. Its manual route relies on Circle's attestation and doesn't use Wormhole messaging, while an executor integration may coordinate a Circle attestation with a Wormhole execution message. The selected route determines which proof appears in tracking.

Evidence for each finalization stage

Three records identify a Wormhole transfer end to end: the source transaction hash, the cross-chain message identifier and the destination transaction hash.

For anyone starting out, Wormholescan can locate an operation from the source hash and expose its attestation state. A VAA uses a three-part identity: emitter chain, emitter address and sequence. The emitter address is 32 bytes, the chain field is a 16-bit unsigned integer and the sequence is a 64-bit unsigned integer. Together they identify the message without relying on the wallet's activity list.

• Source confirmed means the initiating chain accepted the route transaction.
• Attested means the required proof is available for destination processing.
• Destination submitted means a user or executor broadcast the final transaction.
• Completed means the destination contract accepted the message and changed token state.

Keep both chain hashes when they exist. A source success alone doesn't prove delivery, while a completed destination hash anchors the final balance change to the intended recipient and token contract.

Worked transfer arithmetic from the quote

Six hypothetical inputs define this Wormhole quote example: 250 USDC, a 0.30 USDC executor fee, a 1 USDC gas drop-off, CCTP, Base and Arbitrum.

The quote selects native USDC from Base, EVM chain ID 8453, to Arbitrum One, EVM chain ID 42161. Subtract the 0.30 USDC execution fee and 1 USDC converted for destination gas from the 250 USDC input. The expected token delivery is therefore 248.70 USDC, plus the quoted native-gas amount sent separately to the recipient. Source gas paid in ETH sits outside this subtraction because the wallet pays it directly.

The arithmetic must use the accepted quote's fields. Executor pricing and gas conversion move with network conditions, and a signed quote carries its own expiry. Refreshing it may change the final output before source submission.

Recovering from the wrong wallet network

Two recoverable Wormhole setup states exist: no source signature means no transfer started, while a confirmed source hash means the route must be resumed.

Before source execution, follow the wallet's network-switch request and recheck the chain identifier. Selecting Base in the interface doesn't switch MetaMask by itself in every wallet state; the confirmation must still show Base chain ID 8453. Rejecting that prompt leaves balances unchanged. Reconnect the wallet, restore the intended source and destination selections and request a fresh quote if the prior one expired.

After source confirmation, don't create a replacement transfer. Copy the source hash, reopen the interface that initiated the route and use its resume or redeem flow. A manual WTT transfer then waits for its VAA and a destination signature. An executor route continues from its recorded request. For CCTP, a nonzero destination caller reserves completion for that named application, so another interface won't be able to claim it. Record the selected route and recipient before closing the status view again.

If the destination transaction already completed, network switching is only a display correction. Select the destination chain and inspect the delivered token contract before treating a missing wallet balance as unfinished execution.

Delivered precision and token-contract checks

Eight decimal places cap WTT transfer precision, so the smallest transferable increment is 0.00000001 token when the native asset exposes at least eight decimals.

WTT rounds an 18-decimal ERC-20 amount down to the nearest eight-decimal transfer unit. Native USDC uses 6 decimal places, so that normalization doesn't remove USDC precision. The destination amount still changes through an executor fee, gas drop-off or an included swap. Compare the quoted base asset, destination contract and displayed units before signing rather than inferring identity from the ticker.

A completed balance belongs to one network and one contract. Native USDC delivered by CCTP and Wormhole-wrapped USDC delivered by WTT aren't interchangeable wallet entries. The destination transaction identifies which contract credited the recipient.

Records that make repeated transfers maintainable

Three saved records make a Wormhole workflow maintainable: the source hash, selected route label and expected destination token contract for each transfer.

Add the destination hash after completion and retain the quoted recipient address. These fields let an operator distinguish waiting for attestation, waiting for manual redemption and a finished transfer that the wallet hasn't displayed. They also preserve the exact path when Connect, Portal Bridge or an embedded integration offers a different route on a later visit. Route availability and executor pricing are evaluated again for every new transfer.

This operating pattern suits users prepared to manage two network contexts and read transaction evidence. Recheck gas, recipient and delivered asset each time, because a new chain pair changes the available route set.