2026-10-07 13:42 UTC0b6718
Portal bridge: how wrapped tokens reach your wallet
Portal bridge moves tokens across chains by locking or burning the source asset, then minting or releasing the matching token after a signed message is redeemed.
Crypto Record Editorial4 min read

Portal bridge transfers tokens between blockchains by recording a source-chain action, getting that action signed, and redeeming it on the destination chain. The token that arrives may be a wrapped representation: a token contract on one chain that represents an asset from another. To receive it, you need the right destination network and address, and the transfer must complete on that chain.
How does a portal bridge transfer work?
First, the bridge contract on the source chain handles the token. If it is the token’s original chain, the contract locks the tokens in custody. If it is already a wrapped token, the contract burns them. The source transaction also publishes a message describing the transfer, including the destination chain and recipient address.
Next, Wormhole’s Guardians observe that message and sign an attestation called a Verified Action Approval, or VAA. The VAA is proof of the source-chain event. It does not carry the tokens across chains; it gives the destination bridge contract evidence to check.
Finally, the VAA is submitted to the destination chain. The contract verifies it, then either mints the corresponding wrapped token or releases the original token from custody. A relayer may submit the VAA automatically, or the transfer may require a separate redemption step. Think of the VAA as a signed claim ticket: the destination contract checks the ticket before paying out the matching asset.
For a transfer between Solana, Ethereum, or another supported chain, use portal bridge as the Wormhole-built bridge app for moving tokens across those networks. The transfer still depends on the source transaction and destination redemption both completing.
What does a wrapped token represent?
A wrapped token is a chain-specific representation of an asset whose original token lives elsewhere. Its contract address, balance, and transactions belong to the destination chain. It is not the original token contract copied onto that chain.
For example, when an original-chain token is locked, the destination chain can mint a wrapped version against that locked balance. When the wrapped version travels back, it is burned and the original can be released. This lock-and-mint, burn-and-release mechanism keeps the two sides connected through the bridge’s records.
The name and ticker alone do not establish which asset you have. A token can share a familiar symbol with another asset while using a different contract. When receiving, check the source chain and token identity, then confirm the destination chain and recipient address. The wrapped token’s contract on the destination chain is the identity that matters for later transfers or swaps there.
What should you check before receiving tokens?
Check the transfer details before submitting the source transaction, because the destination address and chain are part of the message that gets signed. A correct source transaction can still send tokens to the wrong destination address if those details are wrong.
- Confirm the exact source token and the chain where it originated.
- Choose the destination chain your wallet is connected to and can use.
- Check the recipient address against the wallet or account you intend to receive into.
- After redemption, verify the destination token contract before treating the balance as the asset you expected.
These checks matter most when an asset has more than one wrapped version or when a token name is unfamiliar. Keep the source transaction record. If the transfer is pending, use its details to distinguish a confirmed source transaction from a completed destination redemption.
Why can a transfer show as sent but not received?
The source transaction and destination transaction are separate chain events. The source may confirm first, while the VAA is still being produced or the destination contract has not yet redeemed it. In that interval, the transfer has started but the destination balance may not have changed.
Once the message is available, the destination redemption must succeed. Depending on the transfer flow, a relayer handles submission or the recipient needs to complete the step. A failed destination transaction does not mean the source event never happened; check the transfer status and transaction records before starting another transfer. The useful distinction is simple: “sent” describes the source action, while “received” means the destination contract has minted or released the tokens to the intended address.