A token native to one chain is represented on another through a bridge. There are two dominant models. Lock-and-mint: the canonical token is locked in a contract on the source chain, and a wrapped representation is minted on the destination. Burn-and-mint: the token is burned on the source chain and an equal amount minted on the destination. Either way, the destination token is only as sound as the bridge behind it.
1// Burn-and-mint style bridge (simplified, two chains):2// Source chain:3function bridgeOut(uint256 amount, uint256 dstChain) external {4_burn(msg.sender, amount);5emit BridgeOut(msg.sender, amount, dstChain); // relayers observe this6}7// Destination chain (called after the message/proof is verified):8function bridgeIn(address to, uint256 amount) external onlyBridge {9_mint(to, amount);10}
A subtle problem: multiple independent bridges can each mint their OWN wrapped version of the same asset, fragmenting liquidity (the classic USDC.e vs. native USDC split). Standards like xERC20 (EIP-7281) give the token issuer control over which bridges may mint and impose per-bridge mint/burn rate limits. Native issuance schemes (e.g., Circle's CCTP) burn and mint the canonical token directly, avoiding wrapped duplicates entirely.
Bridges are the single most-exploited primitive in DeFi — well over $2 billion has been stolen via bridge hacks. A bridge compromise can mint wrapped tokens with no backing, instantly depegging them from the canonical asset. Lock-and-mint concentrates risk in the lock contract; understand a bridge's security model before holding its wrapped tokens.
1// xERC20 (EIP-7281): issuer authorizes bridges with rate limits2function setLimits(address bridge, uint256 mintLimit, uint256 burnLimit)3external onlyOwner;4// Each bridge gets a capped, replenishing mint/burn allowance,5// so one compromised bridge cannot mint unlimited supply.
Connect your wallet to mark this lesson as complete
Earn 25 EFFORT tokens