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.

Fig. 01 · One screen, as a capturelanes · typical 2–3 s · re-screen returns the cursor
Pipeline timing diagramSchematic timeline of one screen: evidence sources run concurrently, deterministic rules score, the analyst writes and is clamped by a guard, the attestation is signed, and the registry write settles asynchronously. The readouts beside each lane come from the latest real decision on the ledger (none yet).0 ms4008001.2 s1.6 s2.0 s2.4 sEVIDENCERULESANALYSTATTESTATIONREGISTRY·LEDGERyentearc-graphblacklistpayee-booknetworktipst/oguard-----re-screen · HIGH 1 h · MEDIUM 24 h · LOW 7 d · tier.changed webhook0 ms

The five stages

  1. Evidence. Sources run concurrently, each behind a per-source timeout (4 s, EVIDENCE_SOURCE_TIMEOUT_MS). Phase 1: subject facts (first seen, tx count, USDC isBlacklisted, 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.
  2. 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.
  3. 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.
  4. Attestation. The replayable core of the decision is canonicalised and hashed (decisionHash), then signed as an EIP-712 Attestation by the attester key. Validity follows the tier: LOW 7 days, MEDIUM 24 hours, HIGH 1 hour.
  5. Ledger, store, registry. A SCREEN (or RESCREEN) 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 to AttestationRegistry on Arc without blocking the response (registryTx is null until it lands; the registry is live at 0xA82EDb5e111c31C63E06EF0007f2fa1a9e7EB30d).

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: 2 after seeing hop 1; the pipeline honours that once, re-scores, and asks the analyst again.

What the model can and cannot decide

FieldWho decidesGuard in code
scorerulespure function of the evidence; the model never sees a way to change it
tierrulesband of the score
recommendedLimitsanalystclamped into the tier band: LOW ≤ 10,000 / 50,000 USDC, MEDIUM ≤ 250 / 1,000, HIGH 0 / 0; day ≥ tx
nextRescreenAtanalystclamped 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
eddRequestedanalystdropped for LOW; trimmed, de-duplicated, at most 3 questions of 8+ characters
rationaleanalystany 0x hash, address or sanctions id not present in the evidence is replaced with “[unverified identifier removed]”; cut at 120 words
requestDepthanalysthonoured 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