> 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/reference/faq.md).

# FAQ

Short answers to the questions that come up first.

## General

**Does Canary hold funds?** No. Canary verifies. It never custodies assets and holds no keys to user funds. With Canary Cosigner, Canary holds one approval key, inside an enclave, within the issuer's own signing quorum. Cosigner is one approver alongside the issuer's own signers. Its role is to withhold approval when the checks fail, not to initiate transactions, and issuance and redemption remain the issuer's decisions.

**How is Canary different from other DVNs?** Canary is a custom-built, fully independent verifier, not a shared reference implementation. It runs every verification inside hardware-isolated enclaves with a k-of-n quorum, certificate-pinned sources and confirmation floors it sets itself, and it has operated for nearly two years with 100% uptime and zero security incidents. Every application configures its own DVN set. Canary's view is simply that lighter verification carries tradeoffs in reliability and security that only become visible when something goes wrong.

**Is Canary part of the LayerZero default?** Yes. 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.

**Is Canary Protocol related to canary tokens or canary deployments?** No. Canary Protocol is the company behind Canary DVN, Canary Cipher, Canary Cosigner and Canary Collateral Proofs, and it is unrelated to canary tokens, canary deployments and other products that share the name.

**Can an AI assistant read these docs?** Yes. Connect it to the Canary MCP server, or point it at llms.txt or the Markdown version of any page. [Use these docs with AI](/canary/reference/ai-assistants.md) has the setup for each tool.

**What happens when Canary refuses?** For the DVN, the message does not reach quorum on that pathway and nothing settles. For Cosigner configured as a required approver, the issuer's quorum cannot complete and the mint or redemption does not execute. In both cases the refusal and its reason are recorded.

**Can a refusal be overridden at runtime?** No. On the DVN and Cipher path, policy is sealed into the enclave image at deploy time, so changing policy is a deployment, not a toggle. Cosigner can hold a request for further checks and review, but it does not sign a request whose checks have not passed.

## Canary Cipher

**Is Cipher mandatory?** No. Cipher is composable by design. Protocols configure the checks that match their own risk profile, and every application continues to receive Canary's core verification standard.

**Can protocols add their own checks?** Yes. Cipher supports custom verification hooks, so protocol infrastructure, issuer APIs, risk systems, compliance systems and backend services can take part in verification before Canary signs.

**What does a don't know verdict mean?** That correctness could not be established, which resolves to refusal. Fail-closed means uncertainty is never treated as approval.

**How do thresholds work?** They are custom per chain and pathway, defined with each protocol, and sealed at deploy time. Exact figures are not published.

**When are Cipher capabilities available?** Cipher is already in production with select protocols, including live reserve accounting. Capabilities roll out progressively across the Canary DVN as they are ready rather than to a fixed date. Protocols that want early access to advanced capabilities can talk to Canary directly.

## Canary Cosigner

**Who is Cosigner for?** Asset issuers, including stablecoin issuers, tokenised treasuries and funds, wrapped and bridged assets, and commodity-backed tokens.

**Do we need a new wallet or a migration?** No, where your authorisation mechanism supports it. Cosigner joins the signing workflow you already run as one more approver. It is designed to integrate with Fireblocks, MPC signing infrastructure, Safe multisig workflows and direct onchain roles.

**What does Cosigner check?** It reconciles collateral across onchain holdings, custodian, bank and fund administrator records, and auditor confirmations against token supply after the request, then runs anomaly detection and your own rules, before it signs. Canary Collateral Proofs are designed to supply the same evidence and show it to users.

**Does Cosigner prove that a bank balance is real?** No. Attestation proves which code processed the records and what it computed. Reconciling each record against independent sources and live onchain supply strengthens the evidence, but it does not prove that the bank's books are complete or that the assets are unencumbered.

**What happens if a key in our quorum is stolen?** If Cosigner is a required approver, a stolen key cannot complete the quorum without Cosigner's signature, and Cosigner signs only when the backing reconciles. If your contract also requires the onchain proof, a signature without a valid, request-bound proof is rejected.

**Is Cosigner's track record two years long?** Cosigner is a new product. The track record figures in these docs describe Canary's existing verification infrastructure, not Cosigner's standalone operating history.

## Canary Collateral Proofs

**How is this different from a reserve dashboard?** A reserve dashboard shows balances. Canary Collateral Proofs are designed to also show where each number came from, how it was checked, how current it is and what still needs trust, and to supply the same evidence to Cosigner and the DVN to inform whether a protected action can proceed.

**Does a verified record prove the bank's books are complete?** No. Verification shows that approved code processed the record and how the record was checked. It does not prove that the institution's books are complete or that the assets are unencumbered, and the transparency view keeps that limit visible.

**Why is an auditor confirmation not added to the reserves?** Because it confirms the same assets rather than adding new ones. Counting it as a second pool of reserves would overstate the backing.

**What happens when evidence is stale or sources disagree?** The transparency view is designed to show the record as stale, unavailable or in disagreement, and that evidence is not treated as current when Cosigner or the DVN evaluates a protected action. On the Cosigner path, a request with inconsistent records is held for review rather than approved on the more convenient number.

**Do the dashboard and the signing systems use the same numbers?** That is the design. Both outputs come from one verification foundation, so that the dashboard does not show one version of the reserves while the signing systems use another.

**Do the underlying records have to be published?** No. In the intended proof-enabled design, an onchain verifier checks a zero-knowledge proof of the attestation and its result, so verification can be part of approval without publishing all the underlying records.

## Pricing

**Does the fee require integration changes?** No. Existing integrations continue working exactly as before. The fee is collected onchain as part of the standard message cost.

**What does the fee fund?** Engineering, audits, multi-cloud and multi-hardware infrastructure, independent TEE technologies, onchain zero-knowledge verification, and continued Cipher development.

**How are Cipher and Cosigner priced?** Higher-volume teams, protocols that need advanced Cipher capabilities, and issuers adopting Cosigner work directly with Canary on tailored commercial agreements. See [Pricing](/canary/pricing.md).