The honest version of any privacy protocol's pitch includes a list of attacks it does not defend against. We'd rather you read that list now than discover it the hard way.
SolMask breaks the on-chain link between a deposit and a withdraw using zero-knowledge proofs over a shielded pool. That is a real, mathematically grounded property. What follows is what that property does not include.
Timing correlation if you withdraw too quickly
The privacy delay is a minimum, not a recommendation. If you deposit a distinctive amount and then withdraw the same amount one hour and one slot later — exactly the minimum the protocol allows — an observer with a stopwatch and a chain explorer will probably guess correctly that the two are linked. The math says the chain doesn't know; the timing says you do.
A passive timing-correlation attack costs nothing to run. Anyone with access to a Solana RPC can do it retroactively, days or months later, by aligning the public list of deposits and the public list of withdraws. The defence is your delay choice and the size of the anonymity set in the window you waited through. The protocol cannot pick those for you.
If your deposit amount is unusual (say, 7.3219 SOL), the timing problem gets sharper still, because the universe of plausibly matching withdraws is much narrower than it is for round amounts. Use round numbers, use the longest delay you can stomach, and avoid the temptation to withdraw the moment your unlock slot ticks over.
RPC-level IP tracking
When your browser talks to a Solana RPC endpoint to build your deposit or withdraw transaction, your IP address is visible to the RPC operator. The same is true of any indexer your wallet pings, the relayer your withdraw routes through, and any third-party analytics your wallet quietly phones home to.
The blockchain doesn't record IPs, but the infrastructure that ferries your transaction to the chain does. A determined adversary who can correlate RPC logs from the wallet that deposited and from the fresh wallet that withdrew may be able to tie them together, even though the chain itself doesn't.
The defences here are not cryptographic. They live at the network layer: route your traffic through Tor or a non-logging VPN, ideally using different exit nodes for your deposit and withdraw sessions; avoid running both sessions back-to-back from the same IP; consider using a self-hosted RPC or one with documented log-retention policies. We provide the math; you bring the network hygiene.
Recipient address linkability
This one is covered in detail in how to choose a recipient address, but it bears repeating here. If the wallet you withdraw to has any on-chain history that ties it to your real identity — your exchange deposit address, your main wallet, your DAO voter address — the privacy of the SolMask withdraw collapses.
The chain doesn't know who you are. But it knows everything about what every address has ever done. If a target address is publicly "yours" for any reason, the withdraw to that address is effectively a withdraw to your name.
A fresh, never-used wallet, funded cleanly without touching your origin wallet, is the only configuration where the cryptography buys you what it claims to.
Admin compromise in v1
SolMask has an admin account. The admin can pause the protocol in an emergency, add or remove supported assets, ban specific wallets at the deposit layer (as part of the high-risk-address controls), and sweep accumulated fees. The admin cannot decrypt your notes, alter your withdraw, freeze a specific deposit, or extract funds from a pool without going through the same proof-verifying withdraw instruction that every user uses.
But "pause" is a real lever. If the admin key is compromised — or if the holder is coerced — withdraws can be halted across the whole protocol until the admin acts again. Your funds are not lost in this scenario; they remain in the pool, recoverable when the pause is lifted. They are, however, illiquid until then.
Admin authority is held by a multisig, with governance hardening over time. Size your usage to your comfort with the admin's pause power.
Trusted-setup compromise before the v2 ceremony
Groth16, the proof system SolMask uses, requires a one-time trusted setup to generate the public parameters every proof refers to. If anyone who participated in the setup retained the secret randomness ("toxic waste") used during the ceremony, that person could in principle forge proofs and drain the pool.
The ceremony's soundness rests on contributors discarding their entropy. A public Bitcoin-block beacon serves as the randomness anchor and makes the ceremony non-replayable.
A public multi-party ceremony — many independent participants — is planned as the protocol matures. A multi-party ceremony distributes trust across many independent contributors, so no single party can compromise the setup. See Trusted setup for the verification procedure and roadmap.
Side channels we haven't thought of
Privacy systems fail in creative ways. We have done what we can to test for the standard pitfalls — amount fingerprints, timing leaks, anonymity-set degradation, replay attacks — but the history of this corner of cryptography is mostly the history of unexpected leaks. We invite anyone to look at our circuits, our verifier, and our relayer code and tell us what we missed. If you find something, please report it before publishing.
The cryptography is strong. The system around the cryptography is what you should worry about. Use SolMask for the threats it was built to address, and don't assume it covers more than this page admits.