Methodology · rule pack 0.5.0-mvp

How Sentry402 scores wallet risk.

17 deterministic rules, severity-weighted, citation-bound. The same engine runs the free /api/screen endpoint, the x402-gated /api/preflight verdict for AI agents, and the dossier you see on the homepage. No LLM in the scoring path; the rule pack version + its SHA-256 are pinned to every dossier so you can re-run the same score against the same inputs months later (FCA 2024 reproducibility model).

← Back to dashboard Changelog Engine source on GitHub →Sample dossier JSON →

Rules in pack

Critical rules

High-severity

How the score adds up

Each rule contributes a fixed maximum number of points when it fires. Contributions sum, then the displayed score is capped at 100. Severity is taken from the highest single rule that fired, not from the sum. We chose this design so that a wallet with one critical hit and zero noise rules reads obviously critical, instead of being averaged down by neutral signals.

Worked example · OFAC SDN address (Amnokgang DPRK)

● ofac_direct_match+100
● sanctions_adjacency_hop1+60
● stablecoin_dprk_cluster_proximity+40
Total contribution200
Displayed score (capped at 100)100
Verdict (from severity, not sum)block

Theoretical maximum across all 17 rules is 541, but no real dossier should hit that — it would require the subject to be sanctioned AND a drainer AND a DPRK-cluster contact AND a non-cooperative-issuer holder simultaneously. The cap exists so the displayed number remains comparable across dossiers.

Severity → verdict mapping

The screening dossier reports the highest-severity signal that fired. The Firewall endpoint folds severity into a single verdict an AI agent can branch on. Bias toward warn at the medium tier is intentional: FATF's risk-based approach and FinCEN's April 2026 NPRM both prefer enhanced review over a hard block at borderline signals.

Severity	Verdict	Recommended agent action
critical	block	Abort transfer. Log generation_id, route to SAR queue.
high	block	Abort. Optional human override only.
medium	warn	Queue for human approval; attach dossier and signals.
low	allow	Proceed under normal policy. Persist generation_id.
info	allow	Proceed.

The 17 rules in pack 0.5.0-mvp

Every signal Sentry402 emits originates from exactly one rule below. The rule ID you see in the dossier (type field) matches the heading you can deep-link to here.

Sanctions · 3 rules

criticalofac_direct_match

Subject wallet itself is on the active OFAC SDN list.

+100

max contribution

Fires when the screened address is itself a Treasury-designated SDN entry. Saturates the score at 100. Per OFAC's 50% rule and Treasury enforcement guidance, all transactions involving the address are prohibited for U.S. persons; any non-U.S. person facilitating such transactions risks secondary sanctions.

What the engine checks: Subject address ∈ active SDN list (lib/sdn.ts). Designation date and Treasury reference are stamped on the signal.
Threshold: 1 (binary)
Citations: FATFFATF Rec 6 — Targeted Financial Sanctions
FinCENFinCEN SAR Form 111, Suspicious Activity Type 31y
TreasuryOFAC SDN list (human-readable) + designation press release

criticalsanctions_adjacency_hop1

Direct (1-hop) counterparty is on the active OFAC SDN list.

+60

max contribution

Fires when the subject's direct counterparty set (incoming and outgoing addresses from the last ~500 transactions, plus USDT/USDC ERC-20 transfer logs) intersects an active SDN entry. Treated as material exposure regardless of the dollar amount of the interaction.

What the engine checks: Top-level transaction counterparties (5 pages, ~500 tx) + ERC-20 transfer event sweep (USDT, USDC, 3 pages each) on EVM. Decoded Helius DAS counterparty set on Solana.
Threshold: ≥ 1 SDN match in counterparty set
Citations: FATFFATF Rec 7 — Targeted Financial Sanctions, Proliferation
FinCENFinCEN SAR Form 111, Type 31y / 31z

highsanctions_indirect_exposure_2hop

Materially-gated 2-hop path to an active SDN address (EVM only).

+35

max contribution

Fires when at least one 1-hop counterparty had ≥ $1,000 bidirectional flow with the subject AND that counterparty's own 1-hop set contained an active SDN address. The $1,000 gate exists because below it, 2-hop exposure is statistical noise — almost any active wallet on Ethereum sits within 2 hops of some sanctioned address through DEX routing.

