> 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/canary-cosigner.md). # Canary Cosigner Independent collateral verification before every mint and redemption. Canary Cosigner joins the issuer's signing quorum and signs last. **Verify first. Sign last.** Canary Cosigner is independent collateral verification before every mint and redemption. It checks the backing, evaluates the issuer's rules, and adds its signature only when the required checks pass. Cosigner joins the signing workflow an issuer already runs, first as an optional signer and then as a required approver. Configured as a required approver, it ensures no request can be authorised without its independent checks. Cosigner is available now to asset issuers, including stablecoin issuers, tokenised treasuries and funds, wrapped and bridged assets, and commodity-backed tokens. ## Why issuers need it **Transparency is not enforcement.** An issuer can publish reserve data, maintain a dashboard and distribute attestations through independent networks. These are real steps towards accountability. On their own they do not prevent a transaction that violates the conditions the data is supposed to support. **Monitoring is not authorisation.** Monitoring can identify anomalies, raise alerts and trigger pauses. Detecting a problem and deciding whether an individual transaction should be authorised are different responsibilities, and an alert still has to be interpreted and acted on separately. **A signature is not proof.** A valid signature proves that a signing key was used. It does not prove that the transaction satisfied the issuer's financial or operational requirements. Protecting keys remains essential, but possession of a key should not be the only condition standing between an attacker and a high-value mint. Among the 57 verified incidents described in [Why Canary exists](/canary/why-canary-exists.md), several teams ran multisigs, threshold signers or cloud key vaults, and attackers still produced valid signatures. **The next step is to make verification a condition of execution.** Before a protected action receives the approval it needs, Cosigner verifies that it satisfies the required conditions. When the checks do not pass, Cosigner does not provide its approval, and where that approval is mandatory, the operation cannot proceed through that authorisation path. The same information that supports transparency now supports protection.
Two lanes for the same mint request. On the old standard, a key signs first, then tokens mint, supply exceeds backing and an alert fires after settlement. On the Canary standard, Cosigner reads every source, reconciles supply plus the request and applies the issuer rules before any signature exists, then signs, or withholds its signature and nothing moves.

Two standards for the same mint request. On the old standard the signature is the last thing that happens before the loss. On the Canary standard it is the last thing that happens after the evidence.

## What Cosigner checks Cosigner independently reconciles collateral against token supply and the proposed transaction. It connects the evidence across the asset's onchain and offchain sources. [Canary Collateral Proofs](/canary/the-assurance-layer/collateral-proofs.md) are designed to supply that same evidence and show it to users, so that the position Cosigner approves against is the position users can inspect. | Source | What is read | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **Onchain holdings** | Collateral wallets, vault balances and token supply on every chain the asset is issued on, read from pinned RPC sources | | **Offchain assets** | Records from custodians, banks and fund administrators, pulled over pinned, attested connections, never a screenshot or a PDF | | **Independent confirmations** | Accounting and auditor evidence, treated as a checkable input and reconciled against the other sources rather than taken on trust | | **Activity** | Request size, velocity and counterparties, checked against the issuer's limits and history | How this applies to each operation: * **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. The requested issuance is checked against reserve information, existing supply and issuer-defined limits, and the position after the mint must still satisfy the required conditions. * **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. The required token burn is verified, together with the relevant issuer-side conditions. * **Cross-chain movement** is covered by [Canary DVN](/canary/the-assurance-layer/canary-dvn.md), which is designed to use the same backing evidence. Where a route requires Canary's approval and the collateral checks are enforced, a failing transfer is not approved. ## Read, reconcile, detect, co-sign Every check runs inside a trusted execution environment, and so does Cosigner's signing key. The enclave's attestation links the results to the specific request, and no one, neither the issuer's team nor Canary's, can produce Cosigner's signature without the checks passing. 1. **Read.** Retrieve collateral and supply data from the connected sources: onchain balances, custodian and bank records, and auditor attestations, over pinned connections. 2. **Reconcile.** Check the post-transaction position against the backing rules. Reserves must still cover total supply after the request, across every source, before the request moves on. 3. **Detect.** Flag inconsistent records, unusual activity and limit breaches. Anomaly detection and the issuer's own policy rules, such as limits, counterparties and timing, run as signing conditions. 4. **Co-sign.** Attest to the results and sign only when every required check passes.
Three sources, onchain reserves, offchain custody and independent confirmations, feed a hardware enclave that takes a mint or redemption request through four steps: read every source directly, reconcile reserves against supply plus the request, detect anomalies and apply the issuer rules, then co-sign with an attestation bound to the request. Three outcomes follow: co-sign when every required check passes, hold when something is unusual, and refuse when the backing is missing or a limit is breached, with both teams alerted.

