> 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/security-stack.md).

# The security stack

The layered defences every message passes through before Canary signs.

Canary's verification pipeline is built as a sequence of layered defences. Each layer independently removes an entire class of attack, and together they require an adversary to defeat every layer at the same time.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2Fi3BOmYx5XJ8xGYsHtaNJ%2Fsecurity-stack-layers.png?alt=media" alt="Six defence layers stacked, each labelled with the class of attack it removes: the independent client, trusted execution, quorum, certificate pinning, authenticated headers and operational security."><figcaption><p>Each of the six layers removes a class of attack.</p></figcaption></figure>

## Layer 1, the independent client

The Canary client is written from the ground up in Go. This removes correlated failure modes. When most of an ecosystem runs the same implementation, a single bug has a blast radius the size of the ecosystem. Ethereum learned this with client concentration, and the verifier layer is no different.

The codebase is compact by design, small enough to fit entirely inside a TEE enclave without unnecessary dependencies. That keeps the trusted computing base tight and the audit surface small.

## Layer 2, trusted execution

Every verification runs inside a hardware-isolated enclave, with cryptographic attestation of exactly which code ran. The host operating system, the hypervisor and the server operator cannot read or modify enclave memory, and signing keys never leave it. Covered in full on [Trusted execution](/canary/how-it-works/trusted-execution.md).

## Layer 3, quorum

Multiple independent TEE nodes, operated across different infrastructure providers, must agree on every verification before it is signed. Compromising one node is not enough, and an unreachable node does not fail into malicious data. The detail is on [Quorum, sources and node health](/canary/how-it-works/quorum-sources-and-node-health.md).

## Layer 4, certificate pinning

Every upstream data source is verified by certificate pinning inside the enclave, which removes the RPC substitution class of attacks. An attacker who controls the network path cannot swap in their own endpoint without failing the pinned check. The detail is on [Quorum, sources and node health](/canary/how-it-works/quorum-sources-and-node-health.md).

## Layer 5, authenticated headers

Every request to the DVN carries authenticated headers. Unauthorised traffic is rejected at the edge before it consumes verification resources, legitimate requests are prioritised, and flood traffic is dropped. This layer is designed to resist the denial-of-service-to-failover pattern, and it gives Canary per-protocol rate management and early detection of anomalous traffic.

## Layer 6, operational security

This is the infrastructure baseline underneath all of it, covering network isolation, hardware-backed key management, continuous threat detection and an audited codebase. The detail is on [Operational security](/canary/how-it-works/operational-security.md).

## The signing path

A message only becomes a Canary signature by passing every stage in order. A failure at any stage ends the path in refusal rather than escalation, and where [Cipher checks](/canary/how-it-works/cipher-checks-and-hooks.md) are configured, they run before the signature, never after.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FVnkEFZf7CKKs15we5hVM%2Fsigning-path.png?alt=media" alt="The signing path. A message is received and authenticated, decoded, read from pinned sources and cross-checked, held to the confirmation floor, checked by Cipher where configured, agreed by a k-of-n quorum and only then signed. Every stage has a fail-closed branch that ends in refusal."><figcaption><p>Review happens before signature. There is no signed-and-awaiting-review state.</p></figcaption></figure>

1. **Receive.** The request arrives with authenticated headers. Unauthorised or replayed traffic is rejected at the edge.
2. **Decode.** The DVN decodes the message and extracts what matters: source and destination, sender and receiver, transfer value and the supply change the message would create.
3. **Read the source chain.** The enclave reads the source-chain event from multiple pinned RPC sources and cross-checks them. A source that disagrees is outvoted rather than believed.
4. **Hold to the floor.** The event must have reached Canary's confirmation floor for that chain, or the higher depth the application asked for, and Canary waits until it has.
5. **Run checks.** Where Cipher is configured, policy decides which checks run for this message, and the DVN waits for every verdict.
6. **Reach quorum.** Independent nodes on different infrastructure must agree. A node that cannot be reached contributes nothing, and nothing fails open.
7. **Sign.** Only now does a signature exist, produced inside the enclave by attested code.