THE METHODOLOGY

This is a specification, not marketing copy. It exists so that a verdict can be argued with: if you disagree with a score, the rule that produced it is on this page, with its weight, its mechanism and the date it last changed.

Every number here is rendered from the scanner's own scoring configuration at page load. There is no second copy to fall out of date — when a weight changes, this document changes with it, and the change appears in the revision history in Part VIII.

A verdict asserts one thing: given the evidence listed in that verdict, this is the deduction the published formula produces. It is a reproducible measurement, and every input it used is printed alongside it.

Two scans of an unchanged token under an unchanged formula produce an identical score, an identical tier, and an identical result fingerprint. The score is a function of the evidence and nothing else — not of when you asked, who asked, or how long the scan took.

A verdict is not a prediction, and it is not financial advice. A CLEAR token can be rugged five minutes later by a key that was never on-chain to begin with; the score measures what the contract and the market permit, not what the people behind them intend.

It is also not a judgement about a project's merit. The checks look for mechanical exit risk — custody of the liquidity, privileged functions, concentration, manufactured volume, funding lineage. A token can be structurally sound and still worthless.

Every check declares where its evidence comes from, and that declaration is published in the verdict. Across the 19 weighted checks, 5 overrides and 4 post-score rules:

• 7explorer
• 7RobinCalls DB
• 7DEX market data
• 5live eth_call
• 1contract audit
• 1canonical registry

A check that cannot reach its source does not silently return a passing result — see Part VI.

Every token starts at 100 and loses points. A check that FAIL deducts its full weight; a check that WARN deducts half. A PASS and a SKIP both deduct nothing — which means a check that could not run costs a token exactly as much as a check it passed, and is the reason the skipped ones are printed on the verdict rather than hidden.

The weights total 155 points across 19 checks — deliberately more deduction weight than there are points to spend, so a token failing broadly reaches the floor rather than requiring a clean sweep to get there. The score floors at 0 and never goes negative.

The final score maps to one of four bands. The band is what the verdict leads with; the number is what it is derived from.

CRITICAL is reachable two ways: by scoring below its ceiling, or by a single override firing regardless of score (Part III).

The complete table, in weight order. The bar is each check's share of the 155 points available to deduct.

Worked through with the live weights. Take a token where LP custody fails outright and Wash trading raises a warning, and everything else passes:

That arithmetic is the whole model. What follows are the two ways the arithmetic gets overruled.

Some findings are not worth points, because no amount of good behaviour elsewhere offsets them. Any one of these forces the CRITICAL band outright, whatever the score was.

Caps are the softer instrument: the score is computed normally, then ceilinged. This is how persistent memory (Part IV) and live market manipulation reach into a scan without distorting the weighting.

A cap is published on the verdict as a rule that fired with a deduction of zero, because it did not deduct — it ceilinged. Read the ceiling, not the zero.

The three stages run in a fixed order, and each can only lower the result:

1. 1

   WEIGHTED DEDUCTION

   Every check runs; FAIL takes its full weight, WARN half. The result is floored at 0.

2. 2

   CRITICAL OVERRIDES

   If any override fired, the band becomes CRITICAL regardless of the number computed in step 1.

3. 3

   POST-SCORE CAPS

   Any active cap ceilings the score, and the band is re-derived from the capped number.

Every token that ever fails the honeypot simulation is marked forever. While a mark is active the score is capped at the top of DANGER: a scammer who switches the trap off later still cannot buy back a CLEAR.

An admin can lift a mark for a verified false positive — a token scanned before trading was enabled, later audited. The lifted mark stays visible with a public reason and date, and re-arms automatically if the trap ever fires again.

The gas that funds a fresh wallet is the umbilical cord back to its operator. When a rug is confirmed, guilt propagates through the funding web: one hop is a kill shot, two hops a heavy deduction, and no further.

High fan-out hubs — exchange hot wallets, faucets, bridges — break the chain and never transmit guilt, because everything downstream of them is everyone. Every stain carries the exact transaction path that produced it, so any flag can be re-verified against public chain data.

Not every rug happens in one transaction. Tokens on record are re-checked for liquidity bleeding down from its trailing peak, and that signal earns a ON-WATCH mark.

