# LayerZero DVN Checker: Bridge Verifier Settings

> Check LayerZero DVN settings for major OFT tokens: required and optional verifiers, block confirmations and 1-of-1 DVN routes, read from each endpoint's config.

Markdown copy of https://voltfincrypto.com/apps/layerzero-dvn-checker

**Question:** How many independent verifiers must sign off on messages for each major LayerZero-bridged token, and which rely on just one?

- Kind: Table in Voltfin Strata
- Topic: [Layer 2s](https://voltfincrypto.com/topics/layer-2)
- Chains: Multi-chain, Ethereum, Arbitrum, Base, OP Mainnet, BNB Chain, Avalanche, Polygon
- Status: Planned. The data is not published yet, so this page states no figure; each figure will open its receipt when it is.

LayerZero moves tokens between chains by passing messages, and the destination accepts a message only once the verifiers an app has chosen, called DVNs, have checked it. This table reads that choice for every major LayerZero-bridged token, route by route, straight from the LayerZero endpoint contracts: which DVNs are required, how many optional ones must also agree and how many block confirmations they wait for.

A route that needs a single DVN trusts one verifier with every message on it: if that verifier is wrong or its keys are compromised, the destination can mint or release tokens that were never sent. The table flags those routes, as well as routes still running on LayerZero's default settings, which change whenever the defaults do.

Each row is read at a pinned block on the receiving chain, with the call and the decoded configuration as its receipt, so any setting can be checked again by anyone.

## Blueprint

One row: One row per token per route (source chain to destination chain), at the latest daily read

- **Token** (`token`): The bridged token, linked to its OApp contract on the destination chain.
- **From** (`source_chain`): The chain that messages on this route come from.
- **To** (`destination_chain`): The chain whose endpoint configuration is read: where messages are verified and tokens minted or released.
- **Required DVNs** (`required_dvns`, count): How many DVNs must all attest to each message on this route.
- **Optional DVNs** (`optional_threshold`): The number of optional DVNs that must also attest, out of the number listed; empty when the route lists none.
- **Verifiers needed** (`verifiers_needed`, count): Required DVNs plus the optional threshold: the attestations each message needs before delivery.
- **DVN operators** (`dvn_operators`): The operator behind each listed DVN from published deployment lists, or its address where no label exists.
- **Confirmations** (`confirmations`, blocks): Blocks the DVNs wait on the source chain before verifying a message.
- **Config source** (`config_source`): Whether the route uses the app's own configuration or LayerZero's default, and whether its library is pinned.
- **Single verifier** (`single_verifier`): Yes when one DVN's attestation is enough to deliver a message on this route.
- **Supply on destination** (`supply_on_destination`, tokens): The token's totalSupply() on the destination chain, or the locked balance where the destination is the home chain, at the same day-end block.
- **Receipt** (`receipt`): The block, the getConfig call and the decoded configuration behind the row.

## How it will be measured

- For each token's app (its OApp) and each source chain, the receive library is read with EndpointV2 getReceiveLibrary, then its ULN configuration with getConfig, config type 2, decoded into confirmations, required DVNs, optional DVNs and the optional threshold.
- Verifiers needed is the required DVN count plus the optional threshold: the number of independent attestations a message must collect before it can be delivered.
- A route is marked as on defaults when the OApp has set no configuration of its own, and as unpinned when it follows the default library, because a change to either default changes its security.
- DVN addresses are labelled with their operators from LayerZero's published deployment lists; an unlabelled DVN is shown by its address, never guessed.
- Routes are found from PeerSet events on each OApp, and token supply on each chain is read with totalSupply() at the same day-end block.

## Data it needs

- `bridge_flows_daily` (to build): Deposits into and withdrawals out of canonical and major third-party bridges by chain, token and day, plus escrow balances at day end.
- `token_supply_daily` (to build): Total supply of each registry token on each chain at day end: wrapped BTC, liquid staking tokens, tokenized assets and other tracked tokens.
- `address_labels` (to build): Labels for known addresses: exchanges, bridges, protocols, funds, treasuries, sanctioned addresses and known attackers.
- Source: EndpointV2 getConfig(oapp, receiveLibrary, srcEid, 2), decoded to confirmations, requiredDVNCount, requiredDVNs, optionalDVNs and optionalDVNThreshold
- Source: EndpointV2 getReceiveLibrary and defaultReceiveLibrary per OApp and source endpoint id
- Source: OApp PeerSet events, to map each token's deployments and routes
- Source: OFT totalSupply() on each chain at day-end blocks
- Source: LayerZero's published DVN and endpoint deployment lists, for operator labels

## Questions

### What is a DVN in LayerZero?

A decentralized verifier network: an operator that checks a cross-chain message on the source chain and attests to it on the destination. Each app chooses which DVNs it requires, and the destination accepts a message only when enough of them have verified it.

### What does a 1 of 1 DVN setup mean?

It means a route requires a single DVN and no optional ones, so one verifier's attestation is enough to deliver a message. The route is then only as secure as that one operator and its keys.

### Who sets the DVN configuration?

The owner or delegate of each app sets it per route on the LayerZero endpoint. If they set nothing, the route uses LayerZero's default configuration for that pathway, which LayerZero can change later.

### How many DVNs does LayerZero recommend?

LayerZero's own documentation recommends that production routes require at least two DVNs run by different operators. The table shows each route's actual settings, so readers can compare them with that guidance.

### Does a strong DVN setting make a bridged token safe?

No. The verifier setting is one part of the risk. The token contract and its owner powers, the executor, the source chain's finality and the backing held on the home chain all matter too; the bridged token backing page checks the last of these.

## Glossary

- **OApp**: An omnichain application: a contract that sends and receives LayerZero messages, such as an OFT token contract on each chain.
- **OFT**: Omnichain fungible token: a LayerZero token standard that burns or locks tokens on one chain and mints or releases them on another.
- **Required DVNs**: The verifiers that must all attest to a message before the destination delivers it.
- **Optional threshold**: How many of an app's listed optional DVNs must also attest to a message, on top of the required ones.
- **Block confirmations**: How many blocks the DVNs wait on the source chain before verifying a message, as protection against reorganizations.

## Related apps

- [Bridged Token Backing: Locked vs Minted Supply](https://voltfincrypto.com/apps/bridged-token-backing)
- [DeFi Admin Keys: Multisig Thresholds and Timelocks](https://voltfincrypto.com/apps/defi-admin-keys-multisig-timelocks)
- [Cross-Chain Intents: Volume, Solvers and Fill Times](https://voltfincrypto.com/apps/cross-chain-intents-solvers)
- [Smart Contract Upgrade Tracker: Proxy and Owner Changes](https://voltfincrypto.com/apps/smart-contract-upgrade-tracker)
- [Liquid Restaking Tokens: Backing and Exchange Rates](https://voltfincrypto.com/apps/liquid-restaking-backing)
- [Ethereum TPS: Mainnet and Layer 2 Transactions per Second](https://voltfincrypto.com/apps/ethereum-tps)

Build it in Voltfin Studio: https://app.voltfincrypto.com/signup?next=%2F