The Security Stack Configuration Standard governs the setConfig interface on the LayerZero Endpoint, the mechanism through which an Omnichain Application (OApp) declares its chosen Decentralized Verifier Networks (DVNs), optional Executors, and verification thresholds. This is not a global protocol setting; it is an application-specific security profile. Every OApp owner must explicitly configure this stack, meaning the trust model for a token bridge, a cross-chain lending market, or a governance adapter is a deliberate, auditable choice made by the application deployer, not inherited from the protocol.
Protocols
Security Stack Configuration Standard
Standard defining how OApps select Decentralized Verifier Networks, optional Executors, and verification thresholds via the setConfig interface. Directly impacts the trust model for every omnichain application.
introduction
THE OAPP TRUST MODEL
Introduction
The Security Stack Configuration Standard defines how an OApp programmatically selects its verifiers, executors, and security thresholds, making it the single most consequential design decision for any omnichain application.
Operationally, the configuration binds an OApp to a specific set of DVNs that must verify every inbound message packet before it can be delivered. The standard defines how thresholds are set—requiring, for example, that m of n selected verifiers attest to a packet's validity. This directly impacts liveness and safety. A poorly chosen threshold can lead to a frozen application if verifiers disagree, while a permissive configuration can reduce security to the honesty of a single DVN. The standard also specifies how an OApp selects an Executor, the off-chain agent authorized to call lzReceive and deliver the verified message, creating a critical dependency chain from verifier selection to execution liveness.
For protocol architects and risk teams, this standard is the control panel for cross-chain security posture. A Chainscore security stack assessment maps the chosen DVNs' operational history, stake distribution, and collusion thresholds against the OApp's economic value at risk. For integrators, exchanges, and custody providers evaluating whether to support an omnichain asset, a due-diligence report on the OApp's active security configuration is essential to understanding whether the application's trust assumptions align with institutional risk tolerance.
SECURITY STACK CONFIGURATION
Quick Facts
Key operational and security considerations for OApp teams configuring their verification and execution stack via setConfig.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Trust Model | OApp selects specific DVNs, threshold, and optional Executor, defining its own security assumptions. | OApp developers, protocol architects, risk teams | Formally document the chosen trust model and its failure modes. |
DVN Selection | The setConfig interface allows assignment of a list of DVNs and a verification threshold. | OApp developers, DVN operators | Audit the security properties and historical performance of each selected DVN. |
Verification Threshold | Defines how many of the assigned DVNs must verify a packet for it to be considered valid. | OApp developers, risk teams | Model the cost of bribery or collusion against the chosen threshold. |
Executor Assignment | OApp can specify an Executor to force a specific entity to deliver verified messages. | OApp developers, Executor operators | Assess the liveness guarantees and failure recovery of the chosen Executor. |
Configuration Immutability | The ability to change the security stack depends on the OApp's own admin/governance model. | OApp developers, governance delegates | Verify the access control on the setConfig function and plan for key management. |
Cross-Chain Consistency | Security stack configurations must be set correctly on every chain the OApp is deployed to. | OApp developers, deployment engineers | Implement a cross-chain configuration validation step in the deployment pipeline. |
Integration Risk | Downstream integrators inherit the OApp's security stack choices. | Wallets, exchanges, DeFi protocols integrating the OApp | Request a due-diligence report on the OApp's security stack before integration. |
Operational Monitoring | A change in a DVN's behavior or an Executor's liveness directly impacts message verification. | Node operators, DevOps teams, risk managers | Set up monitoring for DVN stake changes, Executor downtime, and configuration change events. |
technical-context
PROGRAMMATIC TRUST MODEL
Technical Mechanism
How the `setConfig` interface allows OApps to programmatically define their security stack by selecting DVNs, Executors, and verification thresholds.
The Security Stack Configuration Standard is the mechanism by which an Omnichain Application (OApp) declares its trust model on-chain. Through the setConfig function on the LayerZero Endpoint, an OApp explicitly selects which Decentralized Verifier Networks (DVNs) are required to verify a message packet and which Executor is authorized to deliver it. This is not a global protocol setting; it is a per-OApp, per-path configuration. The standard defines the data structures and encoding rules that allow an OApp to require a threshold m-of-n signature scheme from a set of chosen DVNs, creating a customizable security posture that can range from a single trusted verifier to a multi-entity consensus model.
The configuration is path-specific, meaning an OApp can enforce a different security stack for messages traveling from Ethereum to Avalanche than it does for messages from Avalanche back to Ethereum. The standard specifies how an optional Executor address is set, granting a specific entity the exclusive right to call lzReceive on the destination chain. If no Executor is configured, the application defaults to a permissionless execution model where anyone can deliver a verified message. This design directly impacts liveness and censorship-resistance: a configured Executor creates a trusted delivery pipeline, while a permissionless setting relies on a competitive market of executors to ensure message delivery.
The operational consequence of this standard is that the security of every OApp is a function of its own configuration choices, not a uniform protocol guarantee. A misconfiguration—such as selecting a single, low-reputation DVN or setting a threshold that is too low—can completely undermine the application's cross-chain security. For integrators, wallets, and exchanges interacting with an OApp, the active security stack is queryable on-chain but requires off-chain due diligence to assess the real-world identity, operational history, and collusion resistance of the configured verifiers. Chainscore Labs can audit an OApp's setConfig parameters against its stated risk tolerance, verify the operational integrity of selected DVNs, and produce a due-diligence report for integrators evaluating the application's trust assumptions.
SECURITY STACK CONFIGURATION IMPACT
Affected Actors
OApp Builders
OApp developers are the primary actors affected by the Security Stack Configuration Standard. Every setConfig call directly defines the trust model for their application's cross-chain message verification.
Key responsibilities:
- Select a composition of DVNs, Executors, and optional verification thresholds that align with the application's security budget and risk tolerance.
- Understand the liveness and safety trade-offs of requiring multiple independent verifiers versus relying on a single default DVN.
- Handle configuration updates securely, ensuring that changes to the security stack cannot be exploited to downgrade verification requirements.
Action items:
- Model failure scenarios for your chosen DVN set, including collusion and prolonged downtime.
- Implement timelocks and multisig controls on the admin function that calls
setConfig. - Monitor the operational status and stake distribution of your selected DVNs continuously.
implementation-impact
SECURITY STACK CONFIGURATION
Implementation and Operational Impact
The Security Stack Configuration Standard defines how OApps select and combine DVNs, Executors, and verification thresholds. This directly dictates the trust model for every cross-chain message, making implementation choices critical for security.
01
Trust Model Definition
The setConfig interface is the single point where an OApp defines its security assumptions. A misconfiguration here—such as selecting a single, low-reputation DVN or setting a threshold of 1 out of N—can reduce the application's security to that of a single trusted party. Protocol architects must treat this configuration as the primary security risk surface and document the rationale for each chosen verifier.
02
DVN Selection and Due Diligence
OApp teams must perform rigorous due diligence on each DVN before adding it to their security stack. This includes assessing the DVN's operational history, client software robustness, geographic and jurisdictional distribution of its operators, and its slashing or staking model if applicable. A security stack is only as strong as its weakest verifier.
03
Threshold Configuration Risks
The verification threshold (M-of-N) requires careful calibration. A low threshold increases liveness but risks a single faulty DVN confirming an invalid packet. A high threshold increases security but risks liveness failure if multiple DVNs go offline. Teams should model failure scenarios and consider using a DVN Adapter to enforce complex logic like quorum-based signing or proof aggregation.
04
Executor Configuration and Gas Griefing
Configuring an Executor involves setting gas limits and airdrop amounts via OptionsBuilder. Incorrect gas parameters can lead to message delivery failure or gas griefing attacks where a malicious actor forces the Executor to expend gas on a transaction that reverts. OApp developers must test execution paths under adversarial conditions and set enforced options to bound execution costs.
05
Operational Monitoring and Alerting
Post-deployment, OApp operators must continuously monitor the health of their configured security stack. This includes tracking DVN liveness, verifying that the active configuration matches the intended one, and alerting on any calls to setConfig that could alter the trust model. A robust monitoring system is essential to detect both technical failures and governance attacks.
06
Chainscore Security Stack Assessment
Chainscore Labs provides a comprehensive review service for OApp security stack configurations. We audit the setConfig parameters, assess the chosen DVNs and Executors, model failure and collusion scenarios, and deliver a due-diligence report for your team and your integrators. This ensures your cross-chain trust model is explicit, robust, and aligned with your protocol's risk tolerance.
SECURITY STACK CONFIGURATION
Risk Matrix
Evaluates the operational and security risks introduced by the setConfig interface, which allows OApps to dynamically select Decentralized Verifier Networks, Executors, and verification thresholds.
| Risk | Failure mode | Severity | Mitigation |
|---|---|---|---|
Unverified Configuration Change | An OApp owner or compromised admin calls setConfig to switch to a malicious or non-functional DVN/Executor, enabling theft of all cross-chain messages. | Critical | Implement a timelock and multi-signature governance on the OApp's setConfig function. Chainscore can audit the admin access control and configuration change workflow. |
DVN Collusion Threshold Misconfiguration | An OApp sets | Critical | Require a minimum of 2 geographically and jurisdictionally diverse DVNs. Chainscore can provide a due-diligence report on DVN operator profiles and recommend a secure threshold. |
Executor Liveness Failure | The selected Executor goes offline or fails to process the message queue. All cross-chain messages for the OApp are stuck in a 'verified but not delivered' state indefinitely. | High | Select a permissionless Executor option or maintain a fallback Executor configuration. Chainscore can review the execution liveness guarantees and fallback logic. |
DVN Incompatibility with New Chain | An OApp deploys to a new chain but its configured DVN does not support it. The security stack is unconfigurable, blocking all message verification on the new path. | High | Verify DVN chain support matrix before deployment. Chainscore can perform a pre-deployment compatibility assessment for the target chain path. |
Forced Message Bypass via Configuration | An OApp sets | Medium | Audit the OptionsBuilder logic to ensure minimum gas limits are enforced. Chainscore can review the options encoding and simulate execution costs. |
DVN Proof Verification Logic Flaw | A custom DVN adapter contract has a bug in its signature aggregation or threshold logic, allowing a single malicious verifier to pass a fraudulent packet as 'verified'. | Critical | Conduct a formal audit of any custom DVN adapter or composer contract. Chainscore can audit the adapter's proof composition and threshold enforcement logic. |
Lack of Security Stack Monitoring | An OApp's DVN or Executor configuration is changed by governance without the operations team's knowledge, leading to a delayed response to a security incident. | Medium | Implement on-chain monitoring and alerting for all |
SECURITY STACK HARDENING
Operator Configuration Checklist
A practical checklist for OApp operators and DVN runners to verify that their security stack configuration is correctly set, resilient to misconfiguration, and aligned with the application's stated trust model. Each item includes the signal that confirms readiness.
What to check: Confirm the exact list of Decentralized Verifier Networks (DVNs) and the required verification threshold configured via setConfig for each pathway.
Why it matters: A mismatch between the intended and configured DVN set is the most critical security misconfiguration. An incorrect threshold can allow a single compromised or malicious DVN to unilaterally verify a message, breaking the application's security model.
Readiness signal: The output of getConfig for each active remote endpoint and pathway exactly matches the audited security stack specification, including the address of each DVN and the confirmations threshold.
resource-links
LAYERZERO SECURITY STACK CONFIGURATION
Source Resources
Primary resources for verifying LayerZero OApp security-stack configuration, DVN selection, Executor assumptions, and deployed Endpoint behavior. Teams should use these sources to confirm live configuration before launch, listing, integration, or risk approval.
05
OApp Owner and Governance Records
The canonical source for a deployed OApp’s security stack is not only the LayerZero specification; it is the live configuration controlled by the OApp owner or governance process. Risk teams should identify the owner account, multisig, timelock, DAO proposal system, or upgrade authority that can alter DVNs, thresholds, Executors, peers, and enforced options. Maintain an internal evidence pack with transaction hashes, governance approvals, signer sets, timelock delays, emergency roles, and monitoring alerts. If those controls are opaque, integrators should treat the application’s cross-chain trust model as externally mutable.
06
Chainscore Configuration Review Checklist
For a production review, validate the full path-specific security stack: source and destination Endpoint addresses, OApp peer mappings, selected DVNs, required and optional verification thresholds, Executor choice, enforced execution options, owner permissions, and upgrade routes. Test failure modes such as missing DVN confirmation, insufficient gas, executor non-delivery, replay attempts, and unexpected governance updates. Chainscore Labs can help teams turn these checks into a launch-readiness report, integration due-diligence memo, or continuous monitoring plan for LayerZero-based OFT, ONFT, bridge, and governance deployments.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
SECURITY STACK FAQ
Frequently Asked Questions
Common questions from protocol architects and risk teams evaluating or configuring a LayerZero security stack.
The setConfig function on an OApp allows the application owner to programmatically define its security stack by specifying:
- Required DVNs: A list of Decentralized Verifier Network addresses that must verify a message before it can be delivered.
- Verification Threshold: The number of listed DVNs that must successfully verify a packet. This can be set to
N(a subset) or equal to the total number of listed DVNs for unanimous consent. - Optional Executor: The address authorized to call
lzReceiveon the destination chain to execute the verified message. - Execution Options: Default gas limits and airdrop parameters for message delivery.
This configuration is stored per remote chain path (source-to-destination), allowing different trust models for different connections. Misconfiguration here is the most common source of a single-DVN trust failure.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.