Building an Opt-In Privacy Pool for Solana With Groth16 Proofs
A shielded-pool privacy layer for Solana using Mimblewimble-style UTXOs, Poseidon commitments, and batched Groth16 verification, running on devnet.
Solana transactions are completely transparent. Anyone with access to the chain can trace who paid whom. Smoke.sol is an opt-in privacy layer that changes that for users who choose it: deposit SOL into a shielded pool, make private transfers inside it, and withdraw, with the link between a deposit and a later withdrawal cryptographically broken. It draws on Mimblewimble-style UTXO pools and leans on Poseidon commitments and Groth16 zero-knowledge proofs to get there.
I want to be precise about the stage, because the README is. Phases one through seven are complete, deposits are confirmed working on devnet, and the prototype is deployed. It is not audited and it is not ready for mainnet. What follows is engineering, not a launch claim.
The Pieces That Make Untraceability Work
Several components have to line up before a private transfer means anything. A 32-depth Merkle tree tracks commitments as they enter the pool. A nullifier system, with sharded storage, prevents double-spends by ensuring a given note can only be consumed once. Poseidon is the hash function throughout, chosen because it is cheap to prove inside a zero-knowledge circuit rather than because it is familiar. The circuit itself is written in Circom and produces Groth16 proofs.
The honest detail is that on-chain proof verification in the current phase is still a placeholder. The real privacy constraints, the Merkle proofs and balance equations that make the guarantee hold, are the phase-four work. Deposits, withdrawals, the tree, and the nullifier machinery are what is actually proven out today.
Batching to Fit Solana's Economics
Verifying zero-knowledge proofs one at a time on-chain is expensive, and on Solana that expense is a real constraint. So the design aggregates up to 32 transactions and verifies them together as a batch. That amortizes the fixed cost of verification across many operations instead of paying it per transfer, which is the difference between a system that is theoretically private and one that is affordable to actually use.
The takeaway from this build is that a privacy system is only as strong as its weakest unfinished phase, and the discipline is saying so. The commitment and nullifier layers can be solid while proof verification is still a stub, and calling that out plainly is what separates a working prototype from a dangerous one.
Have something that needs building, or stabilizing?
These notes are the work log. The paid work runs through Moonshine Labs, my product and engineering studio. Tell us what you're building, or grab a call.
Work with us →