A mark is not an indictment. Indictment additionally requires separately verified LP control and gradual-drain evidence under the public rug criteria. Wallet-cluster supply deltas remain dormant until a holder-snapshot feed is live — and are documented here as dormant rather than described as if they were running.

We analyse the contract's verified source when the deployer has published it, and its on-chain bytecode when they have not. If the token is a proxy — a shell that forwards to an upgradeable implementation — we follow it to the real code first, so an upgradeable token is judged on what it actually runs rather than on the empty husk in front of it.

Not function names — effects. We catalogue the capabilities that let an insider reach into a live market: minting or rebasing supply, pausing trading, blacklisting holders, changing fees or wallet and transaction limits, granting exemptions, rerouting the AMM, withdrawing liquidity, rescuing assets, redeeming custody, upgrading the code, or executing arbitrary calls.

Each is listed with the exact functions that carry it, so anyone can check the finding against the public contract.

A power that exists is not the same as a power that is loaded. For each capability we resolve the authority that gates it and ask whether that authority is live or neutralised.

A renounced owner does not mean safe. Renouncing closes only the doors that owner held. If the same power is gated by a different role, a dev wallet, a proxy admin or a multisig, it stays live — and we say so.

If the source is not verified, or a node times out mid-read, the audit can only go so far — and it reports exactly how far. An analysis that could not finish is never dressed up as a clean bill: the absence of a finding we could not look for is not evidence of safety.

Every capability also carries how firmly it is known: traced in source, likely through indirection, or a bytecode-only match.

The audit drives exactly one weighted check. A privileged power reachable through a live or unresolved authority is a FAIL; powers that exist but whose only key has been provably renounced are a WARN; a contract with none is a PASS.

Everything else the audit surfaces — the full capability map, the controlling addresses, the proxy graph — is published for transparency but does not move the number. When the audit cannot complete, the check falls back to a plain bytecode scan rather than guess.

This is the failure mode the engine is built against, and it deserves a part of its own because it is the one that produces confident, wrong, user-visible verdicts.

A failed probe is not a negative result. An RPC node that never replies has not told us the token is safe, and it has not told us the token is a honeypot; it has told us nothing. Collapsing “we could not look” into “we looked and found nothing” is how a scanner publishes an all-clear it never earned — and an all-clear is the dangerous polarity, because a false accusation gets disputed by the token's own holders within the hour and a false exoneration never does.

So the two are kept apart everywhere they meet. A contract call that reverts is an answer and is scored. A call that times out is an absence, is marked transient, and falls back to stored state rather than demoting the token. An empty result — no pool found, no template matched, no funder on record — is treated as unknown unless the read can show it actually looked.

Each scan is assessed as complete or partial before it is allowed to mint a permanent receipt, and the rule is deliberately narrow: only an infrastructure failure of a scoring-required provider degrades a scan.

A partial result is not a fact either. A check that answered over a fraction of its subject has not answered — a custody audit that could read six percent of a pool's holders knows nothing about the other ninety-four, and the largest holder is exactly the one most likely to be missing from a short sample.

The contract the engine is held to therefore has two halves. Evidence records how much of its subject it accounted for, so a conclusion drawn over a sliver is visible as one. And an all-clear requires having accounted for the subject, not merely having found nothing in the part that was read — for LP custody that means the pool must be accounted for before a PASS is available, and custody that cannot be attributed to this token's liquidity is recorded without being scored.

Each verdict is serialised to a canonical payload with a fixed key order before it is hashed. It contains the token address, the score, the tier, whether an override fired, the formula version, the ordered list of check ids with their statuses and deductions, and the creation timestamp — and nothing else.

Request noise never enters: no simulation wallets, no request ids, no latency. That is what makes the hash re-derivable by anyone holding the public row.

Each entry's hash is sha256(previous_hash : payload). The first entry chains from a genesis constant. Change one historical entry and every hash after it breaks — there is no way to edit the past that leaves the chain intact.

The chain head is periodically committed in a transaction from the Robin wallet: a public timestamp nobody can backdate, including us.

Separately from the chain hash, each outcome gets a result fingerprint — a hash over the formula and receipt-policy versions, the token, the score, tier and override flag, the ordered checks, the active permanent marks, and the selected pool. Two scans with the same fingerprint say the same thing about the token, so the second reuses the existing receipt instead of minting a duplicate.

