SolMask is a privacy protocol on Solana. It is a shielded pool: you deposit a supported SPL token into a per-asset pool, wait, then withdraw the same asset to a different wallet. The on-chain link between deposit and withdraw is hidden by a Groth16 zero-knowledge proof that the withdraw wallet has a secret matching one of the deposits — without revealing which deposit. The pool itself is a Poseidon Merkle tree over the BN254 curve, depth 20, with a capacity of 1 << 20 = 1,048,576 leaves per asset.
SolMask exists for users who have an ordinary reason to keep their balances and transfers off public chain-analytics dashboards: payroll, treasury operations, OTC settlement, donations, personal transactions. It is not a tool for laundering proceeds of crime. Every deposit passes through a banlist check at the program boundary. Wallets added to the on-chain ban registry — typically flagged by an address-risk screening provider before deposit, with admin-curated additions — are rejected. The deposit transaction reverts; no commitment lands.
The user flow is two instructions. Deposit transfers amount of the asset into the shielded vault fee-free — the full amount is credited — and appends commitment = Poseidon(secret, nullifier_secret, amount, unlock_slot) to the Merkle tree. Only the commitment hash is public; the four pre-images are derived deterministically from your wallet and never leave your browser. The deposit also publishes an encrypted recovery blob on-chain (carried in the deposit event), so the same wallet can rediscover the note on any device — there is no passphrase to choose and no note file to back up. Withdraw submits a Groth16 proof together with a nullifier_hash. The verifier checks that the proof binds against a recent Merkle root (the most recent roots are retained in a ring buffer), that the nullifier has not been seen before, that the requested release amount does not exceed the note's value, and that the current slot is at or past your declared unlock slot. The released amount goes to a recipient ATA; any change becomes a fresh commitment appended to the tree in the same transaction.
What SolMask is not is worth being explicit about. It is not a generic privacy tool for arbitrary funds — the banlist is a hard precondition at deposit time and is non-bypassable from the user side. It is not a guarantee of anonymity if your withdraw lands in an empty pool: privacy is statistical, bounded by the anonymity set, and SolMask's UI surfaces the current set size before you commit a deposit amount. It is not custodial — your note secrets are derived from your wallet (no passphrase), and the on-chain encrypted recovery blob can be decrypted only by that same wallet, so reconnecting it on any device restores your balance while SolMask sees nothing; the flip side is that if you lose access to the wallet itself, the notes are gone and SolMask cannot recover them. It is not metadata-private at the network layer — a passive observer of your RPC connection can still time-correlate a withdraw to a TCP connection from your IP, which is why SolMask's hosted relayer is the default path and the self-relay docs spell out the IP-correlation trade-off.
The protocol is permissionless on the withdraw side: anyone with SOL to pay gas can submit a valid proof. The relayer signer is unconstrained beyond being someone willing to pay to initialize the nullifier record and forward the 0.003 SOL protocol fee to the fee destination. The hosted relayer is a UX layer, not a gatekeeper. If it ever censors a user, the self-relay path is available; the only thing it gives up is the IP-correlation protection.
The protocol is deliberately small for v1, covering deposit, withdraw, banlist, pause, fee sweep, and admin rotation. The withdraw circuit is a single file. The trusted setup was a phase-2 ceremony with a Bitcoin-block beacon; a public multi-party ceremony is planned as the protocol matures (see Trusted setup). Every simplification in v1 is documented.
Read next: Architecture for the four subsystems and what each one knows; ZK circuits for the public-input vector and the circuit constraints; Threat model for the explicit list of attacks SolMask defends against and the ones it does not. If you want the plain-English version first, start at How it works.