Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.layerzero.network/llms.txt

Use this file to discover all available pages before exploring further.

This page is the canonical reference for choosing a production DVN configuration. The shorter Integration Checklist tells you what to do; this page explains why, and gives you the risk-tier guidance to choose between a 2-of-2, a 2-of-3, a 3-of-N, and so on.

​
Threat model: what a DVN compromise means

A DVN attests that a specific payloadHash was emitted by a specific source-chain message. The library on the destination chain accepts a message for delivery only if every required DVN has attested. A 1-of-1 configuration means a single operator can:
  • Forge messages that were never sent on the source chain. Any operation reachable by a forged message — minting tokens on the destination, releasing collateral from a lockbox, granting permissions — can be executed without consent of the OApp owner or the source chain.
  • Suppress messages that were sent on the source chain (by simply refusing to attest), creating a censorship channel.
The compromise vector can be:
  • The DVN operator’s signing keys.
  • The DVN operator’s RPC infrastructure (an attacker who compromises every RPC the DVN reads can feed it false source-chain data, causing the DVN to attest forged events with its real keys).
  • The DVN operator’s deployment artifacts (binaries, S3-hosted config, etc.).
  • A social engineering or insider attack on the operator.
Multi-DVN configurations are not immune to all of these, but they require the attacker to compromise every required operator’s pipeline simultaneously. Provider diversity (different operators, different infrastructure, different verification methods) raises that bar substantially.

​
Choosing providers (the diversity rules)

The point of multi-DVN is to reduce correlated failure. A configuration with two DVNs run by the same operator, on the same infrastructure, with the same verification method, has correlated failure — a single compromise still breaks the pathway. Diversity dimensions, in order of priority:
  1. Operator diversity. Two different legal entities. Two different on-call teams. Two different deployment pipelines.
  2. Infrastructure diversity. Different cloud providers. Different RPC providers. Different signing key custody.
  3. Verification method diversity. Examples: a node-based committee DVN paired with a zk-proof DVN; a native-bridge DVN paired with an oracle DVN. An attacker who exploits a bug in one method does not automatically compromise the other.
  4. Geographic / jurisdictional diversity. Less critical for most threat models, but relevant if your pathway is exposed to government-level censorship risk.
Available providers are listed in DVN Addresses. Not every provider is deployed on every chain; check coverage before committing to a target configuration.

​
X-of-Y-of-N strategies

X-of-Y-of-N lets you mix mandatory and pluggable verifiers:
  • X (required) — DVNs that must attest every message. Increase X to require more independent witnesses.
  • Y (threshold of optional) — minimum number of optional DVN attestations. Increase Y to require redundancy beyond the required set.
  • N (total optional) — pool of optional DVNs available. Increase N to widen the pool.
Common patterns:
  • 2-of-2 strict: X=2, optional=[]. Both required DVNs must attest. Simplest. Single point of liveness failure for either DVN — if one DVN goes offline, all messages stall.
  • 2-of-3: X=2 with one optional, threshold 1 (where one of three operators is in the “optional” slot). Two named operators are required; the third operator can sub for one of the named two if needed. Better liveness.
  • 2-of-3 redundant: X=2, optional=[N=2, threshold=1]. Two required + at least one of two optional. Tolerates one optional DVN failing. Recommended for medium-value pathways.
  • 3-of-3 + 1-of-2 optional: Three required + one of two optional. Maximum security floor; widely used for critical assets.
For OFTs and bridges with composable downstreams (e.g., LRTs that flow into restaking, LSTs that collateralize lending), favor the higher tiers. The downstream blast radius of a forged mint is not bounded to your own protocol.

​
Confirmation depth

confirmations is the number of source-chain blocks the DVN waits before attesting. Low confirmations are fast but allow reorg-vulnerable messages to be confirmed. High confirmations are slow but resilient to source-chain reorgs. Recommended floors (tune to the source chain’s reorg profile):
  • Ethereum mainnet: 15 minimum, 32 (1 epoch) preferred for high-value pathways.
  • Optimistic L2s: typically 15–30; consult the L2’s reorg history before going below 15.
  • ZK L2s: typically lower (1–5) is acceptable once finality is committed to L1, but check the specific rollup’s finality model.
  • Solana: 32 minimum (consult the Solana DVN config docs).
  • Move chains (Aptos, Sui, IOTA): consult the per-VM config docs.
The CLI examples in this documentation use [1, 1] for fast iteration during development. Replace with production values before mainnet.

​
Executor concentration

DVNs support a multi-attestor security stack (X-of-Y-of-N); the Executor does not — there is exactly one Executor per pathway. For high-value pathways, evaluate:
  • Running your own Executor (see Build Executors).
  • Using a different third-party Executor.
  • Operating without an Executor and using LayerZero Scan or a custom relayer to call lzReceive / lzCompose directly.
See Executors for the full discussion.

​
Pre-launch checks

Before mainnet, confirm:
  1. Resolved config matches intent. Run getConfig (or the per-VM equivalent) for every pathway. Compare against your target configuration in this document. Do not rely on defaults — see Default Config Checker.
  2. DVNs are sorted in ascending address order on every requiredDVNs and optionalDVNs array. The contract reverts on unsorted arrays.
  3. Send and receive sides match. A common bug is updating one side and forgetting the other. Both directions of every pathway need symmetric configurations.
  4. No Dead DVN in your resolved config. A Dead DVN means the message will never be deliverable; this is a configuration error, not a security feature.
  5. Confirmations are production-grade, not the [1, 1] development value.
  6. Executor is set explicitly, not inherited from defaults.
  7. You have a tested rollback procedure for each pathway.
The full set of pre-launch items is enumerated in the Integration Checklist.

​
See also