> 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/collateral-proofs.md).

# Canary Collateral Proofs

Make trust visible and evidence verifiable, and use that evidence wherever an asset is minted, redeemed or moved across chains.

Canary Collateral Proofs connect transparency about an asset's backing with the controls that govern how that asset is minted, redeemed and transferred between chains.

The product has two equally important purposes. The first is to make clear what backs an asset, how that information was verified, and who users still need to trust. The second is to feed that same evidence into [Canary Cosigner](/canary/the-assurance-layer/canary-cosigner.md) and [Canary DVN](/canary/the-assurance-layer/canary-dvn.md), so that it protects transactions before they execute.

The dashboard is the visible part of the product. The verification behind it is built to work inside the systems that control the asset as well.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FEFdUNYOTQPdIRceeePUF%2Fcollateral-proofs-two-outputs.png?alt=media" alt="Canary Collateral Proofs, one verification foundation with two outputs. Evidence comes from onchain observation, direct connections to custodian, bank and fund administrator records, issuer reports and third-party confirmations. It passes through a verification framework of multiple notaries, trusted execution, attestations and zero-knowledge proofs, and every record keeps its source, freshness and limits. The first output is a transparency experience, in which users inspect the backing, follow the evidence and see which trust dependencies remain. The second is an actionable verification result, which Canary Cosigner uses for mints and redemptions and Canary DVN uses for cross-chain movement, to approve, hold or refuse. The two outputs stay connected. A closing note says verification shows how a record was checked, not that a bank&#x27;s books are complete or that the assets are unencumbered."><figcaption><p>One evidence base feeds both what users see and what the signing systems approve.</p></figcaption></figure>

## Why this is needed

Dashboards that show reserve balances, custody addresses and the location of funds already exist. That information is useful, but a balance alone does not explain the trust behind it.

If a dashboard says an asset has $100 million in reserves, users should be able to understand where that number came from.

* Was it read directly from a custodian, supplied by the issuer, or confirmed by an independent party?
* Does it represent an onchain balance, an offchain account record or a valuation?
* When was it last updated, and what remains unverified?

Without that context, a dashboard can look transparent while leaving the most important assumptions hidden.

There is also a gap between showing information and using it. A reserve figure can be visible to everyone while the issuer's signing system still approves a mint that exceeds those reserves, and an alert may identify the problem only after the transaction has happened.

Canary Collateral Proofs address both gaps. They explain the evidence, and they make that evidence part of transaction authorisation.

## Transparency that shows where trust sits

The transparency layer helps users understand the full relationship between a token and its backing.

| What users can see               | What it answers                                                                                                                    |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| What backs the asset             | The underlying holdings, where they are held, and the obligations they support                                                     |
| Who controls the backing         | The issuer, bank, custodian, fund administrator or other institution responsible for it                                            |
| Where the information comes from | A direct source connection, an onchain observation, an issuer report or a third-party confirmation                                 |
| How it was verified              | The checks performed, the parties involved and the cryptographic evidence available                                                |
| How current it is                | When the underlying information was valid, when it was retrieved, and whether it is still within an acceptable verification window |
| What users still need to trust   | The institutions, source records and assumptions that cryptographic verification cannot remove                                     |

The interface is designed to keep these distinctions clear. A directly observed onchain balance does not look the same as an issuer-supplied statement, and an independent confirmation is not presented as a second pool of reserves when it simply confirms the same assets.

Missing information and disagreements between sources are visible too. If a balance is stale, a source is unavailable, or two records do not reconcile, users can see it.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FJEq4giY1cJwPE4RKtv6R%2Fcollateral-proofs-transparency.png?alt=media" alt="An illustrative transparency view for an asset reporting $100.0M in backing, of which $85.0M is independently checked and $15.0M rests on the issuer&#x27;s statement. An onchain vault balance of $40.0M is observed onchain and current. A custodian account of $45.0M comes from a direct source connection, checked inside the enclave and retrieved two hours earlier, and is marked as checked at source. Bank deposits of $15.0M are an issuer-supplied statement, not independently verified and outside the verification window, so they are marked unverified and stale. An auditor confirmation confirms the custodian account and is not counted twice. A closing panel lists what users still need to trust: the issuer&#x27;s bank statement until it is independently verified, the custodian&#x27;s and the bank&#x27;s records and their completeness, and that the assets are unencumbered, which checking the records does not prove."><figcaption><p>This view is illustrative. Each record shows where it came from and how it was checked, so $100M reported is not mistaken for $100M verified.</p></figcaption></figure>

