Explaining Decentralized Verifier Networks

Background: Why Modular Security

LayerZero is a messaging protocol — a permissionless, open framework designed to securely move information between blockchains. It empowers any application to bring its own security, execution, and crosschain interaction, providing a predictable and adaptable foundation for decentralized applications living on multiple networks.

With LayerZero, an application on chain A sends a message and an application on chain B receives it. The question in between is how to confirm that the message arriving on B was actually sent from A.

Most cross-chain bridges and interoperability protocols have one shared verification layer defined and configured by the bridge operator or protocol. Every application on the system trusts the same signers, runs against the same security model, and inherits the same risks, lacking the ability to eliminate the single point of failure associated with early bridge designs.

LayerZero is built on the premise that the answer on how to verify messages depends on the asset issuer, application developer, use case, and chain. Different applications have different needs, so security itself has to be configurable.

Every application on LayerZero chooses its own verifiers, called Decentralized Verifier Networks (DVNs). An application can require any combination of DVNs and mix verification methods, operators, infrastructure, and jurisdictions. The choice is per-channel, per-application, and onchain. The protocol enforces it; the application owns its security.

As more value moves through LayerZero and issuers with more varied needs come onchain, we expect DVNs to diversify further and issuers to take a larger role in configuring their own verification.

What is a DVN?

A DVN is an independent entity that verifies a cross-chain message on behalf of an application. Mechanically, it is a smart contract paired with off-chain infrastructure.

A DVN runs off-chain infrastructure to observe events on a source chain, decide whether they are valid and final, and submit cryptographic attestations of the message contents to the destination blockchain.

When an application sends a message:

The DVNs configured for that channel observe the PacketSent event on the source chain and wait for sufficient finality.
Each DVN independently confirms the integrity of the payloadHash using its own verification scheme.
Each DVN calls verify on the destination chain's Message Library.
Once the required DVNs and any optional threshold have signed off, any caller (typically an Executor) commits the packet to the Endpoint and triggers execution.

The LayerZero protocol is permissionless. This means anyone can run a DVN and the protocol is agnostic to how a DVN verifies, whether by signed attestation, validity proof, optimistic challenge window, or otherwise. The protocol cares only that the DVN delivers an attestation of the payloadHash.

What a DVN set is for

An application configures a group of independent DVNs who agree that a message left chain A and should execute on chain B. The set should be chosen to prevent DVNs from colluding to wave through a fraudulent message (a safety failure), censoring a legitimate one (a censorship failure), or delaying message delivery (a liveness failure). Addressing these three risks is the purpose of a configurable DVN set.

Each application defines a set of required DVNs, a set of optional DVNs, and an optional DVN threshold. Required and optional DVNs are represented as lists of unique addresses of DVN contracts. All required DVNs must attest before a message is accepted. If a required DVN does not attest or attests to different data, the message will be stalled in the protocol. For example, a "1 of 3 of 5" configuration means there is 1 required DVN (X), and at least 3 (Y) out of 5 (N) optional DVNs must also verify the message for it to be executed.

The idea here is for multiple parties, chosen by the application owner, to sign off on a transaction before it is executed, offering redundancy against malicious actors, single points of failure, or potential censors. It also empowers application owners to update their configuration to improved verification technology or new DVNs as they come online.

