> 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/how-it-works/collateral-proofs-verification.md).

# Collateral Proofs verification

How Canary Collateral Proofs verify an asset's backing, what each part of the framework adds, and what verification cannot establish.

Canary Collateral Proofs are built to strengthen the evidence around a claim about an asset's backing without overstating what that evidence proves. The verification framework is designed to combine several mechanisms, and each one serves a different purpose.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FIaYn7wwOL5S1fpxPjOOg%2Fcollateral-proofs-framework.png?alt=media" alt="The Collateral Proofs verification framework as five components, each with what it adds and what it does not establish. Together they strengthen the evidence, and none of them makes an offchain record true. Multiple notaries add corroboration, but several parties reading one source are not several independent sources of truth. Trusted execution protects the checks and sensitive material from the surrounding infrastructure, but not the accuracy of the data that goes in. Attestations bind the result to the workload and to the specific action, but show which code ran, not that the source records were complete. Zero-knowledge proofs let an onchain verifier check the result without publishing all the records, but do not remove reliance on the hardware attestation model. Third-party evidence adds checks from custodians, administrators and independent confirmations, but does not extend any source beyond its own scope, and those limits stay visible. A closing band states that proof that approved code processed a bank record is not proof that the bank&#x27;s books are complete or that the assets are unencumbered."><figcaption><p>Each component adds something different, and the limit beneath them all stays in view.</p></figcaption></figure>

## The framework

| Component                      | Purpose                                                                                                                                                                                                                                  | What it does not establish                                                                                 |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Multiple notaries              | Corroboration, so the system does not rely on one party's unexamined statement. The transparency layer shows what each notary checked and which sources it relied on.                                                                    | Several parties reading the same source are not several independent sources of truth.                      |
| Trusted execution environments | The checks run in a hardware-isolated environment that protects the verification logic and sensitive material from interference by the surrounding infrastructure.                                                                       | They protect the verification process, not the accuracy of the data that goes into it.                     |
| Attestations                   | Evidence that binds the verification result to the workload that processed it. For transaction protection, the result also needs to be tied to the specific action being approved, so it cannot be reused for a different request.       | They show which code produced a result, not that the source records were complete.                         |
| Zero-knowledge proofs          | In the intended proof-enabled design, an onchain verifier checks a proof of the accepted attestation and its bound result, so cryptographic verification becomes part of approval without all of the underlying records being published. | They do not remove reliance on the hardware attestation model.                                             |
| Third-party evidence           | Custodian records, administrator data, independent confirmations and other relevant proofs add further checks to the verified position.                                                                                                  | Each has its own scope and limits, which stay visible rather than hidden behind a single "verified" label. |

These mechanisms strengthen the evidence around a claim. They do not automatically establish that an offchain record is true. 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, and that distinction is central to the product.

## The questions the evidence answers

The same evidence base answers a different question at each point where value changes.

* **Minting.** Does the backing support the existing obligations plus the new issuance? A valid request from an authorised issuer is not enough by itself.
* **Redemption.** Is the claim valid, does the payout match it, can it settle, and do the remaining obligations stay backed after the release?
* **Cross-chain movement.** Does the movement preserve the relationship between the backing and its obligations across chains, without creating duplicate claims, overlooking an unsettled transfer, or treating each chain as though it had a separate claim on the same reserve pool?

The rule underneath all three is simple to state. After the requested change, verified backing must still cover the asset's obligations, across every source and every chain, under the rules the issuer has set. The question is never whether the asset is backed today. It is whether the asset will still be backed if this request is approved.

{% hint style="info" %}
**Illustrative example.** Verified reserves across a custodian account and an onchain vault total $100.4M, and supply across all chains is $100.0M. A request to mint 5M tokens would take supply to $105.0M, above verified reserves, so Cosigner refuses and alerts. A request to mint 0.3M would leave supply at $100.3M, covered by reserves, and proceeds to the detection checks. The figures are invented for illustration.
{% endhint %}

## Freshness, gaps and disagreements

Evidence that is out of date or incomplete is designed to be treated as exactly that, both in what users see and in what the enforcement products can approve.