Read, reconcile, detect, co-sign. Every source is read directly, every check runs inside the enclave, and the attestation is bound to the request.

### Three outcomes | Outcome | Trigger | Effect | | -------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | **Pass: co-sign** | Every required check passes | Cosigner adds its signature and the issuer's quorum can complete | | **Anomaly: hold** | Unusual size, velocity or counterparty, or inconsistent records | The request is held for further checks and review before any signature is produced | | **Fail: refuse and alert** | Backing missing, a limit breached or a rule violated | No signature is produced, and the issuer's team and Canary are alerted | Three illustrative examples of how this plays out: * A mint request arrives, every source reconciles and every rule passes. Cosigner co-signs and the mint proceeds. * A custodian balance falls short of the supply the request would create. Cosigner refuses and alerts both teams, and where Cosigner is a required approver, the mint cannot complete. * A redemption arrives at six times the 30-day median. Cosigner places it on hold for review before any signature exists. ## Verification evidence onchain Cosigner can generate a zero-knowledge proof of the enclave attestation for verification by the issuer's approval contract. The proof is tied to the specific request and to the approved verification code that ran. When the contract requires that proof, possession of a signing key alone is not enough to authorise the transaction. * **Without Cosigner.** A signing key is compromised, the mint is approved, and unbacked supply exists. * **With Cosigner.** A signing key is compromised, there is no valid attestation, and the contract rejects the mint. Where the contract requires the proof, a stolen key is no longer enough to mint. How the proof is bound to the request is described on [Collateral Proofs verification](/canary/how-it-works/collateral-proofs-verification.md). ## Fits the signing workflow you already run Cosigner is designed to integrate with Fireblocks, MPC signing infrastructure, Safe multisig workflows and direct onchain roles. Where the authorisation mechanism supports it, Cosigner is one more approver in the quorum the issuer already runs, with no new wallet and no migration. Canary works with the issuer's team to connect the data sources and define the approval rules.
Cosigner works with four signing stacks: Fireblocks as an API co-signer under the transaction authorisation policy, Safe as an owner key whose threshold needs a passing verification, MPC signing as a key share that runs the checks inside the signing ceremony, and onchain as a required signer on mint and burn roles. Whichever stack the issuer runs, the signing quorum holds the issuer signers and Canary Cosigner as a required signer, and a mint or redemption executes only when every required signer has signed. Rollout runs in three steps: optional signer, observe, then required approver. A note says Cosigner integrates where the signing mechanism supports a required approver, with no new wallet and no migration.

Cosigner joins the quorum an issuer already runs as a required approver. Teams start with it as an optional signer, observe the checks on real requests, then make it required.

