> 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/integrate/recommended-dvn-sets.md).

# Recommended DVN sets

The verifier configurations Canary recommends, and why they are shaped this way.

The April 2026 incident happened on a one-of-one verifier configuration. No application holding real value should run anything weaker than 3-of-4.

Canary recommends one of two configurations depending on value at risk and threat model. Both always require Canary and LayerZero Labs as core verifiers, and both leave one optional slot for you to choose. That last point matters. If every Canary-integrated application ran the exact same five DVNs, a single compromised DVN would affect every customer at once. Letting you pick one slot deliberately decorrelates verifier sets across the integrated base, so your configuration is stronger, and so is everyone else's.

## Primary recommendation, 4-of-5

For production applications with material TVL, institutional counterparties or RWA exposure.

| Role                  | DVN              |
| --------------------- | ---------------- |
| Required              | Canary           |
| Required              | LayerZero Labs   |
| Required              | Deutsche Telekom |
| Optional, threshold 1 | Horizen          |
| Optional, threshold 1 | Your chosen DVN  |

The result is 4 signatures from 5 distinct verifiers on every message.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FUL1Z1AZFpYQlbmpuRlPL%2Frecommended-dvn-set-2026-10-08.png?alt=media" alt="The recommended 4-of-5 verifier set. Three required DVNs, Canary, LayerZero Labs and Deutsche Telekom, must all sign. Two optional DVNs, Horizen and a verifier the application chooses, sit behind a threshold of one. Four signatures from five distinct verifiers are required on every message. Notes below suggest Animoca-Blockdaemon or BCW Group for the open slot and describe the lighter 3-of-4 alternative."><figcaption><p>All three required DVNs and one of the two optional DVNs must sign, and the slot you choose keeps verifier sets decorrelated across the ecosystem.</p></figcaption></figure>

## Lighter alternative, 3-of-4

For smaller applications, early-stage protocols, or pathways that need a meaningful floor above one-of-one without the operational overhead of a five-DVN set.

| Role                  | DVN             |
| --------------------- | --------------- |
| Required              | Canary          |
| Required              | LayerZero Labs  |
| Optional, threshold 1 | Horizen         |
| Optional, threshold 1 | Your chosen DVN |

The result is 3 signatures from 4 distinct verifiers on every message.

## Strong choices for the slot you choose

Pick based on chain coverage, your existing operator relationships, and what diversifies your verifier set the most. Strong choices include Animoca-Blockdaemon and BCW Group. Diversity matters across five dimensions: codebase, operator, infrastructure, data source and security model.

## Why this shape

* **Why not only required DVNs.** Every required DVN is a liveness dependency. If any one of them has an outage, every message stalls until it recovers. An optional tier adds independent verifiers, and raises the bar for forgery, without adding a new single point of failure, because one optional verifier can be unavailable without stalling anything.
* **Why 4-of-5 over 3-of-4.** Forging a message in the 3-of-4 set requires compromising both required verifiers and one optional verifier, three in total. The 4-of-5 set raises that to four, including three independent required verifiers. For anything material, the marginal cost is small and the gain in resilience is significant.
* **Why not 5-of-5.** It is the strongest on safety, but the slowest DVN sets your latency and any single outage halts the system. It is worth considering only for the highest-value stablecoin or RWA bridges.

## When to go stronger

* **Above $1B TVL, or with institutional counterparty requirements,** raise the optional threshold to 2, which gives effectively 5-of-5 coverage on every message.
* **For stablecoin or wrapped-asset bridges,** the asymmetry between a safety failure, which is catastrophic, and a liveness failure, which is recoverable, favours higher thresholds. Add [Canary Cipher](/canary/the-assurance-layer/canary-cipher.md) reserve accounting and value-scaled checks on the pathways that carry the most value.
* **For regulated or RWA issuers,** the configuration should be a documented security decision signed off at the right level inside your organisation, not an engineering default. Issuers should also consider [Canary Cosigner](/canary/the-assurance-layer/canary-cosigner.md) for mint and redemption approvals, and [Canary Collateral Proofs](/canary/the-assurance-layer/collateral-proofs.md) to check and show what backs the asset across chains.

In all three cases, contact Canary to scope the right configuration for your threat model.

## The default configuration

Canary is part of the default security configuration on LayerZero, so new deployments that keep the default configuration have Canary verifying their messages on pathways where Canary operates. Setting your own configuration opts you out of future default changes. That is a feature, because your security posture cannot be silently altered, and a responsibility, because you own keeping the configuration current. Working code is in the [configuration file guide](/canary/integrate/configuration-file.md).