> For AI agents: the documentation index is at https://docs.umbraprivacy.com/llms.txt, and every page is available as Markdown at its URL with .md appended.

# Guardian nodes (/docs/guardian-nodes)

Guardian nodes are three independent services that must all co-sign every registration and every value transaction before the shielded pool accepts it. Each also holds one share of the viewing key that every transaction carries.

## What they are

Each guardian node runs inside an AWS Nitro enclave on the Turnkey Verifiable Cloud (TVC), Turnkey's service for running enclave applications, under QuorumOS, the enclave operating system Turnkey builds. Together the three nodes form a guardian cluster, which the shielded pool reads for every transaction.

No person holds a guardian node's keys. They exist only inside its enclave. Each node's long-lived key material comes from its own QuorumOS quorum key, which is split among the node's quorum members and reassembled only inside the enclave, at each boot. The keys its committee signature depends on come from a root that is generated inside a dedicated enclave, root-gen, and delivered only to enclaves running approved code. The quorum keys themselves are generated by another enclave, quorum-gen.

## What they do

**Co-sign.** Each node signs the transaction's context digest, a hash of the whole public transaction, with its BLS key. Your device combines the three nodes' signatures with those of the other attesters into one combined attester signature, which the pool checks. Because the digest covers the whole transaction, the signature authorises exactly that transaction. See [signatures](https://docs.umbraprivacy.com/docs/cryptography/signatures).

**Hold a viewing-key share.** Your device splits a viewing key three ways and sends each node its share, encrypted to that node alone: your outgoing viewing key at registration, and the per-transaction viewing key in every value transaction. One share reveals nothing about the key. See [secret sharing](https://docs.umbraprivacy.com/docs/cryptography/secret-sharing).

**Escrow the share.** Each node returns its share re-encrypted under a key only its own enclave can derive, and the relay in front of it stores the result in write-once storage. The share therefore survives the node being restarted.

## What they check

Before it signs, a node checks that the request is meant for it, that its share decrypts, and that the share matches the commitment inside the transaction's zero-knowledge proof. A transaction therefore cannot collect the guardians' signatures while carrying shares that do not rebuild the key it actually used.

A node does not verify proofs, read the chain or screen addresses. Those checks belong to the shielded pool program and the other attesters.

## Why their code can be trusted

Which enclave code a cluster accepts is approved through governance, and a node's key counts only once its AWS attestation, which proves the code running in its enclave, has been verified on chain against that approval. A node that restarts must attest again before it signs for the pool. See [trusted execution](https://docs.umbraprivacy.com/docs/cryptography/trusted-execution).

## What they can and cannot do

**They cannot move funds.** The pool releases tokens only for a transaction with a valid zero-knowledge proof, fresh nullifiers and the combined attester signature. A guardian's signature is required but never enough, and the viewing-key shares they hold can read, never spend.

**Any one of them can stop transactions.** The pool accepts only a signature all three nodes produced, so one node that is offline, restarting or refusing halts every registration and value transaction until it is back. The [escape hatch](https://docs.umbraprivacy.com/docs/operations/escape-hatch) needs no guardian signature and stays open.

## Who controls the cluster

Which nodes are members of the cluster, and which enclave code they may run, are decided through timelocked governance. A node's own operator can also take it out of the cluster at once, and anyone can evict a node running code the cluster no longer approves. See [governance and upgrades](https://docs.umbraprivacy.com/docs/security/governance).

## Related

- [Secret sharing](https://docs.umbraprivacy.com/docs/cryptography/secret-sharing): Why one share reveals nothing.
- [Trusted execution](https://docs.umbraprivacy.com/docs/cryptography/trusted-execution): What an enclave attestation proves.
- [The fee enclave](https://docs.umbraprivacy.com/docs/fees/fee-enclave): The other enclave that signs for the pool.
- [Governance and upgrades](https://docs.umbraprivacy.com/docs/security/governance): Who decides which nodes are members.


Last updated 12 October 2026