> 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/integrate/onboard-to-cosigner.md).

# Onboard to Cosigner

How an issuer adds Canary Cosigner to the signing workflow it already runs, from first session to required approver.

Canary Cosigner is added to the signing workflow an issuer already runs. Where the authorisation mechanism supports it, there is no new wallet and no migration. Canary works with the issuer's team to connect the data sources and define the approval rules. [Canary Collateral Proofs](/canary/the-assurance-layer/collateral-proofs.md) are designed to use the same connected sources, so that the position Cosigner checks is the one the transparency view shows.

## Integration modes

Cosigner is designed to integrate with Fireblocks, MPC signing infrastructure, Safe multisig workflows and direct onchain roles. Choose the mode that matches the authorisation mechanism you already use.

{% tabs %}
{% tab title="Fireblocks" %}
Cosigner participates as a co-signer in the Fireblocks workspace, under the transaction authorisation policy you already maintain. Mint and redemption requests that match the policy require Cosigner's approval before they can be signed.
{% endtab %}

{% tab title="Safe" %}
Canary holds one owner key in the Safe multisig, with the key held inside the enclave. To make Cosigner a required approver, the Safe must be configured so that the threshold cannot be met without that key, for example with a guard that requires Cosigner's signature or a threshold equal to the number of owners. A request then cannot execute without a passing verification.
{% endtab %}

{% tab title="MPC" %}
Cosigner participates as a key share in the MPC signing ceremony, running the same enclave checks inside the ceremony. Configured as a required share in the access structure, the ceremony cannot complete without it.
{% endtab %}

{% tab title="Direct onchain" %}
Canary is set as a required signer on the token's mint and burn roles. Optionally, the token or approval contract also requires a zero-knowledge proof of the enclave attestation, so that a signature without a valid, request-bound proof is rejected.
{% endtab %}
{% endtabs %}

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FzQt2SxlCY6TgGk0Kr3rP%2Fcosigner-signing-workflow.png?alt=media" alt="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."><figcaption><p>Whichever mode you use, Cosigner joins the quorum you already run. Rollout runs in three steps: optional signer, observation on real requests, then required approver.</p></figcaption></figure>

## The onboarding path

1. **Define the signing policy.** A working session with Canary sets the backing rules, limits, counterparties, timing windows, and the conditions that should place a request on hold.
2. **Connect the sources.** Collateral wallets and token supply on every chain of issuance, custodian, bank and fund administrator records over pinned, attested connections, and auditor confirmations.
3. **Start as an optional signer.** Cosigner evaluates every request and records what it would have decided, without being required for the quorum to complete. This is the same observe-then-enforce model used for Cipher.
4. **Upgrade to required.** Once the checks have proven themselves, configure Cosigner as a required approver, so the infrastructure cannot authorise a request without its independent checks.
5. **Require the proof, where it fits.** For high-value operations, the issuer's approval contract can require a zero-knowledge proof of the enclave attestation, so a signing key alone is no longer enough.

## What to prepare

| Item                                                  | Why it is needed                                                           |
| ----------------------------------------------------- | -------------------------------------------------------------------------- |
| A list of collateral wallets and vaults per chain     | Onchain holdings are read directly from pinned sources                     |
| Token contracts and supply on every chain of issuance | Supply after the request is part of the reconciliation                     |
| Contacts at custodians, banks and fund administrators | Records are pulled over pinned, attested connections to the source systems |
| Auditor confirmation format and cadence               | Auditor evidence is reconciled against the other sources                   |
| Current approval policy and quorum                    | Cosigner joins the policy you already run                                  |
| Alert recipients                                      | Refusals alert both the issuer's team and Canary                           |

## Built for

* Stablecoin issuers
* Tokenised treasuries and funds
* Wrapped and bridged assets
* Commodity-backed tokens

To start, book an integration call at [canaryprotocol.com](https://www.canaryprotocol.com).