A ZK DVN for LayerZero. Different trust assumptions for cross-chain delivery.
Boundless is a DVN that verifies messages with ZK-backed consensus proofs. It layers on top of today's trust-based DVNs, so an attacker has to break two different security assumptions, not one.
Why add a ZK DVN? It fails differently.
On Apr 18 an attacker poisoned the RPC nodes the LayerZero Labs DVN trusted for source-chain data. The 1/1 DVN config attested to forged messages. $292M drained in one tx, every OFT bridge using the default config froze within hours.
Most current DVNs reduce to operator honesty and RPC integrity. Boundless reduces to validator signatures, proof verification, and circuit soundness. That does not make it magic. It makes it a different security layer.
That only matters if it is practical to deploy. For routine cross-chain flows, it already is: proof cost can amortize below a cent per message at normal volume.
- A multisig signs that it saw the message.
- Truth comes from an RPC node.
- Failure: RPC spoofing, operator compromise, key theft.
- The attack surface Apr 18 exploited.
- A ZK circuit verifies the source chain's state directly.
- Truth comes from validator BLS signatures.
- Failure: circuit bug or cryptographic break — different surface, audited.
- Decentralized proving — no single prover can forge.
Boundless does not replace your current DVNs. It adds an independent verification layer whose failure modes do not overlap with a trust-based DVN. The result is stronger defense in depth without asking you to rip out the stack you already run.
Same LayerZero packet. Four steps. The only new part is the proof.
A Boundless DVN example is live today.
This example shows the full LayerZero integration shape on a live Sepolia ↔ Base Sepolia corridor. The same pattern can be extended to additional chains and hardened for partner-specific production routes.
Live example today, with a stack built to cover the routes most EVM teams care about first.
The live corridor proves the design on a real route today. From there, the same verification pattern can be carried into the inbound and outbound routes partners care about first.
Production routes expand from the same design, starting with the corridors partners care about most.
Security you can price today: practical for routine flows, stronger proofs for higher-stakes transfers.
You do not need to choose between stronger verification and workable margins. Pick the proof tier that matches the value at risk and the latency you can tolerate. Every cycle count below is from an R0 executor run against live or realistic data.
Helios is the practical default for routine flows. When the value settled by a single proof crosses ~$20M, or when counterparties want full-validator slashable security, move to Signal. Boundless currently sponsors Signal proof generation, so the incremental cost is dominated by on-chain verify gas. The tradeoff is latency: tens of minutes per proof today. Same DVN contract, same integration surface — you choose the proof tier per flow.
Destination-side on-chain verify() is ~35K gas on any L2 (~$0.01) and ~50K gas on Ethereum L1 (varies with L1 gas price). That cost is the same for every tier.
One proof covers every message in its window. Batch your outbound flow and per-message cost collapses toward the verify gas.
A Helios proof covers a ~27-hour sync-committee window. A Signal proof covers a ~12.8-minute epoch. A blobstream0 proof can cover 1,000+ Cosmos headers at the same cycle cost as one. You don't pay per-message — you pay per proof, and the proof is shared across every message the DVN attests in that window.
The numbers above are marketplace pass-through as of April 2026 at the spot floor. Dedicated proving capacity, SLA-backed uptime, and volume discounts aren't published — if this matches a flow you care about, reach out and we'll size the actual profile against your message load.
Audited primitives, live proving volume, and a verifier stack you can carry into partner routes.
One setConfig() tx. No governance. No migration.
Boundless layers onto your current DVN stack without replacing it. LayerZero calls this an optional DVN in config. With optionalDVNThreshold = 1, Boundless becomes part of the enforced verification path for every message. Snippet below is illustrative — exact values depend on your OApp's DVN set and destination chains.
- Testnet
- Ethereum Sepolia → Base Sepolia
- Target mainnets
- Ethereum, Base, Optimism, Arbitrum
- Launch pricing
- Marketplace pass-through
- SLAs / volume terms
- By conversation
// 1. Deploy Boundless DVN is already done for you on your destination chain.// Addresses live in https://boundless.network/dvn/addresses.address constant BOUNDLESS_DVN = 0x0000_...9AF2; // Base mainnetaddress constant LZ_LABS_DVN = 0x589D...5BE8; // keep your existing required DVNUlnConfig memory cfg = UlnConfig({confirmations: 15,requiredDVNCount: 1,optionalDVNCount: 1,optionalDVNThreshold: 1, // message cannot commit without ZK proofrequiredDVNs: toArray(LZ_LABS_DVN),optionalDVNs: toArray(BOUNDLESS_DVN)});SetConfigParam[] memory params = new SetConfigParam[](1);params[0] = SetConfigParam({eid: BASE_EID,configType: 2, // ULN configconfig: abi.encode(cfg)});// 2. One tx, OApp-owner signed.ILayerZeroEndpointV2(ENDPOINT_V2).setConfig(oapp, receiveLib, params);
Questions security, bridge, and integration teams will ask first.
The short answers below are meant to make the design, the live example, and the current support surface legible without a separate architecture review.