Liquidity is deliberately excluded from the fingerprint. It enters the receipt decision through its own threshold comparison; bucketing it into the fingerprint as well would both double-count it and make receipts flap every time a pool drifted across a bucket edge.

Three steps, entirely from public data:

1. 1

   REBUILD THE PAYLOAD

   Take any row from the ledger and reconstruct its canonical payload from the published fields, in the key order specified above.

2. 2

   RE-HASH IT

   Hash it together with the previous entry's hash. It must equal the entry hash on the row.

3. 3

   CHECK THE ANCHOR

   Confirm the chain head appears in the anchoring transaction on-chain. If it does, the record held.

Every formula change, newest first. A score that moved without the chain moving is always attributable to an entry in this list.

1. v1.30 · 2026-08-19CURRENT

   Two contract checks added in the previous version were not reaching any token we had already looked at. Analysis of a contract's code is stored and reused, keyed to the version of the rules that produced it, and that key was not moved when the checks were added — so every previously scanned token kept its older analysis and simply never gained them. Moving the key re-runs the analysis. Separately, the check that finds switches able to block selling now also recognises the opposite shape: a list of addresses that are waved past the block instead of stopped by it. That is the same power, held the same way, and on one token it was the whole mechanism — the operator kept a hundred addresses on the list, sold through it, and everyone else was stopped. No check weights changed.

2. v1.29 · 2026-08-18

   Sell simulations now pay this chain's real gas price. They previously ran with no gas price at all, which a contract reads as zero — so a token that blocks selling whenever the gas price is above zero passed every simulation while reverting for every real person, and we published a clean bill on one. When a realistic sell fails, the same sell is re-run with no gas price: if it then succeeds, the token is gating sales on the gas price and the verdict says so instead of describing an ordinary sell failure. The realistic result is always the one reported. A sell that fails because our own simulated wallet could not cover the gas is now reported as unproven rather than as the token refusing the sale. Where the gas price could not be read, the verdict says the simulation was not representative instead of quietly claiming a clean exit. A switch that can block transfers or selling is now named for that, rather than for the category its setter's name happened to match — one such switch was published as a "limit change". Tokens that emit fake transfer records, attributing coins to an address that never held them, are now reported. No check weights changed.

3. v1.28 · 2026-08-18

   This scanner now reads the Up venue, a concentrated-liquidity market that holds the deepest pool of about one token in five here and was previously invisible to every custody check. Its pools now count toward a token's liquidity, and who controls them is read through the staking contract that holds most of it, so the staking contract is no longer mistaken for a single large holder. Where too little of such a pool can be attributed to name a holder at all, custody says so rather than naming one. Custody also names the venue a pool sits on when that venue is one this scanner does not cover, instead of describing it only as unreadable. Where the venues we can read hold a minority of a token's liquidity, that shortfall now counts toward the unread part of the scoring surface, so such a token can no longer be certified CLEAR. Every share in the custody summary now states what it is measured against, so a pool's share of what we read is never mistaken for its share of the token's whole market. Wording throughout the custody summary was rewritten for plain reading. No check weights changed.

4. v1.27 · 2026-08-17

   A token is no longer certified CLEAR over checks the scan could not complete; where a material part of the scoring surface goes unread, the score is held at the top of CAUTION and the verdict says how much was unread. Custody now measures a holder arrangement it previously set aside as untraceable, described with the same caution as any other contract holder — as something that may be able to move liquidity, never as something proven to. A sell that could only be checked at the quote level now reports as unestablished rather than as exitable. Two sentences were corrected: a pool on a venue this scanner does not cover is described as outside our coverage rather than as a failed read, and the holder-concentration figure states which basis it is measured against. No check weights changed.

5. v1.26 · 2026-08-13

   Three improvements to who a check is about. A pool whose liquidity history cannot be fully accounted for is no longer scored on the part that could be read. A contract holding a controlling share of a pool is now judged on what its code can actually do, rather than on the fact that it is a contract — a judgement that can raise a concern on an incomplete reading but can only clear one on a complete reading. And the checks about a launcher's own history now run against the person a launchpad's records name, instead of standing down at the launchpad. No check weights changed.

