Strengthen Your Existing Bridge With ZK

Starting with out-of-the-box support for LayerZero DVNs

Estimated ~5 minute read

Learn more at: crosschain.boundless.network

Executive Summary

• Most cross-chain systems still rely on the same basic trust model. Offchain verifier networks observe source-chain events and attest to them on the destination chain. LayerZero, Wormhole, Axelar, and Chainlink CCIP use different names, but the underlying model is similar.

• More verifiers help, but they do not remove correlated observation risk. Adding the same kind of verifier leaves the evidence model unchanged. A proof-backed verifier changes the evidence model.

• Boundless adds a ZK-backed verifier path to that stack. It does not ask teams to replace the bridge they already use. Boundless-DVN integrates seamlessly with LayerZero today, including existing OFTs on L2->L1 and L2->L2 routes.

• Earlier ZK lite client efforts, such as PolyHedra, proved the idea was real. What changed is cost, latency, and integration shape. On the Boundless Market today, Helios-class proofs can be produced in under a minute and land as low as $0.01 per L1 proof. Full finality remains slower, tens of minutes, and more expensive (as low as $0.20), but that is acceptable on high-value routes.

Cross-chain systems often use different labels for a similar trust model. LayerZero calls them DVNs. Wormhole calls them Guardians. Axelar uses validators. Chainlink CCIP uses a DON. The terminology differs, but the underlying pattern is similar.

An event happens on a source chain. Offchain actors observe it. A destination chain accepts their attestations that the event was real and sufficiently final. That model won for good reasons. It is fast, portable across chains, and easy to adapt. It is also more fragile than it looks when too much of the security story rests on operator observation.

The KelpDAO exploit on April 18, 2026 made that fragility hard to ignore. A forged LayerZero message passed through a compromised 1-of-1 DVN configuration and roughly $292 million was lost.[1][2] The obvious lesson was that no serious route should rely on a single verifier. That is true. It is also incomplete. The deeper lesson is that verifier count alone is not enough if the stack still depends on the same observation-heavy trust model.

More Verifiers Is Not Enough

"Use 2-of-3 instead of 1-of-1" is directionally right, but it does not solve the whole problem. Multiple DVNs only help if they are genuinely independent in how they reach a decision. In practice, that independence is easy to overstate. Different verifier networks can still depend on similar RPC infrastructure, same node providers, similar monitoring pipelines, or similar operational shortcuts. On paper the stack looks diverse. In production the failure modes can still line up.

That is the actual security question. Not just how many verifiers are in the quorum, but what evidence they are using. A trust-based DVN says, in effect, "I saw this message on the source chain and I am signing that claim." A ZK-backed verifier says something stronger: "Here is cryptographic evidence that this message is consistent with the source chain's consensus and inclusion rules."

A proof-backed verifier changes the evidence model. It does not ask the destination chain to trust another offchain observer. It asks it to verify proof against the finalized chain state. That removes a major class of observation-based failure. Poisoned RPCs can fool an operator. They cannot fabricate a valid proof of the finalized chain state. That does not remove every risk. Bugs still exist. Integrations can still be wrong. Bridge logic can still fail around the proof path. But it does remove one of the most important failure modes in today’s cross-chain stacks, and that is why a ZK layer materially improves security.

Why This Is Practical Now

This is not a new category. Polyhedra's zkLightClient showed early that a ZK-backed verification path could be integrated into LayerZero and deployed across many chains.[5] That mattered because it proved the idea was real. It also showed why the market did not immediately standardize on it. Proving was expensive, chain-specific engineering was hard, and latency was worse than the fast heuristic paths teams were already comfortable with.

That tradeoff has changed. That tradeoff has changed. What used to look like tens of dollars per proof can now land closer to cents for lighter paths, with a clear path to further reductions. Development patterns are more mature and efficient. Modular security surfaces make additive integration cleaner. After KelpDAO, this is no longer a theoretical improvement looking for a use case; the market now has a concrete reason to accept some extra latency in exchange for a stronger trust model.

Safe And Practical Means Using Tiers

The practical model is not to replace every fast path with the heaviest possible proof. It is to add proof-backed verification that teams can match to risk and value. On supported routes, that is deployable today. It is efficient enough to use broadly, and configurable enough to strengthen the routes where being wrong matters most. Put simply: safe systems should use ZK in tiers.

At the fast end, trust-based DVNs still have a role. They remain the lowest-latency path, but they are also the weakest from an evidence standpoint because they still rely on operator observation. The next tier is light-client-style verification. A16z Helios is the clearest example. It can be proved in under a minute and, on current Boundless measurements, costs on average $0.04 per L1 proof. That is cheap enough to use broadly on routes that need a real cryptographic check without paying for maximum assurance on every message.

At the higher-assurance end, full-finality proofs like Signal do more work and cost more. Today, a full-finality proof is closer to $0.37 per finality event. That is not the right path for every transfer. It is the right path when the value at risk is high enough that being wrong is catastrophic.

That is the model. Use lighter proofs where they are sufficient. Use deeper proofs where more value is at risk. Keep fast paths where speed matters, but stop letting pure observation be the only line of defense. Cross-chain security is end-to-end, and high-consequence messages should clear more than one independent verifier path, not just more copies of the same one. For those routes, a few extra minutes and less than a dollar for a stronger proof-backed path is a reasonable price to pay.

Why We Started With LayerZero

This vulnerability is not unique to LayerZero. We nonetheless begin here because there is a heightened sense of risk following the recent hack, on top of this LayerZero provides a clean integration surface for adding a stronger verifier path without forcing a bridge migration. Existing OFTs can add that layer today, including L2->L1 and L2->L2 routes.

The harder work was not "support LayerZero." It was building the general pattern: source proofs, destination-side verification, and an integration shape that strengthens a bridge without replacing it. That pattern matters beyond LayerZero. Once it exists, adapting it to other bridge providers gets much easier. Boundless-DVN is the LayerZero package of that broader model.

Conclusion

Cross-chain messaging will keep using offchain worker networks. That is not the part that needs to change. The part that needs to change is the evidence they rely on.

Not every verifier path needs full finality. Not every route needs the same proof depth. But high-value routes should stop relying on observation alone. Require at least one verifier path that has to prove cryptographically what it claims.

If you operate a high-consequence cross-chain route, now is the time to add a proof-backed verifier path. Boundless Networks can help you strengthen the bridge you already use, starting with LayerZero today.

Learn more at: crosschain.boundless.network

Sources

1. LayerZero, "KelpDAO Incident Statement" (April 19, 2026): https://layerzero.network/blog/kelpdao-incident-statement

2. Blockaid, "How a Single LayerZero DVN Compromise Drained $292M from KelpDAO" (April 19, 2026): https://www.blockaid.io/blog/how-a-single-layerzero-dvn-compromise-drained-292m-from-kelpdao

3. LayerZero, "LayerZero V2: Explaining DVNs" (February 9, 2024): https://layerzero.network/blog/layerzero-v2-explaining-dvns

4. LayerZero Docs, "EVM DVN and Executor Configuration": https://docs.layerzero.network/v2/developers/evm/configuration/dvn-executor-config

5. Polyhedra, "zkLightClient on LayerZero": https://docs.zkbridge.com/zklightclient-overview/zklightclient-on-layerzero