Wallet Standard connection, balance reads, simulation, signing, confirmation, and explorer receipts.
Zcash proved private money works · now on Solana
Shared SOL vault · private notes · verifiable exits
Many deposits. One shielded pool.
The proposed zSOL protocol pools many equal-size SOL deposits in one program vault. Each depositor keeps a private note; later, a zero-knowledge proof can authorize a withdrawal without revealing which pooled deposit it spends.
Many fixed deposits→Shared vault + commitments→Proof-authorized exit
Mainnet launch control
Everything is staged. The CA comes last.
The website and wallet layer are live on Solana Devnet. The token market remains off until an owner-signed STONK launch produces a public mint address and verifiable market URL.
Added only after the launch transaction confirms. No placeholder CA is displayed.
The owner reviews and signs the launch in their wallet; this app never receives the launcher key.
30% buybacks and burns · 40% liquidity · 30% infrastructure and development.
01
Sign the launch in the owner wallet after reviewing the asset, fee recipient, quote asset, network, and total cost.
02
Record the public result: mint/CA, market URL, pool, and treasury addresses. No signing secret enters this application.
03
Verify on-chain, then publish. Any later liquidity addition is a separate reviewed transaction signed by the owner or multisig.
How it actually works
The pool creates the crowd. The proof spends the note.
- 01Deposit a fixed amount
A public Solana transaction moves SOL into a program-owned vault and publishes a commitment derived from a secret note.
- 02Join a shared commitment set
Your commitment sits among many same-denomination deposits. More independent deposits can create a larger privacy set; fake wallet churn does not.
- 03Keep the note client-side
The note is the withdrawal credential. It must never be uploaded, stored by zSOL, or confused with a tradable SPL token.
- 04Prove membership and non-use
A zero-knowledge proof shows one eligible commitment is yours; a nullifier prevents the same note from being spent twice.
- 05Vault releases SOL
After the program verifies the proof, the vault pays the chosen recipient. A new address alone provides no privacy—the valid pooled proof is the privacy mechanism.
Commitments, notes, proofs, nullifiers
This is the proposed shielded vault. It requires a custom audited program, real circuits, a verifier, a solvent reserve, and independent set publishers.
zSOL / SOL token liquidity
An AMM can provide public swaps, price discovery, and fee revenue. It does not hide the transaction graph and is not the source of “fresh” SOL.
Important design correction: a private withdrawal note and a freely tradable zSOL token are different instruments. The protocol specification must define their relationship before either can safely launch.
Protocol model · 132 illustrative commitments
Visualization only — not an on-chain pool or a balance.
Your deposit In your association set Flagged deposit Outside your set
association set58 of 132 illustrative deposits
flagged inside0 — excluded by this model
proof designmembership ∧ ¬flagged, in zero knowledge
model verdictWould prove exclusion if implemented and audited
The web app is deployed and live. Wallet connection and public Solana transfers work below. The shielded pool is a documented architecture—not a live mixer—and remains blocked on its verifier, vault program, circuits, audit, and funded reserves.
Working application
Use the parts that genuinely exist.
Connect a wallet, read its confirmed Solana Devnet balance, request faucet funds, or send a standard public Solana transfer. Nothing here is private, bridged, or presented as zSOL.
Solana Devnet
Checking wallets…Protocol economics
Fees that keep the market thick.
Proposed routing for creator-fee revenue after launch. The split becomes real only when an audited treasury controller, verified payout wallets, and permissioned execution rules are deployed.
Buybacks + burns
Creator-fee funds would buy zSOL from the market and permanently burn the acquired tokens under public, rate-limited rules.
Pool liquidity
Deepens the proposed zSOL/SOL market so ordinary swaps have lower price impact. LP accounting stays separate from the privacy vault.
Infra + development
Funds provers, RPC, monitoring, audits, maintenance, and protocol development through a disclosed treasury.
Important: an AMM can swap zSOL for SOL, but it cannot make that SOL “fresh” or private. Any unlinkability would have to come from a separately audited commitment/nullifier vault and a valid zero-knowledge proof.
Launch architecture
One asset, two systems, no blurred lines.
STONK launch market
A future zSOL mint can launch against SOL through a supported STONK/Raydium route. The mint, quote asset, fee tier, pool, and creator-fee recipient must be verified before signing.
zSOL / SOL liquidity
The public AMM handles transparent buys and sells. A 0.1% fee is the proposed pool target; the signed pool creation transaction is authoritative. LP funds never count as privacy-vault reserves.
Shielded vault
The future custom program holds pooled deposits and verifies commitments, proofs, and nullifiers before releasing SOL. It needs independent audits and a funded, solvent reserve.
Zcash is cryptographic heritage, not the pair. A zSOL/ZEC market would be a separate public pool using a specific verified Solana ZEC mint. It would not create Zcash privacy or bridge guarantees.
The lineage
Privacy grew up on Zcash. It belongs on Solana too.
Zcash established the note, commitment, Merkle-tree, nullifier, and zero-knowledge-proof pattern used by modern shielded pools. Those primitives can hide transaction links while still enforcing conservation and preventing double-spends.
zSOL proposes adapting that pattern to Solana and adding association-set proofs: a user could prove their note belongs to a selected eligible set without revealing which member it is. That remains a research and engineering target until circuits, governance, and a deployed verifier are audited.
Mechanism
How a withdrawal is intended to work
Deposit SOL, create a private note
You send a fixed SOL denomination into the shared vault and publish a commitment — a hash derived from a secret only you hold. The deposit transaction is public.
Choose your association set
A set is a published list of deposits somebody vouches for. Pick a broad set for a bigger anonymity crowd, a conservative one for a stronger claim.
Withdraw with a proof
You choose a recipient and publish a zero-knowledge proof: you know the secret behind some commitment in that set, and it has not been spent. The proof—not the recipient address—is intended to hide which deposit is yours.
The nullifier closes it
Each withdrawal reveals a one-way nullifier derived from the note. A correctly implemented program rejects a repeated nullifier, preventing the same note from being withdrawn twice without exposing its commitment.
The distinction
Why zSOL isn't a mixer
The proposed difference is not the cryptography — it is what the protocol would let you prove.
| Mixer | zSOL design | |
|---|---|---|
| Hides your transaction graph | Yes | Intended: yes |
| Lets you prove funds aren't from a hack | No — impossible by design | Intended: in zero knowledge |
| Honest users separable from stolen funds | No | Intended: by association set |
| An exchange can inspect the withdrawal claim | No exclusion proof | Intended: verify the proof |
| Current deployment status | Varies | Not implemented |
These are protocol-design claims, not measured properties of a deployed system. They require a security proof, working circuits, a deployed verifier, robust set-provider governance, and independent audit.
Where this stands
Roadmap
Now
Public devnet wallet tools
Live balance reads, faucet requests, transaction simulation, wallet signing, confirmation, and explorer links.
Next
Reference circuits and devnet program
Groth16 circuits for membership and exclusion, a Solana program on devnet, and published test vectors.
Then
Independent audit and trusted setup
Circuit audit plus a multi-party trusted-setup ceremony with public transcripts. No mainnet before both.
Later
Set-provider ecosystem
Tooling so more than one organisation publishes association sets, so no single party becomes the gatekeeper.
Questions
Straight answers
- Is the live transfer private?
- No. It is a normal public Solana System Program transfer. The interface says so before signing and links to the public explorer after confirmation.
- Does the privacy protocol exist on devnet?
- No. The working devnet layer is wallet connection, faucet funding, balance reads, simulation, and public SOL transfer. The custom vault and proof verifier remain dependencies.
- Does this app handle ZEC?
- No. The artifact uses Zcash as cryptographic heritage; it does not establish a ZEC asset, bridge, custodian, wrapped mint, or liquidity path on Solana.
- Does the app ever see my seed phrase?
- No. It uses Wallet Standard. Signing occurs inside the connected wallet, and this app neither asks for nor stores seed phrases or private keys.
- Is zSOL a token I can trade?
- No token is deployed. A future public zSOL SPL token and a private vault note are separate instruments; their minting, backing, redemption, and burn rules must be specified and audited before launch.
Privacy, brought home.
The public wallet layer is live. The launch card above changes only when verified public on-chain addresses are configured—never from an invented balance or claim.