What the compliance proof actually verifies

Correction, September 25, 2026: this post described the legacy 16-signal compliance.circom demo circuit as if it were current. The current pilot profile, pilot-transfer-v3, publishes eight values with no public amount tier or review flag, and screens both wallets. See the circuits page.

The circuit documentation describes the three checks the legacy Groth16 circuit enforces:

1. Sanctions non-membership — a sorted-tree gap construction shows the queried value lies between neighboring leaves. This establishes a fact about the supplied tree; authenticity, completeness and freshness of the screening source are separate requirements.
2. Credential validity — checks performed against the credential commitment and issuer tree supplied to the circuit.
3. Amount tier — the amount is compared against three ordered public thresholds and the claimed tier is checked.

The public-signal array exposes all sixteen signals, including an advisory sar_review_flag that is tier-derived — it is not a suspicious-activity determination or filing instruction.

What the proof does not do: a cryptographically valid proof is not an accepted transfer. Registry acceptance checks, credential authenticity, holder authority, actual transfer binding and replay/expiry handling depend on the verifier and its configuration — see the security boundaries page. These components are unaudited development work, and the off-chain verification recipe shows exactly which four checks a verify call performs so you can compare them against what your own acceptance policy needs.