LayerZero's initial security model relied on a 2-of-2 verification scheme between an Oracle and a Relayer. The Oracle submitted the block header of the source transaction, and the Relayer submitted the transaction proof. The protocol's core guarantee was that a message was valid if these two independent entities agreed, with the explicit assumption that they would not collude. This model was simple but rigid: applications inherited a single, protocol-wide security configuration with no ability to customize their trust assumptions or add additional verification layers.
Protocols
Security Model Upgrades
Tracks modifications to LayerZero's core security architecture, including the shift from the original Oracle/Relayer model to the Decentralized Verifier Network (DVN) framework. Analyzes changing trust assumptions and composability of security stacks.
introduction
LAYERZERO SECURITY MODEL EVOLUTION
From 2-of-2 to Modular Verification
How LayerZero replaced its original Oracle/Relayer model with a Decentralized Verifier Network (DVN) framework, fundamentally altering the protocol's trust assumptions and security composability.
The transition to the Decentralized Verifier Network (DVN) framework in the V2 protocol upgrade dismantles this monolithic model. Applications now compose a modular security stack by selecting a set of DVNs, specifying a threshold of required verifications, and optionally attaching on-chain security modules like Pre-Crime. This shifts the trust model from a binary 'collusion or not' assumption to a configurable, application-specific security posture. A protocol can require verification from a mix of institutional, geographically distributed, and economically-staked DVNs, making the cost of collusion variable and potentially quantifiable per OApp.
For operators and risk teams, this upgrade is not a simple improvement but a fundamental change in responsibility. The protocol no longer provides a single default security guarantee; each OApp owner must actively design, configure, and monitor their DVN set. A misconfiguration—such as selecting a single DVN with a threshold of one—reduces security to a trusted third-party model. Chainscore Labs can audit OApp security stack configurations, assess DVN selection for collusion resistance, and review Pre-Crime module logic to ensure the composed security model meets the application's stated threat profile.
TRUST MODEL EVOLUTION
Security Model Upgrade: Quick Facts
Key operational and risk changes when LayerZero shifts its core security architecture, such as the transition from the default Oracle/Relayer model to the Decentralized Verifier Network (DVN) framework.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Verification Entity | Shift from a fixed 2-of-2 (Oracle + Relayer) model to an application-chosen set of DVNs. | OApp developers, risk teams, protocol architects | Review and explicitly configure the DVN set for each OApp path instead of relying on legacy defaults. |
Trust Assumptions | Security model moves from trusting two specific entities to trusting a configurable threshold of staked or reputation-based verifiers. | Due-diligence analysts, institutional integrators | Re-assess the honesty and liveness assumptions of the specific DVNs chosen for your application's paths. |
Security Stack Composability | Applications can now compose a security stack by combining multiple DVNs, Executors, and optional security modules like Pre-Crime. | Security engineers, OApp developers | Design and audit a custom security stack that matches the value at risk for each cross-chain path. |
Default Configuration | New default DVN sets are applied to new paths, potentially changing the baseline security posture for applications that do not customize settings. | Risk teams, OApp developers using default settings | Verify the current default DVN configuration for your paths against the canonical source and override if necessary. |
Liveness Dependency | Message verification liveness now depends on the threshold of the chosen DVN set, not just a single Oracle and Relayer. | OApp developers, risk teams | Evaluate the liveness guarantees of your chosen DVN set and implement forced message delivery logic for timeout-sensitive applications. |
Verification Logic | On-chain verification modules are upgraded to support new proof types, signature aggregation, and threshold logic from multiple DVNs. | DVN operators, security engineers | Upgrade DVN client software to be compatible with new verification module requirements and monitor for breaking changes. |
Legacy Model Sunset | The original Endpoint V1 security model is deprecated, and legacy applications must migrate to the new framework to remain operational. | OApp developers, asset issuers, wallets | Plan and execute migration from Endpoint V1 to V2, including reconfiguring security settings and migrating user state before the sunset transaction. |
Replay Protection | The path identification system (Eid) is updated to ensure cryptographic domain separation under the new verification framework. | OApp developers, auditors | Audit OApp implementations to confirm correct handling of the updated path identifiers and replay protection mechanisms. |
technical-context
SECURITY MODEL UPGRADES
DVN Architecture and Trust Composability
How LayerZero's shift to a Decentralized Verifier Network (DVN) fundamentally restructures cross-chain security from a fixed two-party model to a composable, application-defined trust framework.
LayerZero V2 replaces the legacy Oracle/Relayer model with the Decentralized Verifier Network (DVN) architecture, a modular framework where each omnichain application (OApp) independently selects the set of verifiers required to authenticate its cross-chain messages. Instead of a single mandatory security pair, the protocol now enforces a configurable threshold of signatures from an application-chosen DVN set. This shifts the security model from a protocol-wide constant to a per-OApp variable, making trust assumptions explicit, composable, and auditable at the application level.
Operationally, this means a message is only delivered to the destination OApp once the required number of DVNs from the application's configured set have verified the packet and submitted their signatures on-chain. The Executor contract enforces this threshold. This design introduces new failure modes: an OApp can become frozen if its chosen DVNs fail to verify or if the threshold is set too high relative to DVN availability. Conversely, a low threshold or a colluding DVN set can compromise security. The protocol provides a lzCompose feature for atomic multi-message execution and a forced-delivery mechanism as a liveness backstop, but the primary security posture is now a direct function of the OApp's DVN configuration.
For risk teams and protocol architects, the DVN framework demands a new due-diligence process. Evaluating an OApp's security requires analyzing the identity, stake, client diversity, and historical performance of each DVN in its set, not just the protocol's global parameters. The composability of trust means a bridge or DeFi application inherits the aggregate risk of its weakest configured verifier. Chainscore Labs can assist integration teams by auditing OApp security stack configurations, modeling failure scenarios under various DVN collusion and liveness assumptions, and designing monitoring systems that alert on threshold changes or DVN unavailability before message delivery is impacted.
ACTOR-SPECIFIC IMPACT ANALYSIS
Who Is Affected by the Security Model Shift
OApp Developers
OApp teams are the most directly affected by security model upgrades. The shift from the default Oracle/Relayer model to the DVN framework means applications must explicitly configure their security stack rather than inheriting a protocol-wide default.
Immediate actions:
- Audit your OApp's
setConfigcalls to verify which DVNs are required, optional, and what threshold is set. - Test message verification against new DVN versions in testnet before mainnet activation.
- Review liveness assumptions: if your application requires forced message delivery, confirm timeout parameters are compatible with new verification latency.
Long-term considerations:
- Custom security stacks require ongoing monitoring. A DVN that is reliable today may deprecate or change its verification logic.
- Consider implementing Pre-Crime modules for application-specific invariants that DVNs cannot enforce.
Chainscore can review your OApp's security configuration, test verification paths, and design custom security modules for your deployment.
implementation-impact
SECURITY MODEL UPGRADES
Operational and Integration Impact
Shifts in the core verification architecture require every downstream team to reassess trust assumptions, update configurations, and verify integration compatibility.
SECURITY MODEL TRANSITION ANALYSIS
Risk Matrix: Legacy vs. DVN Security Model
Evaluates the shift in trust assumptions, failure modes, and operational responsibilities as LayerZero moves from the Oracle/Relayer model to the Decentralized Verifier Network (DVN) framework.
| Risk Area | Failure Mode | Severity | Affected Actors | Mitigation & Action |
|---|---|---|---|---|
Verifier Collusion | In the legacy model, a single Oracle and Relayer colluding could pass any message. In the DVN model, collusion requires a threshold of independent DVNs. | Critical | OApp developers, risk teams, asset issuers | Audit OApp security stack configurations. Verify that the chosen DVN set and threshold provide sufficient decentralization. Chainscore can assess DVN collusion risk for specific OApp configurations. |
Liveness Dependency | Legacy model had two fixed off-chain actors. DVN model allows applications to choose multiple DVNs, but a quorum failure halts message verification. | High | OApp developers, Executors, users | Review DVN selection for liveness. Implement forced message delivery logic for timeout scenarios. Chainscore can review OApp liveness assumptions against chosen DVN quorum requirements. |
Application-Controlled Security | OApp owners now select their own DVN set and threshold. Misconfiguration can result in a weaker security model than the legacy default. | High | OApp developers, protocol architects, governance delegates | Do not rely on defaults without review. Explicitly design a security stack with a threshold appropriate for asset value. Chainscore can audit OApp security configurations for misconfiguration risks. |
DVN Operational Risk | A DVN running outdated software or experiencing downtime can cause verification delays or permanent message blocking if quorum is lost. | Medium | DVN operators, OApp developers, users | Monitor DVN client versions and uptime. OApp teams should diversify DVNs across independent operators. Chainscore can build monitoring for DVN health and version compliance. |
Executor Centralization | The legacy Executor was whitelisted. The DVN model moves toward permissionless execution, introducing front-running and MEV risks. | Medium | OApp developers, MEV researchers, Executors | Design receiving contracts to handle unordered or front-run execution. Use lzCompose options for atomic composability. Chainscore can review OApp execution logic for permissionless execution vulnerabilities. |
Replay Protection | Changes to path identifiers and the Eid system during migration could create edge cases where messages are valid on unintended paths. | Critical | OApp developers, auditors, bridges | Verify that chain ID and path identifier handling is correct for the new Endpoint. Audit replay protection logic. Chainscore can audit OApp implementations for correct cross-chain replay resistance. |
Legacy Endpoint Freeze | Deprecated Endpoint contracts will be permanently frozen. OApps that fail to migrate will lose user funds and state. | Critical | OApp developers, asset issuers, wallets | Track sunset timelines. Execute migration transactions before the freeze deadline. Chainscore can provide sunset migration planning and execution support for teams still on legacy Endpoints. |
Verification Module Upgrades | New proof types or signature schemes in DVN verification modules could break compatibility with custom security stacks. | Medium | DVN operators, security engineers, OApp developers | Test custom verification logic against new module versions. Monitor upgrade announcements. Chainscore can assess the impact of verification changes on custom security stack configurations. |
DVN TRANSITION READINESS
Security Stack Migration Checklist
A practical checklist for protocol architects and risk teams migrating from the legacy Oracle/Relayer model to the Decentralized Verifier Network (DVN) framework. Each item identifies a critical change in trust assumptions, a verification step, and the signal that confirms readiness.
What to check: Identify every OApp deployment currently using the default Oracle/Relayer configuration or a custom set of verifiers. Document the specific Oracle, Relayer, and any additional security modules in use.
Why it matters: The DVN framework replaces the fixed two-party model with a composable set of on-chain verification modules. A direct mapping is required to understand which trust assumptions are being replaced, removed, or added.
Readiness signal: A complete inventory of OApp deployments with their current security stack, including chain IDs, endpoint versions, and verifier addresses. Teams should confirm whether any legacy verifiers have announced deprecation timelines.
resource-links
LAYERZERO SECURITY MODEL UPGRADES
Canonical Resources
Use these resources to verify how LayerZero security assumptions change across Endpoint, DVN, Executor, and OApp configuration updates. Teams should treat official docs and contract source as the baseline, then validate deployed configuration against their own application paths.
03
Endpoint and Path Configuration Verification
For any security model upgrade, validate the production Endpoint address, source and destination endpoint IDs, configured send and receive libraries, required DVNs, optional DVNs, confirmation thresholds, and Executor settings for each path. This is the control surface that determines the effective trust model of an OApp. Teams should not assume that a network-wide LayerZero upgrade automatically changes their deployed application security posture; OApp owners need to inspect their own on-chain configuration and compare it with the intended design.
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 MODEL FAQ
Frequently Asked Questions
Common questions from protocol architects, risk teams, and integration engineers evaluating the impact of LayerZero's shift from the Oracle/Relayer model to the Decentralized Verifier Network (DVN) framework.
The legacy model required trusting that the chosen Oracle and Relayer would not collude to deliver a fraudulent message. The DVN model replaces this with an application-defined quorum of verifiers. The key shift is from a fixed 2-of-2 collusion risk to a configurable threshold model.
- Application Sovereignty: OApp owners now select their own set of DVNs and the required threshold for message verification. This means security is no longer a protocol-wide constant but a per-OApp configuration.
- Composability Risk: If an application chooses a weak or homogenous set of DVNs, its security posture can be significantly lower than the network's perceived standard.
- Liveness vs. Safety: A higher threshold increases safety (more parties must collude) but decreases liveness (more parties must be online to verify). Teams must model this trade-off for their specific use case.
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.