Getting started02
How it works
A screen is one pass through five stages, and only one of them involves a language model. Evidence is collected from public sources, deterministic rules turn it into a score and a tier, the Risk Analyst explains and sets limits inside hard bands, the attester key signs, and the result is logged, stored and mirrored on-chain.
The five stages
- Evidence. Sources run concurrently, each behind a per-source timeout (4 s,
EVIDENCE_SOURCE_TIMEOUT_MS). Phase 1: subject facts (first seen, tx count, USDCisBlacklisted, protocol blocklist, yente by address and name) alongside the funder trace; phase 2: the funders get the same checks in one batched yente call, plus the cross-client network signal and verified community tips. A source that fails contributes its neutral value, so a bundle is always produced. - Rules.
scoreEvidence(bundle)is pure: same bundle in, same score and reasons out. Weights are fixed (reason codes), funder hits stack with diminishing returns, three hard hits floor the score at 61, and reasons are sorted so the output is byte-stable for hashing. Tier bands: LOW 0–20, MEDIUM 21–60, HIGH 61–100. - Risk Analyst. Claude (
ANALYST_MODEL) receives the bundle, score, tier and reasons and must call one tool,submit_decision. It returns limits, a rationale, EDD questions, a re-screen interval and optionally a request for the second hop. Every field is clamped or filtered in code before it is used; without an API key a deterministic fallback produces the same shape. - Attestation. The replayable core of the decision is canonicalised and hashed (
decisionHash), then signed as an EIP-712Attestationby the attester key. Validity follows the tier: LOW 7 days, MEDIUM 24 hours, HIGH 1 hour. - Ledger, store, registry. A
SCREEN(orRESCREEN) entry is appended to the hash chain, the verdict is stored for the free endpoints, an EDD request is opened when questions were asked, and the attestation is written toAttestationRegistryon Arc without blocking the response (registryTxisnulluntil it lands; the registry is live at0xA82EDb5e111c31C63E06EF0007f2fa1a9e7EB30d).
One hop or two
The funder trace reads USDC Transfer logs from Arc's system emitter (0xffff…fffE, 18 dp) so native sends are seen, paging the public RPC in chunks of at most 9,999 blocks over a 50,000-block lookback. Hop 1 is always traced. Hop 2 costs more RPC and is only taken when it can change the answer:
- Never when the subject itself is sanctioned or blacklisted: it is already HIGH.
- Always when a hop-1 funder has a hit, the wallet is fresh (first seen under 7 days or fewer than 5 txs), the amount is 1,000 USDC or more, a payee-book lookalike matched, or the request pins
depth: 2. - On request when the analyst answers
requestDepth: 2after seeing hop 1; the pipeline honours that once, re-scores, and asks the analyst again.
What the model can and cannot decide
| Field | Who decides | Guard in code |
|---|---|---|
score | rules | pure function of the evidence; the model never sees a way to change it |
tier | rules | band of the score |
recommendedLimits | analyst | clamped into the tier band: LOW ≤ 10,000 / 50,000 USDC, MEDIUM ≤ 250 / 1,000, HIGH 0 / 0; day ≥ tx |
nextRescreenAt | analyst | clamped into the tier window: HIGH 5 min–1 h, MEDIUM 15 min–24 h, LOW 1 h–7 d; the ceiling halves after a tier change |
eddRequested | analyst | dropped for LOW; trimmed, de-duplicated, at most 3 questions of 8+ characters |
rationale | analyst | any 0x hash, address or sanctions id not present in the evidence is replaced with “[unverified identifier removed]”; cut at 120 words |
requestDepth | analyst | honoured once, ignored when depth is already 2 or the client pinned depth 1 |
Every clamp is recorded as a guard note in the decision log entry, so a reviewer can see when the model was overruled and by what.
Re-screen cadence
A verdict carries the next time the analyst wants to look again. Watched addresses are re-screened on that schedule by the watcher (every 10 minutes on Vercel, every 60 s as a worker) and a webhook fires on every tier change. Two other loops re-grade without being asked: the Trust Map tailer re-grades mainnet recipients every 24 hours, and the blocklist reactor re-screens any watched, mapped or recently screened address within one tick of a USDC Blacklisted event.
- HIGH
- re-screen between 5 min and 1 h · attestation valid 1 h
- MEDIUM
- re-screen between 15 min and 24 h · attestation valid 24 h
- LOW
- re-screen between 1 h and 7 d · attestation valid 7 d
- After a tier change
- the window ceiling halves for the next cycle
- Failed re-screen
- retried in 10 min; the last tier is kept