* **Freshness.** Each record carries when the underlying information was valid and when it was retrieved. Evidence outside its verification window is shown as stale, and it is not treated as current when a protected action is evaluated.
* **Gaps.** When a source is unavailable, the transparency view says so, and the evidence for a protected action is incomplete.
* **Disagreements.** When two records that should agree do not reconcile, the disagreement is visible, and a protected request is not approved on the more convenient number. On the Cosigner path, the request is held for review.

The dashboard and the signing systems are designed to use the same evidence, so that neither shows or approves a version of the reserves that the other does not.

## From attestation to a proof the contract can check

The reconciliation runs inside a trusted execution environment. The enclave produces an attestation, a signed document from the hardware that identifies the code and configuration that ran and binds the results to the request. Its authenticity can be checked against the hardware vendor's attestation certificate chain, which for Canary's production enclaves today is the AWS Nitro chain.

Authenticity alone is not enough. A verifier must also check that the attestation's measurements correspond to the approved verification code and policy, so that a genuine enclave running the wrong code cannot authorise anything.

For high-value operations, Cosigner can generate a zero-knowledge proof of the enclave attestation for verification by the issuer's approval or token contract. Three conditions make that protection real.

1. **Bound to the transaction.** The proof commits to the specific request it authorises, so it cannot be reused for a different mint.
2. **Protected against replay.** The same proof cannot authorise the same request twice.
3. **Mandatory in the authorisation path.** The contract requires the proof, so a signature without it is rejected.

Under those conditions, compromising a signing key is not enough to authorise an operation that fails verification. An attacker would also need to satisfy the enforced, transaction-bound attestation requirement, which requires the approved code to run inside a genuine enclave and reach a passing result.

An illustrative contract interface expresses the binding.

```solidity
// Illustrative only. The parameters show what the proof is bound to.
function verify(
    bytes calldata zkProof,        // proof of the enclave attestation
    bytes32 attestationHash,       // the attestation it wraps
    bytes32 reservesRoot,          // the reserve state it was computed against
    bytes32 requestHash            // the specific request it authorises
) external returns (bool);           // marks requestHash as used, so the proof cannot be replayed
```

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FY7S0bro2SzAuDayWsyaH%2Fcollateral-proof.png?alt=media" alt="How a collateral check reaches a contract. Onchain holdings, offchain custody records and auditor confirmations flow over pinned connections into the enclave, which reconciles reserves against supply after the request, detects anomalies and produces an attestation. The attestation can be wrapped in a zero-knowledge proof that the issuer&#x27;s contract verifies before the mint executes. Without a valid proof, the contract rejects the mint."><figcaption><p>Read every source, reconcile against supply after the request, attest from inside the enclave, and let the contract check the proof.</p></figcaption></figure>

## Collateral Proofs and reserve accounting

Reserve accounting is the Cipher check already in production on cross-chain pathways. It reconciles assets locked on the source chain against supply issued across destination chains, before the DVN signs. Collateral Proofs are designed to supply the wider evidence about an asset's backing, including offchain records with their limits stated, to both enforcement paths.

|                     | Reserve accounting                                | Collateral Proofs                                                                                       |
| ------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| What it is          | A Canary Cipher check in the DVN's signing path   | The evidence foundation and transparency layer                                                          |
| What it reconciles  | Locked assets against issued supply across chains | Onchain and offchain backing against the asset's obligations after the requested change                 |
| Where it is applied | Cross-chain messages, before the DVN signs        | Mints and redemptions through Cosigner, cross-chain movement through the DVN, and the transparency view |
| On failure          | The DVN does not sign and the pathway pauses      | The protected action is held or refused, and the reason is shown                                        |

## What verification does and does not establish

* It establishes that the approved code, running inside a genuine enclave, read the named sources over authenticated connections, reconciled them under the issuer's rules, and reached a passing result for this specific request.
* It does not make an offchain record true. A custodian statement is still a statement. What changes is that it is checked against independent sources and live onchain supply instead of being trusted alone, and that its limits are shown to users.
* It does not remove reliance on the hardware attestation model. Wrapping the attestation in a zero-knowledge proof makes the result checkable by anyone, including a contract.