The objective is not to claim that trust has been eliminated. For assets held offchain, trust remains in institutions, ownership records, custody arrangements and the accuracy of the underlying data. Canary's role is to make those dependencies explicit and to provide verifiable evidence around them, so that users can tell what has been independently checked from what still depends on someone's assertion.

## The same evidence protects transactions

Transparency is one use of the evidence. The second is to make it operational. Canary Collateral Proofs are designed to supply a shared verification foundation for Canary Cosigner and Canary DVN, so that the evidence shown to users is the same evidence that informs whether a protected transaction can proceed.

### Minting and redemption, through Canary Cosigner

Cosigner brings collateral verification into the issuer's signing workflow.

* **For a mint,** the question is whether the backing supports the existing obligations plus the new issuance. A valid request from an authorised issuer is not enough by itself, and the financial position after the mint must still satisfy the required conditions.
* **For a redemption,** the questions are whether the claim is valid, whether the payout matches it, whether it can settle, and whether the remaining obligations stay backed after the release.

Collateral Proofs supply the evidence for those decisions, and Cosigner applies the relevant checks before it gives its approval. Where Cosigner is a required approver, a request that fails those checks cannot complete through the protected signing path, so the collateral evidence has a direct role in controlling issuance and redemption.

### Cross-chain movement, through Canary DVN

Canary DVN verifies that a cross-chain message corresponds to what actually happened on the source chain. Collateral Proofs add the backing information needed to evaluate the transfer against the asset's broader accounting rules.

The question is not only whether a message is authentic. It is also whether the movement preserves the relationship between the asset's backing and its obligations across chains. A transfer should not create duplicate claims, overlook an unsettled transfer, or treat each chain as though it had a separate claim on the same reserve pool.

On the DVN path, the check of this kind already in production is reserve accounting, which runs in [Canary Cipher](/canary/the-assurance-layer/canary-cipher.md). Where a route requires Canary's approval and the collateral checks are enforced, a failing transfer is not approved.

| Where value changes               | Product that applies the evidence | The question it answers                                                                                 |
| --------------------------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Minting                           | Canary Cosigner                   | Does the backing support the existing obligations plus the new issuance?                                |
| Redemption                        | Canary Cosigner                   | Is the claim valid, does the payout match, can it settle, and do the remaining obligations stay backed? |
| Cross-chain movement              | Canary DVN                        | Does the movement preserve the relationship between backing and obligations across chains?              |
| What users and counterparties see | The transparency view             | What backs the asset, how was it verified, and what still needs trust?                                  |

Cosigner covers minting and redemption, and the DVN covers cross-chain movement. Collateral Proofs provide the backing evidence used by both.

## One verification foundation, two outputs

Collateral Proofs produce two connected outputs.

1. **A transparency experience.** Users can inspect the backing, follow the evidence, and understand the trust dependencies that remain.
2. **An actionable verification result.** Cosigner and the DVN use the same evidence to approve, hold or refuse a protected action under the applicable rules.

The two outputs are designed to stay connected, so that the dashboard never shows one version of the reserves while the signing systems use another. When evidence changes, becomes stale or stops reconciling, that is reflected both in what users see and in what the enforcement products can approve.

## How the evidence is verified

The verification framework is designed to combine multiple notaries, trusted execution environments, attestations and zero-knowledge proofs, alongside third-party evidence where required. Each component serves a different purpose. Together they strengthen the evidence around a claim, but they do not 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 framework, the reconciliation rules and the proof a contract can check are described on [Collateral Proofs verification](/canary/how-it-works/collateral-proofs-verification.md).

The purpose of Canary Collateral Proofs is to make trust visible and evidence verifiable, and to put that evidence to work wherever assets are minted, redeemed or moved across chains.