This post explains DVN adapters in LayerZero: what they are, when to use one, and how a team like Ether.fi can fold an external verifier into its security stack without changing protocols. If you want to build with DVN Adapters, visit Developers or reach out to our team.
Cross-chain applications inherit the trust assumptions of the system that verifies their messages. Most messaging protocols ship such a system and every application built on them has to use it.
But the verifier a team trusts is not always the verifier the protocol ships. A treasury may require an attestation from a specific network. A risk committee may want two independent verification systems on a high-value lane. A long-tail asset moving onto a new chain may need a different posture than the protocol's default:
LayerZero separates how a message moves from how it’s verified. An adapter is the contract that brings an external verifier into an application's security stack, where it acts as one Decentralized Verifier Network (DVN) among several others. For what a DVN is more broadly, see DVN explainer.
What a DVN adapter actually is
An adapter is a thin contract that wraps an existing verification system in the DVN interface.
The wrapped protocol (such as Chainlink's CCIP, Axelar, Wormhole, an enterprise signer network, etc.) keeps running its own consensus, validators, and economics. The adapter only translates that protocol's verification result into a DVN attestation.
The adapter does not absorb or replace the wrapped protocol. It does not change how a third party runs their infrastructure, or how an enterprise signer manages keys. Instead, it exposes the result of that work to a LayerZero MessageLib in a form the MessageLib understands.
This means an application can list a third party protocol as a verifier inside its security stack without rebuilding. The third party can sit alongside a zk light client and an enterprise DVN. None of them need to know about each other and that is why the application selects them: it wants a verifier set that is hardened against the worst case scenario.
Where the adapter sits
An Adapter is a DVN like any other, it lives in the same configuration surface and follows the same threshold rules (set by the app inside the MessageLib). LayerZero expresses verification policy as a security stack: a set of required DVNs plus a threshold drawn from a pool of optional DVNs, it is the X required + (Y of N optional) model.
An adapter is part of that security stack. When an application sets three optional DVNs (and no required DVN) with a threshold of two, for example [CCIP_adapter, CanaryDVN, NethermindDVN], any two attestations against the same payloadHash allow the message to be committed.
Real-world Example: Ether.fi and a CCIP adapter
Ether.fi uses LayerZero to connect its tokens – like weETH (which has moved over $9B in historical value) – across chains.
The Ether.fi team, which is behind the neobank product securing $3B+, has been explicit about its security posture: multiple verifiers, rate limits, application-owned configuration. As part of that approach, Ether.fi sets its weETH security stack at four DVNs with a 4/4 threshold and has said it is evaluating a second independent stack such as CCIP or Wormhole, so verification spans independent systems.
In that setup, a weETH transfer between chains requires multiple independent verification systems to agree on the same payloadHash before delivery. No single verifier can finalize the message.
When to add an adapter
There is no universally correct verifier set. A larger set costs more gas per message and introduces more counterparties to manage. A smaller or more correlated set reduces overhead but concentrates trust.
Teams usually add an adapter for one of three reasons:
- Counterparty diversification: The application wants verifiers that run independently. Two DVNs operated by similar entities is not the same as two DVNs with no shared dependencies.
- Stakeholder requirement: A treasury, custodian, or institutional partner names a specific verification network as a precondition. An adapter lets the application meet that requirement without migrating off LayerZero.
- Verification method: The application wants the specific guarantee a verifier provides, such as a zk proof of source-chain state or an economically-staked committee. An adapter adds that verifier's signal to the stack, counted under the application's own threshold.
Each additional required DVN adds one attestation to the verification path and the gas to read it on the destination. The benefit grows with diversity: independent verifiers have to collude, or all fail at once, to corrupt a message.
What an adapter does not do
An adapter does not replace LayerZero's Endpoint, MessageLib, or Executor. The wrapped protocol does not take over delivery, fee abstraction, or retry logic. The adapter does one job: take the verification payload the wrapped protocol delivers and submit the packet header and payloadHash to LayerZero's MessageLib.
This is also why adapters do not change the application's contract surface. An OFT or OApp (Omnichain Application) does not need to know which DVNs are in its stack. The security stack lives in MessageLib configuration. Swapping one adapter for another, adding a new verifier, or raising the threshold are configuration changes, not redeploys of the application.
The adapter also does not grant the wrapped protocol any control over the message. CCIP cannot deliver a LayerZero message on its own. It can only contribute an attestation that the LayerZero stack chooses to count. Trust delegation is opt-in and scoped to verification. The application can swap or remove an adapter at any time through configuration.
What you can adapt into a DVN
DVN adapters are a way to integrate third-party generic message passing networks, such as native asset bridges, middlechains, or other specialized verification systems. In practice, that admits four working categories:
- Third-party message passing protocols. Chainlink's CCIP, Wormhole, Hyperlane, and similar networks. Each runs its own verification system. The adapter exposes the result of that work to the LayerZero protocol without changing how the wrapped protocol operates.
- Middlechains. Networks like Axelar that run a dedicated chain whose validators attest to cross-chain messages. The adapter reads the validator-set attestation and translates it into a DVN attestation.
- Native asset bridges. Arbitrum and other rollup or sidechain bridges. Where a chain’s bridge can expose its verification result, it can be wrapped as one verifier in the LayerZero security stack .
- Other specialized verification systems. Anything else built for verifying cross-chain state. External light client systems are the most common case. Hashi is the cleanest current example, wrapping its message-hash relay into DVN-style verification. The same pattern can extend to multisigs, custody arrangements, or partner federations whose signing committee already exists for governance.
Each one of these has its own assumptions, latency, and failure modes. The adapter does not erase those differences. It gives applications a way to import the verifiers it wants in its stack, including ones not currently available as DVNs.
Start building
If your team already trusts a verifier (a bridge, a middlechain, an oracle network, a zk light client), there is likely a path to express that trust through an adapter in LayerZero's security stack. The choice of who verifies a message stays with the application.
To build with DVN Adapters, contact our team.
Read next: DVN explainer.
FAQ
- Is a DVN adapter different from a bridge integration? Yes. A bridge integration moves assets through another protocol. A DVN adapter borrows only that protocol's verification signal. The message still travels through LayerZero.
- Can an application use multiple adapters at once? Yes. The security stack accepts an arbitrary set of DVNs, including any combination of adapters, as long as the application's threshold is met before a message is delivered.
- Does adding an adapter require redeploying the application? No. Adapters are added through MessageLib configuration. The OApp or OFT contract does not need to change.
- Who runs the adapter contract? A DVN adapter is operated as DVN infrastructure by a provider, and has to be deployed on the pathways where an application wants to use it. The wrapped verifier runs its own underlying system. The adapter only translates the verification result into a DVN attestation.