LayerZero v2 is an omnichain messaging protocol that splits verification from execution. The redesign moved security configuration from the protocol to the application: developers pick which Decentralized Verifier Networks (DVNs) attest to their messages and which executors deliver them, with the LayerZero Endpoint contract on each chain enforcing only that the chosen verifiers all agree. The result is a layered architecture where each component is replaceable and the trust model is configurable per application.
​

Released in January 2024, v2 supersedes the original Ultra Light Node design that pinned every application to one Oracle and one Relayer. As of April 2026, LayerZero is deployed on more than 90 chains and has carried over 200 million messages, according to LayerZero Scan. This article walks through the v2 architecture component by component.
​

LayerZero v2 is the second-generation design of LayerZero's omnichain messaging protocol. It is a set of immutable Endpoint contracts deployed on every supported chain, plus a marketplace of pluggable verifiers (DVNs), executors, and message libraries that applications combine to define how their messages are secured and delivered.
​

The core insight is that there is no universal trust model that fits every cross-chain use case. A $100 million treasury rebalance and a $5 retail token transfer have different security requirements. v2 lets the application owner specify a Security Stack — typically two to five DVNs that must all sign — rather than inheriting a one-size-fits-all multisig. The full specification is in the LayerZero v2 documentation, and the protocol's audited Solidity contracts live in the LayerZero-v2 GitHub repository.
​

v2 maintains backward compatibility with v1 OApps (Omnichain Applications) but introduces new primitives — OFT (Omnichain Fungible Token), ONFT (Omnichain Non-Fungible Token), OApp Read, and the Compose pattern — that are only available on v2. Most new omnichain applications since 2024 deploy directly on v2.
​

A v2 message moves through five components. The application contract calls the source-chain Endpoint, the Endpoint records the message in a configured Message Library (MessageLib), the chosen DVNs observe the source-chain event off-chain and sign attestations on the destination chain, an executor calls the destination Endpoint to commit the verified message, and the destination Endpoint delivers the payload to the receiving OApp.
​

The Endpoint is intentionally minimal. It enforces nothing about message contents — that is the application's job — and it does not run validation logic itself. Verification is delegated to the configured Security Stack. Once enough DVNs have signed, any executor can pay the destination gas and trigger delivery. This separation is what makes v2 modular: changing the verification policy or the executor does not require redeploying the application.
​

One subtle property is that DVNs sign on the destination chain, not off-chain. Each DVN runs a smart contract on every chain it supports. When the DVN's off-chain agent observes the source event, it submits a transaction on the destination chain attesting to the source message hash. The destination Endpoint then checks that the application's required DVN set has all signed before allowing the executor to commit. This on-chain attestation pattern means the verification step is auditable and replayable.
​

The v2 architecture is intentionally composed of small, swappable parts. Five components matter most.
​

An immutable contract deployed once per chain. It exposes send and lzReceive as the two entry points for applications, manages nonce ordering for each (source, destination, sender) triplet, and reads each application's configured MessageLib and Security Stack. The Endpoint is the single trust anchor — applications inherit only the Endpoint's correctness, not any verifier's.
​

Versioned, upgradeable contracts that handle message encoding, fee calculation, and verification orchestration. UltraLightNode302 is the default v2 MessageLib. Applications can pin a specific MessageLib version to immunize themselves from future protocol upgrades. The MessageLib source is open and audited.
​

Independent off-chain operators that attest to message validity. As of April 2026, more than 50 DVN operators run on the network, including LayerZero Labs, Google Cloud, Polyhedra Network, Nethermind, Animoca, Horizen Labs, and Delegate. Applications choose a Required DVN set (must all sign) and an Optional DVN set with a threshold (e.g., 2 of 4 must sign). The full DVN catalog is at LayerZero's DVN config docs.
​

Off-chain agents that pay for destination gas and trigger lzReceive after verification. Executors compete on price and reliability. Most applications use the default LayerZero Labs Executor, but any address can act as an executor — the protocol makes the role permissionless.
​

The application-defined policy that combines DVNs, MessageLib version, and confirmation thresholds. Applications can configure a different Security Stack per (source, destination) pair, allowing different trust models for different routes. A common pattern is two Required DVNs (LayerZero Labs + Google Cloud) plus one Optional DVN from a 2-of-3 threshold for cost optimization.
​

v2 introduced the Omnichain Fungible Token (OFT) standard as a reference contract for tokens that exist natively across multiple chains. An OFT does not bridge — it burns on the source and mints on the destination, eliminating the wrapped-asset risk that plagued earlier bridge designs. Stargate Finance, Tapioca, and Pendle's PT tokens use OFT as their cross-chain asset format.
​

Composability comes from the Compose pattern. After lzReceive delivers a message, the receiving contract can call back into the Endpoint with a separate lzCompose transaction that triggers a follow-on action. This separates verification from downstream execution and prevents a malicious or buggy receiving contract from blocking message delivery. The pattern is documented in the LayerZero Composer overview.
​

