ZK proofs on Solana: the two stacks, mapped

Ask "does Solana support ZK proofs?" and you'll get contradictory answers, because Solana has two separate ZK stacks that share almost nothing — different curves, different proof systems, different programs, different use cases. One is purpose-built for hiding token amounts. The other is general-purpose SNARK verification. Here's the map.

Stack 1: curve25519 sigma proofs (the ElGamal stack)

Built into the runtime for exactly one job: Token-2022 confidential transfers. Balances are encrypted with twisted ElGamal over curve25519; correctness ("I'm not sending more than I have," "amounts balance") is proven with sigma protocols and range proofs — interactive-style proofs made non-interactive via Fiat-Shamir. Not SNARKs: no trusted setup, no circuits, fast to verify, but limited to the specific statements they were designed for.

The verifier is the native ZK ElGamal Proof program (ZkE1Gama1Proof11111111111111111111111111111), with instructions for equality, validity, range, and zero-ciphertext proofs that compose into transfer flows.

And the cautionary tale: in mid-2025, two proof soundness bugs — including a missing element in the Fiat-Shamir transcript that let a malicious prover forge proofs — took the whole program offline. The post-mortem is required reading: the runtime disabled the program, Token-2022 paused confidential transfers, and re-enablement was restructured under SIMD-0153 with external audits (a public Code4rena contest ran in August 2025). The lesson generalizes: ZK verifier code is consensus- critical cryptography, and "it verifies valid proofs" is the easy half — the hard half is rejecting every invalid one.

Stack 2: BN254 SNARKs (the Groth16 stack)

The general-purpose stack. Three syscalls make SNARK verification practical inside the compute budget:

• sol_alt_bn128_group_op — G1 point addition, G1 scalar multiplication, and pairings on the BN254 (alt_bn128) curve. Pairings are the expensive core of Groth16 verification.
• sol_alt_bn128_compression — compress/decompress G1 and G2 points, so proofs travel small and expand on-chain.
• sol_poseidon — the Poseidon hash over BN254, the standard ZK-friendly hash. This is what makes Merkle trees cheap inside a circuit and verifiable on-chain.

On top of the syscalls sits groth16-solana — the verifier crate most projects use. A Groth16 proof is 128 bytes regardless of what it proves, and verification is constant cost — on the order of 100–200k CUs, which fits comfortably in one transaction. That constant-size property is the whole trick: you can prove arbitrarily large computation happened correctly and verify it for a flat fee.

The production users of this stack:

• ZK Compression (Light Protocol) — state lives in Poseidon Merkle trees, only roots stay on-chain, and every state transition ships a Groth16 validity proof. Compressed accounts cost ~5000x less than regular ones. This is by far the highest-volume ZK verification happening on Solana — and note it's ZK for scaling, not privacy: the data is public, the proof just makes it cheap.
• Bonsol — a verifiable-compute co-processor: run arbitrary programs in the RISC Zero zkVM off-chain, verify the receipt on-chain. The zkVM route means you write Rust, not circuits.
• Circuit toolchains — Circom and Noir circuits compile to Groth16 proofs verifiable via the same syscalls, so Ethereum-style ZK dApps (private voting, mixers, proof-of- reserves, ZK identity) port over. Write circuit → generate verifying key → drop it into a groth16-solana program.

The map in one table

                    Stack 1: sigma proofs      Stack 2: SNARKs
curve               curve25519 (Ristretto)     BN254 / alt_bn128
proof system        sigma protocols +          Groth16 (+ zkVM
                    bulletproof-style ranges    receipts via Bonsol)
verifier            ZK ElGamal Proof program   your program + syscalls
                                               (groth16-solana crate)
trusted setup       none                       per-circuit ceremony
                                               (none for zkVM users)
what it proves      statements about           anything you can put
                    encrypted balances          in a circuit / zkVM
flagship use        confidential transfers     ZK compression, Bonsol,
                                               Circom/Noir dApps
status              rebuilt after mid-2025     live, in production
                    soundness bugs (SIMD-0153,  at scale
                    audits)

What this means for builders

• Hiding token amounts? Don't build it yourself — that's the confidential transfer extension, and its history shows why you don't hand-roll sigma protocols.
• Proving off-chain computation? Bonsol (RISC Zero) if you want to write Rust; Circom/Noir + groth16-solana if you want minimal proof size and cheapest verification.
• Scaling state? ZK compression already productized it — use the SDK, don't rebuild the tree machinery.
• Full private payments? Neither stack gives you hidden parties out of the box — amounts, yes; sender/receiver, no. That's the app layer: the privacy landscape article covers who's building it.
• Proving is the bottleneck, not verifying. On-chain verification is a solved, flat cost. Generating proofs — client-side WASM provers, proving services, zkVM runtimes — is where the latency and infra pain lives. Budget accordingly.

TL;DR

• Two stacks: curve25519 sigma proofs (ZK ElGamal program, purpose-built for confidential transfers, rebuilt after the 2025 soundness bugs) and BN254 SNARKs (alt_bn128 + Poseidon syscalls, Groth16, general-purpose).
• Groth16 verification on Solana is production-grade: 128-byte proofs, roughly 100–200k CUs, powering ZK compression at scale.
• zkVMs (Bonsol/RISC Zero) mean you can get ZK guarantees writing plain Rust — no circuit DSL required.
• ZK on Solana today is mostly about scaling and verifiability; privacy is the smaller, younger half of the story.