> 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-cipher.md). # Canary Cipher The security engine. Composable checks and hooks, tailored to each protocol, that run before the DVN signs. Canary Cipher is the security engine, a composable security framework made of building blocks that are tailored to each protocol, asset, chain, backend system and risk profile. Canary DVN answers whether a message is valid. Cipher asks the second question, before anything is signed, of whether the transfer should happen at all. When the answer is anything other than a proven yes, Cipher refuses and nothing moves. ## Why one size does not fit A stablecoin, a tokenised fund, a lending protocol and a perpetuals exchange may all use cross-chain messaging, but they do not share the same risks. They have different accounting systems, backend infrastructure, liquidity assumptions, token logic, issuer controls and settlement requirements. Their security should not be identical either, and Cipher lets each protocol compose the checks it actually needs before a transfer is released. ## Building blocks * **Reserve accounting and collateralisation**, enforcing that supply is genuinely backed on every chain. See [Reserve accounting](/canary/how-it-works/reserve-accounting.md). * **Mint-and-burn validation**, so no mint is attested without its corresponding burn or lock. * **Onchain state and offchain APIs**, because verification is not limited to what lives on a chain. * **Issuer systems, traditional finance systems and crypto-native infrastructure**, brought into the verification path. * **Liquidity checks, anomaly detection and rate limits.** * **High-value transfer policies**, with deeper verification and confirmation requirements where more is at stake. * **Zero-knowledge proofs verified onchain**, for the highest-value transfers.
Verification depth rising with transfer value: routine transfers take the fast path, larger transfers trigger reserve, burn and anomaly checks with deeper confirmations, and the highest-value transfers add manual approval and an onchain-verified proof.

Security scales with what is at stake, so the routine path stays fast and depth arrives exactly where value does.

## Custom verification hooks Protocols can add their own hooks to the verification path. For high-value, anomalous or suspicious transfers, Canary can consult issuer infrastructure, protocol backends, risk engines, compliance systems or any other required source of truth before signing. If something should be verified before value moves, Cipher is designed to verify it, before release rather than after the transfer or after a report. Hooks are permissioned throughout. The protocol controls which checks exist, what they may inspect, and whether each one is advisory or blocking. How the DVN consults the engine is described on [Cipher checks and hooks](/canary/how-it-works/cipher-checks-and-hooks.md). ## Extended controls * **Rate limits.** Protocols define transfer limits, and when a limit is exceeded, Canary pauses signing automatically. Large-scale exploits depend on moving significant value quickly. In the April 2026 incident the attacker moved six figures of a staked asset in a single operation, and a rate limit set to a fraction of that amount would have stopped the attack before material damage. * **Manual approval.** For high-value transfers, Canary can require a signature from the protocol's own key before it signs, so that no single system can approve a large transfer alone. * **Priority escalation.** Critical alerts page Canary engineers and the protocol team directly. For protocols managing hundreds of millions in cross-chain value, response time matters as much as prevention. ## Observe first, then enforce Every capability runs in one of two modes, as an observation that reports or as a hook that blocks. A new check starts in observe mode, runs against real traffic and records what it would have decided, without gating anything. Once its accuracy is proven, it is promoted to blocking with thresholds calibrated from evidence rather than guessed. Promotion requires no re-integration, and a protocol can move each capability between modes through a policy deployment. The full adoption path is on [Onboard to Cipher](/canary/integrate/onboard-to-cipher.md). ## In production Cipher is in production with select protocols, and capabilities roll out progressively across the Canary DVN as they are ready. Live integrations include Ondo Perps, where Cipher runs code checks on new software versions, Midas, where it runs NAV checks on mHYPER, and a major stablecoin, where it runs reserve checks on mint requests. In that deployment an authentic mint request can still fail if the backing is missing. ## Honest scope Canary enforces what is provable and states the limits of everything else. What a cross-chain pathway proves directly is supply integrity across chains, reserve state as attested, and the invariants a protocol defines, and Cipher enforces exactly that. A cross-chain message does not prove offchain custody, hedges or bank balances, and Cipher does not claim that it does. Where offchain backing matters to a decision, the evidence is designed to come from [Canary Collateral Proofs](/canary/the-assurance-layer/collateral-proofs.md). Collateral Proofs are designed to check custodian, bank, administrator and auditor records with each record's source, freshness and limits kept visible, and to supply that evidence to checks on the DVN path and to [Canary Cosigner](/canary/the-assurance-layer/canary-cosigner.md) at mint and redemption. A checked record shows how it was checked. It does not prove that an institution's books are complete or that the assets are unencumbered.