6. v1.25 · 2026-08-11

   Two checks stop describing something they did not examine. The liquidity-withdrawal check no longer reports a clean result for pools outside its reach; it says so plainly, and points the reader at the LP custody check instead. Separately, holder concentration no longer treats a contract that holds tokens on other people's behalf as though it were a single owner — where it can identify the people behind such a balance it credits them, and combines that with whatever those same people hold directly. Where it cannot identify all of them, it keeps the more cautious reading and says so. No check weights changed.

7. v1.24 · 2026-08-11

   Three checks stop treating a missing answer as a negative one. Where a reference source does not report whether a contract's source is published, or whether it carries a scam listing, the scan now states plainly that the question could not be answered — instead of marking the token unverified, or clearing it of a listing nobody checked for. A source that does answer is unaffected either way. No check weights changed.

8. v1.23 · 2026-08-11

   The scan now correctly recognises when it has already examined a token's main pool. On one widely used venue that pool was always counted as unexamined, however thoroughly it had in fact been read, which let a real problem found elsewhere be reduced to a minor note. It also meant the same token could score differently on two scans minutes apart with nothing on-chain having changed. A finding is now softened only when the main pool genuinely could not be read. No check weights changed.

9. v1.22 · 2026-08-11

   Liquidity custody no longer calls a pool safely spread when nearly all of it sits with a single holder it could not classify; such a pool now reads as unresolved rather than clear. A problem found in a smaller venue is softened only when the token's main venue was genuinely assessed, not merely when nothing was found there. Where a pool's own history does not reconcile with what the pool reports holding, the history is treated as incomplete and no ownership share is claimed at all. A token whose creator could not be identified no longer loses points for that — it is a gap in what we know, not a finding against the token — and every pool the scan scores now shows how much of it was actually examined. No check weights changed.

10. v1.21 · 2026-08-11

    A privileged function is now reported only while it can still be used. Some contracts arm a restriction for a fixed window at launch, or expose a setup function that can run exactly once; after the window closes or the setup has run, that code is present but no longer usable by anyone. Those are now named separately as retired rather than counted as live dangers, and they are still disclosed so a reader can tell an expired capability from an absent one. This applies only where the scanner can prove the guard can never be reset, and only after reading the contract's current state — anything it cannot read, or any switch an owner could flip back, keeps counting as live. A contract whose every capability has retired is reported as such, never as having none. Also: the summary line naming a token's deepest pool now identifies what kind of holder controls it instead of always saying 'the deployer', and a promotion read that missed only the purchased-listing half no longer discards the boost count it did read. No check weights changed.

11. v1.20 · 2026-08-10

    Checks may no longer describe an address they never identified. A holder is called a wallet only once it is confirmed to be one; an unread classification now reads as 'an address' instead of defaulting to 'wallet', and a contract holding liquidity is reported as ambiguous rather than accused of being able to withdraw it. Liquidity that is burned or locked no longer counts as anyone's to pull at any level, so a locked pool keeps its credit as it grows instead of losing it at a threshold. Where the token's creator is itself a contract — a launchpad rather than a person — the checks about a deployer's own history, funding and past rugs now stand down instead of judging every token that launchpad ever made. Ownership and upgradeability now use the contract audit's answer rather than publishing an all-clear it contradicts, holder concentration will not measure a float built from an incomplete pool list, and a promotion or fee-history read that only half-completed no longer reports an absence. Custody thresholds are editable at /admin and every scan records the values it used. No check weights changed.

12. v1.19 · 2026-07-24

    Custody now cross-checks its own coverage against independent market data. When the token's deepest pool by reported liquidity is one this scan could not read directly, that pool still counts toward the total being measured — so a verdict drawn from the venues we could read cannot claim to speak for the whole market. The adjustment only ever softens a finding or withholds an all-clear, never hardens one, and it files the token for human review. No weights changed.

13. v1.18 · 2026-07-23

    Two correctness fixes that moved scores; no check weights changed. Database-backed checks (funder history, launchpad provenance, deployer and lineage lookups) now read real data instead of reporting the record as unavailable. And a pool's share of a token's liquidity is now measured per pool, by the depth actually tradeable at the current price — so the venue backing the price is judged as the main venue rather than averaged away.

