Concepts

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. The shielded-UTXO idea is inspired by Zcash, but the mechanics are Sombra's own: there are no nullifiers and no global commitment tree. Instead, every vault owns a private ledger — a chain of UTXOs — and Sombra is signature-free: you never sign to prove ownership. A zero-knowledge proof does.

Vaults, UTXOs, and the ledger chain

• A vault is a shielded account owned by a user. Balances and activity inside a vault are not visible on-chain. A vault is a keyless Solana address (a PDA) — the real owner is the holder of the vault's Kyber-768 key.
• A UTXO (an encrypted "note") represents a discrete amount of value held by a vault. Each UTXO is encrypted under the recipient's Kyber-768 public key and stored on-chain as an encrypted account plus a commitment hash — no amount, owner, or recipient is readable on-chain.
• Every vault has its own ledger: a linked chain of UTXOs. Each new UTXO points at the chain's current tip, so the ledger is a strict linked list.

A transfer spends UTXOs from your chain and produces new ones — a UTXO for each recipient, plus a mandatory change UTXO back to yourself. Amounts, sender, and recipient are never visible on-chain; the chain only ever sees encrypted UTXOs, commitment hashes, and node votes.

How double-spending is prevented (no nullifiers)

Sombra does not use a nullifier set. Double-spending is prevented structurally, by the shape of the ledger:

• Chain continuity. Each new UTXO must point at your ledger's current tip; finalization rejects any chain that doesn't line up (UtxoHashMismatch).
• Spend-all. A transfer consumes all of your UTXOs from your last finalized change up to the tip, producing one change UTXO. Selective spending — the thing a nullifier normally guards against — simply isn't expressible.

Because each vault's ledger is one linear chain anchored to a single moving tip, the same value cannot be spent twice: a second attempt no longer matches the tip and is rejected.

Network fees and rent reclaims

Sombra shows you a single network fee, computed as:

Network fee = initial cost − automatic reclaims

• Initial cost — the total Solana gas + Solana rent to process your transactions on Sombra. Each Sombra transfer cost includes real transactions and decoy transactions that will eventually get reclaimed.
• Automatic reclaims — the total Solana rent freed up from your historical transactions.

Most of the initial cost is refundable rent, not a fee — it is reclaimed automatically as your older transactions are cleaned up. The exact amounts are shown in the wallet at signing time and depend on network conditions. The decoy transactions below are the main driver of the initial cost; here's why they're fixed by the protocol.

Fixed decoy set

Every transfer includes 8 predefined decoy UTXOs alongside your real recipient outputs (note: the number of decoys decreases if you use multi-transfer). 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 UTXOs are unlinkable to receiving vaults on-chain.
• Signature-free spend authorization. Ownership is proven by a zero-knowledge proof, not a signature — nothing on-chain links a spend to a private key.
• 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 transfer is accompanied by a STARK proof that asserts:

1. The sender owns every input UTXO (they hash to the sender's vault).
2. The input UTXOs form a continuous chain up to the sender's on-chain ledger tip.
3. Output amounts balance with input amounts — no value is created.
4. Output UTXOs 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-256, Poseidon2) 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.

Signature-free spend authorization

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 removes signatures from spend authorization entirely. To spend, the user proves — in zero knowledge — that they hold the Kyber-768 key for the vault that owns the input UTXOs (the same key that decrypts them). That proof is folded into the same STARK that carries the transfer logic, so spend authorization and transfer validity are one primitive, not two.

The only signing key anywhere in the wallet is a small Solana "gas" key that pays network fees — it can never move your shielded funds. 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 is not a single Solana transaction, and the proof never goes on-chain. Your wallet:

1. Builds the change and recipient UTXOs (each encrypted under the recipient's Kyber-768 key) and writes them on-chain — where they sit unattached to any ledger.
2. Generates one STARK over those UTXOs, proving the whole transfer is valid — ownership, chain continuity, and balance.
3. Sends that proof off-chain to QFire, which hands it to the node set.
4. The nodes verify the proof and attest to quorum.
5. On quorum, finalization attaches your new UTXOs to the ledger and advances the tip. This is the only step that touches your ledger — and only the nodes can do it.

No signature. No amount. No recipient. On-chain there are only encrypted UTXOs, commitment hashes, and node votes.

Next: Architecture — how the Solana program, client, prover, and node set fit together, with a full transfer walkthrough.