> 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/confirmations-and-pitfalls.md).

# Confirmation counts and common pitfalls

The settings that stall messages, and how not to hit them.

## Confirmation counts

The `confirmations` value is the number of source-chain blocks DVNs wait before signing. Too low risks a reorg invalidating a message that has already been signed. Too high adds unnecessary latency.

Canary enforces a minimum floor per chain and overrides any configuration below it, as described on [Confirmation floors](/canary/how-it-works/confirmation-floors.md). You can always ask for more confirmations than the floor. You cannot ask for fewer.

To sanity-check a pathway, read what major applications on the same pathway use through `getConfig` with `configType = 2`. The standard across institutional applications is a strong signal.

## Common pitfalls

**Ordering.** DVN address arrays must be sorted ascending. A set that is correct but unsorted is rejected when you apply it. Sort by the lowercase form of each address, which matches numeric order. A case-sensitive sort of checksummed addresses can put them in the wrong order.

**Send and Receive must match.** Both ends of a pathway must expect the same DVN set. If Chain A sends with a set that Chain B's Receive configuration does not expect, messages stall. This is the single most common integration error. The devtools warn about it, but check anyway, and if you change your required DVNs on one chain, update the other at the same time.

**Explicit configuration opts out of defaults.** Once you call `setConfig`, you are opted out of future default changes. This is a feature, because your security posture cannot be silently altered, and a responsibility, because you own keeping the configuration current if a DVN is deprecated.

**Configure both directions.** A common mistake is configuring Chain A to Chain B and forgetting the reverse. Bidirectional applications need complete Send and Receive configurations both ways.

**Set the delegate first.** If your application uses a delegate for configuration changes, set it explicitly with `setDelegate` before wiring, or subsequent configuration updates will revert.

**Verify, then trust.** Read every configuration back onchain and confirm it on LayerZero Scan for every pathway, in both directions.

## Pre-mainnet checklist

* [ ] Canary and LayerZero Labs are required on every pathway.
* [ ] The optional tier has a threshold and a slot you chose deliberately.
* [ ] DVN arrays are sorted ascending on every chain.
* [ ] Send and Receive configurations match on both ends of every pathway.
* [ ] Both directions are configured for bidirectional applications.
* [ ] The delegate is set before wiring.
* [ ] Confirmation values are at or above what institutional applications use on the same pathway.
* [ ] The live configuration has been read back with `getConfig` and checked on LayerZero Scan.