> 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/cipher-checks-and-hooks.md).

# Cipher checks and hooks

How the DVN consults the Cipher security engine before anything is signed.

On the cross-chain path, Canary runs two components inside trusted execution environments. The DVN sits in the signing path of every message it secures. The Cipher security engine holds knowledge about the state of the world: reserves, burns, chain state, node health, and whatever sources a protocol brings into the path. The DVN consults the engine during verification, before anything is signed.

## The interface

The interface is deliberately lightweight. The DVN asks a question and receives one of three answers, which are yes, no or don't know. Only a yes proceeds. A no, a don't know, a timeout or an unreachable engine all resolve the same way, and Canary does not sign. Fail-closed is the default for every blocking check. Where a protocol wants a check to be advisory instead, it runs in observe mode and reports without gating anything.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FrshxqVWzZzOBplfpMByC%2Fcipher-verdicts.png?alt=media" alt="The DVN sends a question to the Cipher security engine. Three verdicts can come back: yes, no and don&#x27;t know. Only a proven yes proceeds to signing. No, don&#x27;t know, a timeout and an unreachable engine all end in refusal."><figcaption><p>Of the three possible verdicts, only a proven yes proceeds.</p></figcaption></figure>

## The flow

1. **A message arrives.** The DVN decodes it and extracts what matters: transfer value, source and destination chain, sender, receiver, and the supply delta the message would create.
2. **Policy decides which checks run.** Checks are conditional, and thresholds are custom per chain and pathway. A routine transfer may trigger none. A large transfer may trigger several, with deeper confirmation requirements.
3. **The engine is consulted.** The DVN waits for every verdict.
4. **All clear, or refuse.** If every required verdict is yes, verification continues to quorum. Anything else ends in refusal.

The transaction is never in a state where it has been signed and is awaiting review. Review happens first.

## Checks combine

A single gate can require several conditions at once, for example whether there are sufficient reserves for this transfer and whether the corresponding burn is visible on the sending chain. Each condition is answered independently, and the gate passes only when every answer is yes.

## Hooks bring in the protocol's own sources

A hook is a check executed in the verification path, before an attestation exists. Protocols can add hooks that consult their own infrastructure: issuer APIs, protocol backends, risk engines, compliance systems or any other source of truth. Hooks are permissioned. The protocol controls which checks exist, what they may inspect, and whether each one is advisory or blocking, and new checks can be added as the protocol's risk stack evolves without changes to its contracts.

## The engine is held to the same standard

Every check the engine performs runs inside a TEE and produces an attestation. The roadmap extends this into mutual verification, in which the DVN examines the engine's attestation before it accepts a verdict, so that a compromised engine cannot quietly wave transactions through. The aim is a checker that is itself checked, so that no single key guards the system and the system guards itself.