> 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/why-canary-exists.md).

# Why Canary exists

The structural problem Canary was built to remove, across cross-chain movement, issuance and redemption.

Onchain finance runs on signatures. Value moves between chains when verifiers sign a message, and supply is created or destroyed when an issuer's keys sign a mint or a redemption. In both cases the signature is the last step between an instruction and a settlement that cannot be undone.

The industry has treated a valid signature as proof that the action behind it was correct. It is not. A valid signature proves that a key was used. It does not prove that the source-chain event happened, that the transfer respects the application's limits, or that the collateral behind a new token exists. Canary exists to close that gap by making proof a condition of the signature, rather than something discovered after settlement.

## The same shape, again and again

Nearly every major cross-chain exploit and unbacked mint has followed the same four steps. Someone held a key or a signing path, something signed, value or supply moved away from what was supposed to back it, and everyone found out afterwards.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FswxKZWwp8T1Af4cAi7ze%2Ffailure-pattern.png?alt=media" alt="Four steps shared by most major losses: someone held a key, something signed, value moved away from its backing, and everyone found out afterwards."><figcaption><p>The details vary from incident to incident. The shape does not.</p></figcaption></figure>

The details vary, from a compromised deployer key or a validator set that was too small to a single verifier configuration, a cloud key vault, or a mint function that checked a signature and never checked the collateral. The shape stays the same, because in each case the system was built to accept a signature as the end of the question.

## Cross-chain movement

Value now moves between chains as messages. A transfer is an instruction, verified somewhere, signed by someone and settled on the destination. When a message that should never have existed gets signed, the funds leave and they do not come back. Interoperability has become one of crypto's highest-value attack surfaces, with billions lost through bridge and messaging exploits.

The legacy archetypes all find a way to say yes. The committee bridge treats verification as a vote. The optimistic bridge treats it as a timer. The solver bridge defers the check until after the money has moved. In each case the system is built to say yes quickly, and correctness is assumed rather than proven.

When these systems have failed, the protocol layer held. The failures were application-layer configuration choices, with verifier sets too small, too correlated or too permissive for the value they carried. The April 2026 incident ran on a one-of-one verifier configuration, a setting that is valid in the framework and unsafe in practice. Security was available and was not configured.

Redundancy that is only cosmetic fails in the same way. Signatures from correlated keys, from verifiers that share a codebase, or from a set with a single required verifier add up to one point of failure presented as several.

## Issuance and redemption

The same pattern appears wherever a key can authorise value, including the moment supply is created. Between 14 September 2023 and 15 September 2026, 57 verified incidents show a privileged key or signing path authorising value without independent proof that the collateral existed. Primary economic loss across that set is $1.19 billion ($1,188,341,603). Face-value mints are excluded, gross figures are not permanent loss, and one of the 57 incidents has no verified dollar figure and is not included in the sum.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FQTayOv5cg9qJHUQJInRb%2Fcosigner-same-shape.png?alt=media" alt="The four steps shared by the 57 verified incidents: someone held a key, something signed, supply moved away from its backing, and everyone found out afterwards. Below them, the incidents are plotted from September 2023 to September 2026, each sized by primary economic loss, which totals $1.19B ($1,188,341,603)."><figcaption><p>57 verified incidents between 14 September 2023 and 15 September 2026, $1.19 billion in primary economic loss, and the same four steps in each.</p></figcaption></figure>

Several of those teams ran serious key security, including multisigs, threshold signers and cloud key vaults. Attackers still produced valid signatures, because the approval process checked who was signing and never checked whether the backing existed.

Publishing reserve data does not change this on its own. Transparency is a real step towards accountability, and a dashboard can show whether conditions are satisfied. It cannot stop a transaction that violates them. A balance on a dashboard also says nothing by itself about where the number came from, how it was checked, or who still has to be trusted.

{% hint style="info" %}
Incident figures come from Canary's incident inventory for this pattern, covering 14 September 2023 to 15 September 2026. Losses are primary economic loss, excluding face-value mints.
{% endhint %}

## Monitoring is a witness, not a guard

The market's answer has been monitoring, and monitoring is genuinely good at its job. Its job is telling you what happened. An alert fires after a transaction settles, when the funds are already gone, and the response is incident management. Detection is forensics. Refusal is security.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FLoRrpoPKNDM1zDmMWlIj%2Fdetection-vs-refusal.png?alt=media" alt="Two timelines. With monitoring, the transaction settles, the alert fires and the funds are already gone. With Canary, verification runs before the signature and a failed check ends in refusal, so nothing settles."><figcaption><p>Alerts fire after settlement. Refusal happens before it.</p></figcaption></figure>

This is only becoming more true. Automated attacks move faster than human response, which makes post-settlement alerting less useful every year, not more. The only defence that still works at machine speed is verification before settlement. An attacker cannot talk a hardware-attested quorum into signing a failed reserve check.

## What Canary changes

Canary moves verification in front of the signature at every point where value is created, moved or redeemed.

* On every cross-chain message it secures, [Canary DVN](/canary/the-assurance-layer/canary-dvn.md) proves that the message matches the source chain, at Canary's own confirmation floor, inside a hardware-attested quorum, before it signs.
* Where a protocol needs its own rules enforced, [Canary Cipher](/canary/the-assurance-layer/canary-cipher.md) asks whether the transfer should happen at all, and refuses when the answer is anything other than a proven yes.
* Where an issuer creates or redeems supply, [Canary Cosigner](/canary/the-assurance-layer/canary-cosigner.md) reconciles the collateral against supply and the request before it adds its signature to the issuer's own quorum.
* Wherever an asset's backing matters, [Canary Collateral Proofs](/canary/the-assurance-layer/collateral-proofs.md) are designed to show what backs it, how each record was checked and what still needs trust, and to supply that same evidence to Cosigner and the DVN, so that the evidence users see is the evidence that informs what can be approved.

Trillions of dollars are preparing to move onchain. They will not be secured by a private key and good intentions. Nothing settles unproven.