What the engine checks: 1-hop edges with ≥ $1k USD bidirectional flow are walked one more hop. Capped at 30 walks per scan to bound latency.
Threshold: 1-hop edge ≥ $1,000 USD bidirectional; ≥ 1 SDN at hop 2
Scope note: EVM only. Solana subjects do not fire this rule — 1-hop USD aggregates are not yet computed on the Helius pipeline.
Citations: FATFFATF Recommendation 16 (Wire Transfers / Travel Rule); FATF Targeted Update June 2025 §indirect exposure

External cross-check · 2 rules

criticalexternal_sanctions_oracle_confirmed

Chainalysis Sanctions Oracle independently agrees the subject is SDN.

max contribution

When the subject is on our own SDN list AND the public Chainalysis Sanctions Oracle returns true, we attach the oracle response as a second independent source on the existing direct-match signal. This does not double-count score (the oracle agreement confirms, it does not amplify). The cross-check makes the dossier audit-ready: two independent SDN datasets converge, one of them (Chainalysis) being the same reference Uniswap, Coinbase Wallet, and most major frontends rely on.

What the engine checks: eth_call isSanctioned(subject) on the Chainalysis Oracle contract (0x40C57923924B5c5c5455c48D93317139ADDaC8fb), Ethereum mainnet. Read-only, no gas, no API key.
Threshold: Both local SDN match and oracle = true
Scope note: EVM only — the oracle contract is not deployed on Solana.
Citations: TreasuryChainalysis Sanctions Oracle (court-admissible reference; matches OFAC SDN)

criticalexternal_sanctions_oracle_disagreement

Chainalysis Oracle disagrees with the local SDN list — investigate.

+80

max contribution

Two directions. (a) ORACLE YES + LOCAL NO: Treasury may have designated the address since our last manual SDN sync. Treated as critical — the dossier flags the wallet as effectively sanctioned even though our local list is silent, so the verdict is block. This is the most regulator-relevant case: it surfaces designations we would otherwise miss between syncs. (b) ORACLE NO + LOCAL YES: emitted at low severity. The verdict is still driven by the local match, but the disagreement is logged so the compliance officer can confirm the address has not been delisted since our last sync.

What the engine checks: Compares Chainalysis Oracle result against isSdnAddress(subject) from lib/sdn.ts. Severity is chosen per direction.
Threshold: Either side returns a result the other does not
Scope note: EVM only. Direction (a) saturates score at 100. Direction (b) does not raise the score but logs the disagreement.
Citations: TreasuryChainalysis Sanctions Oracle vs. internal SDN list (lib/sdn.ts, pinned by sdn_list_version)

Approvals & drainers · 3 rules

criticaldrainer_pattern

Three or more unlimited token approvals to the same spender.

+35

max contribution

A primary mechanism in 2024-2025 drainer attacks: the victim is socially-engineered into granting unlimited ERC-20 approvals to a single attacker-controlled spender, which then sweeps the wallet when liquidity arrives. The rule fires when ≥ 3 unlimited approvals point at the same spender contract.

What the engine checks: GoldRush token-approval endpoint per chain. Unlimited = type(uint256).max or 2^256 − 1.
Threshold: ≥ 3 unlimited approvals to same spender
Citations: FATFFATF Targeted Update June 2025 §unhosted-wallet typologies
FinCENFinCEN SAR Form 111, Type 31z (computer intrusion)

highapproval_value_at_risk

Active token approvals expose ≥ $1,000 of value-at-risk.

+25

max contribution

Surfaces total USD value-at-risk currently exposed via active ERC-20 approvals across all known spenders. A compromised approval relationship could drain this value without further user authorization.

What the engine checks: Sum(approved_amount × current_token_price) across all active approvals to non-known-safe spenders.
Threshold: Total VAR ≥ $1,000 USD
Citations: FATFFATF Targeted Update June 2025

mediumunlimited_approval

Any single unlimited approval to a non-known-safe spender.

+15

max contribution

Catches the precondition of a drainer attack before the full pattern emerges. Many legitimate dApps request bounded approvals; an unlimited approval to a contract we cannot label is a yellow flag, not a red one.

