Screening
What the screener checks before it co-signs a value transaction, which addresses it screens, what it refuses, and what it sees.
The screener is an off-chain service that checks the public parties of every value transaction before it co-signs. It is one of the attesters whose combined signature the shielded pool requires, so no deposit, transfer or withdrawal lands without it.
Who is screened
The screener works out whom to screen from the transaction itself, so a client cannot choose what gets checked. Every value transaction has up to three kinds of subject:
- The submitter, the wallet that submits the transaction: usually a relayer, or your own wallet if you submit it yourself. It is screened on every transaction, private transfers included.
- Depositors, for each deposit: the wallet that signs the transfer into the pool, and the owner of the token account the tokens come from.
- Withdrawal recipients, for each withdrawal: whoever receives the tokens.
A private transfer has no public deposit or withdrawal, so its submitter is its only subject. The screener never learns or screens the private recipient.
How a verdict is reached
Each subject is checked by the screening providers the screener is configured with: CipherOwl's risk screening, and a designation list built into the screener from the OFAC sanctions list. Every screening ends in one of three verdicts, and only the first leads to a signature.
- Clear. Every subject was answered by every provider, and none was flagged.
- Deny. Every subject was answered, and at least one was flagged. The screener does not sign.
- Indeterminate. Some subject could not be fully answered, because a provider failed or an address could not be resolved, even if another subject was flagged. The screener does not sign; an incomplete answer counts as a refusal, never a pass.
Spent notes
Alongside screening, the screener checks that none of the transaction's input notes has already been spent, by looking up their nullifiers in the indexer's copy of the chain's nullifier records. If any has been spent, or a transaction repeats one, it refuses to sign. If it cannot check, it refuses rather than sign unchecked. This is a second safeguard behind the pool's own double-spend checks; see preventing double spends.
What the chain checks
The screener's signing key is registered on chain in the screener registry, and the shielded pool includes it in the combined attester signature it checks for every value transaction. The screener does not run in an enclave: the chain checks its key, not its code. Registering, revoking or rotating a screener's key is a timelocked governance operation. The escape hatch does not involve the screener.
What the screener keeps and sees
The screener writes a record of every screening, keyed by the transaction it belongs to: the verdict, the addresses screened and the providers' answers. It sees only the transaction's public part, which the chain shows anyway once the transaction lands, and it sees it slightly earlier, along with the network address of whoever sent it. It never sees note contents, amounts moving inside the pool, or the recipient of a private transfer.
Related
Last updated
Guardian nodes
What the three guardian nodes are, what they do for every registration and value transaction, why their code can be trusted, and what they can and cannot do.
Zones
What a zone is, the signatures it controls for notes entering and leaving it, what stays private, and how zones are created, frozen and revoked.