> 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-canary-standard.md). # The Canary standard The doctrine behind every design decision, applied the same way to every Canary product. Canary is built to say no. Every product applies the same standard, whether the decision in question is a DVN attestation on a cross-chain message, a Cipher verdict on a transfer, a Cosigner approval on a mint, or what Collateral Proofs present as verified. ## Correctness over liveness Most systems treat uptime as the prize and correctness as the assumption. Canary inverts the priority. Others may sign first. Canary signs when its standards are met, and never below them. If correctness cannot be proven, the system refuses and halts rather than signing anything it cannot verify. Liveness still matters, and it is protected by design rather than by lowering the bar. The recommended DVN sets add verifiers in an optional tier, where one can be unavailable without stalling messages, and Canary's own nodes run with geographic and infrastructure redundancy so that a single failure does not take the quorum down. ## Predefined standards, not negotiated ones Confirmation floors are predefined, not negotiated. Baseline thresholds, check sets and policy are fixed before traffic arrives and sealed into the enclave image at deploy time. An application can always ask for stricter settings. No one, including Canary, can loosen them at runtime, and no customer can negotiate them down. ## Fail-closed by construction Refusal is not an error state that operators handle. It is the designed response to uncertainty. A missing answer, a timeout and an unreachable dependency each resolve to refusal, because a system that fails open is a system an attacker only needs to inconvenience. ## Impossible, not unlikely The design goal is that it should be cryptographically impossible for Canary, or anyone who compromises Canary, to produce a false attestation, not merely expensive or unlikely. Every layer of the stack exists to meet that goal, and where one layer cannot meet it alone, another independent layer is added rather than an assumption. ## From keys to proofs The industry's answer to key-shaped exploits has been to guard the key more carefully. Canary's answer is to make the key insufficient. A Canary signature requires many signers rather than one, every check a protocol needs rather than a single check, and proof that the right code ran rather than trust that it did. Even a stolen key cannot produce a valid attestation without the correct code executing inside a genuine enclave. The cryptography is the security, not the keys. ## Always an and, never an or No single cloud provider, region, hardware vendor, RPC path, backend system or signer should be enough to compromise the network. Canary uses multiple RPC sources, multiple checks, multiple systems and multiple layers of verification. Each layer independently removes a class of attack, and together they require an adversary to defeat every layer at once. ## Enumerable claims Canary states exactly what it proves and what it does not. Hardware attestation establishes which code ran and what it computed. It does not make an offchain record true. Where Canary relies on a record it cannot prove directly, such as a custodian statement, it reconciles that record against independent sources rather than trusting any one of them, and says so. A claim that cannot be stated precisely is not made. A proof that approved code processed a bank record is different from proof that the bank's books are complete or that the assets are unencumbered. Canary Collateral Proofs are designed to keep that difference in view. An independent confirmation of the same assets is never presented as a second pool of reserves, and a single "verified" label never hides the scope of what was checked. ## One standard for every boundary Every Canary product shares one foundation: hardware-isolated execution, pinned and attested data sources, evidence with its limits visible, reconciliation before signature, and refusal as the security primitive. A new chain, a new product or a new customer receives the same standard from its first day, not after a period of trust-building. ## The controls are not new Serious finance runs checks before money moves: dual approval, senior sign-off on large transfers, daily caps, hold and recall, reconciliation and separation of duties. Crypto replaced all of them with a single private key. Canary redesigns them in code, with multi-party sign-off, checks that scale with value, rate limits and caps, automatic halt, reserve accounting and anomaly detection, and no single-key power.
Six controls from traditional finance mapped to their Canary equivalents: dual approval becomes multi-party sign-off, senior sign-off becomes value-scaled checks, daily caps become rate limits, hold and recall becomes automatic halt, reconciliation becomes reserve accounting and Collateral Proofs, and separation of duties becomes no single-key power.

The controls that have protected money for a century run as code before the signature.

These controls have protected money for a century. Canary is how they come onchain without bringing back the middlemen. ## Proof over promises Operating at scale without an incident was the proof of concept, and the record is public. Live figures are published on Dune, every refusal is logged with its reason, and the headline figures in these docs carry their basis and date on [Figures and sources](/canary/reference/figures-and-sources.md). Nothing settles unproven.