What the engine checks: Approval.amount == type(uint256).max and spender not in KNOWN_SAFE_SPENDERS.
Threshold: ≥ 1 unlimited approval to unknown spender
Citations: Operational signal — no regulator citation required.

Stablecoin compliance · 6 rules

criticalstablecoin_dprk_cluster_proximity

Direct interaction with an SB0416-designated USDT address.

+40

max contribution

Fires when the subject has any direct counterparty interaction with a USDT address designated under Treasury press release SB0416 (March 12, 2026, DPRK IT-worker funnel cluster). Indexed by cluster tag in lib/sdn.ts, not by name match — future DPRK designations can be added with cluster: 'SB0416_DPRK' and the rule will catch them automatically.

What the engine checks: Counterparty set ∩ SDN entries where cluster == 'SB0416_DPRK'.
Threshold: ≥ 1 SB0416 cluster contact
Citations: FATFFATF Targeted Update June 2025 §DPRK IT-worker funnels
TreasuryTreasury SB0416 (2026-03-12) DPRK stablecoin designation

criticalstablecoin_non_cooperative_issuer

Holds a stablecoin from a non-cooperative issuer (e.g. A7A5).

+50

max contribution

Surfaces holdings of stablecoins whose issuers have publicly declined to honor lawful enforcement requests (freezes, takedowns, KYC disclosures). Includes A7A5 and similar sanctions-evasion-vehicle issuers. Even small holdings are treated as critical because the issuer relationship is unrecoverable from a compliance perspective.

What the engine checks: Subject's stablecoin holdings ∩ STABLECOIN_REGISTRY where issuer.cooperation == 'non-cooperative'.
Threshold: Any holding > 0
Citations: FATFFATF Targeted Update June 2025 §non-cooperative issuers
TreasuryTreasury OFAC stablecoin guidance Dec 2024

highstablecoin_issuer_frozen_match

Counterparty was publicly frozen by a stablecoin issuer.

+35

max contribution

Matches counterparties against the ISSUER_FROZEN_LIST — Tether, Circle, and Paxos addresses publicly disclosed in their quarterly transparency reports as frozen for AML or sanctions concerns. Different from OFAC SDN: these are issuer-level freezes that often precede or supplement government designations.

What the engine checks: Counterparty set ∩ ISSUER_FROZEN_LIST entries.
Threshold: ≥ 1 frozen-address match
Citations: FATFFATF Recommendation 10 — Customer Due Diligence
FinCENFinCEN SAR Form 111, Type 31z

mediumstablecoin_velocity_typology

DPRK IT-worker funnel pattern — high stablecoin transfer velocity.

+18

max contribution

Fires when stablecoin (USDT/USDC) transfer count in the last 24h exceeds a threshold derived from the SB0416 designation cluster behaviour — funnel wallets typically show >20 stablecoin tx per day, distinct from genuine high-frequency DeFi users who concentrate on native or wrapped assets.

What the engine checks: Count(USDT.transfer + USDC.transfer) on subject in last 24h.
Threshold: ≥ 20 stablecoin tx in last 24h
Citations: FATFFATF Targeted Update June 2025 §DPRK IT-worker funnels

mediumstablecoin_mica_emt_non_compliant

Concentration in stablecoins not registered as EU MiCA EMTs.

+10

max contribution

Informational for non-EU customers; material for EU CASPs. Flags when the subject holds > $1,000 USD in stablecoins whose issuers are not listed on the ESMA EMT register. EU CASPs servicing this subject would face restrictions under MiCA Article 17.

What the engine checks: Sum of subject stablecoin holdings in non-EMT issuers.
Threshold: ≥ $1,000 USD concentration in non-EMT stablecoins
Citations: MiCAMiCA Regulation (EU) 2023/1114 Article 17; ESMA EMT register

lowstablecoin_issuer_compliance

Informational profile of the subject's stablecoin issuer mix.

max contribution

Always low-severity. Provides a cited summary of which stablecoin issuers the subject holds (Tether, Circle, Paxos, etc.) so the dossier reader has a one-glance view of the regulatory venue mix without having to compute it themselves.

What the engine checks: Profile of subject stablecoin holdings by issuer (size-weighted).
Threshold: ≥ $100 USD total stablecoin holdings
Citations: Operational signal — no regulator citation required.

