Security
Sombra's threat model, stated plainly — what it protects, and what it does not.
This page says what Sombra defends against and what it does not. Read it before you trust it with anything.
The adversary
Sombra is built to hold up against an attacker who:
- Has a quantum computer at some future time. They can run Shor's algorithm against elliptic curves and Grover's against hashes, at scale.
- Sees every Solana transaction since genesis.
- Acts. They can submit transactions, try to forge, try to replay.
- Archives. They can store today's ciphertexts and decrypt them years later.
What has to hold
If any of these breaks, Sombra's guarantees break with it:
- Module-LWE, the lattice problem behind ML-KEM-768.
- SHA-256, as a collision-resistant hash. It is the one hash in the protocol — commitments, nullifiers, the tree, and the key derivation all use it.
- STARK soundness.
- The hardware TEE that holds your witness while a proof is generated.
- The verifier quorum. This one is not a cryptographic assumption, and it is the subject of the first limitation below.
What Sombra protects
Amounts. Never published, on any action except a withdraw.
Recipients. An output commitment cannot be linked to the address that owns it.
The token. A transfer does not name the mint. Only a withdraw does.
Spend authority. Only the holder of the spend key can spend a note, and nothing on-chain carries a signature to forge. The key does go to the prover while your proof is generated, which is covered below.
The transfer graph. Who paid whom cannot be reconstructed from chain data. Nullifiers do not reveal which leaf was spent.
Your history, retroactively. A ciphertext archived today stays closed when the attacker gets a quantum computer, because it was never protected by an elliptic curve.
Reading without spending. Your keys split. The viewing branch decrypts; the spend branch moves money. Viewing keys are issued per week, so you can give an auditor one range of weeks and nothing outside it.
What Sombra does not protect
The verifier quorum is trusted
The Solana runtime cannot verify a STARK. So verification happens off-chain: a registered set of nodes checks each receipt and votes on-chain, and the program counts votes.
A quorum of verifiers that colluded could approve an action no honest verifier would accept. The program would finalise it. Nothing on-chain would notice.
Today that set is registered by the admin, and the admin holds every administrative seat on devnet. This is the weakest link in Sombra as deployed, and it is not a cryptographic weakness — it is a governance one.
One thing limits it. Every node verifies against a pinned image ID, which is the hash of the exact proving program. So the rules a node enforces are fixed by the release it runs. Staking, slashing, and open participation are not built.
Deposits reveal where your money came from
Moving public tokens into the pool creates a visible link between your public wallet and your first note. Everything you do inside the pool is private. The way in is not.
You can only deposit your own tokens. That is deliberate, because it means nobody can plant a note in your history. It also means the deposit edge is always yours.
If this matters to you, fund the wallet you deposit from through a path that is not tied to your identity.
Withdraws are public by necessity
A withdraw pays a real token account. The destination, the token, and the amount are all visible. That is unavoidable: the money is leaving the pool.
The link to your deposits is not revealed, but the exit is.
Your spend key goes to the prover
The witness your wallet sends to the prover contains your spend key. Anyone who could read that witness could spend the notes in the action.
The prover runs inside a hardware trusted execution environment, on NVIDIA Confidential Computing GPUs. The witness stays in encrypted memory that the host cannot read. The operator cannot see it with full control of the machine, and neither can we. The guarantee comes from the hardware, not from our conduct.
Proving on your own machine is not available in V2 at the moment, so this is the path every spend takes.
What you are trusting here is the TEE and its vendor. If confidential computing on that hardware is broken, the witness is exposed.
Remote attestations are not published yet. Once they are, you will be able to check for yourself that the prover you reached is genuine and runs the code we published.
Wrapped tokens inherit their source chain
A token bridged from a chain secured by classical signatures carries that chain's quantum exposure. An attacker who can break the source chain can counterfeit there, and the wrapped version in Sombra represents the same asset.
Sombra's post-quantum guarantees cover Sombra's own cryptography. They do not upgrade an asset you bridge in.
Your device
If your recovery phrase is stolen, your money is gone. Sombra cannot defend against malware, phishing, or someone with your phrase. Timing and power side channels on your own machine are out of scope, as are physical attacks on it.
Solana
Sombra is a Solana program. If Solana halts, reorganises, or fails at consensus, Sombra is affected the same way.
Network metadata
IP addresses and timing are not hidden. An observer watching the network can correlate your submissions even though the on-chain data is shielded. A relayer helps here, because the transaction arrives from the relayer rather than from you.
Anything you say out loud
If you post your address, or sign a message tying it to your name, no amount of cryptography undoes it.
Audit status
Sombra has not been audited. It runs on devnet. Audit scope and auditors are not yet announced.
Do not commit real value.
Reporting something
Security findings go through the GitHub issues linked in the site header. A formal disclosure process will be published before any mainnet launch.
Next: FAQ — shorter answers to common questions.