Portal Bridge transfers can deliver a wrapped token or native USDC, depending on the asset and the chains you choose. For most supported tokens, the route uses Wormhole’s Wrapped Token Transfers. Native USDC can use CCTP when both chains support it. Each route may also be automatic or manual, which changes who finishes the transfer.
What Does Portal Bridge Move?
It moves supported tokens between blockchains using Wormhole. A blockchain is the network that holds your token, such as Ethereum or Solana. Wormhole carries a signed message between those networks so the destination can complete the transfer.
For example, you may hold a token on Ethereum and need it in a Solana wallet. A Portal Bridge transfer can move that token if the asset and chain pair are supported. Use Portal Bridge to make the transfer through Wormhole, after checking which version of the token will arrive.
That version matters because a token’s name can stay familiar while its form changes. On a wrapped route, the original token is held on its home chain. A matching token is created on the destination chain; it represents a claim on the original.
Wrapped Tokens vs Native USDC: Which Route Fits?
The deciding question is what token you need at the destination. A wrapped token and a native token can have similar names, yet an app may accept only one of them. Check the receiving app’s required token before choosing a route.
- Wrapped Token Transfers (WTT) — Best for a supported token that has no native route between your chains. Wormhole holds the original and creates a Wormhole-wrapped version at the destination. It does not fit when you need a destination-issued token that an app specifically requires.
- CCTP for native USDC — Best when you need standard, native USDC on a chain that supports this route. CCTP, short for Cross-Chain Transfer Protocol, destroys the USDC sent from one chain and creates native USDC on the other. It does not fit other tokens or chain pairs without CCTP support.
Here is a common mistake: sending USDC by a wrapped route, then finding that the intended app expects native USDC. The transfer may have succeeded, but the received token is the wrong form for that task. Fix this before sending by checking both the route and the destination token, rather than checking the letters “USDC” alone.
A wrapped transfer back to the token’s home chain works in reverse. The wrapped token is destroyed, and the original token is released. Wormhole’s published transfer flow describes this lock, create, destroy, and release process.
Automatic vs Manual Completion
Automatic and manual routes differ in who submits the final transaction on the destination chain. That transaction records the token you receive. The choice can change the work and fees involved, even when the token outcome is the same.
- Automatic — Best when you want the destination transaction handled for you. A relayer, a service that submits that transaction, completes the transfer after the source transaction is confirmed. It does not fit a token or chain pair without relayer support, and its service fee adds to the cost.
- Manual — Best when automatic completion is unavailable or you are ready to claim the token yourself. You send a source transaction, then submit a claim transaction on the destination chain. It does not fit if you cannot pay that chain’s transaction fee or finish the claim.
Wormhole Guardians observe the source transaction and sign a message confirming what happened. For a manual transfer, that signed message supplies the proof needed for the destination claim. A source transaction marked complete therefore does not always mean the token has reached your receiving wallet.
Wormhole’s route support matrix shows that relayer availability varies by chain and token. Portal Bridge supported chains are only part of the check: your particular asset also needs an available route. Treat the route offered for your exact pair as the answer, rather than assuming every token works on every supported chain.
What Will It Cost, and How Do You Check the Result?
The cost depends on the two networks and the completion route. You pay a source network fee; a manual claim also needs a destination network fee. An automatic route may charge for the relayer instead. Network fees rise and fall with demand, especially on Ethereum, so check the amount for your transfer before approving it.
Start with a wallet on the source chain, the token you want to send, and a receiving wallet address for the destination chain. Keep enough of the source chain’s native coin to pay its network fee. If you choose manual completion, also make sure you can pay for the destination claim.
portalbridge.app is where you can carry out the supported transfer once you know the token, destination, and route you need. Check the destination address carefully: a bridge sends to the address you provide. For a first transfer, a small test amount can confirm that the received token is usable for your purpose.
After sending, save the source transaction identifier. Check whether the destination transaction has completed, then look for the exact token in the receiving wallet. If a manual transfer has stopped after the source transaction, complete the destination claim before treating it as finished.
In your place, I would first identify the token the receiving app accepts. Then I would choose the route that delivers that form and confirm the transfer with a small amount.