> 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/cosigner-verification-flow.md).

# Cosigner verification flow

How a mint or redemption request moves through Canary Cosigner, from the issuer's signing workflow to a co-signature, a hold or a refusal.

Canary Cosigner sits inside the issuer's authorisation path rather than beside it. Once it is configured as a required approver, a mint or redemption cannot complete without its signature, and its signature cannot exist without its checks passing inside the enclave.

## Where Cosigner sits

Cosigner participates in the authorisation mechanism the issuer already runs. The four integration modes are described on [Onboard to Cosigner](/canary/integrate/onboard-to-cosigner.md).

* As a co-signer inside a Fireblocks workspace, under its transaction authorisation policy.
* As an owner key in a Safe multisig, configured so that the threshold cannot be met without its signature.
* As a required key share in an MPC signing ceremony, running the same enclave checks inside the ceremony.
* As a required signer on the token's mint and burn roles, with optional onchain verification of the proof.

## The request lifecycle

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FkhYsvZr9DiVSpmzwHCcB%2Fcosigner-request-lifecycle.png?alt=media" alt="A sequence across four lanes: the issuer&#x27;s signing workflow, the Cosigner enclave, the connected sources and the approval contract. The issuer submits a request, the enclave reads the sources, reconciles and runs detection, then either co-signs with an attestation, holds the request, or refuses and alerts. Where the contract requires it, a proof of the attestation is verified before the mint executes."><figcaption><p>A request becomes a mint only after the checks pass, the quorum completes and, where required, the contract verifies the proof.</p></figcaption></figure>

1. **Request.** The issuer initiates a mint or redemption through its existing workflow. The request reaches Cosigner with what is needed to evaluate it: the asset, the amount, the counterparty and the chain.
2. **Read.** The enclave reads the connected sources over pinned connections: onchain balances and supply, custodian, bank and fund administrator records, and auditor confirmations. [Canary Collateral Proofs](/canary/the-assurance-layer/collateral-proofs.md) are designed to work from the same evidence and show it to users.
3. **Reconcile.** The enclave computes the position after the request and checks it against the backing rules. For a mint, the backing must support the existing obligations plus the new issuance. For a redemption, the claim must be valid, the payout must match it and be able to settle, and the remaining obligations must stay backed after the release.
4. **Detect.** Anomaly detection and the issuer's policy rules run as signing conditions: size and velocity against history, counterparties, timing windows, limits, and consistency between sources.
5. **Decide.** Every required check passes, and Cosigner co-signs. An anomaly or an inconsistency places the request on hold. A failed check ends in refusal and an alert to the issuer's team and to Canary.
6. **Attest and sign.** On a pass, the enclave produces an attestation that binds the results to this request, and Cosigner signs with a key that exists only inside the enclave.
7. **Prove, where required.** For high-value operations, Cosigner can generate a zero-knowledge proof of the attestation for the issuer's approval contract. See [Collateral Proofs verification](/canary/how-it-works/collateral-proofs-verification.md).
8. **Execute.** The issuer's quorum completes, the contract verifies the proof where it requires one, and the mint or redemption executes.

## Behaviour under uncertainty

Cosigner follows the Canary standard, under which uncertainty is never treated as approval.

* **Inconsistent records** between sources that should agree place the request on hold rather than letting it be signed on the more convenient number.
* **Unusual activity**, such as a request far outside the asset's normal size or velocity, or an unfamiliar counterparty, places the request on hold for further checks and review before any signature exists.
* **A source that cannot be read or reconciled** means the evidence is incomplete, and Cosigner does not sign on incomplete evidence.
* **Stale evidence**, outside its verification window, is not treated as current. Collateral Proofs are designed to show the same status in the transparency view, so that what users see and what Cosigner can approve do not drift apart.

## What the issuer controls

* Which sources are connected to the reconciliation.
* The backing rules, limits, counterparties and timing windows the request must satisfy.
* What should place a request on hold.
* Whether Cosigner runs as an optional signer while the checks prove themselves, or as a required approver.
* Whether the approval contract requires the onchain proof.

## What no one can do

No one, neither the issuer's team nor Canary's, can produce a Cosigner signature without the checks passing inside the enclave. The signing key never leaves the enclave, and the attestation records which verification code and policy ran. An approval contract that requires the proof will reject a request whose proof does not show the approved code and policy.

## Every decision leaves a record

Every co-signature, hold and refusal is logged with its reason. The record shows the issuer, and anyone the issuer shares it with, not only what was approved but what was stopped and why.