> ## 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. # Security Stack (DVNs) > As mentioned in previous sections, every application built on top of the LayerZero protocol can configure a unique messaging. LayerZero enables secure... As mentioned in previous sections, every application built on top of the LayerZero protocol can configure a unique [messaging channel](../protocol/message-security). This stack of multiple DVNs allows each application to configure a unique security threshold for each source and destination, known as [X-of-Y-of-N](../protocol/message-security#configurable-channellevel-security-xofyofn). In this stack, each DVN independently verifies the `payloadHash` of each message to ensure integrity. Once the designated DVN threshold has been reached, the message nonce can be marked as verified and inserted into the destination Endpoint for execution. Diagram showing DVN verification flow: multiple DVNs independently verify the payloadHash of each message, and once the designated threshold is reached, the message can be committed to the destination Endpoint Diagram showing DVN verification flow: multiple DVNs independently verify the payloadHash of each message, and once the designated threshold is reached, the message can be committed to the destination Endpoint Each DVN applies its own verification method to check that the `payloadHash` is correct. Once the required DVNs and optionally a sufficient number of optional DVNs have confirmed the `payloadHash`, any authorized caller (for example, an [Executor](../permissionless-execution/executors)) can commit the message nonce into the destination [Endpoint’s](../protocol/layerzero-endpoint) messaging channel for execution. The following image and table describe how messages can be inserted into the Endpoint's messaging channel post-verification: Table diagram showing message nonce verification states: illustrating how required DVNs (DVNᴬ, DVNᴮ) and optional DVNs verify payloadHash before nonces can be committed to the Endpoint's messaging channel Table diagram showing message nonce verification states: illustrating how required DVNs (DVNᴬ, DVNᴮ) and optional DVNs verify payloadHash before nonces can be committed to the Endpoint's messaging channel | Message Nonce | Description | | :-----------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | The Security Stack has verified the `payloadHash` and the nonce has been committed to the Endpoint’s messaging channel. | | 2 | All configured DVNs have verified the `payloadHash`, but no caller has yet committed the nonce to the Endpoint’s messaging channel. | | 3 | Two required and one optional DVN have verified the `payloadHash`, meeting the security threshold, but the nonce has not yet been committed. | | 4 | Even though the optional DVN threshold is met, the Security Stack requires that every **required DVN** (e.g. `DVNᴬ`) must verify the `payloadHash` before the nonce can be committed. | | 5 | Only the required DVNs (e.g. `DVNᴬ`, `DVNᴮ`) have verified the `payloadHash`; none of the optional verifiers have submitted their proof. | | 6 | Both the required DVNs and the optional threshold have verified the `payloadHash`, but no caller has committed the nonce to the Endpoint’s messaging channel yet. | ## Verification Model Each DVN can use its own verification method to confirm that the `payloadHash` correctly represents the message contents. This design allows application owners to tailor their Security Stack based on the desired security level and cost–efficiency tradeoffs. For an extensive list of DVNs available for integration, see [DVN Addresses](../../deployments/dvn-addresses). ### DVN Adapters **DVN Adapters** enable the integration of third-party generic message passing networks, such as native asset bridges, middlechains, or other specialized verification systems. With DVN Adapters, applications can incorporate diverse security models into their Security Stack, broadening the spectrum of available configurations while still ensuring a consistent verification interface via the `payloadHash`. Diagram showing DVN Adapters: enabling integration of third-party verification systems like native bridges, middlechains, or specialized networks into the Security Stack while maintaining consistent payloadHash verification Diagram showing DVN Adapters: enabling integration of third-party verification systems like native bridges, middlechains, or specialized networks into the Security Stack while maintaining consistent payloadHash verification Since “DVN” broadly describes any verification mechanism that securely delivers a message’s `payloadHash` to the destination [Message Library](../protocol/message-send-library), application owners have the flexibility to integrate with virtually any infrastructure that meets their security requirements. ## Configuring the Security Stack Every LayerZero Endpoint can be used to send and receive messages. Because of that, **each Endpoint has a separate Send and Receive Configuration**, which an OApp can configure per remote Endpoint (i.e., the messaging channel, sending to that remote chain, receiving from that remote chain). For a configuration to be considered valid, **the Send Library configurations on Chain A must match the Receive Library configurations on Chain B.** ## Default Configuration For each new channel, LayerZero provides a placeholder configutation known as the **default**. If you provide no configuration settings, the protocol will fallback to the default configuration. This default configuration can vary per channel, changing the placeholder block confirmations, the [X‑of‑Y‑of‑N](../glossary#x-of-y-of-n) thresholds for verification, the Executor, and the message libraries. A default pathway configuration will typically have one of the following preset Security Stack configurations within `SendULN302` and `ReceiveUlN302`: | | Security Stack | Executor | | ------------------------------ | ------------------------------------------------------------------- | -------------- | | **Default Send and Receive A** | requiredDVNs: \[ Google Cloud, LayerZero Labs ] | LayerZero Labs | | **Default Send and Receive B** | requiredDVNs: \[ Polyhedra, LayerZero Labs ] | LayerZero Labs | | **Default Send and Receive C** | requiredDVNs: \[ [Dead DVN](../glossary#dead-dvn), LayerZero Labs ] | LayerZero Labs | | **Default Send and Receive D** | requiredDVNs: \[ [Dead DVN](../glossary#dead-dvn) ] (count: 1) | LayerZero Labs | You can view all of the current default pathway configurations on [LayerZero Scan's Default Configs by Chain](https://layerzeroscan.com/tools/defaults).
Defaults A, B, and C list **LayerZero Labs** as a required DVN, and every default uses **LayerZero Labs** as the Executor. A single operator controls both verification and execution on every pathway whose default has a working DVN. Production deployments should explicitly configure their security stack with at least one required DVN that is not operated by LayerZero Labs, and consider the Executor accordingly. See the [Integration Checklist](../../tools/integration-checklist#set-security-and-executor-configurations-on-every-pathway). **Some chains have only one DVN provider currently deployed.** On those chains, an OApp's options are: 1. Run your own DVN (see [Build a DVN](../../workers/off-chain/build-dvns)). 2. Wait until a third-party provider deploys (track on [DVN Addresses](../../deployments/dvn-addresses)). 3. Defer the chain until multi-DVN coverage exists. You should not assume a second DVN will appear in time for a launch. Confirm available DVNs on every chain in your mesh via the [Default Config Checker](https://layerzeroscan.com/tools/defaults) before committing. What is a **[Dead DVN](../glossary#dead-dvn)**? Since LayerZero allows for anyone to permissionlessly run DVNs, the network may occassionally add new chain Endpoints before the default providers (Google Cloud or Polyhedra) support every possible pathway to and from that chain. A default configuration with a **Dead DVN** will require you to either configure an available DVN provider for that Send or Receive pathway, or run your own DVN if no other security providers exist, before messages can safely be delivered to and from that chain. Some pathways currently use **Default D** above — a single Dead DVN with no co-DVN. On these pathways, the network default is fully non-functional: no message can be verified until the OApp explicitly configures its own DVNs. Verify the current state of any pathway you depend on via the [Default Config Checker](https://layerzeroscan.com/tools/defaults). You should always **set your DVN configuration** explicitly. Defaults are placeholder configurations — they may be Dead DVNs that prevent message delivery, may include only a single DVN, and may change without notice. ## Further Reading To query and set your application's configuration, you can review these VM-specific guides: * [EVM DVN and Executor Configuration](../../developers/evm/configuration/dvn-executor-config) * [Solana DVN and Executor Configuration](../../developers/solana/configuration/dvn-executor-config) * [Aptos DVN and Executor Configuration](../../developers/aptos-move/configuration/dvn-executor-config)