The math behind SolMask makes a withdraw cryptographically unlinkable to its deposit. But math is not the only signal an observer has. The simplest, cheapest, and most powerful deanonymisation tool is a clock.
If you deposit 5 SOL at 14:02:11 and someone withdraws 5 SOL at 14:02:23, an outside analyst doesn't need to break any cryptography. They just need to notice that you were the only depositor in those twelve seconds, and the only withdraw is yours by process of elimination. The zero-knowledge proof did its job perfectly; you just stood on stage alone.
The privacy delay is what we use to make sure you're not standing alone.
What the delay actually does
When you deposit, you pick an unlock slot — a Solana slot number in the future before which your funds cannot be withdrawn. The withdraw circuit enforces this directly. The relevant line in circuits/withdraw.circom reads, in spirit, unlock_slot ≤ current_slot. If you (or anyone with your note) tries to generate a proof before the unlock slot, the constraint fails and there is no valid proof to submit.
This is enforced inside the zero-knowledge proof itself, not by a separate timer the protocol could turn off. The chain has no idea what your unlock slot is — it stays inside your commitment — but it knows the proof would not exist unless the timing rule was respected.
The default privacy delay in SolMask is one hour, which on mainnet is roughly 9,000 slots. The UI offers shorter and longer options (10 minutes, 6 hours, 1 day, 3 days, 1 week). Longer is always more private. The recommended default is one hour because that's where, in our judgement, the crowd-size returns start flattening for most assets and amounts.
What "more time" buys you
The anonymity-set size — the number of plausible deposits your withdraw could correspond to — grows with the time window you wait through. If five other people deposited SOL in the hour after your deposit, your withdraw is one-of-six. If fifty did, it's one-of-fifty-one.
The relationship is not perfectly linear. Anonymity-set growth depends on the pool's traffic, which varies by asset, by hour, and by week. Quiet pools grow slowly. The USDC pool will reliably accrue more deposits in an hour than an obscure SPL token's pool, so the same delay buys you more privacy in USDC than in a long-tail asset.
The SolMask UI shows you the live anonymity-set estimate before you commit to a delay. If the estimate looks weak — say, fewer than ten plausible deposits in your selected window — the right answer is to pick a longer delay, or to wait and deposit later when traffic is healthier.
The trade-off is real
Privacy delay is friction. You're locking up funds you can't access. For payroll or treasury operations that's usually fine — those operations were always scheduled in advance. For an urgent personal transfer, a one-week delay is unhelpful no matter how excellent the anonymity-set math.
The right framing is: pick the longest delay you can tolerate. If you can afford to wait a day, wait a day. If you genuinely need the funds in an hour, pick the one-hour delay and accept that the anonymity set will be smaller than if you'd waited longer. The protocol cannot force you to be patient; it can only enforce the minimum you committed to at deposit time.
Why we don't enforce an even longer minimum
We considered making the minimum delay 24 hours by policy. We decided against it because privacy-as-friction tends to push users into worse alternatives — bridges, OTC desks, or simply giving up. A one-hour minimum is short enough to handle most ordinary use cases and long enough that the chain has churned through millions of transactions, dozens of blocks, and (in healthy pools) tens of unrelated deposits since yours.
If you want stronger privacy than the one-hour minimum, the dial is in your hands. The UI surfaces the actual anonymity-set numbers so you can pick a delay informed by reality, not by superstition.
What the delay does not solve
A delay alone is not sufficient privacy. If your withdraw address is already linked to your identity through some other on-chain activity, or if your RPC provider logs your IP, or if you broadcast on social media that you used the protocol, no delay can save you. The delay protects against the specific attack of timing-correlation by a passive on-chain observer. The other articles in this section cover the other attack surfaces.