Portal Bridge is a Wormhole-based token bridge for moving supported assets between Solana, Ethereum and other chains. For a Portal Bridge integration, the deciding question is whether your destination contract accepts a Wormhole-wrapped asset. If it does, use Portal Bridge to transfer the token across chains; if it requires a separately issued native token, choose an issuer-controlled route.
Start with the token your application must receive, not its displayed symbol. A Wormhole Token Bridge transfer usually locks an origin asset and mints its wrapped representation elsewhere; sending that representation back burns it and releases the origin asset. An issuer-controlled route can deliver a token minted under the issuer’s authority instead. Those balances may share a name while remaining different assets to a contract.
Check the origin chain and token address, then resolve the destination token address before accepting deposits or building a quote. Your integration should compare that address with the mint or contract its downstream protocol actually accepts. A ticker match cannot establish interchangeability, and liquidity in one representation says nothing about liquidity in another.
A Portal Bridge Solana to Ethereum transfer of SOL illustrates the distinction. The destination receives a Wormhole representation of SOL, often labelled Wrapped SOL, rather than Ethereum’s gas token. On Solana, Wrapped SOL also names SOL held in an SPL token account; Solana’s token documentation describes that account mechanism. Treat the chain and mint or contract address as part of the asset identity in your database.
A Token Bridge transfer commits the source asset before the destination can release value. For the SOL example, the source transaction places tokenized SOL under bridge custody and emits a Wormhole message naming the amount, origin asset, destination chain and recipient. Guardians observe the finalized message and sign a Verified Action Approval, or VAA. Submitting that VAA on Ethereum mints the wrapped asset to the recipient.
Confirm that the destination has registered the wrapped asset before initiating a new token route. Registration uses a separate metadata attestation and is needed once per origin token and destination chain. A source transaction can succeed even when that registration or the later redemption has not happened, so neither a transaction hash nor a VAA alone proves delivery.
Amount precision is another route check. Wormhole Foundation’s WTT payload specification normalizes transfer amounts to eight decimal places, even when the origin token has more. For example, pre-quantize 1.234567899 SOL to 1.23456789 SOL before quoting or approving the transfer; the nine-lamport difference must be handled in your source balance accounting. Use integer base units throughout, and reject amounts that become zero after normalization.
Choose automatic completion when a relayer supports the specific chain and token route and your user needs delivery without signing on the destination. The relayer submits the VAA and charges for that work. Choose manual completion when your application can retrieve the VAA, fund destination gas and submit redemption itself; it gives you control over retries and transaction timing.
Compare the full cost at quote time: source-chain gas, any message fee, destination-chain gas, a relayer charge if used, and any account creation cost on Solana. These values depend on current network conditions and the selected route. A low token amount can be uneconomic even when the bridge accepts it, particularly if the destination requires a new token account.
Check finality and completion separately in your latency budget. Guardian signing follows the source chain’s required finality, and destination inclusion follows after VAA submission. For manual transfers, Wormhole’s guidance is to complete within 24 hours; a later Guardian-set change can require refreshed VAA signatures. Build that recovery path before offering a route whose redemption your service owns.
Track a transfer from source submission through source finality, VAA availability, destination submission and confirmed redemption. Store the source chain, emitter address and sequence together: that tuple identifies the Wormhole message once the source transaction is final. Also retain the intended recipient, origin asset, normalized amount and destination transaction hash so a resumed worker can reconcile the result.
If VAA retrieval times out, query again for the same finalized message instead of initiating a second transfer. If redemption fails, inspect the destination transaction and retry submission only after checking whether the VAA was already consumed. A successful source transaction with no destination balance is a pending transfer to investigate, not a reason to debit the user again.
Choose Portal Bridge when its wrapped destination asset fits your contract and its available completion route fits your gas and recovery model; choose native issuance when the destination must receive the issuer’s token.