Velocity & freshness · 2 rules

mediumhigh_velocity

More than 50 transactions in the last 24 hours.

+12

max contribution

High transaction velocity is not in itself a typology, but it gates the difference between a slow-moving custody address and an active operational wallet (trading desk, bot, DEX router). Surfaces the velocity so the analyst can reason about whether the recent-100 tx sample is representative.

What the engine checks: Count(tx where block.timestamp > now - 24h) on subject.
Threshold: > 50 tx in last 24h
Citations: Operational signal — no regulator citation required.

lowfresh_wallet

Wallet first seen on-chain less than 7 days ago.

+10

max contribution

New wallets are not inherently risky, but they have less history to score from. Fires only when the wallet age (first on-chain transaction) is < 7 days AND the wallet is not exhibiting custody behaviour (which would trigger a different signal).

What the engine checks: now - subject.first_seen_at < 7 days, and subject is not a known custody address.
Threshold: Wallet age < 7 days
Citations: Operational signal — no regulator citation required.

Mixer & historic exposure · 1 rule

lowtornado_cash_historic_exposure

Historic interaction with Tornado Cash router contracts.

max contribution

Treats Tornado Cash exposure as a low-severity historic flag rather than a sanctions hit. OFAC delisted the original 2022-08-08 Tornado Cash designations on 2025-03-21; we retain the addresses in the SDN registry as 'historic concern' so that analysts can still surface interaction patterns for SAR narrative purposes.

What the engine checks: Counterparty set ∩ Tornado Cash router contract list. Marked historic in SDN dataset.
Threshold: ≥ 1 historic TC interaction
Scope note: OFAC delisting acknowledged — this is informational, not a sanctions hit. Different jurisdictions treat the underlying activity differently.
Citations: TreasuryOFAC delisting press release 2025-03-21 (original designation 2022-08-08)

What this pack does NOT cover yet

Honest scope statement. The rule pack is targeted at the highest-leverage AML and sanctions typologies in scope for the current set of regulator references — it is not a Chainalysis substitute. Gaps a compliance officer should know about before relying on Sentry402 in production:

Privacy mixers beyond Tornado Cash — Aztec, Railgun, and chain-native privacy pools are not in the SDN dataset yet. Out of scope for the May 2026 build.
MPC / smart-account custody attribution — Safe modules, Squads multi-sigs, and AA bundlers are not yet labelled. The score treats them as unknown-custody.
Cross-chain bridge graph — sanctions adjacency does not yet follow funds through Wormhole, LayerZero, or LiFi. A 2-hop walk that crosses a bridge will stop at the bridge contract.
Solana 2-hop indirect exposure — the sanctions_indirect_exposure_2hop rule is EVM-only because Solana 1-hop USD aggregates are not yet computed.
Real-time SDN sync — the SDN dataset (2026-05-07-tc-expanded) is hand-curated to 37 high-signal entries for this hackathon scope. A production deploy would replace this with a daily Treasury sync.
Behavioural ML — no machine-learning signals. We chose deterministic rules so that scores are reproducible across the same inputs. ML signals can be added later as a separate, clearly-labelled rule family.

Versioning & reproducibility

Every dossier carries three pinned versions in its metadata field:

rule_pack_version + rule_pack_sha256 — the rule definitions
sdn_list_version — the SDN dataset (e.g. 2026-05-07-tc-expanded)
goldrush_api_version + helius_das_version — the on-chain data sources

Bumping the rule pack version is the canonical way to record a rule change for FCA 2024 documentation purposes. The version string + SHA-256 give an auditor everything they need to recreate the exact rule pack at the moment the score was generated.

Regulatory references

Frameworks the rule pack cites. Each emitted signal carries the specific reference inline, so the dossier reader can trace any flag back to its regulator basis without leaving the page.

FATF Recommendations 6, 7, 16 — targeted financial sanctions; Travel Rule
FATF Targeted Update June 2025 — Virtual Assets / VASPs
FinCEN SAR Form 111 — Suspicious Activity Type 31y / 31z
MiCA Regulation (EU) 2023/1114 Article 17 — EMT-issuer compliance
OFAC SDN list + Treasury press release SB0416 (2026-03-12)