> 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.

# Secret sharing (/docs/cryptography/secret-sharing)

Umbra splits two kinds of viewing key into three shares, one per guardian node, so that any two shares rebuild the key and one share alone reveals nothing about it. 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.

## Shamir's scheme, two of three

Shamir secret sharing hides a secret as the constant term of a random polynomial over a field. For a two-of-three split, the polynomial is a straight line: f(x) = s + a·x, where s is the secret and a is a random slope. Each guardian node receives one point on the line: the first node f(1), the second f(2), the third f(3).

- **Any two shares rebuild the secret.** Two points fix a line, and the secret is where that line crosses x = 0.
- **One share reveals nothing.** Through a single point there is a line for every possible secret, each equally likely. This holds whatever computing power an attacker has.

Everything happens in the BN254 scalar field, so the shares are field elements like the keys they split.

## What is shared

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

*The same split is made at registration and in every value transaction.*

- **At registration**, your outgoing viewing key is shared, the key from which every per-transaction viewing key you will ever use is derived. Your device derives both lines' slopes from your identity's master secret rather than drawing them fresh, so a registration that is retried at the same threshold deals the same shares.
- **In every value transaction**, that transaction's per-transaction viewing key is shared, the key that decrypts its sender record.

Spending needs keys that are never shared, so no set of shares can 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 secret's line, the circuit builds a second random line through a blinding value, and each node's share is a pair: the point on the secret's line and the point on the blinding line at the same x. The share leaf for a node is a Poseidon hash of that pair, with the domain for share leaves and the node's x-coordinate 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 shared is the same outgoing viewing key committed in your identity commitment (sometimes called the user commitment).
- In the transaction proof, the key shared is the per-transaction viewing key the circuit derives from your outgoing viewing key, and the same key that encrypts the sender record.
- In both, the circuit requires each line's slope to be non-zero. With a zero slope, every share would equal the secret, and one node would hold the whole key.

The threshold (2) and the number of nodes (3) 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 for a different split does not verify against the cluster in use. Both `register` and `process_3x3x2x2` also refuse outright a cluster whose threshold and node count are not the 2 and 3 the circuits fix, and the keys compiled into the program are for that split alone.

## What each guardian node checks

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

1. decrypts the pair;
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. 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.umbraprivacy.com/docs/guardian-nodes#what-they-check).

## Limits

- **Two of three is a recovery threshold, not a signing threshold.** Two shares rebuild a viewing key, but all three nodes must sign every transaction for it to be accepted. See [signatures](https://docs.umbraprivacy.com/docs/cryptography/signatures).
- **The split is fixed.** Both circuits are built for two of three, with the evaluation points 1, 2 and 3.

## Related

- [Guardian nodes](https://docs.umbraprivacy.com/docs/guardian-nodes): Who holds the shares and how they are run.
- [Your keys](https://docs.umbraprivacy.com/docs/account/keys): The outgoing viewing key and what it derives.
- [Disclosure](https://docs.umbraprivacy.com/docs/disclosure): Who can read what, and when.
- [Commitments](https://docs.umbraprivacy.com/docs/cryptography/commitments): Why each share carries a blinding.


Last updated 12 October 2026