Private transactions, accountable validators

Every validator validates and stores each private transaction's inputs — but the stored record is threshold-encrypted. No single validator (or its operator) can read it. Any 2 of 3 validators can jointly authorize the decryption of one specific transaction, without ever reconstructing the network's long-lived decryption key.

Validator 1

Validated transaction store — encrypted at rest, opaque to the operator.

Validator 2

Validated transaction store — encrypted at rest, opaque to the operator.

Validator 3

Validated transaction store — encrypted at rest, opaque to the operator.

Forensic decryption →

Select one transaction, collect decryption shares from 2 validators, and reveal its contents — for this transaction only, in this session only.

1 · Encrypted at rest

Each validator holds the transaction inputs sealed under the network's joint public key: XChaCha20-Poly1305 for the payload, EHTDH1 wrapping the content key.

2 · Share, not key

A validator contributes a decryption share bound to one transaction's record and context. Its long-lived secret share never leaves the validator.

3 · Threshold reveal

Any 2 valid shares recover the record's content key. Fewer than 2 reveal nothing — and every other transaction stays sealed.