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

# Secret sharing (/cryptography/secret-sharing)

Nimbus shards two kinds of viewing key across the three guardian nodes. Each node receives one share, encrypted to that node alone and handled inside its AWS Nitro enclave, and a single share reveals nothing about the key. The zero-knowledge proof shows the shares were made correctly, and each node checks that the share it receives is the one the proof committed to.

## How a key is sharded

Nimbus uses Shamir secret sharing over the BN254 scalar field. The key becomes the constant term of a random polynomial, and each guardian node receives the polynomial's value at its own point: the first node at x = 1, the second at x = 2, the third at x = 3. Through a single point there is a polynomial for every possible key, each equally likely, so one share reveals nothing about the key, whatever computing power an attacker has.

## What is sharded

1. Viewing key: outgoing, or per-transaction
2. Random polynomial through it
3. Three shares: at x = 1, 2, 3
4. One per guardian node: each encrypted to that node

*The same sharding is done at registration and in every value transaction.*

- **At registration**, your outgoing viewing key is sharded. Your device derives the polynomials from your identity's master secret rather than drawing them fresh, so a registration that is retried deals the same shares.
- **In every value transaction**, that transaction's per-transaction viewing key is sharded.

Spending needs keys that are never shared, so the shares cannot be used to spend.

## Share commitments

Each share is committed to before anyone receives it, so that a node can check its share and the proof can bind all three.

Alongside the key's polynomial, the circuit builds a second random polynomial through a blinding value, and each node's share is a pair: the key's value and the blinding value at the same point. The share leaf for a node is a Poseidon hash of that pair, with the domain for share leaves and the node's point built into the hash, so a leaf is tied to one position. The three leaves hash together into a sharing root.

- At registration, the sharing root is one of the proof's public values, and it is part of the payload the guardian nodes and the data endorser sign.
- In a value transaction, the three share leaves are folded into the privacy artifacts root, which the proof is bound to.

## What the proof guarantees

The registration and transaction circuits compute the shares themselves, from the same key they use elsewhere in the proof.

- In the registration proof, the key sharded is the same outgoing viewing key committed in your identity commitment (sometimes called the user commitment).
- In the transaction proof, the key sharded is the per-transaction viewing key the circuit derives from your outgoing viewing key.
- In both, the circuit requires the polynomial to be non-trivial, so no share ever equals the key itself.

The sharing parameters are public values of both proofs. The program takes them from the guardian cluster's configuration when it recomputes the public input, so a proof made for a different cluster does not verify against the one in use, and the keys compiled into the program fit the circuits' parameters alone.

## What each guardian node checks

A guardian node receives its share pair encrypted to its own transport key (see [encryption](https://docs.nimbusprivacy.xyz/cryptography/encryption)). Before it signs, and among its other checks, it:

1. decrypts the pair inside its enclave;
2. recomputes its share leaf and checks it equals the share commitment in the request;
3. checks that leaf sits at its own position among the leaves supplied, and that the leaves rebuild the root the transaction carries: the sharing root for a registration, the privacy artifacts root for a value transaction.

Only then does it sign and keep an escrowed copy of its share, sealed under a key only its own enclave can derive. The node does not verify the zero-knowledge proof itself; the program does that on chain. Together the two checks mean that a node which signed holds a correct share of the key the proof used. See [what a guardian node checks](https://docs.nimbusprivacy.xyz/guardian-nodes#what-they-check).

## Sharding is not signing

All three nodes must sign every transaction for it to be accepted, whatever they hold. See [signatures](https://docs.nimbusprivacy.xyz/cryptography/signatures).

## Related

- [Guardian nodes](https://docs.nimbusprivacy.xyz/guardian-nodes): Who holds the shares and how they are run.
- [Your keys](https://docs.nimbusprivacy.xyz/account/keys): The outgoing viewing key and what it derives.
- [Disclosure](https://docs.nimbusprivacy.xyz/disclosure): Opening chosen fields to a zone.
- [Commitments](https://docs.nimbusprivacy.xyz/cryptography/commitments): Why each share carries a blinding.


Last updated 15 October 2026