This selection, together with the chosen MessageLib and block confirmations is what LayerZero calls a Security Stack. (For a discussion of LayerZero Labs' Security Stack defaults, see 'A Note on Defaults' below.) Onchain the Security Stack lives in UlnConfig:

struct UlnConfig {

uint64 confirmations; // Block confirmations required

uint8 requiredDVNCount; // X, all of these must verify

uint8 optionalDVNCount; // N, total optional DVNs

uint8 optionalDVNThreshold; // Y, threshold of optional DVNs

address[] requiredDVNs;

address[] optionalDVNs;

}

An OApp that explicitly sets its Send and Receive libraries and configures its DVN set ensures that it then owns its unique Security Stack. After that, only the OApp owner can change DVNs, block confirmations, or any other parameter.

The Current DVN Landscape

Because the protocol is permissionless, any entity can build a DVN, or wrap an existing system in a DVN Adapter as long as it can attest to a message hash. A DVN may be self-hosted, federated across independent providers, an adapter, or some sort of hybrid.

The DVNs live today span many categories. An issuer picks from these, or runs their own.

Application-run DVNs. BitGo operates a DVN as a required signer within the WBTC Security Stack. Paxos operates its own for PYUSD and USDG. Ondo Finance does the same for USDY and its tokenized stocks with the Ondo Token Bridge.
Client-diverse signers (Canary). Canary operates an in-house Go client within AWS Nitro enclaves, with attestations backed by TEE hardware and staked collateral. LayerZero Labs is also building a Rust-based DVN.
DVN Adapters. Adapters wrap third-party networks like CCIP. Adapters are useful when an issuer wants the trust model of an existing third-party messaging network as one signer in their set.
Enterprise signers. Worldpay , Google Cloud, Nansen, Blockdaemon, P2P.org, Luganodes, Horizen Labs, Nethermind, and LayerZero Labs-operated attestation-based DVNs.
Institutional DVNs. Deutsche Telekom MMS operates a DVN on its Open Telekom Cloud, designed for banks, stablecoin issuers, and exchanges. The Fidelity Center for Applied Technology launched a DVN earlier this year, with Ondo Finance as its first integrator.

How to Configure a Strong DVN Set

DVN selection should be based on diversity across multiple axes. This will harden against cloud outages, natural disasters, bugs in code, jurisdictional issues, weaknesses in single verification methodologies or even DVN compromise. Configuring diversity across the following factors can be used to construct strong DVN sets:

Verification method. Optimize for the number of independent methods in the required set, not the total DVN count. Mix TEE attestation, threshold signatures, ZK proofs, light clients, and cryptoeconomic security so no single flaw breaks the entire stack.
Client software. Ensure different client software implementations to mitigate the risk of a bug in one client affecting the entire set. Most DVNs sign through Gasolina, which handles gas and transaction submission so operators can focus on verification. DVN builders can implement different clients for Gasolina that check for different properties, and still leverage essence gas abstraction. For instance, Canary does this by running its own Go client and is the production option for a second client in the required set today. LayerZero Labs is designing a DVN client in Rust.
Infrastructure. Cloud failures correlate within providers, regions, and accounts. Jurisdictions correlate legally. Data centers correlate physically. The current DVN set spans AWS, GCP, Open Telekom Cloud, and bare metal across multiple jurisdictions, so issuers can spread across infrastructure to mitigate single points of failure.
Operator independence. Look for different organizations, key custody, signing personnel, reporting lines, counsel, and regulatory domiciles. Reputation is also another signal: operators with a market position to protect have a long-term reason not to sign fraudulent messages. Cryptoeconomic DVNs can harden reputational claims economically through staked collateral and slashing.

A Note on Defaults

If developers do not explicitly configure a Security Stack, the protocol falls back to a default DVN selection, owned by LayerZero Labs. To be clear, pointing to defaults is a delegation of trust to a third party. The LayerZero Labs multisig sets the defaults for all pathways, chooses which messaging library to point to, and sets the default DVN configuration. Any application that does not pin its Security Stack is, by definition, fully reliant on that multisig for the parameters of its own security.

All applications that are not using defaults are unaffected by what the LayerZero Labs multisig does, because their parameters cannot be changed by anyone other than the OApp owner. The official guidance from LayerZero Labs:

Set your own DVN configuration and block confirmations rather than inheriting defaults.
Lock your libraries by calling setSendLibrary and setReceiveLibrary.

The Marketplace Ahead

The DVN architecture already supports more than most current applications use. An application’s Security Stack is per-channel and onchain, which means an application can run different DVN sets on different chains without any code changes. An issuer with an OFT on Ethereum, Solana, BNB Chain, and Hyperliquid can run a 7-of-9 with TEEs and ZK on the Ethereum channel and a leaner 2-of-3 on lower-volume ones. Security can also scale with the application: an issuer can start with a leaner stack and expand it as value at risk grows.

A few directions the DVN architecture may support that the market has not yet built:

Specialized DVNs that compete on a single axis. For instance a Speed DVN could sell its high-speed attestation infrastructure to verify transactions as fast as the underlying chain itself, useful for trading and settlement workflows where the messaging layer needs to keep up with traditional rails – though with re-org risks that the application and DVN should be aware of. A Subscription DVN could run on managed signing paths like Gasolina to deliver attestations at the lowest practical price point. The service is priced for high-volume, low-value flows and billed monthly. A Compliance DVN might embed regulatory enforcement directly in verification. A DVN could come to market as a MiCA or NYDFS-compliant signer, or a Travel Rule validator that screens KYC, AML, sanctions, and counterparty metadata before settlement.
More DVN Adapters. Adapters today wrap a small set of third-party messaging networks like CCIP. The category will widen as more developers build wrappers for other native validation networks. Native bridge adapters, multi-protocol attestation systems, oracle-and-bridge composites, and cross-chain validity proof networks are all viable.
Per-transaction verification markets. Perhaps the furthest extension is a dynamic DVN market on a per-message basis. An asset issuer could publish a policy onchain; competing DVNs bid for the right to verify each transaction within that policy, on price, speed, jurisdiction, or any other dimension the issuer encodes. In this potential future, maybe Security Stack becomes a market rather than a static configuration.

Conclusion

LayerZero’s architecture allows every application to own its security end-to-end by configuring its own Security Stack. The protocol enforces the security policy chosen by the application, whether that is a 3-of-3 default or a complex multi-DVN configuration with a self-run required signer. This lets applications opt out of the systemic risk of a shared validator set and allows applications to select verification methods, operators, and economic guarantees that match their specific needs. The strongest version of this is an issuer who runs their own DVN as a required signer in their own Security Stack. At that point, the trust assumption for moving the asset across chains collapses to the same assumption as holding the asset in the first place.

About LayerZero

LayerZero is a permissionless, censorship-resistant, and immutable protocol that connects blockchains. Using LayerZero, developers can send and compose arbitrary messages across chains while preserving full control over their application's security.