Portal Bridge is a cross-chain transfer interface for moving supported tokens between blockchains. The condition that matters most is which token contract you need on arrival: a Wormhole-wrapped asset, an issuer-native token, or the output of a swap.
- Match the route to the exact destination token, not its ticker alone.
- Choose manual or automatic redemption according to gas access and the quoted fee.
- Check finality, recipient address, and minimum received before signing.
The Route Determines the Asset You Receive
A Portal Bridge route specifies both how value crosses chains and what settles in the recipient wallet. Wrapped Token Transfers (WTT) lock a token on its home chain and mint a Wormhole-wrapped representation elsewhere; sending it home burns that representation and releases the original. A native route can instead deliver a token issued or recognized directly on the destination chain.
The distinction matters most when depositing into a lending market or exchange. Two tokens labeled USDC can have different contract addresses and different acceptance rules. Read the destination contract address in the route preview, then compare it with the contract the receiving application accepts.
Five Route Types Cover the Main Choices
The Wormhole Portal Bridge interface can show different routes for the same chain pair as the selected asset changes. Availability also depends on token support, destination liquidity, and whether a relayer serves that route. These are the practical categories:
- Manual WTT — Best for a supported token when you can fund gas on both chains and redeem the signed message yourself. It does not fit when the recipient lacks destination gas or requires a native token.
- Automatic WTT — Best for the same wrapped-asset outcome with destination redemption handled by a relayer. It does not fit when the token lacks relayer support or the relay charge consumes too much of a small transfer.
- Native USDC through CCTP — Best when both chains support Circle’s burn-and-mint route and the recipient needs native USDC. It does not fit a chain pair outside CCTP coverage; a WTT fallback would produce Wormhole-wrapped USDC.
- Issuer-managed Native Token Transfers (NTT) — Best when the token issuer has deployed its own cross-chain system and the receiving application recognizes that token on both chains. It does not fit arbitrary tokens; the issuer must have enabled the route.
- Native-asset or swap routes — Best when the desired output is canonical ETH, USDT, or another quoted destination asset rather than a wrapped copy. They do not fit when the required pair lacks liquidity or the quoted price impact exceeds the benefit.
Manual and automatic describe who submits the destination transaction; WTT, CCTP, NTT, and swap routes describe how the asset is delivered. Treat those as separate choices. A route can look easier because it is automatic yet still deliver the wrong token contract.
A Transfer Becomes Complete at Destination Redemption
On Portal Bridge, a WTT source transaction locks the original token, or burns an existing Wormhole-wrapped token, and emits a transfer message. Wormhole Guardians observe the finalized transaction and sign a Verifiable Action Approval (VAA). That signed message is what lets Portal Bridge transfers proceed to redemption: the destination contract verifies it, then mints the wrapped asset or releases a token held in custody.
For manual WTT, you submit the VAA and pay destination gas; for automatic WTT, a relayer submits it under the quoted terms. A pending source transaction, an available VAA, and a completed destination transaction are distinct states. If delivery stalls, look up the source hash in Wormhole Explorer before sending again; an unredeemed VAA may still be claimable.
WTT also normalizes transfer amounts to eight decimal places. For a token with 18 decimals, an amount such as 1.123456789 is carried as 1.12345678, with the smaller remainder left on the source chain. A token must also have its metadata attested on a destination chain before its wrapped version can first be created, so an obscure asset may need that extra step.
Fees and Wait Times Depend on the Route
Portal Bridge transfer fees are a combination of source gas, destination gas or a relay charge, and any route-specific fee or swap spread shown in the quote. Manual redemption saves the relay charge but requires native gas in the destination wallet. Automatic redemption can include a gas drop-off, which converts part of the arriving value into destination gas and reduces the token amount received.
Say you send 1,000 native USDC from Base to Arbitrum through an automatic CCTP quote showing a 0.30 USDC relay charge and no other deduction. The displayed arrival would be about 999.70 USDC before an optional gas drop-off; Base gas is paid separately. Those numbers are illustrative: inspect the live quote, especially for small transfers where a fixed charge is a large percentage.
Finality often sets the wait. Ethereum.org puts Ethereum finality at roughly 15 minutes, so a conventional transfer originating there can take that long before redemption proceeds; a faster liquidity or intent route may quote seconds by using a different delivery mechanism. Other chains, relayer queues, and destination congestion change the total. Compare the quoted arrival time with the route’s finality assumptions, not only its advertised fastest case.
The Destination Check Comes Before the Signature
Set the source chain and asset, destination chain, recipient address, and amount, then inspect every available route’s output contract and minimum received. Portal Bridge can send to a connected destination wallet or a separately entered address; verify the chain as well as the address, particularly when sending to a treasury or exchange deposit. An address that looks valid is no proof that its owner can use the arriving token.
Approve token spending if prompted, review the source transaction, and retain its hash. For a manual route, keep the destination wallet funded and complete the claim after the VAA appears. For an automatic route, wait for the destination transaction before treating the transfer as settled; if it stalls, check the recorded state and recovery option rather than repeating the source payment.
Four Questions Settle the Route Choice
How does the transfer work?
WTT locks or burns on the source chain, waits for a Guardian-signed VAA, and mints or releases on the destination. CCTP burns native USDC and mints native USDC after Circle’s attestation. Issuer-managed and liquidity routes use their own contracts and settlement terms. The destination token contract in the quote tells you which outcome you are accepting.
How long does it take and what does it cost?
Expect source gas plus either destination gas or a quoted relay charge. A fast route may settle in seconds when liquidity and execution are available; a route waiting for Ethereum finality can take around 15 minutes or longer. Use the live estimate and minimum received for the exact amount and chain pair, since congestion and relay pricing move.
What limits apply?
Support is specific to the token, chain pair, and route. Automatic delivery may require a minimum amount sufficient to cover relay costs, while a swap route may face liquidity and slippage limits. WTT requires destination token registration and carries at most eight decimal places of transfer precision. Check these constraints before approving a large or unusually small amount.
Which option fits the destination?
If the receiving application specifies a contract, choose a route that delivers that contract. If it accepts a Wormhole-wrapped asset and you have destination gas, manual WTT can be straightforward; otherwise compare automatic delivery with its charge. For native USDC or another canonical asset, inspect native and swap routes first, then judge their quote against the wrapped alternative.
I would start with the required destination contract, then compare the routes that actually deliver it. I would send only after checking the minimum received, gas arrangement, and recipient address in the final quote.
Top comments (0)