Why Does a Bridge Transfer Arrive as a Wrapped Token?
If you bridge a token to another chain and receive a wrapped version, that usually means the destination chain has no native copy of the token in that transfer route. A bridge locks or burns the source asset, then uses a signed message to release a native asset or mint a token that represents it on the destination.
What does “wrapped” mean after a transfer?
A wrapped token is a destination-chain token whose value is tied to an asset held or burned on another chain. It can look like the familiar token in your wallet, but it has a different contract address and depends on the bridge’s transfer system for redemption.
In a common lock-and-mint transfer, the source contract locks the original tokens. A network of Guardians observes the transaction and signs an attestation, a cryptographic approval called a VAA. The destination contract checks that approval and mints the wrapped tokens to your wallet. Wormhole’s documentation describes this as Wrapped Token Transfers, or WTT; the contracts and SDK may call it Token Bridge. Wormhole’s transfer overview explains the distinction.
For example, imagine sending 100 units of a token from a chain where its original contract lives to Solana, where the route issues a wrapped version. Your wallet may show 100 units with a similar name or symbol, but the important identifier is the destination token’s contract or mint address. A matching ticker alone does not prove that two tokens are interchangeable.
Why doesn’t the bridge always send the native token?
The destination chain can receive the native version only if the route supports a mechanism to release or mint that token there. If it does not, a wrapped representation is the practical way to make the asset available on that chain while preserving a claim connected to the source asset.
There are two broad mechanisms. Wrapped Token Transfers typically lock original tokens and mint wrapped ones on the destination; when the wrapped asset returns, it is burned and the original tokens can be released. Native Token Transfers, or NTT, can instead burn and mint a project’s native token across chains, or release it from a hub. That requires the token project to configure and control the relevant contracts on the chains involved. The NTT overview describes that model.
That difference matters for use after arrival. A wrapped asset may be accepted by some wallets and applications but not by others that recognize only the chain’s native version. Before you send, check the token identity shown for the destination and confirm that the wallet, exchange, or app where you plan to use it accepts that exact asset.
How can you check the route before sending?
Check the source chain, destination chain, source token, and destination token as a set; changing the destination can change the asset you receive. For example, Portal Bridge supported networks helps you check whether a particular chain pair and token are available before you build the transfer. On the confirmation screen, read the destination asset name and symbol, and compare its displayed address or mint with the one your receiving app expects.
Consider a user moving a balance to Solana for a specific application. If the transfer preview shows a wrapped token but the application accepts only the native token, stop and check for another route or an explicit conversion step before approving. A successful bridge transaction means the selected route completed; it does not guarantee that every Solana application will accept the resulting token.
Also check the amount expected to arrive and the fee breakdown. You may pay source-chain gas, destination-chain gas, and, for an automatic transfer, a relayer fee that pays a service to submit the destination transaction. These costs vary with chain conditions and the selected route, so use the live quote shown before signing rather than assuming a fixed fee.
What should you expect after signing?
After the source transaction confirms, Guardians observe its message and a supermajority signs the VAA; Wormhole documents that threshold as 13 of 19 Guardians. The destination contract then verifies the VAA and mints the wrapped asset or releases the native one. Automatic routes can have a relayer submit the destination transaction; a manual route may require you to claim or redeem it yourself.
Wait time depends on source-chain confirmation, message signing, and destination-chain processing, so it can vary with network conditions and route. If the source transaction is confirmed but the destination balance has not appeared, check the transfer status before starting again. For a manual transfer, follow the route’s completion steps; Wormhole’s WTT guidance says to complete manual transfers within 24 hours because a Guardian Set can change and make an older attestation invalid.
In your place, I would verify the destination token address and the receiving app’s requirements before sending a meaningful amount. For a first transfer on a route, I’d send a small test amount, confirm that it arrives in the expected form, then move the rest.
Comments
Post a Comment