Cross chain messaging

An asset on chain A stays on chain A, and the usual construction locks or burns it there and mints a representation on chain B. The holder on B owns a claim against whatever holds the original, and that claim is worth exactly what the bridge's custody and verification arrangement is worth. Where the construction is burn and mint, the issuer on both sides is the same party, which is a different and usually better position for the holder.

Underneath, the thing being transported is a message: an assertion that an event occurred on the source chain, delivered to a contract on the destination chain that acts on it. Token movement is one application of that message layer, and a protocol that can carry arbitrary messages can also carry an instruction, a price or a state update. A failure in this message layer can therefore extend beyond theft from one bridge.

An external validator set is the most common: a group of nodes watches the source chain and signs an attestation that an event happened, with a threshold of signatures accepted by the destination contract. The external-validator approach fails when enough of the signing keys are compromised or collude, and the whole security reduces to the key management of that set.

A light client verifies the source chain's consensus directly inside a contract on the destination chain, which removes the external trusted party and replaces it with the source chain's own security. The light-client approach fails on cost and on upgrades, since consensus verification is expensive onchain and a source-chain hard fork can break the client. Optimistic verification accepts a message after a challenge window in which anyone can submit a fraud proof, which trades latency for a weaker trust assumption, and it fails when nobody is watching during the window or when the window is too short for a challenge to land. Each model is a different answer to the same question, and none of them removes trust: they relocate it.

CCIP routes messages through the decentralized oracle networks of Chainlink and adds a Risk Management Network as a separate, code-diverse layer that monitors every transfer, which is a defense-in-depth arrangement with a second independent check. CCIP waits for more source-chain confirmations by default, so it settles more slowly. Chainlink develops other products alongside CCIP for applications using blockchain networks.

LayerZero separates the endpoint, the verification and the execution, and lets each application compose its security from Decentralized Verifier Networks, which puts the configuration decision on the application developer. Wormhole uses a fixed set of 19 institutionally run Guardian nodes with a 13-of-19 signing threshold, which is simpler to reason about and not configurable. Axelar has its own validator set reach consensus on and sign cross-chain messages through General Message Passing, re-attesting other chains' state. Hyperlane lets each application pick multisig, optimistic or zero-knowledge verification through modular Interchain Security Modules. CCTP from Circle is specific to USDC and uses burn and mint by the issuer, while IBC in the Cosmos ecosystem verifies with light clients.

Ronin lost around 625 million US dollars through compromised validator keys, which is the external validator set failing at key management. Wormhole lost around 320 million through a signature verification bypass, a bug in the destination-side check. Nomad lost around 190 million after a flawed Merkle root initialization let anyone replay a message. The Horizon bridge from Harmony lost around 100 million through a compromised two-of-five multisig, where the threshold itself was too low to survive two compromises.

The pattern is that the theft happened at the verification boundary and not in the underlying chains, which both kept working correctly. Bridge exploits accounted for roughly 2.8 billion US dollars of losses in 2025, around 40 percent of all Web3 security incidents. In April 2026 a forged cross-chain message drained about 292 million in rsETH affecting KelpDAO, and the cause was traced to a single-verifier configuration and not to a protocol bug, with responsibility disputed between the application and the protocol. A configurable security model places the choice with the application, including the decision to accept the default configuration.

A regulated instrument requires clarity about when its transfer becomes legally final and irreversible. A cross-chain transfer has at least two finality events, one on each chain, and a window between them in which the source chain could still reorganize while the destination has already acted. A protocol that acts on an unfinalized source block can be made to deliver an asset against a transaction that then does not exist.

The confirmation policy therefore affects legal finality as well as performance. A tokenized security crossing a chain needs a stated point at which the transfer is final, the register that holds the authoritative record, and the treatment of a reorganization that crosses that point. For tokenized securities, the transfer must match the legal register. In onchain capital markets, settlement against payment is another requirement. These requirements help explain why most regulated tokenization currently stays on one ledger.

A cross-chain message and a price feed are the same problem with a different payload. In both cases a contract has to act on information it cannot verify itself, and a set of parties is trusted to report it faithfully. The failure modes overlap: a compromised reporting set, a stale value acted on as current, an aggregation rule that a manipulator can exploit.

That is also why the same infrastructure serves both, and why an institution assessing one should ask the questions from the other. Verification mechanisms used by oracle networks also apply to cross-chain messaging. The attacks and defenses involved in oracle network security concern similar risks to transmitted data.

Protocols differ in their trust assumptions and failure modes, so security depends on the requirements of each application. A fixed, named validator set is easy to assess and impossible to improve per application. A configurable model can be made stronger than any fixed one and can also be left on a default that is weaker. A light client has the best trust properties and the highest cost. The useful question for an institution is which assumption it can state in writing to a risk committee and monitor afterward.

A wrapped token is a claim issued on the destination chain, and its value rests on the bridge's custody of the original plus the correctness of the minting logic. If the bridge is drained, the wrapped token remains on the chain with nothing behind it, which is what holders discovered in each of the large failures. Where the issuer of the original does the burning and minting itself, as with CCTP from Circle for USDC, the holder's counterparty is the issuer and not a bridge, which is a materially different risk.