Every check reduces to one plain data structure, AnalyzerInput (see the served source). All reads are pinned to a single block, so an independent verifier reading the same block reproduces the same facts. Each fact below is labeled chain read (deterministic: same block, same answer, from any node) or heuristic (a judgment rule; the exact rule is stated so you can disagree with it).

The two heuristics, in full

Only two rules in the whole system are judgment calls rather than direct chain facts. Both are stated exactly, and both only ever push a verdict toward more suspicion, never toward a cleaner one:

• heuristic Symbol impersonation. The token's symbol is case-folded with a confusables map (Cyrillic and Greek look-alikes, zero-width characters stripped) and compared against a table of 50 well-known tickers. An exact match is impersonation (NAME_IMPOSTER). A symbol within Levenshtein distance 1 that contains non-ASCII characters is homoglyph impersonation (NAME_IMPOSTER): legitimate tickers are ASCII. A distance-1 ASCII symbol is a possible typosquat (SYMBOL_LOOKALIKE). The tables and the distance function are in the served knownAssets.ts.
• heuristic Fresh creator. A creator address with a transaction count of 3 or less at the pinned block is flagged FRESH_CREATOR (low severity): throwaway wallets are common in scam launches, and established issuers are not new wallets. The threshold is arbitrary and documented as such.

This table is a transcription of deriveFlags in the served analyzer.ts; if they ever disagree, the source wins and the test set will catch it. Severity feeds the verdict roll-up in section 03.

The roll-up is a short ordered rule list; the first rule that applies wins. It is asymmetric on purpose: many things can pull a token down to caution or danger, and ok is only reachable when the issuer retains no standing control at all.

1  copycat                                        danger
2  any NAME_IMPOSTER flag                         danger   (applies to non-B20 contracts too)
3  not a native B20:
     symbol unreadable                            caution  (the imposter check never ran)
     canonical asset (address-matched)            ok
     anything else                                not_applicable
4  native B20:
     any medium or high severity flag,
     or FREEZE_ACTIVE / CAN_SEIZE present,
     or latent admin / freeze / seize power       caution
5  otherwise                                      ok

• not_applicable is deliberately not ok. An agent that reads only the verdict field must not mistake "this is not a B20 token" for "this is safe". isB20: false remains the machine-readable scope signal.
• Latent power counts. A token whose admin has never minted or frozen anything is still caution if the admin could start today: the flag is about what the issuer can do to you, not what it has done so far.
• ok for a native B20 therefore means: no active admin, no freeze policy, no dedicated seize or pause role, no uncapped live minter, no identity collision. Renounced, inert, honestly named.

The rules above assume the facts could be read. The service's one hard invariant governs every case where they could not: no failure mode ever produces a false clean. A transient outage, a partial index, a lagging node must surface as an error or a conservative verdict, never as ok.

• Token not in the index and not scannable in budget: the response says dataSource: "not_indexed", carries an explicit NOT_INDEXED flag, and gets a conservative verdict computed outside the pure core; identity checks (copycat, imposter) still run live. It never silently pretends the power scan succeeded.
• Scan too large / RPC node behind our snapshot: the request fails with a 503 (scan_too_large, stale_rpc). An answer that could not be computed honestly is not signed at all.
• Symbol unreadable on a real contract: at least caution, because the imposter check never ran (section 02). A total RPC failure while reading it propagates as an error instead.
• Unknown caller of the analyzer: the optional input fields default toward over-flagging (hasCode defaults to true, canonicalAsset to absent), so a caller that forgets a fact gets extra flags, never a cleared scam.

/testset.json contains real Base mainnet tokens with the complete fact structure (AnalyzerInput) recorded at one pinned block, and the flags and verdict the published logic derives from those facts. All four verdict classes are represented.

It is enforced, not decorative: the service's own test suite loads this exact JSON and asserts that deriveFlags and deriveVerdict still produce the recorded expectations on every build. Any change to the logic fails the build until the published set is regenerated, so this page, the source and the test set cannot quietly diverge.

Reproducing it yourself

• Take any case's address and the set's pinnedBlock.
• Against any Base archive node, re-read the facts at that block: factory isB20 / isB20Initialized, getCode, symbol(), the role-grant event history, supplyCap(), the transfer policy id, the creator's transaction count.
• Compare with the recorded input: they must match, or you have found a bug worth reporting.
• Run the recorded input through the served analyzer.ts (it is dependency-light TypeScript) and compare flags and verdict.

Found a token the logic gets wrong, or a rule you disagree with? Tell me: @k_log_exe. "Your FRESH_CREATOR threshold is wrong and here is the token that proves it" is the best bug report I can get.