OApp Read, added in late 2024, lets applications query state from a remote chain without sending a message first. The receiving chain runs an off-chain RPC call against the source chain through the same DVN attestation pipeline, returning the result asynchronously. As of April 2026, Read is used by yield aggregators that need cross-chain TVL data and by perpetual exchanges that mirror collateral state across deployments.
​

The DVN model trades a fixed protocol-wide trust assumption for application-level configurability. The trade-offs are real and worth naming.

For a comparison of how this verification model differs from external validator networks like Wormhole or permissionless ISM stacks like Hyperlane, see cross-chain messaging security models compared.
​

Most v1 OApps that have not migrated still work. The v1 Endpoint contract continues to operate on every chain where it was originally deployed, and v1 messages route through the Ultra Light Node design that pinned each application to one Oracle and one Relayer. What v1 does not get is access to the new primitives — OFT, Compose, OApp Read — and the Security Stack flexibility that v2 introduced.
​

The migration path is documented in the v1-to-v2 migration guide. A typical migration involves deploying the OApp against the v2 Endpoint, configuring an initial Security Stack (often two DVNs to start), and either running both endpoints in parallel during a cutover or migrating user balances chain by chain. Stargate ran a multi-month parallel deployment in 2024; PancakeSwap migrated in a single coordinated cutover in late 2024.
​

One subtle migration cost is gas: v2 messages cost slightly more on the destination side because the Endpoint reads the application's Security Stack configuration on every lzReceive. The increase is typically 10–20k gas per message, which is meaningful for high-frequency applications but invisible for once-per-day flows.
​

By April 2026 most v1 applications have migrated to v2 or are running both endpoints in parallel. Five deployments illustrate the range of what the architecture supports.

Production LayerZero v2 deployments face four operational decisions that the protocol surfaces but does not resolve. Each has cost and security implications worth surfacing before integration.
​

DVN selection. The Required DVN set is the highest-impact choice. Most production applications run two to three Required DVNs from operationally diverse providers — for example, LayerZero Labs plus Google Cloud plus Polyhedra. A single-DVN configuration is cheaper but pins the application's security to one operator's correctness. Stargate Finance runs five DVNs across most of its routes; Radiant Capital tightened to five DVNs after its October 2024 incident.
​

Confirmation depth. Each DVN waits for source-chain finality before signing. The default is the protocol's recommended depth per chain (12 minutes on Ethereum L1, 64 confirmations on Arbitrum, 32 confirmations on Optimism). Applications can require deeper confirmations at the cost of latency.
​

Executor selection. The default LayerZero Labs Executor is reliable but not the only option. Applications that want diversified execution can configure a different executor or run their own. The trade-off is operational complexity versus single-vendor dependency.
​

Fee policy. Applications can pre-pay destination gas through the executor model or pass the fee through to end users. Most consumer-facing applications hide fees by paying upfront; B2B and treasury applications often expose the per-message cost for budgeting.
​

Eco Routes treats LayerZero v2 as one of its transport rails alongside Hyperlane and Circle CCTP. When a developer signs a stablecoin intent, the Routes selector evaluates each available rail by cost, finality, and security profile and picks the one that meets the constraint. For routes between Ethereum, Arbitrum, Base, Optimism, and other LayerZero-supported chains, v2 with a multi-DVN Security Stack is often the lowest-latency option for sub-million-dollar transfers.
​

The selection happens above the rail, not inside it. An application that integrates Eco Routes does not need to write its own LayerZero OApp, configure DVNs, or estimate fees. The Routes CLI and API expose a chain-agnostic interface, and Routes handles the v2-specific configuration internally for any route where v2 is the chosen transport. Builders evaluating cross-chain orchestration can compare the model against direct LayerZero integration in the chain abstraction vs multi-chain comparison.
​

v1 used a fixed Oracle plus Relayer model where the Oracle (Chainlink) reported block headers and the Relayer delivered proofs. v2 generalized this into the DVN/Executor model, where applications choose any number of DVNs from a marketplace and an executor delivers after verification. v2 is more configurable but requires applications to actively pick their security model.
​

A Decentralized Verifier Network (DVN) is an off-chain operator that attests to source-chain messages by signing a transaction on the destination chain. Applications configure which DVNs verify their messages. As of April 2026, more than 50 DVN operators run on LayerZero, including LayerZero Labs, Google Cloud, and Polyhedra.
​

A v2 message costs source gas plus destination gas (paid via the executor) plus a fee per Required DVN. For a simple OFT transfer between two L2s with two DVNs, the all-in cost is typically $0.10–$1.50 as of April 2026. Calldata size and DVN fees dominate; a single-DVN configuration is roughly 30–50% cheaper than a two-DVN configuration.
​

v2 Endpoints can coexist with v1 endpoints on the same chain, and v1 OApps continue to work. New OFT, OApp Read, and Compose features only exist on v2. Most actively maintained applications have migrated to v2 since the January 2024 release.
​

Yes. The Security Stack — DVN set, MessageLib version, confirmation threshold — is a per-application configuration stored in the Endpoint and updatable by the application's admin. Changing the stack does not require redeploying the OApp contract, but in-flight messages continue under their original configuration.
​