Wormhole bridge moves tokens or authenticated messages among Solana, Ethereum, Arbitrum, and other connected blockchains. For Wormhole cross-chain transfers, choose by destination result: wrapped asset, issuer-controlled native token, or application payload. Once the route is available on both chains, use Wormhole bridge to send the selected token or message.
Wrapped Token Transfers (WTT), called Token Bridge in the SDK, suits fungible assets whose destination form may be wrapped. The source bridge locks a native token and the destination mints its counterpart; returning home burns the wrapped token and releases the original. It does not fit an app that requires the issuer’s own destination contract.
Check WTT support on both chains, identify the token by origin chain and address, and query its destination wrapped address. A new route needs an AssetMeta attestation and destination registration before transfer. Wormhole chain IDs differ from EVM chain IDs: Solana is 1, Ethereum 2, and Arbitrum 23. Symbols alone cannot identify the destination asset.
The Wormhole token bridge flow is source transfer, Guardian observation, signed Verified Action Approval (VAA), and redemption. A 13-of-19 Guardian Network quorum signs the VAA, which the destination bridge verifies before minting or releasing funds. Track emitter chain, 32-byte emitter address, and sequence; a source receipt without redemption does not mean the destination balance exists.
WTT encodes at most eight decimals, as the Wormhole Foundation’s token bridge white paper specifies. For an 18-decimal token, a request for 1.234567891234567890 units moves 1.23456789; the remaining 0.000000001234567890 units stay on the source. Manual transfer requires your app to fetch and redeem the VAA and fund destination gas. Automatic WTT in the SDK needs a supported EVM route and relay quote; for Solana, plan manual redemption.
TransferWithPayload is WTT’s route for moving tokens and encoded instructions to a destination contract. It fits an application deposit that credits a position when bridged funds are redeemed. The source calls transferTokensWithPayload with token, amount, destination chain, recipient contract, nonce, and payload; the VAA carries payload ID 3, token origin, source sender, and bytes.
The receiver calls completeTransferWithPayload, validates the source identity and payload, then executes its logic. Budget destination gas for bridge verification and execution; a reverting receiver leaves the source transfer committed and the destination action pending. This route does not fit a wallet payout or a message without an asset, and it requires a retry path.
Native Token Transfers (NTT) suits issuers controlling token contracts across chains and requiring their own token representation at each endpoint. Managers can lock on a hub and mint on spokes, or burn on one chain and mint on another. This avoids wrapped-asset addresses but requires mint or custody authority, deployed managers, registered peers, and governance of limits.
For a Wormhole crypto bridge integration using NTT, verify each peer manager, token decimals, transceiver configuration, and attestation threshold. The source manager locks or burns, a transceiver sends the message, and the destination manager waits for enough attestations before minting or unlocking. An asset whose mint authority or destination contract you cannot control rules this path out.
Each NTT chain has one outbound rate limit shared across destinations and separate inbound limits per source. Capacity normally refills over 24 hours, though deployments can change that window. Say outbound capacity is 1,000 tokens and the destination permits only 50 incoming from this source: a 60-token transfer may clear outbound checks yet wait in the inbound queue.
On the source, shouldQueue=true holds an over-limit transfer for later release; false reverts it. Inbound excess queues until capacity returns. Expose queued status separately from completed balances, and check two-chain gas plus any relay quote at runtime. NTT is excessive for a token you do not administer or for arbitrary data alone.
Core messaging suits application state that needs authentication across chains but no token movement. An EVM sender calls publishMessage(uint32 nonce, bytes payload, uint8 consistencyLevel); Core assigns a sequence, and Guardians sign after the requested finality. A receiving contract verifies the VAA and interprets the bytes. The route cannot deliver a token balance by itself.
Core VAAs have no built-in destination. The receiver must check emitter chain and address, expected target in the payload, and a consumed-message key for replay protection; decide whether out-of-order sequences are valid. Relayers can deliver the signed VAA but cannot alter it, so delayed delivery needs a retry or manual submission path.
Finality is the latency trade-off: the Wormhole Foundation’s finality reference gives around 14 seconds for finalized Solana and around 19 minutes for finalized Ethereum. Lower finality increases source reorganization risk. Budget source gas, any Core message fee, destination verification and execution gas, and optional relay cost. Check that source finality plus a delivery buffer fits any application deadline.
Choose WTT for a wrapped balance, its payload route for token-coupled execution, NTT for an issuer-controlled native token, and Core messaging when only authenticated data must arrive.