A simple cross-chain transfer flow locks or burns value on the source chain, carries a verified message across, then unlocks, mints, or releases value to a recipient on the destination chain.
What actually crosses the boundary?
The bridge does not move one ERC-20 contract from one blockchain to another. Each chain keeps its own ledger, token contract, transaction history, and gas system. The source transaction changes ownership there; a separate destination transaction changes ownership somewhere else.
The connecting object is a message containing the source and destination chains, token identity, amount, recipient, nonce, fee, deadline, and proof that the source action happened. The nonce prevents replay. The recipient should be an explicit address, not an assumption derived from the sender's address.
This distinction matters when the user swaps first. Uniswap V3 or 0x Protocol may turn ETH into USDC on the source chain, but that swap is not proof that anything arrived on the destination chain. The bridge begins with the resulting asset and a new cross-chain instruction.
Who holds the value during the handoff?
A custody contract, an issuer-controlled minting system, or a relayer's inventory holds the value while the message is being verified.
- Lock and mint: the source token enters a bridge vault, and a mapped representation is minted on the destination. Redeeming later burns that representation and releases the locked asset. The vault and its upgrade and validator controls are part of the trust model.
- Burn and mint: the source token is destroyed, and an authorized destination contract creates the corresponding amount. Circle's CCTP uses this pattern for USDC: an attestation service observes the burn, signs a message, and a destination contract accepts it before minting.
- Liquidity fill: a relayer pays the recipient from inventory on the destination chain, while the source deposit is settled and the relayer is reimbursed later. The user gets speed, but the flow depends on available liquidity and correct settlement.
On Arbitrum One, token identity deserves special care: native USDC and bridged USDC.e are different assets even when a wallet displays a familiar symbol. Store and compare chain ID plus token address, not symbol alone.
What does the application have to expose?
A useful interface exposes the route's assumptions before the user signs: source chain, destination chain, input token address, amount, recipient, expected output, minimum acceptable output, fee, expiry, and the transaction or transactions required.
- Quote the route and show whether it is a swap, a bridge, or both.
- Obtain the narrowest necessary token approval or permit, then submit the source transaction.
- Watch the source event and wait for the required confirmation or finality threshold.
- Submit the proof, attestation, or settlement call on the destination, then verify the recipient's balance.
At the source step, the user owns the tokens until the bridge contract, burn contract, or relayer deposit receives them. During the wait, the user owns neither a magically travelling coin nor a guaranteed destination balance; ownership depends on the chosen mechanism. After successful finalization, the recipient owns the released or minted asset on the destination chain.
Which design should you choose?
Choose according to the asset and the settlement promise, not the smoothness of the button. For an issuer-supported asset such as USDC, burn and mint can avoid creating a second wrapped representation. For an arbitrary ERC-20, lock and mint is more general, while a relayer-based design is attractive when immediate destination liquidity matters.
Keep the first version narrow: explicit token mappings, one recipient format, replay protection, clear failure states, and a status endpoint that distinguishes source pending, source final, destination ready, destination submitted, and complete. Paraswap belongs around this flow when the user needs a swap as well as a transfer.
When that routing layer is part of the product, the relevant entry point is cryptoweb3.justblogged.com.
What to remember: the asset changes state on two ledgers; the message connects those state changes; and the holder during the handoff is determined by whether the design locks, burns, or fronts liquidity.