LayerZero DVN Configuration: A Security Guide After Kelp

By the Guardian team Updated November 2026 6 min read

Quick answer. Kelp's route trusted one DVN, so require at least two from independent operators on every pathway. Pin every setting on both chains, including optional DVNs and confirmations, then read live config onchain and alert on every change.

Watch: LayerZero DVN Configuration: A Security Guide After Kelp 1:48

Video transcript

Kelp DAO's bridge trusted a single DVN, and one forged message released 116,500 rsETH. The fix is at least two independent required DVNs on every pathway, with every setting pinned.

A disclosure first. LayerZero is a Guardian client, and we audit its code. LayerZero relies exclusively on DVN attestations, so your DVN set is your bridge's security.

Kelp was not unusual. A Dune dashboard cited by Nexus Mutual put 47 percent of active LayerZero OApps on the same one-of-one setup.

Attackers poisoned the DVN's internal RPC nodes and knocked external ones offline. With only one required DVN, nothing could disagree. The signing keys and the quorum check both held.

LayerZero calls one required DVN not safe in production. Two required is the minimum. Add optional DVNs for medium-value pathways, and three required for critical assets.

A zero inherits whatever LayerZero sets later. Use the NIL value instead. Guardian found this in Olympus's LayerZero bridge, and it was resolved.

Use independent operators, with at least one not run by LayerZero Labs. Set confirmations from each chain's worst reorgs. Pin settings on both chains. Put the delegate on a multisig, and alert on every config change.

Guardian has verified USDT0's DVN configuration across 45 plus engagements on more than 25 chains, and reviewed Gasolina, LayerZero's DVN signing service.

Read the full guide for the onchain checks, or talk to Guardian before your next DVN stack carries value.

Disclosure: LayerZero is a Guardian client, and Guardian audits its code. On Kelp DAO, we give both sides' accounts.

On April 18, 2026, one forged message released 116,500 rsETH from Kelp DAO's LayerZero bridge. The route trusted a single DVN, and that DVN was fed false chain data.

Kelp was not unusual. Nexus Mutual, citing a Dune dashboard published after the exploit, put 47% of about 2,665 active LayerZero OApps on the same 1-of-1 setup.

This guide covers how DVN settings work, what failed at Kelp, and a checklist. The settings come from LayerZero's V2 docs and contracts.

For token-contract checks, see our OFT security checklist. For how other verifier models compare, see LayerZero vs Wormhole.

What DVNs Do

A DVN watches the source chain, decides a message is valid and final, and attests to it on the destination chain.

The destination library accepts a packet "only after the channel's configured DVNs have produced matching attestations."

The most common DVN design, and LayerZero Labs', is a multisig signing committee that reads the source chain through RPC providers.

LayerZero relies "exclusively" on DVN attestations for both validity and finality. Your DVN set is your bridge's security.

Executors only deliver verified messages. The app's delegate picks DVNs and the executor, per chain and direction.

What Went Wrong at Kelp

LlamaRisk's report says Kelp's Unichain to Ethereum route "was configured as a 1-of-1 DVN path with no optional verifiers." LayerZero's report confirms that DVN was its own.

Per LayerZero's May 18 report, the attacker poisoned two internal RPC nodes. A denial of service on external RPCs then left the DVN reading only from those nodes.

The DVN attested to a message that never happened, and Ethereum released the tokens. LayerZero's report scores the key layers:

Layer (owner)	April 18 outcome
Required DVN count (app)	Failed: one, so no second DVN could disagree
RPC sources (DVN operator)	Failed: internal nodes poisoned, external ones knocked offline
Signing keys (DVN operator)	Held: not compromised
Onchain quorum check (contract)	Held: signatures valid

The two sides disagree on why the route had one DVN. LayerZero says the owner changed a 2-of-2 stack to 1-of-1. Kelp told CoinDesk its setup "followed LayerZero's documented defaults," crypto.news reported.

LayerZero's report also shows Kelp's delegate, the account that sets the stack, was an EOA: a single key.

LayerZero Labs' DVN now refuses to sign for any channel where it is the only required DVN. A 1-of-1 with another DVN still works: "the protocol will enforce that policy."

Our Kelp DAO breakdown covers the attack and the Aave fallout.

Required and Optional DVNs

Each pathway's ULN config holds three settings:

requiredDVNs: every one must attest.
optionalDVNs and optionalDVNThreshold: at least the threshold must agree.
confirmations: source blocks to wait before attesting.

The contract rejects a config with no DVNs, but accepts a single DVN. Common stacks compare like this:

Stack	To forge, fool	LayerZero says
1 required	One DVN	"Not safe" in production
2 required	Both, at once	The minimum per channel
2 required + 1 of 2 optional	Three DVNs	For "medium-value pathways"
3 required + 1 of 2 optional	Four DVNs	"Widely used for critical assets"

