Compliance at SolMask
How SolMask is built to interact with the existing regulatory perimeter without adding a custodian, a backdoor, or a privileged operator.
How SolMask approaches compliance
SolMask's compliance posture is structural rather than promised. The deposit instruction in the on-chain program consults a banlist registry as part of account validation. A wallet whose pubkey appears in the registry cannot deposit; the program rejects the transaction at the boundary, before any state change occurs. There is no off-chain promise to enforce, no operator with a kill switch, no human in the loop. The check is part of the program code that anyone can read and that the verifier can re-derive from the on-chain account state.
Everything else — non-custody, the absence of a backdoor, the inability of anyone (including the team) to decrypt user notes — is a property of the cryptography and the program architecture, not a policy that could be quietly changed. That is the design principle: every compliance-relevant constraint should be readable in the program source and verifiable from on-chain state. Policy documents alone are not compliance.
What the banlist does
The banlist is an on-chain registry of BanEntry accounts, one per banned pubkey, addressed as program-derived addresses (PDAs) seeded by the banned pubkey itself. That choice is deliberate: membership in the banlist is a deterministic function of the pubkey, so anyone — a wallet, an indexer, a regulator — can check "is this address banned?" with a single account lookup, without scanning a list.
Listings are sourced from off-chain risk providers (currently Cipherowl, which aggregates Chainalysis, TRM, and similar sanctioned-address feeds). The pre-screening happens off-chain because the underlying datasets are proprietary and updated frequently. The on-chain registry is the authoritative point of enforcement: even if the screening service goes down, the program continues to honour the existing on-chain list.
When a user attempts to deposit, the deposit instruction passes the depositor's pubkey through the BanEntry PDA derivation and requires the corresponding account to not exist. If it does exist, the instruction aborts. Because every banlist check is part of the deposit transaction itself, every check is logged, auditable, and reproducible. There is no separate "banlist enforcement" service to trust or audit out of band.
Withdraws are not banlist-checked at the program boundary — once funds are in the pool, they belong to whoever proves knowledge of the note secret. This is a deliberate boundary; the screening point is entry. Read the mechanics deep-dive.
What SolMask does not do
SolMask does not custody funds. The per-asset vault is a program-derived account; the program is the only authority that can move funds out of it, and the only valid path is a withdraw transaction backed by a Groth16 proof against a known note commitment. The team holds no key that can unilaterally move user funds. There is no admin override.
SolMask does not have a backdoor. The withdraw circuit's trusted setup ceremony binds the proving and verification keys to a specific arithmetic circuit. Forging a withdraw proof would require either solving the underlying hardness assumption (Groth16 with BN254) or compromising every participant of the ceremony (the ceremony transcript is published; anyone can verify they participated). Neither path leaves an opening for the team.
SolMask does not decrypt user notes. A note's secrets are derived deterministically from the user's wallet — the wallet signs a fixed message and the result keys an encryption only that wallet can reproduce. The deposit publishes a wallet-encrypted recovery blob on-chain, but the protocol never sees the wallet signature, never receives the plaintext note, and cannot decrypt the blob from on-chain state. Only the user's wallet can decrypt or spend; if the user loses access to the wallet itself, there is no recovery path the protocol can offer.
Jurisdictional notes
Privacy-preserving payments occupy different regulatory positions in different jurisdictions, and the line between "permitted privacy tool" and "regulated money-transmission service" is drawn differently across legal regimes. SolMask is a non-custodial protocol, not a money transmitter; the user always retains custody and the protocol does not facilitate fiat on- or off-ramps. That said, regulatory characterisation depends on where you are using it from and what you are using it for. We do not give legal advice. A detailed per-jurisdiction page is in progress with legal counsel — it will live at /compliance/jurisdictions and is intentionally not stubbed until the review is complete.