Cross-chain messaging: who is trusted to make the claim
A blockchain cannot read another blockchain. When an application on one chain acts on something that happened on another, somebody has told it so, and the design question in every cross-chain protocol is who that somebody is and what happens when they lie. Nothing about this is solved by cryptography alone.
What follows is what a bridge actually moves, the trust models in use and where each fails, the named protocols by their published designs, the largest failures and their mechanisms, and what a tokenized security needs before it crosses a chain.
What a bridge actually moves
Nothing crosses. 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. That is why the subject is messaging and not bridging, and why a failure in the message layer can be worse than a theft from one bridge.
The trust models and where each one fails
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. It 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. It 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.
The protocols by their published designs
CCIP routes messages through Chainlink's decentralized oracle networks 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. It waits for more source-chain confirmations by default, so it settles more slowly. The Chainlink page covers the company and its other products.
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. Two further systems are worth naming: Circle's CCTP, which is specific to USDC and uses burn and mint by the issuer, and IBC in the Cosmos ecosystem, which verifies with light clients.
The largest failures and the mechanism in each
The record is specific and the mechanisms repeat. 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. Harmony's Horizon bridge 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. That dispute is the lesson: a configurable security model moves the decision to the application, and an application that accepts the default has made a security choice without noticing.
Why a tokenized security needs settlement finality first
For a regulated instrument the question is not whether the token arrives but when the transfer is 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.
That makes the confirmation policy a legal parameter and not a performance setting. 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. The tokenized securities page covers the register question and onchain capital markets the settlement side. The honest reading today is that this is why most regulated tokenization stays on one ledger.
The relation to oracles
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 rhyme: 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. The oracle networks page covers how these networks work and oracle network security the attack and defense patterns that transfer directly to the messaging case.
Which cross-chain protocol is the most secure?
There is no most secure option, only different trust assumptions and different failure modes, and a page that ranks them is selling something. 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.
Is a wrapped token the same as the original?
No, and treating it as the same is how holders have been surprised. 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 Circle's CCTP for USDC, the holder's counterparty is the issuer and not a bridge, which is a materially different risk.
Cross-chain messaging and Finance Loop
Finance Loop is the meeting place for the engineers who integrate these protocols and the risk officers who have to sign off on the trust assumption behind them, in its Digital Infrastructure & Sovereignty track. Finance Loop keeps the subject on the agenda because the losses in this field came from configuration and key management, which are decisions both groups have to make together.
Finance Loop is a professional network and has the goal of driving the adoption of emerging technologies in finance, such as AI, tokenization, stablecoins, and DeFi. Finance Loop helps its members build skills and personal networks in these fields: Investment & Digital Assets, Payments & Digital Money, Digital Infrastructure & Sovereignty, and Risk & Compliance.