Zero means default

In an app's config, 0 does not mean none. It means "use the default."

To set no optional DVNs, use the NIL value, type(uint8).max. A 0 and an empty list inherit whatever LayerZero sets later.

Guardian found this in Olympus's LayerZero bridge. It meant to pin two required DVNs, but encoded optional DVNs as 0 (M-01, resolved).

Count operators, not slots

The contract allows one DVN in both lists. In Animecoin's config, LayerZero's DVN sat in both, and four distinct DVNs were listed where 2 of 3 was intended (L-04, resolved).

Confirmations, Executor and Defaults

Confirmations

Set confirmations "against the worst reorg depth the source chain has produced, not its typical depth."

LayerZero's floors are 15 for Ethereum, with 32 preferred for high-value pathways, and 32 for Solana. Pin the value on both sides.

Guardian's public USDT0 reports show the per-chain judgment involved:

Polygon: 256 blocks looked low after 157 past reorgs; Stargate and Abracadabra used 512 (I-19, acknowledged).
HyperEVM: 60 confirmations, where Guardian advised 43,200, about half a day of blocks (I-02, resolved).
Arbitrum to Stellar: 4,000, where Arbitrum's usual setting was 60, flagged to confirm intent (I-01, acknowledged).

Executor

"A compromised Executor cannot forge messages," but it can delay or censor them.

Every preset uses LayerZero Labs' executor. Set yours explicitly, with a maximum message size.

Defaults

Unset values inherit defaults, which "may be Dead DVNs that prevent message delivery, may include only a single DVN, and may change without notice."

LayerZero advises pinning settings "even when the chosen values match the current default." A pinned config does not move when defaults do.

DVN Config Checklist

Verifiers

Two or more required DVNs from different legal entities, on-call teams and pipelines.
Different cloud providers, RPC providers and key custody across them.
At least one required DVN not run by LayerZero Labs. Never two from one operator.
Each DVN live on both chains. Abracadabra's MIM DVN was missing from LayerZero's Hyperliquid deployments (I-02, acknowledged).
Consider running your own DVN, which LayerZero says it "has always encouraged."

Confirmations

A floor per source chain, set from its worst reorgs.
Pinned on both sides, with send confirmations at or above receive.

Pinning and onchain checks

Libraries pinned with setSendLibrary and setReceiveLibrary on both chains.
Optional DVN count set to NIL or a real list, never 0.
Effective config read with getConfig(oapp, lib, eid, 2) on the endpoint.
Raw config read with getAppUlnConfig on the library. A 0 there is inherited.
Delegate on a multisig, never an EOA. It controls security config "with no signature required from the Owner."

Test the checker too. In USDT0's USAT reconfiguration, a verification script passed a chain still on two required DVNs when the config called for three (L-01, pending).

Changes and monitoring

Change DVN sets in the send-first order from our OFT checklist.
Decode and simulate every config transaction before signing.
Alert on UlnConfigSet and ExecutorConfigSet from the message libraries.
Alert on SendLibrarySet, ReceiveLibrarySet and DelegateSet from the endpoint, and PeerSet from your OApp.
If anything inherits a default, watch DefaultUlnConfigsSet and DefaultExecutorConfigsSet too.

The full per-pathway table is in our deployment verification checklist.

How Guardian Helps

Since February 2025, Guardian has verified USDT0's peers, DVN sets, confirmations and enforced gas on every pathway. That is 45+ engagements across 25+ chains.

In December 2025, we reviewed Gasolina, LayerZero's DVN signing service, for USDT0. It tested whether spoofed source data could make the signer attest to something untrue.

That review found nine issues, none Critical or High, and the fixes were merged upstream. After launch, Managed Security reviews every configuration change as it lands.

Frequently Asked Questions

How many DVNs should a LayerZero pathway have?

At least two required DVNs from independent operators, per LayerZero's post-Kelp guidance. Its docs suggest two required plus one of two optional for medium-value pathways, and three required plus one of two optional for critical assets.

What is the difference between required and optional DVNs?

Every required DVN must attest before a message is accepted. Optional DVNs count toward a threshold, so a 1-of-2 optional set still works with one optional DVN down.

Can the LayerZero Labs DVN be my only DVN?

No. Since the Kelp exploit, LayerZero Labs' DVN refuses to sign for any channel where it is the only required DVN. The protocol still allows a 1-of-1 with another DVN, which LayerZero's docs call unsafe.

How do I check my LayerZero DVN configuration?

Call getConfig on the endpoint for each pathway and direction to read the effective settings. Then read getAppUlnConfig on the library: any zero there means the setting inherits a default.

Sources

Check every DVN stack before it carries value

Guardian reads your live DVN sets, confirmations and roles on every pathway, the standard applied across USDT0's rollout.

Talk to Guardian Read the Gasolina case study