> For the complete documentation index, see [llms.txt](https://canary-1.gitbook.io/canary/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://canary-1.gitbook.io/canary/the-assurance-layer/canary-dvn.md). # Canary DVN The verification layer. What Canary DVN does, what every message gets, and the numbers behind it. Canary DVN is the verification primitive, the layer that decides whether a cross-chain message is real, final and exactly what the source chain says, and proves it before signing. The design goal is simple to state and hard to achieve. It should be cryptographically impossible for Canary, or anyone who compromises Canary, to produce a false attestation, not merely expensive or unlikely. The whole security stack exists to meet that goal. Most verifier operators run the same shared reference implementation, where the practical difference between them is which cloud holds the signing key. Canary is a fully independent client, written from scratch in Go, because the verification standard Canary enforces does not exist off the shelf. ## At a glance | Dimension | Value | | ------------------------------------------------------ | ----------------------------------------------------------------------------------- | | Client | Fully independent, written from scratch in Go | | Execution environment | AWS Nitro Enclaves in production; additional independent TEE vendors in integration | | Footprint per node | 1 vCPU, 2GB RAM | | Throughput | 700+ requests per second per node | | Verification latency | Sub-100ms | | Throughput against the shared reference implementation | Roughly 15x on the same workload | | Quorum | 2-of-3 standard, 3-of-4 on high-traffic chains, custom for high-value applications | | Ecosystem position | Part of the default security configuration on LayerZero | | Coverage | 140+ chains | | In production | Since January 2025 | | Cross-chain volume secured | $53.4B+ cumulative, as of 7 October 2026 | | Messages verified | 1.6M+, as of 7 October 2026 | | Uptime | 100% | | Security incidents | Zero | ## Part of the LayerZero default Canary is part of the default security configuration on LayerZero. New deployments that keep the default configuration ship with Canary verifying their cross-chain messages from day one, on pathways where Canary operates, with no integration work. Applications that set their own configuration choose their DVN set explicitly. Canary's recommendation for those applications, and the reasoning behind it, is on [Recommended DVN sets](/canary/integrate/recommended-dvn-sets.md). ## What every message gets * Multiple independent RPC sources, with variance checks across them, so one wrong or lagging source is outvoted rather than believed. * SSL certificate pinning inside the enclave, so the data path itself is authenticated. * Authenticated headers and replay protection on every request. * Hardware-isolated TEE execution with hardware-level attestation of the code that ran. * A k-of-n quorum across independent operators and infrastructure providers. * Per-chain confirmation floors that Canary sets above network defaults, which no application configuration can lower. * Multisig, geographic and infrastructure redundancy, with no single point of failure.
Six defence layers stacked, each labelled with the class of attack it removes: the independent client, trusted execution, quorum, certificate pinning, authenticated headers and operational security.

Each layer removes a class of attack on its own. Together they require an attacker to defeat every layer at once.

## What you do not get You do not get a signature on anything Canary cannot prove, and that is the product. If a check fails, the sources cannot be reconciled or quorum cannot be reached, Canary does not sign, and it never signs before the confirmation floor is reached. The message does not reach quorum on that pathway and nothing settles. Every refusal is logged with its reason, as described on [Refusal transparency](/canary/trust-and-transparency/refusal-transparency.md). ## Standalone, or with Cipher The DVN runs standalone, and every application that uses it receives Canary's core verification standard. [Canary Cipher](/canary/the-assurance-layer/canary-cipher.md) builds on top of it for protocols that want a second question asked before anything is signed: not only whether the message is valid, but whether the transfer should happen at all. ## With collateral evidence For assets whose backing matters on every transfer, such as stablecoins and tokenised funds, [Canary Collateral Proofs](/canary/the-assurance-layer/collateral-proofs.md) are designed to add the backing information needed to evaluate a transfer against the asset's broader accounting rules. The question is then not only whether the message is authentic. It is also whether the movement preserves the relationship between the asset's backing and its obligations across chains. A transfer should not create duplicate claims, overlook an unsettled transfer, or treat each chain as though it had a separate claim on the same reserve pool. The check of this kind already in production on the DVN path is [reserve accounting](/canary/how-it-works/reserve-accounting.md), which runs in Canary Cipher. Where a route requires Canary's approval and the collateral checks are enforced, a failing transfer is not approved. ## Read more * [The security stack](/canary/how-it-works/security-stack.md) * [Trusted execution](/canary/how-it-works/trusted-execution.md) * [Quorum, sources and node health](/canary/how-it-works/quorum-sources-and-node-health.md) * [Confirmation floors](/canary/how-it-works/confirmation-floors.md) * [Performance and footprint](/canary/how-it-works/performance-and-footprint.md)