Proofs stay with you: how Mixoor keeps Solana transfers quiet
Mixoor spins up Groth16 zero-knowledge proofs fully in-browser with snarkjs and WASM. No server games, this is actual, usable privacy for on-chain Solana moves, and devs can run it without breaking a sweat.
By Jorge Rodriguez · 8 min read · 2026-07-03T11:00:00-03:00
Client-Side Groth16 Proofs: The Key to Private, Practical Solana Transfers
Mixoor’s whole angle: every privacy proof on Solana gets cooked up right in your browser, not stashed on some backend or jammed into a contract. Groth16 ZK proofs are handled client-side using snarkjs and WASM. So your withdrawal secret and all the juicy details never leave your machine. That guts the risk window and keeps wallet privacy real, especially for anyone juggling multi-wallet ops.
Cut to the chase, if you’re deep-Googling “Groth16 proofs Solana” or want to see what actual client-side proving means, this is for You. We’re skipping baby steps and breaking down exactly how Mixoor lets users handle proof gen for real privacy ops.
Why Proofs Outside the Contract? Security, UX, and True Wallet Hygiene
Doing Groth16 proving in-browser isn’t academic, it’s a move that changes both security and privacy. When the user’s machine builds the SNARK proof:
| Proof Generation Location | Who Holds Secret? | Latency | Privacy Risk | UX Friction |
|---|---|---|---|---|
| Client (Browser) | User only | Low (WASM native, local) | Minimal | Very Low |
| Server-side | Server (risk of logs/exposure) | Medium (network round trip) | Significant | Higher |
| Contract-side | On-chain (not feasible w/ ZK) | Very High (not practical) | None (no privacy) | Not Possible |
You want that secret note and withdrawal entropy chilling in RAM, never taking a trip out over the network. Mixoor never touches the note. No backend risk, no honey pot, just browser straight to chain.
How Mixoor’s ZK Circuit and Proving Stack Actually Work
Breakdown for devs: here’s what actually happens every time you kick off a private Solana transfer with Mixoor.
You start a transfer, Mixoor’s UI mints a unique note (your secret) and hashes it with Poseidon. That hash goes on-chain as a Merkle tree leaf. The note pops up once, don’t lose it, your access rides on that.
To withdraw, pick a recipient wallet. The app fires up snarkjs plus the Mixoor WASM circuit. Proof gets built on your device, private. Nothing sensitive moves upstream.
Groth16 proof, nullifier hash, recipient, asset, all bundled into the tx. Mixoor’s Solana contract checks the proof, blocks any nullifier double-use, and if all good, withdraws with no funding wallet trackback.
WASM actually makes the proof snappy, no need to sit through a five-minute grind on mobile. Runs in any modern browser, Mac or PC. If something borks, Mixoor never sees or stores your data. No stunt doubles.
Notice, after it tells you to save your note, the app never asks for it again. Confirmation modals remind you that fees and secrets stay local. No leaks.
The Tech Stack: snarkjs, WASM, and Private Transfer Circuit
Want to see under the hood? The Mixoor Solana Groth16 stack is built like this:
Efficient zero-knowledge proving with a small, verifiable proof for Solana smart contracts.
Works fully in-browser with native speed and no backend or third-party relay.
Purpose-built private transfer circuit: Poseidon commitments, nullifiers, and multi-asset support.
User’s secret never leaves the device, closing backend and credential leaks.
To the dev crew: snarkjs with a compiled WASM circuit shaves ZK proof times down to seconds. No servers in the loop means privacy isn’t an afterthought, it’s default. Everything about withdrawals happens locally.
Troubleshooting, Edge Cases, and Proof Verification
For teams thinking of stacking or forking Mixoor-style zk flows, quick notes:
No original note, no withdrawal, period. Browser can’t make a valid proof without it. Non-custodial, no recovery. Locked funds if you lose it, that’s the deal.
No WASM or crusty browser? Proving fails, error pops up, and all secrets stay local. Nothing spills.
The contract always checks the nullifier (from the note). If it’s seen one before, it’s rejected, no accidental wallet linkage, thanks to contract rules.
Building fresh flows (multi-wallet payouts, delayed sends)? Same core circuit works, just make your UI fail gracefully on backup warnings and proof errors.
FAQ: Groth16 Proofs, Solana, and Client-Side ZK
What is a Groth16 proof and why is it used in Mixoor?
Groth16: super-efficient SNARK, fast proofs right on-chain. Mixoor picked it for proving withdrawal rights on Solana, no deposit or secret ever shown.
Do I need to trust Mixoor’s backend with my private info?
No server-side proof gen here. Everything runs in-browser with snarkjs and WASM. Backend only gets non-identifying proof data, Mixoor never touches your secrets.
How fast is browser-based proving for Solana ZK circuits?
Proof times? Usually seconds on desktop, can drag a bit on mobile. WASM keeps it snappy for most devices.
What if I lose my note or backup?
Lose your note, you’re toast, no withdrawals, no reset, totally non-custodial. You’re responsible, and the app only surfaces the note once.
Want a look under the hood or to kick the tires on Solana? Proof runs 100% in-browser. Handle your flows, and manage privacy the grown-up way.
Try Mixoor Demo →