What zSOL proposes — and what exists today.

The proposed pooled flow

1. Deposit a supported fixed denomination of native SOL into a shared custom vault and publish a secret-derived commitment.
2. Keep the private note client-side; the note is the withdrawal credential and is not the same thing as a tradable zSOL token.
3. Select a third-party association set whose members exclude flagged deposits.
4. Choose a recipient and submit a zero-knowledge membership-and-exclusion proof. A new recipient address alone provides no privacy.
5. Reveal a one-way nullifier so the same deposit cannot be withdrawn twice without identifying the deposit.

Live in this build

• Wallet Standard discovery and connection; the wallet keeps all keys.
• Confirmed native SOL balance reads and faucet requests on devnet.
• Standard public native SOL transfers through the System Program.
• Pre-sign asset, amount, fee payer, destination, network, RPC fee, privacy status, and simulation review.
• Wallet signing, confirmation polling, retryable errors, post-confirmation refresh, and explorer links.

Dependencies before a privacy pool can exist

• A formally specified commitment and nullifier construction.
• Reference circuits, reproducible test vectors, proving keys, and a verifier practical on Solana.
• A deployed, upgrade-controlled vault program and explicit rules separating private notes from any public zSOL token.
• Independent audits of the circuits and on-chain program.
• A trusted-setup ceremony if the proof system requires one.
• Independent set publishers, versioning rules, availability guarantees, and dispute handling.
• A recovery path that cannot strand deposits and a funded devnet vault.

Proposed creator-fee policy

• 30% for transparent, rate-limited zSOL buybacks and irreversible burns.
• 40% for zSOL/SOL market liquidity, accounted separately from privacy-vault reserves.
• 30% for infrastructure, audits, proving services, and protocol development.

Why an AMM is not a privacy vault

A zSOL/SOL pool can provide transparent swaps and price discovery. It cannot issue “fresh” SOL or break transaction links. Privacy requires the separately specified commitment tree, nullifier registry, association-set proof, verifier, solvent vault, and independent audit. This repository does not run operator wallets that churn funds or fabricate anonymity-set activity.

ZEC and bridging

The artifact invokes Zcash as design heritage. It does not define a ZEC deposit, bridge, wrapped ZEC mint, custodian, redemption path, or liquidity source on Solana. This application therefore offers no ZEC transfer, swap, bridge, or claim.

Network separation

The production deployments currently run the public wallet, balance, simulation, and standard SOL transfer flow on mainnet. Devnet remains the test environment. Mainnet configuration does not enable the zSOL privacy protocol, token, pool, treasury routing, or bridge; those remain blocked on their explicit dependencies.

Owner handoff checklist

• Replace the temporary public mainnet RPC with a dedicated production endpoint and monitoring.
• Commission independent audits before deploying any vault, verifier, mint, treasury controller, or LP integration.
• Create hardware-backed multisig authorities for program upgrades, treasury operations, and liquidity management.
• Fund reserves and liquidity only after verifying the deployed program ID, mint, pool, treasury, and authority addresses.
• Set the four public NEXT_PUBLIC_ZSOL_* addresses in Vercel and Railway after verification. Never upload an authority key.