Cross-Chain Bridge

A cross-chain bridge is a protocol that transfers tokens or messages between two technically independent blockchains. The bridge locks or burns the value on the source chain and issues an equivalent value on the destination chain. Which party a user must trust depends on the security model of each protocol.

Every blockchain maintains its own ledger and cannot read the state of another one directly. Ethereum does not recognize a payment on Solana, and Bitcoin recognizes neither. Bridges close that gap. They link layer-1 networks with one another, and they connect rollups and sidechains to their respective main chain. However, they make a promise that neither side can verify on its own, namely that the backing on the opposite chain actually exists.

How a cross-chain bridge transfers tokens

The basic form is called lock-and-mint. First, the user sends a token to a custody contract on the source chain, which locks it. Only then does the bridge mint a 1:1 backed wrapped token on the destination chain. Redemption runs the process in reverse: the bridge burns the wrapped token and releases the original on the source chain. WBTC follows this pattern, with BitGo holding the deposited bitcoin in custody. As a result, the transferred value sits in a single contract on the source chain.

Burn-and-mint, by contrast, needs no custody contract. The protocol burns the token on the source chain. It then mints the native version of the same asset on the destination chain. Consequently, no separate wrapped token exists, only the same asset on two chains sharing one total supply. Circle uses this method in its Cross-Chain Transfer Protocol for USDC.

Finally, the third design drops locking and minting altogether. Liquidity pool bridges hold prefunded reserves on both sides. The user pays into the pool on the source chain. In return, the pool on the destination chain immediately delivers the counterpart. Meanwhile, the protocol rebalances the reserves in the background. Yet the difference is not cosmetic. Whoever holds a wrapped token has a claim against the bridge, while a swap through a pool delivers the reserve prefunded there.

Who confirms that the transfer actually happened?

Whether a cross-chain bridge locks, burns or pays out from a pool says little about its security. Verification decides the matter. The question is who confirms to the destination chain that the source chain really locked or burned the value. In the simplest case, a small committee of named signers handles this, and its multisig approval triggers issuance on the destination chain. Such federated bridges therefore shift the risk entirely onto the operators' key management. The destination chain verifies nothing itself.

Light client verification replaces the committee with cryptography. In Cosmos IBC, each of the two connected chains runs a light client of the other. A relayer merely carries the cryptographic proofs between them. Thus the destination chain checks for itself whether the consensus of the source chain confirmed the transfer. It need not trust an external validator set. Still, the effort is comparatively high, because both sides must operate the other chain's light client.

Optimistic verification initially assumes a transfer is correct until someone challenges it. The native bridges of the rollups Arbitrum and Optimism work this way. A withdrawal from layer 2 back to Ethereum passes through a seven-day challenge period, during which any party can dispute the state transition. In addition, some protocols combine the approaches. LayerZero splits verification into an oracle role for the block header and a relayer role for the transaction proof. Chainlink's CCIP also runs an independent Risk Management Network. It uses its own software and its own node operators, and it can pause transfers automatically when something looks irregular.

Why are cross-chain bridges hacked so often?

A bridge concentrates assets in one place and protects them with logic that must hold on two chains at once. For 2022, Chainalysis attributed roughly 69% of all stolen crypto assets to bridge attacks. Technical post-mortems exist for the following cases.

Two causes dominate overall. At Ronin, the attacker took over five of nine validator signatures. Most of them came through a phishing email to an employee of Sky Mavis. In contrast, at Wormhole and Nomad the verification logic itself failed. One case involved a forged system account, the other a Merkle root initialized to 0x00. Both flaws made the contracts accept arbitrary messages as proven. After the Nomad bug, hundreds of copycats repeated the first attacker's attack. Ultimately, compromised keys and faulty verification shape the documented bridge exploits, not broken encryption.

For Ronin and Harmony, an official attribution exists. The US Treasury Department (OFAC) sanctioned the receiving address of the Ronin theft. In addition, it attributed the attack to the North Korean Lazarus Group. Likewise, the FBI assigned the Harmony case to the same group, there under the designation APT38. Poly Network ran differently, because the attacker voluntarily returned most of the funds.

Distinction from sidechain and native rollup bridge

A sidechain is not a cross-chain bridge but an independent chain with its own consensus. The bridge is merely the connection between that chain and the main chain. That distinction has practical consequences, because the security assumptions diverge. A sidechain can be soundly validated while its connection hangs on a small signature committee.

A native rollup bridge is likewise not the same as a bridge between two unrelated networks. It belongs to the construction of the rollup itself and therefore inherits its fraud or validity proof system. That is why withdrawals to Ethereum pass through a challenge period. A third-party bridge, by contrast, connects two networks that have nothing to do with each other. Thus it brings its own security model, which neither chain secures.

The third misconception concerns the wrapped token. It is a promissory note from the bridge rather than a direct claim against the originating chain. If the backing on the source chain fails, the token ultimately loses its value. That holds even when liquidity remains available on the destination chain. Notably, exactly this gap opened at Wormhole when the attacker minted 120,000 wETH without any backing. Parent company Jump Trading refilled it from its own funds, a decision made outside the protocol.

How MiCA classifies bridges and wrapped tokens

The EU regulation MiCA has applied in full to crypto services since 30 December 2024. However, it contains no separate provision for cross-chain bridges. Instead, two general points of connection apply. The first concerns the token itself. A wrapped token whose value references another asset can qualify as an asset-referenced token, which requires issuer authorization.

The second point of connection concerns operations. Whoever holds the locked tokens of a bridge in custody provides a custody service. Therefore that operator potentially falls under the authorization requirement as a crypto-asset service provider. Pure messaging protocols without a transfer of possession stay outside this perimeter, according to one legal analysis. The same applies to atomic swaps. Consequently, the classification depends on the specific custody arrangement, not on the label the protocol carries.

Moreover, the two points of connection can coincide. An operator can issue a wrapped token and hold its backing in custody at the same time. The regulation can then cover that operator as issuer and as service provider simultaneously. Lock-and-mint constructions have this combination built in.