If a transfer is pending, check the source transaction first, then follow the bridge’s recovery steps for its transfer type. Lock-and-mint holds the original tokens and issues wrapped tokens on the other chain; burn-and-mint destroys tokens on one chain and issues them on another. The difference determines what backs the destination tokens and how they return.
How does lock-and-mint work?
Lock-and-mint puts the original tokens in a source-chain contract, then mints a matching wrapped token on the destination chain. That wrapped token represents a claim on the locked tokens, rather than being the original asset.
For example, a transfer from Ethereum to Base might lock the original token on Ethereum and mint its wrapped version on Base. The source contract emits a message; Wormhole Guardians verify and sign it into a VAA, a proof the destination contract can check. Wormhole’s documentation describes a 13-of-19 Guardian signing threshold.
If your transfer uses this model, the Portal Wormhole bridge details can help you identify whether you received a wrapped token. On the return trip, that wrapped token is usually burned before the original is released. The model needs enough original tokens held in custody to cover outstanding wrapped tokens.
How does burn-and-mint compare?
Burn-and-mint destroys tokens on the source chain and creates matching tokens on the destination. It suits a token issuer that controls the token contracts across chains and wants one token supply spread between them. It does not need a pot of locked original tokens, but it does depend on trusted rules for who may mint.
For instance, a token can be burned on one chain and minted on another after the destination contract verifies the transfer message. The Ethereum ERC-20 standard defines how token contracts expose basic functions; it does not itself authorize cross-chain minting. The issuer must configure that permission and keep supply accounting consistent.
What should you check if a transfer stalls?
A failed source transaction means the transfer did not start; a successful one can still be awaiting a signed message or destination redemption. In a wormhole bridge transfer, check the source transaction status, then the VAA status, then the destination transaction. If the VAA is ready but redemption has not happened, use the bridge’s stated manual completion or recovery process.
Do not send the transfer again until you know whether the first one completed. A retry can create a second transfer. Also confirm the destination chain and recipient address: a wrong address may not be recoverable. Costs vary by chain and route; expect source transaction gas, destination gas, and possibly a relayer fee.
Quick answers
Does a pending transfer mean my tokens are lost?
Not by itself. First check whether the source transaction succeeded. If it did, the transfer may still need a signed proof or destination redemption. Check the bridge’s tracker and compare its status with both chains’ explorers. If the destination transaction failed, follow the bridge’s recovery instructions before trying again.
How can I tell if a token is wrapped?
Check the destination token’s contract address and its bridge details. A wrapped token is a separate token contract representing an asset locked elsewhere. Its name or ticker may resemble the original, so do not rely on the display name alone. Confirm the contract address through the bridge’s official interface or the relevant chain explorer.
Why can a signed message still be pending?
A signed message proves the source event, but it does not itself complete the destination transaction. A relayer may still need to submit it, or you may need to redeem it yourself. The destination chain also needs a successful transaction, including enough gas. Check whether the proof is ready and whether redemption was submitted.
Should I retry a failed bridge transfer?
Only after confirming the first source transaction failed or the bridge’s recovery process says to retry. If the source transaction succeeded, a retry may send the same amount again. Check the source transaction, bridge status, and destination transaction first. If the status remains unclear, use the bridge’s support process with the transaction IDs.
Lock-and-mint relies on locked backing; burn-and-mint relies on controlled minting and supply accounting. For a stuck transfer, trace the source transaction, signed proof, and destination redemption in that order before acting.
Top comments (0)