ASP transparency

The rules

1. Every deposit waits a short vetting delay, then is screened against a public blocklist.
2. Some wait longer: a deposit from a wallet or funder first used only hours before, or one of several in an hour, waits two days; several of these, a wallet refused before, one funder behind many new wallets, a week. Then it is screened again under the blocklist of that day. "Several in an hour", "large" and a surge of new wallets are measured against what is normal in this pool over the last two weeks (the baseline below), never below the fixed bars. Waiting never refuses anything; it gives hack reports time to arrive. It is not an accusation: a new wallet is usually just a new user, and its deposit is approved when the wait ends unless the blocklist names it by then.
3. Wallet analysis. Every wallet that deposits or launches is read before it is approved: its age and activity, how it trades, what it has launched before and where its money came from, from the chain and from independent market data. The signals are combined into one decision. The measures behind them are not published, so they cannot be gamed, and they are tuned as new patterns appear. A wallet with a real history passes without noticing. A thin or suspicious one is frozen: its deposit waits for review before it can join the set, and a launch creator is turned away. It is automatic, nobody decides by hand, and it never holds funds hostage: a frozen deposit can always be taken back with ragequit.
4. Refused: a depositor on the blocklist, or one a blocklisted address funded before the deposit (at least 0.01 SOL, or the pool's own token and, on mainnet, USDC or USDT). Paying a blocklisted address does not count against you, and neither does dust or a spam token someone sent you.
5. Everyone else is approved. Approved deposits form the set every private unzip hides in; its root is posted on-chain with a content hash of the full list.
6. Approvals are re-checked on every run: if the blocklist later shows that a deposit was funded by a blocklisted address, its approval is withdrawn here, with the reason, and it leaves the set.
7. Refused or withdrawn deposits are never frozen: the wallet that zipped can always take them back with ragequit, publicly and without privacy.

Verify it yourself

Download the approved set behind the latest on-chain root and rebuild its Merkle tree here, in your browser. Nothing is taken on trust.

Waiting longer

Deposits that look like money that only just moved (a wallet or funder first used hours before, many deposits at once) wait two days, or a week for several signs, a wallet refused before, or one funder behind many new wallets, before they are checked again. That gives hack reports time to reach the blocklist. Waiting is not suspicion: a new wallet is usually just a new user, approved when the wait ends unless the blocklist names it by then. It never refuses anything, and ragequit works throughout.

What stands out is measured against a baseline of this pool's own deposits, the way security teams baseline behaviour to spot anomalies (UEBA) and exchanges monitor transactions. It reads only what every deposit already shows on chain, never withdrawals: it can tell that a deposit is unusual, never where the money went. The more the pool is used, the more deposits the baseline learns from, and the more precisely it tells the unusual from the ordinary.

Nothing is waiting right now.

Decisions

Launch creators

A launch needs the ASP's co-signature. Rules: C1 the creator passes the same screening as a deposit; C2 the wallet has a week of history; C3 one open launch at a time and none failed in the last 30 days; C4 no other token's name or ticker; C5 terms within the program's bounds. The ASP also analyses the creator's wallet: a weak or suspicious history is refused, or approved only with the backers' tokens unlocking over a week. From the United States, India, the United Kingdom, Iraq or Africa, a launch is approved when asked again an hour later.