Axelar: Comparing Interoperability Security Architectures with InteropBeat

1. Security Thresholds and Bridge Risk

Cross-chain interoperability security should be assessed not only by speed or cost, but by how widely the authority to approve transaction validity is distributed. InteropBeat’s Security Threshold provides a framework for comparing this difference.

A bridge typically works by locking or burning an asset on one chain and issuing a corresponding asset on another. The destination chain, however, cannot directly verify the state changes that occurred on the source chain. It must therefore rely on information submitted by separate verifiers before approving asset issuance or message execution.

InteropBeat organizes this approval structure into a metric called the Security Threshold, making it possible to compare different interoperability solutions on a consistent basis. Security thresholds are generally represented in the form of N/M. This means that, for a fraudulent transfer to be approved, at least N out of M verifiers would need to be compromised or collude. The N/M notation is not unique to InteropBeat. It is a common threshold notation in cryptography and blockchain security. InteropBeat applies it consistently to compare how approval authority is distributed across interoperability solutions.

The higher the N value, the more verifiers an attacker must compromise simultaneously, increasing the difficulty of attacking the approval structure. However, a security threshold does not describe bridge security in its entirety. Actual loss risk also depends on factors such as smart contract implementation, key management, operational policies, application-level verification configuration, verifier independence, and stake distribution. For example, the 2022 Wormhole exploit was caused not by verifier collusion, but by a flaw in signature verification within the contract.

Therefore, a security threshold should not be read as a definitive measure of whether a bridge can be hacked. Rather, it should be understood as a benchmark for comparing how widely approval authority is distributed. Smart contract flaws and key management issues can often be addressed through audits and operational improvements, but approval authority concentrated among a small number of verifiers can leave a structural single point of failure even when other components are robust.

2. How Major Interoperability Solutions Verify Cross-Chain Transactions

Based on InteropBeat, the verification structures of major interoperability solutions can be summarized as follows.

Security thresholds become meaningful when viewed together with the underlying verification structure. In a structure like Axelar’s, where approval conditions are fixed at the protocol level, the same baseline verification structure applies across all applications. In contrast, in a structure like LayerZero’s, where applications choose their own verification configuration, the security threshold can vary depending on each application’s choices. In LayerZero, these external verification networks are referred to as DVNs, or Decentralized Verifier Networks.

CCIP uses a dual verification structure that requires two independent verification groups to approve a message. One is the Committing DON, or Decentralized Oracle Network, composed of Chainlink node operators. The other is RMN, or Risk Management Network, a separately operated verification network. Because both groups must approve a message, CCIP is difficult to compare using a single N/M value.

Wormhole’s Guardians are a fixed set of 19 verifiers designated by Wormhole. They independently observe and sign cross-chain messages. A message must receive signatures from at least 13 Guardians to be approved.

InteropBeat distinguishes between Axelar Classic and Axelar Amplifier. The 28/53 figure shown in the table refers to Axelar Classic, while Axelar Amplifier is listed as 19/28. Even under the Amplifier threshold, Axelar maintains one of the most distributed approval structures in the comparison.

If we compare solutions by the minimum number of verifiers an attacker would need to compromise, or the N value, the distribution spectrum appears as follows.

Approval Authority Distribution Spectrum

Note: The spectrum includes only solutions expressible as a single N/M value; CCIP is excluded due to its dual verification structure.

Structures on the left rely on approval from a larger set of verifiers. Moving to the right, the minimum configurations increasingly depend on a smaller number of verifiers. This is not merely a numerical difference; it reflects the scope of compromise required for a fraudulent transfer to be approved.

3. The Risks of Application-Level Verification

There are clear advantages to allowing applications to choose their own verification configuration. Each application can adjust its verification strength based on its risk profile, cost structure, and operational environment. In practice, however, lower-security configurations may be selected due to cost, convenience, or development speed. The ability to choose a distributed configuration is therefore separate from whether sufficiently distributed configurations are actually used in production.

Dune’s LayerZero DVN Setups dashboard shows that lower-security DVN configurations are widely used across LayerZero applications. By deployment count, 41.3% of all LayerZero deployments operated with a 1/1 configuration, meaning only one verifier was required. The strongest 4/4 configuration accounted for just 0.5% of deployments.