Integration modes and the onboarding path are on [Onboard to Cosigner](/canary/integrate/onboard-to-cosigner.md). ## What changes for the people around the issuer * **Issuers** keep issuance and redemption as their own decisions, executed through their own infrastructure. What changes is that each decision now carries independent, hardware-attested verification of the backing, and, where the issuer chooses, a proof the contract itself can check. * **Custodians, banks and fund administrators** see the records they already produce become attested inputs to an enforceable process, through a data integration over pinned channels rather than a change to how they hold assets. * **Auditors** see their confirmations become checkable inputs, reconciled against live custody and onchain supply between reporting periods. * **Signing infrastructure providers** keep custody and control. Cosigner is an approver inside the policy model they already offer. * **Data feeds, reserve reporting services and transaction screening** become inputs to the decision. Cosigner consumes their outputs rather than replacing them. ## Who reports, who screens, who verifies Issuers can already draw on three kinds of service. Oracle feeds publish signed prices, NAV and reserve figures that contracts can read. Reserve reporting covers custodian, auditor and dashboard reports of where the funds sit. Screening cosigners and policy engines simulate a transaction and approve or reject it against policy. Each answers a different question, and Cosigner reads their outputs as inputs to its own: whether the backing still holds after this request. Oracle feeds are reconciled against the other sources rather than taken on trust, and custodian and fund administrator records arrive over attested connections.
A two-by-two map. One axis runs from services that report the numbers to services that approve or refuse the transaction, the other from reports you take on their word to proofs a contract can check. Reserve reporting covers custodian, auditor and dashboard reports. Oracle feeds put signed prices, NAV and reserve figures onchain. Screening cosigners and policy engines approve or reject a transaction on payload risk. Canary Cosigner approves on verified backing, reconciling every source against supply plus the request, with co-sign, hold and refuse as outcomes. Oracle feeds, reserve reporting and screening all feed Cosigner as inputs.

Who reports, who screens and who verifies the backing. Cosigner reads the reporters and screeners as inputs and approves only on verified backing.

## Two things called a cosigner The word is used in two ways, and the difference matters. A **screening cosigner** is an automated signer in a quorum that simulates a transaction and scores it against threat intelligence and policy. It answers whether a transaction is dangerous. **Canary Cosigner** answers whether the backing still holds after the transaction. It joins the same kind of quorum and does something different with its turn. A screening verdict is welcome as one more rule in the policy Cosigner enforces before it signs.
Side-by-side comparison. Screening cosigners ask whether a transaction is dangerous: they join the signing quorum as an automated signer, simulate the payload and score it against threat intelligence and policy rules, and are strong at catching a compromised device, a malicious contract or a payload that differs from what the signer saw. Canary Cosigner asks whether the backing still holds after the transaction: it joins the same quorum, reads reserves from every source, reconciles them against supply plus the request and applies the issuer limits, and checks that reserves cover supply plus the request, that issuer limits and counterparties pass, and that an attestation is bound to the request before it signs.

Screening cosigners ask whether a transaction is dangerous. Cosigner asks whether the backing still holds after it, and a screening verdict can be one of its inputs.

## How Cosigner fits with the other products | Product | Where it sits | What it gates | | ------------------------ | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | Canary DVN | In the LayerZero signing path of every cross-chain message it secures | Message integrity and finality | | Canary Cipher | Consulted by the DVN before it signs | The application's own rules on cross-chain transfers | | Canary Cosigner | Inside the issuer's own authorisation quorum | The creation and redemption of supply | | Canary Collateral Proofs | Beneath Cosigner and the DVN path, and in the transparency view | It gates nothing on its own. It is designed to supply the backing evidence that Cosigner and the DVN path apply | Cipher and Cosigner enforce the same kind of rules in two different authorisation paths. Canary Cipher already runs reserve checks on mint requests in production for a major stablecoin, where an authentic mint request can still fail if the backing is missing. Cosigner brings that same check into the issuer's own signing workflow. Canary Collateral Proofs are designed to supply the backing evidence to both paths, so that the position checked when supply is created is the same one checked when the asset moves across chains. ## What Cosigner does and does not prove * Attestation establishes the identity and code of the environment that processed the records. It does not make an offchain record true. Cosigner reconciles those records against each other and against live onchain state, which is a stronger position than trusting any one of them, but it does not prove that an institution's books are complete or that the assets are unencumbered. * Verifying an attestation through a zero-knowledge proof does not remove reliance on the hardware attestation model. It makes the result checkable by anyone, including the issuer's contract. * The integration claim covers authorisation mechanisms that support the required controls, not every system that exists. ## Built on Canary's verification infrastructure Cosigner is a new product. The infrastructure behind it is not. In nearly two years in production, Canary has recorded 100% uptime, zero security incidents and zero misverified messages, and has secured $53.4B+ in cross-chain volume as of 7 October 2026. {% hint style="info" %} Track record figures describe Canary's existing verification infrastructure, not Cosigner's standalone operating history. {% endhint %} To build independent verification into your issuance, book an integration call at [canaryprotocol.com](https://www.canaryprotocol.com).