Blockchain Interoperability Has a Trust Problem: How IBC, LayerZero, and Bridges Are Trying to Solve It

Points of Focus

• Interoperability creates a new security layer. Cross-chain communication introduces verification assumptions beyond the security of individual blockchains.
• IBC and LayerZero minimize trust differently. IBC uses light clients and cryptographic proofs, while LayerZero relies on configurable DVNs.
• Configurability introduces trade-offs. LayerZero’s security depends on how applications select and combine independent verifiers.

In late July 2026, two unrelated cross-chain bridges were drained within hours of each other. AFX Trade lost roughly $24 million in USDC (USDC) after an attacker compromised five validator signing keys for the protocol’s custody bridge on Arbitrum, enough to satisfy its quorum and authorize the withdrawal. Hours later, the Verus-Ethereum bridge lost $7.5 million after an attacker exploited the same class of validation flaw that had been used against it just two months earlier.

The attacks exposed two different versions of an underlying problem. AFX’s bridge trusted a validator quorum that became useless once enough private keys were compromised. Verus relied on cross-chain validation logic that interpreted malicious notarization data differently across chains. Neither attack undermined the blockchains beneath the surface. Instead, the failures occurred in the systems responsible for deciding whether information arriving from another chain should be trusted.

That is the central problem of blockchain interoperability. A blockchain can verify its own state, but it cannot automatically know what happened in another blockchain. Interoperability requires a system to carry information across chains and verify it. Traditional bridges have solved the imbroglio with multisigs, validator committees, or other trusted intermediaries. However, this created concentrated points of failure around systems holding billions of dollars in assets.

The Inter-Blockchain Communication Protocol (IBC) and LayerZero take different approaches to reducing this trust: IBC emphasizes onchain verification, whereas LayerZero v2 gives applications configurable verification infrastructure. Other designs use zero-knowledge (ZK) proofs, optimistic verification, and economic security.

The central question is: How can one blockchain trust another blockchain on an event?

Onchain verification vs. configurable security in cross-chain protocols

Let’s begin with an overview of IBC, LayerZero, and bridges.

IBC: Make the blockchain verify

Instead of trusting an intermediary to report cross-chain activity, IBC enables the receiving blockchain to verify the data directly.

IBC uses light clients and cryptographic proofs to establish communication between chains. The destination chain maintains a light client representing the source chain’s consensus state. Relayers transport packets and proofs between the networks. If a relayer submits an invalid proof, the destination chain would reject it.

The mechanism pushes IBC’s core trust assumption toward the consensus security of the participating chains and the precision of their light-client implementations. There is no standalone bridge committee whose signatures alone establish the occurrence of an event. The model provides strong trust minimization, but that security comes with an engineering cost. Clients need to maintain compatibility as consensus mechanisms and networks evolve.

LayerZero v2: Make verification configurable

LayerZero takes a different route. Its v2 architecture separates message transport from verification and allows applications to define the security configuration used to approve incoming messages.

Decentralized Verifier Networks (DVNs) lie at the center of this model. Applications can not only choose which DVNs are to verify messages but also establish thresholds/combinations of mandatory/optional verifiers.

It creates a fundamentally different security proposition from IBC.

Instead of imposing one verification model across every application, LayerZero enables developers to select a configuration suited to the value and risk aspects of their application. A protocol handling substantial collateral could require verification from multiple independent DVNs, while another application might choose a lighter configuration in pursuit of speed, cost, or simplicity.

The advantage is flexibility. The trade-off is that the configuration itself becomes part of the security perimeter.

Traditional bridges: Trust the gatekeepers

As cross-chain bridges rely on vastly different technologies, it is inaccurate to group them under a single architecture.

While light-client, optimistic, and zero-knowledge (ZK) bridges offer higher security by minimizing reliance on third parties, traditional federated or externally verified bridges remain a baseline for comparison. Federated bridges typically rely on custodians, multisigs, or validator networks to attest that cross-chain transactions occurred.

Historically, bridges have depended on custodians, multi-signature setups, or dedicated validator networks to attest to these transactions. Once a sufficient threshold of authorized nodes confirms the event, the target contract executes the corresponding action.

This framework offers broad compatibility and relatively simple setup, but it centralizes substantial control into a small set of credentials.

If an attacker compromises enough validator or multisig keys, they may bypass both blockchains’ underlying consensus entirely, as they only need to breach the bridge connecting them.

The finality trade-off: How cross-chain architectures handle chain reorgs

Cross-chain applications must reconcile different definitions of transaction finality. Acting before the source chain has sufficiently settled risks executing a message based on history that is later reorganized.

IBC derives finality from consensus

As IBC uses light clients, its view of finality is closely connected to the consensus properties of the networks involved.

Many Cosmos chains use Byzantine Fault Tolerance (BFT)-style consensus, offering strong finality. Once consensus has been reached, reverting a block requires conditions substantially different from the probabilistic reorganization risk found in other consensus models.

Connecting networks with different finality properties requires light-client implementations capable of accounting for those differences.

Greater confidence can also translate into greater latency. Waiting until the source chain provides sufficient finality is safer than acting immediately, but users may have to wait longer for cross-chain execution.

LayerZero makes finality part of the security configuration

LayerZero’s modular architecture provides greater flexibility around verification and execution.