14. v1.17 · 2026-07-22

    The Dangerous functions check is now driven by the contract-authority audit rather than a fixed signature list: privileged powers are read from the token's own code and graded by whether the authority controlling them is still live, provably renounced, or unresolved. When the audit cannot complete it falls back to the previous method and never treats an incomplete look as a clean bill. Weight unchanged (6).

15. v1.16 · 2026-07-20

    LP custody now scales the penalty to the venue. A pullable secondary venue is a FAIL only once such venues together back a meaningful share of pooled liquidity; a small measured one is a light WARN, and negligible pools are recorded but not scored. A failing main pool still takes the full deduction. No weights changed.

16. v1.15 · 2026-07-19

    Trusted addresses moved to a single database-backed registry with a short cache and an environment bootstrap. Registered Robinhood RWAs must re-prove their canonical infrastructure on every refresh, and their issuer and custody contracts are excluded from memecoin-specific heuristics. No weights changed.

17. v1.14 · 2026-07-19

    Trusted liquidity lockers moved from environment configuration into the database, so a locker can be added or revoked without a deploy. Liquidity held by a recognised locker is treated as locked rather than as an unidentified large holder. No weights changed.

18. v1.13 · 2026-07-18

    Custody headline honesty. The LP-custody verdict now reports the pool it actually assessed, says so plainly when it could not account for the whole pool, and no longer lets a narrow all-clear outrank an unreadable one. No weights changed.

19. v1.12 · 2026-07-18

    Multi-DEX coverage. Robinhood Chain runs several Uniswap-style venues, and a token's deepest pool is not always on the first one. Discovery now covers all of them, so custody and liquidity are judged against the venue that actually backs the price. No weights changed.

20. v1.11 · 2026-07-18

    Venue honesty. Tokens still on a bonding curve are no longer penalised for lacking a conventional liquidity pool — a curve is a different venue, not a missing one — and their custody and liquidity checks are judged on the curve's own terms. No weights changed.

21. v1.10 · 2026-07-16

    Launchpad provenance goes live. Creators who manufacture their own early demand are now flagged before a DEX pool exists. Bundled with the release: fuller pool-history coverage, rejection of non-token inputs, a retry on transient node faults, and a cleaner rule for permanent Record marks.

22. v1.9 · 2026-07-16

    Paid promotion joins the formula (20 weighted checks): bought screener placement now counts against a token. Every scan also ships a top-traders table with behavioral tags. Tags describe the market and never move the score.

23. v1.8 · 2026-07-15

    Discovery honesty. An unanswered pool lookup is no longer reported as 'no pool.' When discovery is incomplete, the affected checks say so instead of scoring on partial data. No weights changed.

24. v1.7 · 2026-07-15

    Custody now weighs each pool by its share of real liquidity, so tiny side pools can't outvote the pool that backs the price. LP-whale detection extended beyond V2 to V3 and V4. No weights changed.

25. v1.6 · 2026-07-15

    LP custody now detects large non-deployer liquidity holders, not just the deployer's own stake. No weights changed.

26. v1.5 · 2026-07-15

    Checks now judge the right object. Custody, contract age, and holder classification were tightened to attribute evidence to the scanned token itself. No weights changed.

27. v1.4 · 2026-07-14

    Holder concentration is now measured against circulating float rather than raw supply, so insiders can't hide behind pool-held tokens. No weights changed.

28. v1.3 · 2026-07-14

    Wash gets teeth. A live wash-trading failure now caps the score, so a token running manufactured volume can't read CLEAR. No weights changed.

29. v1.2 · 2026-07-14

    The Wash House. Added wash trading (19 weighted checks): a composite turnover and trade-pattern signal calibrated against live pump-and-dumps. New post-score cap on collapsed tokens.

30. v1.1 · 2026-07-13

    The Memory Upgrades. Added funding lineage, upgradeability, dangerous selectors, and serial-clone checks (18 weighted checks). Prior-honeypot marks now cap the score, and honeypot simulation was hardened.

31. v1.0 · 2026-07-12

    Initial published formula. 14 weighted checks, 5 critical overrides, industry-standard tier bands.