Trust model & FAQ

Four commitments

• Never holds funds. There is no custody, vault or quarantine. The paid endpoints receive 0.01 or 0.05 USDC through an EIP-3009 authorization settled by Circle's facilitator; the only USDC CompliR controls is its own revenue, swept to its own wallets. Your treasury, or your contract, pays.
• Deterministic score. scoreEvidence() has no clock, no randomness and no model in it. Same evidence bundle, same score, same reasons, same bytes. The LLM sees the score as an input and cannot return a different one.
• Signed and replayable. Every verdict is EIP-712 signed by one attester key, carries the hash of its decision core, and is an entry in a hash chain whose roots are anchored on Arc. Verification needs the attester address and the formula, nothing from CompliR.
• Honest numbers. /numbers and the daily report exclude OWN_WALLETS and every internal client id, list what was excluded, link every outside payer to a transaction, and list refunds and mistakes rather than hide them.

What the data cannot see

Public RPC caps

eth_getLogs is limited to 10,000 blocks and 2,000 results per query on the public Arc endpoints, so the funder trace pages in 9,999-block chunks over a 50,000-block lookback (≈ 7 h at ~2 blocks/s). A wallet funded only earlier than that shows no funders at hop 1. Explorer APIs sit behind a Cloudflare challenge for non-browser clients and are not used.

Per-source timeouts

each evidence source has 4 s; a slow or down source contributes its neutral value and the bundle records what was checked. A verdict is never withheld for a missing source, which also means a CLEAN can be a clean-so-far.

Thin sanctions coverage

yente indexes OpenSanctions' sanctions collection only (PEPs and other datasets are off by default). Address matches need a listed CryptoWallet; name matches need a supplied name and ≥ 0.7 confidence. Most Arc addresses are simply absent from any list.

No protocol blocklist

Arc documents USDC's own blocklist (isBlacklisted) but no separate protocol-level contract, so PROTOCOL_BLOCKLISTED never fires today.

Reactor lag

the blocklist reactor polls (20 s as a worker, 5 min as a cron) and skips ahead above 5,000 blocks of lag; it is a live reactor, not an indexer.

Network signal

“held elsewhere” and “shared funder” only exist once several integrators screen overlapping books; on a young deployment they are usually empty.

Rationale

prose from a model, bounded by the guards; it can be dull or wrong in emphasis, never in identifiers (unverified ones are stripped) and never in score or tier.

Demo overrides (.data/overrides.json) exist so HIGH can be shown on our own wallets; a real sanctioned address is never paid or used in a test.

FAQ

Can CompliR move or freeze my money?

No. It has no approval, no custody and no hook into your transfer. It answers a question; your code or your contract acts.

What if CompliR is down when I need to pay?

Off-chain: your call fails and you decide (the SDK throws CompliRError). On-chain: isAllowed reads the registry, which keeps working with the last stored attestation until it expires (LOW 7 d, MEDIUM 24 h, HIGH 1 h); after that it fails closed.

Can the LLM mark someone HIGH, or clear a sanctioned address?

Neither. Score and tier come from the rules before the model runs, and the model's output is limits, questions, cadence and prose, each clamped in code. A direct sanctions, USDC blacklist or protocol blocklist hit floors the score at 61.

How do I know a verdict was not altered after the fact?

Recompute decisionHash from the ledger payload, check it equals the one inside the signed attestation, recover the signer, and check the entry's hash and its batch root on Arc. Details on Ledger & reports.

What do you store about my payee book?

Lookalike and payee-change checks run against the book you send; hop-1 funders of your payees are remembered per client id so NETWORK_SHARED_FUNDER can be answered for you. The cross-client signal exposes only counts and the subject's own funder; no other client's id, payee or book ever leaves the network module.

Will I be charged if the screen fails?

No. The handler runs before settlement on screen and watch; a non-2xx is never charged (X-CompliR-Payment: not-charged). Where settlement must come first (the tip stake), a failure after it queues an automatic refund and says so in the error.

Why is the registry address empty?

The contracts are built and tested (45 Foundry tests) but not yet deployed on Arc mainnet. Until then registryTx is null, the EIP-712 domain uses the zero address as verifyingContract, and signatures still verify offline. The mainnet checklist is the deploy order.

Is this legal advice or a compliance program?

No. It is a risk signal built from public data and your own payee book, with its limits listed above. Treat a LOW as "nothing found", a HIGH as "do not pay without a human", and read the reasons.