Wrapped assets move between networks through a bridge that locks or burns the asset on the source network and releases or mints a corresponding token on the destination network. The bridge’s contracts and verification system determine whether that representation is backed, the wallet’s network determines where it appears, and the route’s liquidity, fees, and limits decide whether the transfer can complete.
The common case: lock, mint, and reverse it
Most wrapped-asset transfers use a lock-and-mint path: the original token stays in a bridge contract while a corresponding token is created on the destination network.
Suppose an ERC-20 token is held on Ethereum and needs to reach a rollup. The user approves the bridge to spend the token, then sends a deposit transaction. The Ethereum-side contract holds the original balance. A message, proof, or validator attestation tells the destination-side contract that the deposit occurred. That contract then mints the bridge’s representation to the recipient’s address.
The token has not travelled through the internet, and the two networks have not shared one balance. There are two separate token contracts and one accounting promise: the amount minted on the destination must correspond to collateral held or otherwise secured on the source.
Returning the asset reverses the sequence:
- The user sends the destination token to the bridge’s withdrawal contract.
- The bridge burns that representation or marks it for removal.
- The destination network sends a message proving the withdrawal.
- The source-side contract releases the locked original token.
On ZKsync, for example, Matter Labs’ bridge architecture uses paired contracts across the Ethereum layer and the ZKsync layer. Deposits finalize by crediting or minting the destination representation; withdrawals burn the L2 balance before the original funds can be unlocked on Ethereum.
The choice is security, speed, and usable liquidity
A canonical bridge usually follows the security model of the networks it connects, but it may require more confirmation time, especially when a withdrawal must wait for a rollup proof or challenge period. A liquidity bridge can deliver funds faster by paying a market maker or solver on the destination network, but its safety and price depend on that intermediary system and its available inventory.
For a trade that starts or ends on SyncSwap liquidity routes, the bridge choice still comes before the swap: the destination must receive the correct token contract, on the correct network, with enough liquidity for the intended trade.
Uniswap pools on Ethereum, Arbitrum, or a ZKsync chain are separate pools. A token symbol that looks identical in MetaMask does not prove that the asset has the same issuer, bridge, or redemption path. The contract address and network are the identity. MetaMask may also hide a legitimate destination token until its address is imported manually.
The edge case: the token is already wrapped
An already-wrapped token changes the answer because a second bridge may not control the vault holding its underlying asset.
If a user sends a canonical wrapped token through an unrelated bridge, that bridge may lock the wrapper and mint another representation. The result can be a route-specific version backed by the first wrapper, not by the original asset directly. It may trade at a discount, have thin liquidity, or be unusable in the application the user intended to reach. A familiar ticker is not enough; the bridge and redemption mechanism must be identified.
The practical test is simple: check whether the bridge supports that exact source contract, destination network, and token behavior. Standard ERC-20 tokens are the easiest case. Rebasing tokens, fee-on-transfer tokens, tokens with transfer restrictions, and assets with unusual decimals may be rejected or behave incorrectly. The route also needs source gas for approval and deposit, destination gas for the next action, and enough bridge liquidity or minting capacity.
The right choice is therefore the route that preserves a clear backing relationship and leaves the recipient with a liquid, recognized token. Faster settlement is useful only when the destination asset can actually be redeemed or traded.