FAQ

For users

Is Sombra live?

On devnet, yes. The program is smbrV6UP3CgmF9GjGJjm7rFbLN62zMX1idX3Ptwqmie.

Not on mainnet, and not audited. Use devnet tokens. If something claims to be Sombra and asks for real money, it is not us.

What does Sombra hide?

Amounts, recipients, and which token you sent. An observer sees that an action happened and which verifiers voted for it. See Security.

What does it not hide?

Your deposit into the pool, and your withdraw out of it. Both are public token transfers. Network metadata like your IP is also outside the protocol.

And the verifier set is trusted — read that section before you rely on anything.

Do I need a special wallet?

Sombra is its own browser extension. Get it here.

Does this replace my normal wallet?

No. Keep your normal wallet for public activity. Use Sombra for what you want private.

Do I need SOL to use it?

Only to deposit. A deposit moves your own public tokens, so you sign and pay for it yourself.

Everything after that goes through the relayer, which pays Solana's gas and takes the relayer fee you set — and you can set that to zero. See Fees and the relayer.

Should I use the relayer?

Yes, for everything except deposits.

If you submit a transaction yourself, you pay for it from your own public Solana account, which puts your public identity right next to the private action. Through the relayer, none of your keys touch the transaction.

Is there a token?

No. If that changes, it will be announced.

What changed since the first version

If you read these docs before, the model is different now.

The first version gave every user their own chain of notes and prevented double-spending by making each new note point at the previous one. There was no nullifier set and no shared tree.

Sombra now uses one commitment tree per pool and one nullifier per spent note. Three things got better:

• You can spend any of your notes together. The old chain forced you to spend everything from your last change forward.
• Your spend hides in the whole pool rather than in your own history.
• Transfers no longer name the token.

The old docs also said proofs were verified by checking chain continuity. They are not. A quorum of verifier nodes checks the receipt off-chain and votes.

For builders

How do I integrate it?

Through the SDK. @sombra/client runs the spend flow, @sombra/crypto has the primitives, @sombra/keyring handles keys.

The client takes the chain, the indexer, the prover, and your storage as interfaces you supply, so you can point it at your own infrastructure. The SDK never receives a key it can spend with.

What does a Sombra transfer look like on-chain?

An action account opens, naming the tree root, one nullifier per input note, and one commitment per output. Normally the relayer sends that for the user. Verifier nodes then vote, each signing its own vote. On quorum, anyone can finalise: the nullifiers are recorded and the new leaves appended.

The proof never goes on-chain. See Architecture.

Can I run my own prover?

Not in V2 at the moment. Every spend is proved by a prover we run.

That prover receives your spend key, because the proof needs it. It runs inside a hardware trusted execution environment, so the witness sits in memory nobody can read — including us. Attestations that let you verify this yourself are coming shortly. See Security.

How many notes can one transfer spend?

Up to 24. The limit is Solana's cap of 64 cross-program calls in a single transaction. It was measured, not estimated.

Can I run a verifier node?

Not yet. The set is registered by the admin. Open participation and staking are not built.

On the cryptography

Why not just use Zcash's design?

The shielded-pool shape is similar: commitments in a tree, nullifiers on spend. The cryptography is not.

Zcash uses elliptic-curve commitments, Ed25519 or RedPallas signatures, and pairing-based SNARKs. All three break under quantum attack. Sombra uses ML-KEM-768, SHA-256, and STARKs, and no signature authorises a spend at all.

Is it really signature-free?

Yes, for spending. You prove in zero knowledge that you know the spend key that owns your notes. The only signing key in the wallet pays Solana gas, and it cannot move shielded funds.

Why post-quantum now?

Because for privacy, "migrate later" does not work. Ciphertexts on-chain today are permanent. An attacker can collect them now and read them when they get the hardware. Every day a privacy chain runs on classical crypto is another day of recorded history at risk.

Why ML-KEM-768?

It is the NIST-standardised key encapsulation mechanism at security category 3 (FIPS 203). Well studied, widely reviewed, plenty of implementation work behind it.

Why STARKs over SNARKs?

No trusted setup, so no ceremony to trust and no toxic waste. No pairing-friendly curves, which Shor's algorithm breaks. Soundness comes down to a standard hash.

The cost is proof size, which is why the proof is verified off-chain rather than posted.

How big are the proofs?

Not published yet. The numbers will land here when they stabilise.

What is the anonymity set?

Every note in the pool. The proof shows your inputs are leaves of the tree without saying which, so the set grows with every note anyone adds.

The first version padded each transfer with decoy writes to get a privacy floor. V2 does not need them: the pool itself is the anonymity set.

Can someone audit my account without being able to spend?

Yes. Viewing keys and spend keys come from different branches of your phrase, and viewing keys are issued per week. You can hand over one range of weeks and nothing else.

On the organisation

Who builds Sombra?

Bonsol Labs. The project was once codenamed QCash.

Where do I report bugs?

GitHub issues on the docs repository, linked in the site header. A formal security disclosure process comes before mainnet.