Wormhole bridge offers four paths: wrapped tokens, issuer-managed native tokens, native USDC, and contract messages. For a token move from Solana to Ethereum, use Wormhole bridge to carry the asset across; for a contract instruction, use Wormhole Core messaging. The destination asset determines which Wormhole cross-chain transfer path fits.
What does Wormhole bridge connect?
Wormhole connects blockchains through a message network; applications use those messages to coordinate actions on the destination chain. Solana, Ethereum and Base are connected examples, but support for a chain does not mean every token or route works on every pair.
Wormhole Core publishes and verifies cross-chain messages. Wrapped Token Transfers (WTT), called Token Bridge in contracts and software libraries, and Native Token Transfers (NTT) can use that infrastructure to move token balances. Wormhole Connect is an interface an application can embed to offer available routes; it is not a separate token model.
That distinction matters when you compare options. A wallet holder needs to know which token contract arrives; a developer sending an instruction needs to know what their destination contract will do with a verified message. Chain names alone cannot answer either question.
Which path leaves the right asset in your wallet?
Pick the route by the exact asset the recipient needs on the destination chain. The same ticker can label a native token or a Wormhole-wrapped token, and an application may accept only one of them.
- Wrapped Token Transfers (WTT): Best when you need broad token coverage and can use a Wormhole-wrapped asset at the destination. An original asset is locked and a wrapped representation is minted; this does not fit an application that requires the native issuer token.
- Native Token Transfers (NTT): Best when a token issuer has deployed NTT managers for the asset on both chains and you need its issuer-managed form. Tokens are burned and minted, or locked and released, under the issuer’s configuration; it does not fit an asset without that deployment.
- CCTP for native USDC: Best when the source holds native USDC, both chains support CCTP, and the recipient needs native USDC. It burns USDC on one chain and mints it on the other; it does not fit wrapped USDC or an unsupported chain pair. Wormhole Connect may offer this route, although a manual CCTP transfer does not use Wormhole messaging.
- Wormhole Core messaging: Best for an application passing a command or data to a contract on another chain. It does not by itself put tokens in a wallet; the application must supply the destination logic and any asset handling.
Say you hold 100 native USDC on Solana and need Ethereum USDC for a lending position. A supported CCTP route delivers native USDC, while WTT can leave you with Wormhole-wrapped USDC that the lending contract may reject. If you instead hold a project token on Ethereum with no NTT deployment on Base, WTT may be available, and the wrapped token’s contract address becomes the key check.
How does a transfer actually complete?
A WTT transfer changes balances through two chain transactions joined by a signed message. On the source chain, the token bridge locks an original asset, or burns a wrapped one, and asks Wormhole Core to publish the transfer details. Guardians observe that event; 13 of 19 signatures form a Verified Action Approval (VAA), the proof submitted to the destination chain.
The destination contract verifies the VAA, then mints a wrapped token or releases an original token returning home. With a manual route, you submit the destination transaction and pay its gas; with an automatic route, a relayer submits it and charges for that service. Waiting time depends on source-chain finality and destination submission, so a successful source transaction does not alone prove receipt.
NTT also uses a cross-chain attestation when configured with Wormhole’s transceiver, but the issuer’s token managers control minting, locking and rate limits. CCTP has its own USDC attestation flow. For a pure message, the destination contract interprets the payload; no token arrives unless that contract’s code makes it happen.
What should you check before you send?
Check the source chain, destination chain, token contract and expected destination token contract before approving a transfer. The Wormhole crypto bridge can connect the chains while a particular asset route remains unavailable; a familiar ticker does not establish that the received token will work in your intended app.
Budget for source-chain gas, destination-chain gas if you redeem manually, and a relayer charge if you choose automatic completion. These amounts change with chain congestion and route, so compare the quoted amount received with the value of the transfer, especially for a small move. Keep enough gas token for any transaction you must sign yourself.
After sending, use the source and destination transactions to confirm completion, and keep the transfer identifier if redemption is pending. I would choose native USDC for the lending example because the receiving contract’s token requirement decides the route. I would choose differently if the recipient accepts a wrapped asset, or if the chosen chain pair has no native route.