Legal

How the verdict is produced

The formula, the thresholds and the limits — published in full, because a score you cannot audit is a score you should not trust.

In effect 12 August 2026 · English is the authoritative version

TermsPrivacyRefundsMethodologyContest a verdict

1. Why this page exists

A risk score that will not show its working is asking for faith. This page publishes the actual arithmetic, the actual cut-offs, and the cases where we know the method is weak. If a verdict about a token you hold looks wrong after reading this, contest it.

2. What is measured

Every scan reads public Solana state through an RPC provider and derives three independent components. The final score is not their sum. It is the higher of two paths, so that a token can fail on concentration alone even with no coordination at all.

// coordination: share of traced supply sitting in coordinated clusters base = min(coordinated_pct / traced_pct * 100, 100) // deployer track record: contributes nothing until 40% of past launches are dead, // and is damped until at least 10 past launches have been sampled depComponent = max(0, dead_pct - 40) / 60 * min(1, sampled / 10) * 75 // single largest non-pool holder: contributes nothing below 12% concComponent = max(0, (top_holder_pct - 12) * 2.2) // the verdict takes whichever path is worse score = min(100, max(base + depComponent, concComponent))

Reading those thresholds

  • A deployer is not penalised for losing money. Below 40% of past launches dead, the track-record term is zero. It reaches full weight only when every sampled launch is dead, and it is scaled down until we have sampled 10 launches — so a deployer with two dead tokens is not treated like one with thirty.
  • The largest real holder is free up to 12%. Above that, every percentage point adds 2.2 to the score, so a 30% holder scores 39.6 on concentration alone and a holder above 57.5% maxes the scale.
  • Liquidity pools and locked supply are excluded before any of this runs. A pool counted as a whale was a real bug once; the vault is now identified and separated, which is why our top-10 reconciles with other tools' circulating figures.

3. The bands

0 – 34.9 · CLEANNothing above threshold fired. Not a safety guarantee.
35 – 64.9 · CAUTIONAt least one meaningful signal. Read the findings before acting.
65 – 100 · AVOIDStrong signal on at least one path. The API also returns recommendation: "AVOID".

The API additionally exposes is_controlled, which is true at a score of 35 or above, and risk, which is CLEAN / MEDIUM / HIGH across the same boundaries. Agents integrating the API should gate on the numeric score or on recommendation; those field names and values are stable and we will not repurpose them without notice.

4. The detection layers, ordered by how much we trust them

This order is by strength of evidence, not by how impressive each one sounds.

  1. Holder concentration — the share held by the single largest real wallet, pool and locked supply excluded. Our strongest signal and the one that corroborates against independent tools.
  2. Same-block bundle buys — wallets acquiring in the same slot. Slot-based, so it catches any mechanism, not only one bundling service.
  3. Coordinated exits — multiple holders selling a meaningful share within the same block.
  4. Deployer track record — the creator wallet's full launch history with the peak market cap each past token reached, so a dead count cannot hide a token that ran and was dumped.
  5. Contract safety — live mint and freeze authority, and Token-2022 transfer-fee, transfer-hook and permanent-delegate traps. Can you actually sell?
  6. Funding-cluster trace — top holders walked back to shared funding wallets. Listed last deliberately: this is our weakest layer. On our own sample it has produced no verified true positives once an infrastructure-wallet bug was fixed. We publish it as supporting evidence and we have said so publicly rather than quietly dropping it.

5. What the score cannot tell you

It cannot tell you a token will go up or down. It cannot read intent — a pattern consistent with coordination is also consistent with a launch that simply attracted the same kind of buyer twice. It cannot see off-chain agreements. It cannot see the future behaviour of a wallet that has done nothing yet. And it describes one moment: a scan is not a monitoring service.

Two specific limits worth stating:

  • Degraded scans. When lookups fail, the response is marked degraded. A partial trace gives an incomplete picture and should not be read as a clean one.
  • Freshness. Results are cached briefly for speed. Every response carries the time it was produced; a rescan is always available.

6. Reputation labels

Deployer labels are mechanical outputs of the thresholds above applied to public history. SERIAL_LAUNCHER means a wallet has deployed many tokens; DEAD_ON_ARRIVAL means the sampled launches went to near-zero market cap. These describe observed on-chain outcomes. They are not findings of fraud and make no claim about any person's intent.

7. When the method changes

Thresholds change as we learn. When a change alters published verdicts materially, we will note it here with the date. Verdicts are not silently rewritten: if we correct one after a challenge, we record that it was corrected and when.

Contest a verdict · API documentation · How we compare to other tools