Applications can determine how much confirmation or verification they require before accepting cross-chain messages, while the selected verification infrastructure determines whether the required state has been established.

The flexibility allows different applications to adopt different risk tolerances.

A gaming application handling low-value interactions might favor speed. On the other hand, a lending protocol accepting cross-chain collateral could demand a considerably stronger verification setup.

However, lowering latency can mean accepting greater assumptions somewhere else in the stack.

Federated bridges can trade certainty for speed

Conventional bridges frequently compete on transaction speed and user experience. Waiting for lengthy finality can undermine both.

Operators may therefore recognize deposits after a defined confirmation threshold rather than waiting for an optimal settlement guarantee.

It may work under normal conditions, but it creates an important question when conditions become abnormal. If a reorganization occurs after assets have already been released elsewhere, who absorbs the loss?

In a federated architecture, the answer may ultimately depend on bridge reserves, governance decisions, or operator intervention rather than protocol-level verification alone.

From token bridges to remote execution: The expanding blast radius of arbitrary messaging

Early forms of blockchain interoperability focused mainly on moving assets from one network to another. Such applications gradually grew in sophistication. Cross-chain messaging can now tell another blockchain to invoke a smart contract, change application state, mint a new asset, take part in governance decisions, or unlock collateral.

This difference is important. The more powerful and expressive these messages become, the greater the potential damage in case of an error.

Asset transfers keep the problem contained

Token bridges have a relatively narrow mandate: move representations of value between chains. IBC verifies transfers against light-client state, LayerZero applications use its messaging layer, while federated bridges rely on their validator or custody models. The operation is limited, but the economic exposure can still be substantial.

Arbitrary messaging widens the attack surface

Generalized messaging turns interoperability infrastructure into a remote-execution layer capable of changing application state across chains. IBC supplies structured packet communication that includes acknowledgements, ordering guarantees, and timeouts. LayerZero is built for arbitrary omnichain messaging, enabling developers to design applications whose parts interact across multiple networks. This flexibility shifts extra responsibility onto the application layer itself.

Bridge hacks reveal multiple layers of failure

The history of cross-chain exploits demonstrates why reducing interoperability risk to “bridge security” is too simplistic.

Ronin, Wormhole, and Nomad all suffered major failures, but they did not fail for the same reason.

• Credential concentration (Ronin): Attackers obtained enough validator keys to reach the authorization threshold and approve fraudulent withdrawals.
• Verification failure (Wormhole): An attacker exploited a vulnerability in the system’s verification logic and minted wrapped assets without legitimate backing.
• Message-validation risk (Nomad): A flawed contract upgrade allowed invalid withdrawal messages to be treated as legitimate, leading to widespread copying of the exploit.

Interoperability is a stack of attack surfaces spanning consensus, verification, contracts, validators, key management, relayers, and destination applications.

How IBC changes the attack surface

IBC attempts to reduce dependence on external authorization by requiring destination chains to verify cryptographic proofs against their light-client view of the source network.

Relayers cannot simply invent valid state, shifting major risks toward consensus failures, light-client vulnerabilities, and application-level implementation.

Trust minimization, therefore, does not mean risk elimination; it means moving the critical security boundary deeper into cryptographic and consensus verification.

LayerZero distributes the verification problem

LayerZero’s configurable DVN model enables applications to avoid dependence on one verification provider.

A high-security application may require agreement from multiple independent DVNs before accepting a message, minimizing the consequences of compromising any individual verifier.

Using several verifiers provides limited additional protection if they share infrastructure, operators, or correlated failure modes. Developers must therefore evaluate not simply the number of DVNs but their actual security independence.

LayerZero’s flexibility becomes an advantage only when applications use that flexibility intelligently.

Bridges are moving toward cryptographic verification

The bridge ecosystem itself is also evolving.

Multi-party computation (MPC) and threshold-signature systems reduce the risk of complete private keys being concentrated with individual operators. Optimistic designs can introduce an interval before messages become final. Light-client systems verify source-chain state directly, while zero-knowledge architectures provide compact cryptographic evidence that specified state transitions occurred correctly.

The boundary between a bridge and an interoperability protocol is consequently becoming increasingly blurred.

Systems are attempting to replace trusted assertions with verifiable evidence wherever practical.

IBC vs. LayerZero vs. federated bridges

The table below compares the three architectures:

The trade-off is clear: IBC prioritizes trust minimization at greater integration cost; LayerZero prioritizes configurable security and broad messaging; and federated bridges favor simplicity and liquidity while retaining greater external trust assumptions.

The interoperability trilemma emerges from the choice you make. Reducing trust requires more verification, while maximizing speed and flexibility tends to move assumptions elsewhere in the system.

From committees to ZK-proofs: Navigating the interoperability paradigm shift

Blockchain interoperability is moving toward relying less on trust to verify data across networks. Zero-knowledge systems could accelerate that shift by allowing destination chains to verify cryptographic evidence of source-chain state rather than trust committee attestations.

This could narrow the gap between the security benefits of native verification and the usability of generalized cross-chain messaging.

Shared-security models offer another route. Rather than giving every bridge or interoperability layer an independent security perimeter, multiple networks or services can potentially derive economic security from a common validator or staking framework.

Cross-chain sequencing could push coordination deeper, reducing some of the asynchronous execution problems created when independent networks communicate after transactions have already occurred.