A wrapped token is the IOU a bridge prints when the original asset cannot leave its native chain. The original stays locked in the bridge’s escrow contract on chain A; the wrapped token is a fresh ERC-20 on chain B. When you want the original back, the bridge burns the wrapped token and releases the escrow.

If your first bridge deposit produced an “unknown token” alert, this is why. A bridge does not move tokens. It moves a proof of deposit, and the destination chain mints a wrapper. That wrapper is built to look like the original, same symbol, same decimals, same balance. It is a different contract.

The only number that matters is 1:1

One locked native token equals one wrapped token. Not 1.01, not 0.99. When that ratio changes, the issue is not the symbol, it is the bridge. The wrapper supply is meant to be covered by the escrow on the home chain. To make that true you check the contract, not the ticker.

Here is a real version of that split: on the Optimism Network, USDC bridged from Ethereum was a wrapper for a long time, and later Circle’s native USDC appeared on the same chain. Same symbol, same decimals, different contract. Depending on which route you used, you held the native asset or the wrapped form. The balance read 1:1 in both cases; the contract address was the only way to tell which one owned the value.

The lock, mint, burn cycle

  1. You approve the bridge contract on the native chain, and the contract holds your asset in escrow.
  2. The bridge relays that deposit to the destination chain, where a new contract mints the wrapped token into your wallet.
  3. To return, you send the wrapped token back to the bridge. It burns that wrapper and sends the message that releases the escrowed asset on the original chain.

There is no step where the original asset yourself crosses between ledgers. The same message ordered by the bridge deletes the wrapped form and enables the native one.

What your wallet is actually approving

This is where WalletConnect sessions go wrong. The request shows an approve step, but the meaningful field is the contract address in that request, not the display symbol. If that address is the wrapper’s, keep the confirmation; if it is a different contract, the bridge is asking for a token you have not promised to spend.

The same reason is why wrapping opens the door to the whole ecosystem. A wrapper is an ordinary ERC-20. It plugs into the same 0x protocol order routing, liquidity pools, and swap flows as a native token, with no special path. That single interface makes it close to practical for a one-time bridge deposit to be liquid on the destination chain immediately.

A swap aggregator such as Paraswap also routes by the wrapper contract, not by the popular name. If you see a token in a routing list and then approve a different address, you get to custody the second one. The wrapper contract defines what you actually approved; the logo does not.

The bridge is complete when the wrapper returns and is burned. The native asset stays in escrow the whole time; the wrapper is your side on the destination settlement. That is why the wrapper is not a separate asset, it is the bridge’s claim record.

When you look at the next bridge transaction, ignore the token name and read the contract reported for the incoming asset. Check the wrapped representation before signing, and the rest of the flow can be reduced to waiting.