The same pattern appears when looking at message volume. Over a 90-day period, among roughly 2.1 million messages, 1/1 configurations accounted for 40.1% of total message volume, while 2/2 configurations accounted for 53.0%. High-volume assets such as wBTC and Stargate ETH appeared among the largest 1/1 message flows.

A similar pattern is visible at the token level. Many major LayerZero-based assets, including USDe, USDT0, and weETH, operate under 2/2 configurations. Stargate ETH, meanwhile, uses either 1/1 or 2/2 depending on the transfer route. This shows that even within the same protocol, and even for the same asset, the approval structure can differ depending on the source chain.

Case Study: The KelpDAO Exploit

The KelpDAO exploit in April 2026 illustrates the risks that can arise when verification configuration is selected at the application level. Chainalysis reported that the attacker stole approximately $292 million, or 116,500 rsETH, from KelpDAO’s LayerZero bridge. The incident was described not as a smart contract bug, but as an attack targeting off-chain infrastructure. LayerZero’s official statement noted that rsETH was operating with a single-DVN configuration at the time.

The relevance of the KelpDAO case lies in the structural risk created by insufficiently distributed verification paths. The number of verifiers required for approval is directly tied to security design, and configurations that depend on a single verifier can effectively become single points of failure. In addition, when bridged assets are used as collateral in lending markets or other DeFi protocols, losses can spread to adjacent services.

At this point, the comparison returns to the distribution of approval authority. Unlike structures where verification strength varies by application, a protocol-level approval model is designed to reduce reliance on any single approval path.

4. Where Axelar Stands

From this perspective, Axelar shows a 28/53 Security Threshold under InteropBeat, the highest N value among the solutions compared in this article. Because this approval condition is applied at the protocol level rather than through application-level configuration, applications built on Axelar cannot lower the verification configuration to something like 1/1.

As a result, Axelar maintains consistent baseline approval conditions, unlike structures where the security level can vary from one application to another. Its high security threshold and protocol-level approval conditions can be understood as a design choice aimed at reducing reliance on single-approval paths.

Higher security thresholds may involve trade-offs in latency or cost. However, given the scale and recurrence of major bridge-related losses, interoperability security cannot be evaluated separately from the distribution of approval authority.

5. Interoperability Security Comes Down to Distributed Approval

Even when grouped under the same category of interoperability solutions, verification structures can differ significantly. A structure that requires an attacker to compromise 28 verifiers and a structure that requires only one verifier may both be described as “bridges,” while operational data shows that lower-security configurations are not merely edge cases.

Therefore, when choosing a bridge or evaluating bridged assets, the key question should not be “How many chains does it support?” but rather, “Across how many verifiers is approval authority actually distributed on this route?” In structures like LayerZero’s, where applications choose their own verification configuration, the protocol name alone does not determine the security level. The specific configuration of the application does.

By this standard, Axelar stands out for having the most widely distributed approval authority among the solutions compared, and for preventing individual applications from lowering that baseline. Interoperability is often discussed in terms of coverage and speed, but repeated bridge-related losses point to a different benchmark. The more important question is not simply how many chains a system connects, but how many independent verifiers are required to approve the cross-chain transactions it enables.

Key Source

InteropBeat - Interoperability Security Comparison Dashboard

Dune - LayerZero DVN Setups Dashboard

Chainlink - Seven Key Cross-Chain Bridge Vulnerabilities Explained

Chainlink Docs - CCIP Architecture

Wormhole Docs - Guardians

Chainalysis - Wormhole Hack February 2022

Chainalysis - Inside the KelpDAO Bridge Exploit

LayerZero Blog - KelpDAO Incident Statement

Disclaimer

The contents of this report are for informational purposes only and do not constitute a recommendation or basis for legal, business, investment, or tax advice under any circumstances. References to specific assets or securities are for informational purposes only and do not represent an offer, solicitation, or recommendation to invest. The final responsibility for any investment decisions lies solely with the investor, and this report should not be used as a guideline for accounting or legal judgment.

As a matter of principle, the author does not trade related assets using material non-public information obtained during the research or drafting process. The author and Catalyze may have financial interests in the assets or tokens discussed herein and may serve as a strategic partner to certain networks.

The opinions and analyses expressed in this report reflect the author's personal views and do not necessarily represent the official position of Catalyze or its affiliates. All information is current as of the date of publication and is subject to change without prior notice.