Concepts

The shielded UTXO model and post-quantum primitives that make Sombra work.

This page covers the two ideas under everything else in Sombra: the privacy model (shielded UTXOs) and the post-quantum primitives that secure them.

The privacy model

Sombra uses a shielded UTXO model, adapted from Zcash's note-and-nullifier design and rebuilt on top of Solana.

Vaults, notes, nullifiers

  • A vault is a shielded account, owned by a user. Balances and activity inside a vault are not visible on-chain.
  • A note represents a discrete amount of value held by a vault. Each note is encrypted under the recipient's Kyber-768 public key and stored on-chain as a commitment.
  • A nullifier is emitted when a note is spent. It proves the note existed and prevents double-spending without revealing which note was consumed.

A transfer spends one or more input notes and produces one or more output notes. Amounts, sender, and recipient are not visible on-chain — only the commitments and nullifiers are.

Fixed decoy set

Every transfer includes 7–8 predefined decoy UTXOs alongside the real inputs. The decoy set is fixed by the protocol rather than chosen by the user.

Why fixed: letting users pick their own anonymity set is a known footgun — casual users tend to pick weak sets, which effectively de-anonymizes them. A protocol-enforced decoy set guarantees a baseline privacy floor for every transaction.

What this gives you

  • Amount privacy. Observers see that a transfer happened; they don't see how much.
  • Recipient privacy. Output commitments are unlinkable to receiving vaults on-chain.
  • Spend privacy. Nullifiers prove "some note was spent" without revealing which one.
  • Transfer-graph privacy. Who-paid-whom cannot be reconstructed from chain data alone.

For the precise threat model — including what's not covered — see Security.

The post-quantum primitives

Classical privacy protocols use elliptic-curve cryptography: Pedersen commitments, Ed25519 signatures, pairing-based SNARKs. All of these break under Shor's algorithm once a large enough quantum computer exists. That's fatal for a privacy chain, because archived ciphertexts can be retroactively decrypted.

Sombra replaces every elliptic-curve component with a post-quantum equivalent.

Kyber-768 for note encryption

Notes are encrypted under the recipient's public key using Kyber-768 (ML-KEM, standardized as NIST FIPS 203). Security rests on Module-LWE, a lattice problem believed to remain hard against quantum attackers.

  • Public key: ~1.2 KB
  • Ciphertext: ~1.1 KB
  • NIST security category 3

No elliptic-curve ECDH, no pairing groups, no discrete-log assumption anywhere in the encryption path.

STARKs for zero-knowledge proofs

Every shielded action is accompanied by a STARK proof that asserts:

  1. The sender owns an input note that exists in the commitment set.
  2. The input note hasn't been spent (its nullifier is fresh).
  3. Output amounts balance with input amounts.
  4. Output commitments are well-formed and encrypted to the claimed recipients.

STARKs have two properties that matter here:

  • No trusted setup. Soundness reduces to the collision-resistance of standardized hash functions (SHA-3, Poseidon) plus FRI. There is no ceremony to trust and no toxic waste to leak.
  • No elliptic-curve pairings. Unlike Groth16 or PLONK, STARKs don't rely on pairing-friendly curves, which collapse under Shor.

Proof sizes and verification costs for MVP are TBD before beta.

Zero-knowledge proofs of decryption

Traditional Zcash designs authorize a spend with an explicit signature (Ed25519 in Sapling, RedPallas in Orchard). Both are elliptic-curve and thus quantum-vulnerable.

Sombra replaces the signature with a zero-knowledge proof of decryption (ZK-PoD). To spend a note, the user proves — in zero knowledge — that they possess the Kyber-768 secret key that decrypts the target note's ciphertext to a valid plaintext. The proof is folded into the same STARK that carries the transfer logic, so spend authorization and binding are one primitive, not two.

This removes the need for a separate signature scheme, eliminates the "signature forgery under quantum" attack vector, and shrinks the protocol surface.

Hash-based key hierarchy

The user's master secret is a high-entropy seed. Kyber-768 keypairs, spending keys, and diversified addresses (if enabled) are all derived with hash-based PRFs — no elliptic-curve operations anywhere in the key path.

Exact key-derivation function (HKDF, SHAKE, or a Kyber-specific construction) is TBD before beta. Diversified-address support in MVP1 is TBD before beta.

How the pieces compose

A shielded transfer in Sombra is one Solana transaction carrying:

  • The nullifier of the input note (to prevent double-spend).
  • The commitment of the output note (to add to the set).
  • The Kyber-768 ciphertext of the output note (so the recipient can decrypt).
  • A STARK that proves the whole thing is well-formed, balances amounts, and authenticates the spender via ZK-PoD.

The Solana program verifies the proof and updates two sets: add the new commitment, add the new nullifier. No signature. No amount. No recipient.

Next: Architecture — how the Solana program, client, and prover fit together.

Introduction

What Sombra is, who it's for, and why post-quantum privacy matters on Solana.

Architecture

How Sombra is assembled — the Solana program, the client, the prover, and the node set.

On this page

The privacy modelVaults, notes, nullifiersFixed decoy setWhat this gives youThe post-quantum primitivesKyber-768 for note encryptionSTARKs for zero-knowledge proofsZero-knowledge proofs of decryptionHash-based key hierarchyHow the pieces compose