Interoperability protocols enable communication between different chains. This capability is essential for application developers who need to write data to or read data from other chains. For instance, a money market might transfer tokens to rebalance liquidity between Ethereum and Solana, or a game could verify NFT ownership on Ethereum to allow players to use their assets on the game’s app-chain.

To ensure secure message transmission, a trusted verifier or set of verifiers is required to maintain message integrity — a fact supported by Communication Across Distributed Ledgers.

Two primary verification models exist: shared and isolated.

• Shared: A fixed, restricted number of verifiers used by all applications.
• Isolated: An unrestricted set of verifiers, configured independently by each application.

This article explains why isolated security models are superior to shared ones since they grant applications with sovereignty, ensuring both security (i.e. integrity of messages) and liveness (i.e. continuous operation) even under the most adversarial conditions.

Shared Security

Applications using shared security setups are required to trust the security and liveness of a common verifier set, subjecting them to several challenges:

• No Recourse for Compromise: If a shared verifier set is compromised, every application depending on it loses security and liveness, and has limited recourse in such scenarios.
• No Security vs. Cost Tradeoff: Shared sets impose uniform security standards, which may result in high costs for some applications or insufficient security for others.

These limitations hinder an application’s ability to adapt to its unique requirements. Shared models prevent applications from optimizing their security and cost balance and leave them vulnerable, with limited ability to recover, if the verifier set fails.

Proponents of shared security argue that faulty verifiers can simply be replaced, but this perspective is fundamentally flawed. Transitioning from a shared model to an isolated one in response to failure is not a quick fix. It requires significant technical upgrades — onchain and offchain — such as establishing verifier registries, reconfiguring applications, and updating contracts. This level of architectural overhaul cannot be achieved in a timely manner, leaving applications vulnerable for extended periods–likely indefinitely.

The key takeaway is that shared security setups make it impossible for individual applications to manage their own security and liveness. This dependency creates a single point of failure, putting the entire protocol and all dependent applications at risk.

Isolated Security

Isolated security models resolve the shortcomings of shared setups by allowing applications to independently select their verifiers. This flexibility offers two major benefits:

• Unbounded Fault Tolerance: Even in the worst case scenario where all existing verifiers lose liveness, application developers can operate their own verifiers to continue operation. This ensures continuity of both security and liveness.
• Application Sovereignty: Applications are not beholden to a central authority to replace verifiers. Instead, they can select their own verifiers, including running the verifier themselves, ensuring complete control over their security architecture.

Critics, such as in Circumventing LayerZero: Why Isolated Security is No Security, argue that isolated security models place the burden of assessing security risks on end users, which they claim is impractical. Additionally, they warn that a successful attacker could modify the security model to serve malicious purposes (e.g., “drain funds or misuse it in any other way”).

While these concerns are valid, they overlook the critical point: applications must be designed to withstand worst-case scenarios, such as when some or all verifiers are compromised. In shared security models, trust is centralized in a single verifier set with limited fault tolerance. If this verifier set fails, all dependent applications lose both security and liveness — meaning, they lose the ability to operate (and likely recover). In contrast, isolated security systems provide unbounded fault-tolerance, allowing verifier sets to be reconfigured as needed. This ensures that security and liveness are maintained under any circumstances.

Real-World Example

The best part is that this isn’t just theoretical–hundreds of applications already use isolated security via LayerZero for the reasons mentioned above.

For example, Ondo, which issues tokenized, yield-bearing products, has set up an isolated verifier system as follows:

• Polyhedra: ZK-based DVN
• Axelar: Shared security verifier set consisting of 75 validators.
• Ondo: Application-specific DVN run by Ondo.
• LayerZero Labs: DVN managed by LayerZero Labs.

Ondo’s setup reflects high client (i.e., verifier) diversity, optimizing for security to ensure continuous operation even under adversarial conditions. Additionally, Ondo has the flexibility to modify its DVNs as needed, ensuring both security and liveness are consistently maintained.

A Decentralized Verifier Network (DVN) is a verifier used to validate messages transmitted through the LayerZero Protocol.

The Fundamental Truth

The undeniable reality of interoperability is that isolated security models are superior since they grant applications the sovereignty needed to retain security and liveness in the most adversarial scenarios.

This is a core property of LayerZero, and a primary reason why Ondo, along with hundreds of other applications, have adopted this approach for their security setups.