> 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/reserve-accounting.md). # Reserve accounting The first Cipher check live in production, in detail, with real log entries. Reserve accounting answers a question that no signature should precede, which is whether this transfer would push issued supply beyond verified backing on this pathway. Where the DVN protects assets in transit, reserve accounting protects assets at rest, and the two together close the loop that historically made unbacked releases possible. ## What is monitored, continuously * Assets locked on the source chain. * Total issued supply across all destination chains. * The real-time collateralisation ratio between the two. All computation happens inside the same TEE environment as the DVN, with the same certificate pinning guarantees, so the inputs cannot be spoofed and the results are hardware-attested. ## Two sets of thresholds Each protocol defines its own minimum collateral thresholds, and Canary enforces its own baseline limits on top. Even a misconfiguration on the protocol side cannot weaken the floor. ## What happens on breach If collateral falls below threshold, Canary stops signing immediately. The pathway is paused at the verification layer automatically, with no governance vote and no manual intervention. Alerts fire for both Canary and the protocol team, and transfers resume only once the invariant is restored. ## In the signing path For in-scope transfers above a configured threshold, the DVN asks the Cipher security engine for the current reserve state before signing. Thresholds are custom per chain and pathway, so the routine path stays fast and depth arrives exactly where value does. The check is live in production for a major stablecoin. ## What the logs look like Two entries from one production deployment, with figures as observed. Below the threshold, no engine query is needed. ``` check proof-of-reserves check_status pass dstChain hyperliquid evidence amount 1.93 reason amount.below-threshold ``` Above the threshold, the engine is queried and reserves are sufficient. ``` check proof-of-reserves check_status pass dstChain monad evidence amount 109999.930129 backing 3311675106.659444 minted 3248626474.810225 postMinted 3248736474.740354 ratio 1.0193732647779996 observedAt 2026-08-27T12:09:38.49769Z ```
An annotated reserve accounting log entry. The amount is the value being moved, backing is current verified reserves, minted is issued supply before the transfer, postMinted is issued supply after it, ratio is backing divided by supply after the transfer, and observedAt is when the state was read.

Every field answers part of one question, which is whether supply would still be backed after this transfer.

The fields tell the whole story. | Field | Meaning | | ------------ | -------------------------------------------- | | `amount` | The value being moved by this message | | `backing` | Current verified backing for the asset | | `minted` | Issued supply before the transfer | | `postMinted` | Issued supply if the transfer is signed | | `ratio` | Backing divided by supply after the transfer | | `observedAt` | When the reserve state was observed | In the second entry, `postMinted` is exactly `minted` plus `amount`, and the resulting ratio stays above one, so the check passes. Had the ratio fallen below the protocol's threshold or Canary's baseline, the DVN would not have signed. {% hint style="info" %} Logs label this check `proof-of-reserves`. It is the same capability these docs call reserve accounting. {% endhint %} ## For the highest-value transfers Reserve attestations can additionally be wrapped in zero-knowledge proofs and verified onchain, so that, where the contract requires it, funds release only if the proof is valid. Even if every private key in the system were compromised, an attacker could not forge a valid proof without executing the correct code inside a genuine enclave. Keys alone are not enough. {% hint style="info" %} Onchain proof verification is described here at concept level. Implementation details, contract addresses and thresholds are not yet public. {% endhint %} ## Observe first, then enforce Every check starts in observe mode. It runs against real traffic and records what it would have decided, without gating anything. Once accuracy is proven, it is promoted to blocking, with thresholds calibrated from evidence rather than guessed. Promotion requires no re-integration. This is the adoption model for every Cipher capability, described on [Onboard to Cipher](/canary/integrate/onboard-to-cipher.md). ## Reserve accounting and Collateral Proofs Reserve accounting reconciles what a cross-chain pathway can prove, which is locked assets against issued supply. [Canary Collateral Proofs](/canary/the-assurance-layer/collateral-proofs.md) supply the wider evidence about an asset's backing, including custodian, bank and administrator records with their limits stated. That evidence is designed to be used by [Canary Cosigner](/canary/the-assurance-layer/canary-cosigner.md) at mint and redemption, and by checks on the DVN path for cross-chain movement. The two are compared on [Collateral Proofs verification](/canary/how-it-works/collateral-proofs-verification.md#collateral-proofs-and-reserve-accounting).