> 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/quorum-sources-and-node-health.md).

# Quorum, sources and node health

How Canary decides what the chain actually says, without trusting any single source or node.

No single source of chain data is trusted, and no single verifier node is trusted either.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FMKA6YgGpbZyQ8MRLPk3m%2Fquorum-and-sources.png?alt=media" alt="Several independent RPC providers, each reached over a certificate-pinned connection, feed independent TEE nodes running on different infrastructure providers. The nodes must reach k-of-n agreement before a signature is produced. An unreachable node contributes nothing, and the message is refused if quorum is not reached."><figcaption><p>Pinned sources feed independent nodes, nothing is signed without k-of-n agreement, and nothing fails open.</p></figcaption></figure>

## k-of-n quorum

Multiple independent TEE nodes, operated across different infrastructure providers, must agree on every verification before it is signed. The standard production quorum is 2-of-3, rising to 3-of-4 on high-traffic chains, with custom quorums available for high-value applications that want stricter thresholds.

Compromising one node is not enough. An attacker would need to compromise k separate nodes on different infrastructure at the same time to forge an attestation.

## Failure does not fail open

If a node is unreachable, it cannot contribute to the quorum, and it does not fail into malicious data. The quorum either reaches k signatures from healthy nodes, or the message does not verify.

Denial-of-service-to-failover, the pattern of knocking out the honest path so that traffic falls back to a weaker one, has nothing to attack here. There is no weaker path to fall back to.

## Certificate pinning inside the enclave

Every upstream source, whether a commercial RPC provider or a full node, is verified by certificate pinning inside the TEE.

* An attacker who controls the network path cannot substitute their own endpoint without failing the pinned check.
* A rogue or compromised certificate authority issuing a fraudulent certificate will not pass, because the pinned fingerprint does not change.
* Because the check runs inside the enclave, the verification logic and the certificate validation share the same attestation, so the pin cannot be bypassed by tampering with the host.

This removes the RPC substitution class of attacks, the class behind the April 2026 incident.

## Source variance checks

Data is read from multiple independent providers and cross-verified, so a single wrong or lagging source is outvoted rather than believed. If the sources cannot be reconciled, verification halts rather than defaulting to any one of them.

## Node health feeds quorum

Today, monitoring covers the availability of every node Canary relies on. This is expanding from availability to agreement, testing whether independent nodes concur about the state of the chain, for example the latest block height. Each node earns a score from this history, and the DVN weighs those scores when it forms a quorum, so a node that is alive but drifting counts for less than a node that is alive and in agreement.

## Operator and infrastructure diversity

Canary nodes run with geographic and infrastructure redundancy and, where appropriate, in co-operator configurations, so that a single node or provider failure does not take the quorum below k. The same principle applies one level up: Canary recommends that applications build verifier sets that are diverse in operator, codebase and infrastructure, as described on [Recommended DVN sets](/canary/integrate/recommended-dvn-sets.md).