> 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-assurance-layer.md). # The Assurance Layer Four products on one foundation, covering the evidence behind an asset and how it is created, moved between chains and redeemed. The Assurance Layer is Canary's role in the stack, the place where evidence is gathered and checked before value moves. Four products sit inside it. Canary DVN and Canary Cosigner each guard a different signature, and Canary Cipher adds the application's own rules to the DVN's. Canary Collateral Proofs are designed to supply the evidence about an asset's backing that those signatures rely on, and to show users how that evidence was verified. All four apply the same standard. | | Canary DVN | Canary Cipher | Canary Cosigner | Canary Collateral Proofs | | -------------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | **Role** | The verification layer | The security engine | Collateral verification for issuers | The evidence foundation and transparency layer | | **Where it sits** | In the LayerZero signing path of every cross-chain message it secures | In the same enclave environment, consulted by the DVN before it signs | In the issuer's own signing quorum: Fireblocks, Safe, MPC or onchain roles | Beneath Cosigner and the DVN path, and in front of users through the transparency view | | **What it verifies** | The message matches the source-chain event, at Canary's confirmation floor, agreed by a k-of-n quorum | The application's own rules: reserves, burn match, limits, anomalies and custom hooks | Collateral against supply plus the request, the issuer's rules, and anomalies | What backs the asset, where each record came from, how it was checked and how current it is | | **What it gates** | Cross-chain message delivery | Cross-chain transfers that break the application's rules | Mints and redemptions | It gates nothing on its own. Cosigner and the DVN path apply its evidence | | **Outcomes** | Sign, or refuse | Yes, no or don't know; only a yes proceeds | Co-sign, hold, or refuse and alert | A transparency view, and a verification result used to approve, hold or refuse | | **Built for** | Any LayerZero application | Stablecoins, tokenised funds, wrapped assets, restaking, lending and trading venues | Stablecoin issuers, tokenised treasuries and funds, wrapped and bridged assets, commodity-backed tokens | Issuers of backed assets, and the holders and counterparties who rely on them | | **How you adopt it** | Add Canary to your DVN set, or keep the default configuration on supported pathways | Working session, observe mode, then enforcement | Optional signer first, required approver once proven | Book a call with Canary |
The Assurance Layer across the life of an asset. Canary Collateral Proofs are built to verify the evidence behind the backing, show it to users in a transparency view, and supply it to the products that sign. Canary Cosigner checks mints and redemptions, Canary DVN with Canary Cipher checks cross-chain movement, and every path ends in a proven signature or a refusal. A note says that where Cosigner is configured as a required approver, its refusal stops the mint or redemption.

The same evidence and the same standard guard each signature as an asset is created, moved and redeemed.

## One foundation The four products share the same building blocks, which is why a protocol or issuer can adopt one and add the others on the same foundation. * **Hardware-isolated execution.** Checks and signing keys live inside trusted execution environments, with attestation of exactly which code ran. * **Pinned and attested sources.** Upstream data is read over certificate-pinned connections inside the enclave and cross-checked across independent sources. * **Evidence with its limits visible.** Canary Collateral Proofs are designed to keep each record's source, checks and freshness attached to it, so the evidence shown to users is the same evidence the signing products use. * **Reconciliation before signature.** Supply, reserves and the effect of the request are reconciled before a signature exists, never after. * **Refusal as the security primitive.** Every path ends in a proven signature or a refusal. There is no signed-and-awaiting-review state. * **Proof the contract can check.** For high-value actions, an attestation can be wrapped in a zero-knowledge proof and verified onchain, so that where the contract requires the proof, a key alone is not enough to authorise. ## From cross-chain security to full-stack verification Canary began by securing how value moves between chains. For stablecoins and tokenised assets, issuance, cross-chain movement and redemption are one lifecycle, and treating them as unrelated security problems leaves gaps between them. Canary DVN and Canary Cipher secure the movement. Canary Cosigner extends the same standard to the moments value is created and redeemed. Canary Collateral Proofs are designed to connect them with one body of evidence about the backing, used at every point where value changes and shown to the people who rely on the asset. The aim is not only visibility into transactions. It is verification before execution. ## Product pages * [Canary DVN](/canary/the-assurance-layer/canary-dvn.md), the verification layer. * [Canary Cipher](/canary/the-assurance-layer/canary-cipher.md), the security engine. * [Canary Cosigner](/canary/the-assurance-layer/canary-cosigner.md), collateral verification for issuers. * [Canary Collateral Proofs](/canary/the-assurance-layer/collateral-proofs.md), the evidence foundation and transparency layer.