Every blockchain is its own self-contained world. A network keeps a ledger of balances, and the computers running that network only agree on what happens inside it. They have no built-in way to see what is happening on a different chain. That means you cannot simply send a coin from one blockchain directly to an address on another the way you might send a file between two computers. The two ledgers have no shared language, no shared clock, and no shared record.
Cross-chain bridging is the collection of techniques used to work around that limitation. A bridge does not literally teleport a coin from one chain to another. Instead, it coordinates two separate actions on two separate ledgers so that the overall effect feels like a transfer: something is immobilized or destroyed on the origin chain, and something of equivalent value is released or created on the destination chain.
The most common design is called lock-and-mint. You send your asset to a smart contract or custodial address on the origin chain, where it is locked and cannot be spent. Once the bridge's operators or software confirm that the deposit is final, a corresponding token is minted on the destination chain. That new token is usually described as a wrapped asset. It is a claim ticket: it represents the locked original and is meant to be redeemable for it. To go back, you send the wrapped token to the bridge, it is burned, and the original asset is unlocked on the first chain. This is sometimes called burn-and-release.
A second common design uses liquidity pools instead of wrapping. Here the bridge holds reserves of the same asset on both chains, supplied by people who deposit funds in exchange for a share of the fees users pay. When you bridge, you deposit into the pool on the origin chain and the bridge pays you out of the pool on the destination chain. Nothing is minted, so you receive the native version of the asset rather than a wrapped one. The trade-off is that transfers are limited by how much liquidity sits on the receiving side, and large transfers can be slower or costlier when reserves are thin.
The hard part of any bridge is verification: how does the destination chain become convinced that the deposit really happened on the origin chain? Approaches vary in how much trust they require. Some bridges rely on an external set of validators, signers, or a single custodian who watch the origin chain and sign attestations. Users are trusting those parties to be honest and to keep their keys secure. Other bridges use light clients and relayers, where the destination chain runs a compact verification of the origin chain's consensus rules and checks cryptographic proofs of the deposit directly. This reduces reliance on outside parties but is harder to build and only works between chains with compatible designs. Systems built around a shared settlement layer, such as rollups posting to a common base chain, can inherit security from that layer instead of assembling their own committee.
Bridges also have to deal with finality. A transaction that looks confirmed can, on some networks, still be reversed if the chain reorganizes. Bridges therefore wait for a number of confirmations before acting on the other side. That waiting period is a large part of why bridging is rarely instant, and why different bridges have different speeds for the same pair of chains.
Bridging introduces risks that a normal on-chain transfer does not. The locked reserves behind a wrapped asset are a concentrated pool of value, which has historically made bridges a frequent target of attacks. Bugs in the minting logic can allow tokens to be created without a matching deposit, and compromised signing keys can allow unauthorized withdrawals. A wrapped token is also only as good as the bridge that issued it: if the reserves are lost, the wrapped version can lose its redeemability. On top of that, wrapped versions of the same underlying asset issued by different bridges are generally not interchangeable, so sending one to a contract expecting another can strand funds.
Practical care matters as much as understanding the theory. Users typically check that the destination network is supported and correctly selected, that the receiving address exists on that network, that the token they will receive is the version their destination application actually accepts, and that they hold some of the destination chain's native coin to pay for future gas fees. Small test transfers before a large one are a common habit for exactly these reasons.
This article is for general education only — not financial advice, and nothing here is a recommendation to buy, sell, or hold any asset. Cryptocurrency carries real risk of loss; always do your own research before making a financial decision.
