Why is your DVN threshold still 1?

A multi-chain token lost $292 million in 46 minutes, not to a smart contract bug, not to a novel exploit, but to a single verifier that was fed a lie.

LayerZero’s DVN (Decentralized Verifier Network) reads chain state through RPC nodes. The attacker poisoned two nodes with fabricated data, then DDoS’d the remaining legitimate nodes, forcing failover onto controlled infrastructure. The verifier attested to a fraudulent message. The destination chain executed. The bridge drained.

No Solidity bug. No reentrancy. The contracts did exactly what they were designed to do they trusted the verifier. The verifier was lying.

The Ecosystem Is Still Exposed

We pulled the full Dune dataset: 3,666 LayerZero OApps, 2,246,770 messages, 90 days of live traffic.

The numbers are alarming:

• 45.6% of the ecosystem sits at min_required_dvns = 0 or 1
• 17 named protocols are confirmed live at min=1 market caps ranging from $935K to $380M
• 5 of those 17 ATH, VANA, BIRB, ORDER, and MODE ran with literally 1 DVN signer across every single message for 90 days
• BIRB alone sent 213,037 messages through a single verifier. Not one backup.
• 228,760 total messages across the dataset: one verifier, no rotation, no redundancy

This wasn’t negligence. LayerZero’s V2 OApp Quickstart is shipped min_required_dvns = 1 as the default. Most teams deployed without changing it. 1,563 protocols are still in that configuration today.

Upgrading to min=2 Is Not Enough

The instinctive fix bump to min=2 is necessary but not sufficient.

81% of OApps have distinct_dvn_signers_90d exactly equal to min_required_dvns. Set min=2, you get exactly 2 signers with no rotation pool. If both operators source data from the same RPC provider, min=2 carries the identical attack surface as min=1.

The April attack didn’t target signing keys. It targeted the data that the keys were asked to sign.

Meanwhile, 98.2% of all messages ran with min_optional_dvns = 0 LayerZero's built-in defense-in-depth layer is completely ignored by nearly the entire ecosystem.

Three Things to Do This Week

1. Check your actual deployed config. Open layerzero.config.ts. If any route shows min_required_dvns = 1, that is your attack surface.
2. Verify RPC independence. Ask every required DVN operator which providers they use and what their failover sequence is. Shared infrastructure = shared risk.
3. Add invariant monitoring. April’s drain ran for 46 minutes. A simple off-chain check total cross-chain supply vs. source collateral could have triggered a pause in minutes.

The fix requires no redeployment. It’s a config change, an email, and one engineer-week of monitoring work.

Want the full breakdown named protocols, RPC attack mechanics, signer diversity data, and the complete 90-day dataset analysis?

We’ve covered it in depth: The LayerZero DVN Security Analysis

Why is your DVN threshold still 1? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.