Token Safety Screen methodology

How the screen turns a token creator's on-chain launch history into a verdict, and what it cannot see.

Methodology: Payfetch · Trust Score · Token Safety

This is the methodology behind the Token Safety Screen. The screen answers one question about a freshly-launched token: does the wallet that created it have a track record of launching tokens and abandoning them? It answers from public Solana on-chain data, in a single x402 call to POST /v1/safety/screen ($0.01) or POST /v1/safety/screen/deep ($0.05) at api.forum-labs.com. It makes no trades, no chain writes, and no payments, and it keeps none of the inputs you send it.

We publish how the screen reaches a verdict, and the raw counts behind each one, without publishing the decision boundaries a bad actor could tune against. That line is drawn on purpose, and it is drawn below.

What it flags

The screen flags serial rug-pullers, identified by the launch-and-abandon reputation of the wallet that deployed the token. It is a reputation screen on the creator, not a prediction about the token's price and not a verdict on the token's code. A danger verdict is deployer-reputation-based, and the response says so in a dangerBasis field (deployer_reputation) with a plain-language note: the concern is the wallet that created the token, not the token's current state.

Coverage (v1): Solana pump.fun launches. Other launchpads and chains follow the same append-only, reproducible method as they are added.

How a verdict forms

The pipeline is observable on-chain from end to end:

• Resolve the creator. The token's creator is read from the immutable on-chain create record (the deployer that signed the launch), not from a mutable, editable label. A community-takeover rename does not change who launched the token.
• Enumerate prior launches. The screen looks at that creator's earlier token launches, and those of wallets the chain links to it, strictly before the token you are asking about. A judgment uses only what was on-chain as of the query, so no future information can contaminate a label.
• Label each prior launch by its outcome. Each earlier launch is labeled from its own on-chain history as sustained, abandoned (launched, then went dead and never recovered), or indeterminate (too young or too thin to call). These are observable facts about what happened to each token, not guesses about intent.
• Form the verdict. A creator whose prior launches are a pattern of launch-and-abandon is flagged. A creator with a clean or sustained record is not. When the history is too thin to judge, the screen says unknown rather than guess.

Outcomes are derived from raw on-chain signatures and balances and the launchpad's own public indexer, read through public Solana RPC and parsing providers. They are never taken from another risk vendor's flag graded against itself.

The verdict set

Verdict	Meaning
danger	The creator has a confirmed serial launch-and-abandon record (deployer-reputation basis).
caution	Mixed or partial signals worth a human look.
safe	A sustained token, or no adverse deployer record found.
unknown	Not enough history to judge. The screen says so rather than guess.

The evidence you can re-check

The deep screen returns a re-judgeable deployer evidence block alongside the verdict. It carries the raw counts the verdict rests on, so you can check our conclusion against the same numbers we saw. These are the fields, not the decision logic, and the values below are an illustration, not a threshold:

{
  "verdict": "danger",
  "score": 11,                          // 0-100 safety score, higher is safer
  "dangerBasis": "deployer_reputation",
  "sources": ["on-chain", "launchpad-indexer"],
  "deployer": {                         // the deep-only evidence block
    "address": "<creator address>",     // resolved from the on-chain create record
    "priorLaunches": 34,                // wallet: prior launches enumerated for the creator
    "priorRugs": 31,                    // of those, launched-and-abandoned
    "rugRate": 0.91,                    // abandonment rate behind the verdict
    "clusterId": "<id>",                // on-chain-linked wallet cluster, when one is found
    "clusterPriorLaunches": 12,         // launches attributed to the cluster
    "clusterPriorRugs": 4,              // of those, abandoned
    "clusterRugRate": 0.33,             // cluster-level abandonment rate
    "verdict": "serial_rugger",         // the deployer verdict behind the top-level danger
    "coverage": "cluster_partial",      // how complete the enumeration was
    "thresholdsVersion": "p1s-detect-1.3.1",
    "notes": ["..."]                    // machine-readable degradation / uncertainty markers
  }
}

The score and verdict are stamped with the frozen thresholdsVersion, so you always know which ruleset produced a given answer. The counts are the evidence; the verdict is our reading of them, and you can form your own.

Where the line is drawn

We do not publish the internals a rug-puller could tune against: the counts, rates, windows, or cluster sizes at which a verdict tips; how prior launches are attributed to a creator or grouped into a cluster; how launch records are parsed across program versions; or the caching and registry internals behind the API. Publishing those would turn a transparency page into an evasion manual. Publishing what the screen measures, the verdict set, and the raw counts behind each answer does not, so that is what is here.

Measured accuracy

On a frozen, labeled evaluation set of 31 tokens from wallet-reusing serial deployers and 54 control tokens from legitimate or established creators, screen version p1s-detect-1.3.1 flags 31 of 31 serial-deployer tokens, with 0 false-danger verdicts on the control set and 0 false-safe verdicts overall. The evaluation is point-in-time (no lookahead) and re-runnable; the labeled set and thresholds version are frozen so the number cannot quietly move.

Limits, stated plainly

• Scope is wallet-reusing serial creators. The screen sees a creator's history when the creator reuses wallets or funds launches from linked wallets. A creator who rotates to a fresh, unlinked wallet for every launch is out of scope for v1. Extending coverage to rotation is tracked, deferred work, and we will not quote an "all serial ruggers" number until it exists.
• Thin history returns unknown. A creator whose prior launches are all too young to have an outcome yet returns unknown, never a premature danger. The screen would rather admit it cannot tell than be confidently wrong.
• It screens the creator, not the price. A danger verdict is a fact about the deployer's track record. It is not a prediction that this token will fall, and a safe verdict is not a promise that it will not.
• It degrades toward uncertainty. If an upstream is unavailable or a launch record's layout is unrecognized, the screen returns unknown. It never fills a gap with a confident verdict it cannot stand behind, and it never silently guesses.

---

Forum Labs · Payfetch · Trust Score · Token Safety · Methodology · GitHub · ops@forum-labs.com · @shopforumlabs
© 2026 Forum Labs. Informational screening from public on-chain data. Not financial or investment advice; not a guarantee about any token.