The five checkpoints. How we know whether a token actually died.

Every scan we run gets followed for thirty days. Five fixed checkpoints land at +1h, +6h, +24h, +7d, and +30d after the scan, and at each one we re-fetch the token and decide which of four buckets it belongs in: tradeable, rugged, dumped, or abandoned. The numbers on every other page on the site, the rug-caught counter on the home page, the per-tier accuracy on the metrics page, the share splits in the rug postmortems, all come out of this pipeline. This is how it actually works.

A scan that doesn't get graded isn't a prediction. It's a vibe.

The signals each scan fires are walked through in how to read a doomer scan, the verdict words on top are unpacked in the verdicts piece, and the +24h pattern breakdown lives in the rug anatomy. This post is the layer underneath all three: the part that decides whether the call we made was right.

The five horizons

1h, 6h, 24h, 7d, 30d. Five rows of data per scan, no continuous time series in between. Each horizon has a specific job:

• +1h: research only. Most pump.fun-style rugs need somewhere between one and six hours to fully resolve, so the +1h call understates the catch rate. We capture it for ad-hoc analysis but don't display it as a headline accuracy stat.
• +6h: the fast headline. By six hours roughly 90% of the rugs that will ever happen on a token have happened. Big enough sample to read, fast enough to feel relevant.
• +24h: the canonical accuracy row. This is the number that anchors the metrics page and the rug-anatomy share splits. One day is long enough for the dust to settle but short enough that the cohort is full.
• +7d: catches the slower failures. Locked-LP expirations on a 24-72h timer, deployer dumps that drift in over days, holder bases that fade without a single dramatic event.
• +30d: the survivor view. Anything still tradeable at thirty days isn't a launch outcome anymore. It's a project.

Continuous price streams would buy us more granularity at the cost of writing constantly. Five fixed snapshots, by contrast, are cheap to store, easy to compare across thousands of tokens, and impossible to retroactively re-cut. A horizon you promised is a horizon you have to grade against.

The four outcome labels

Tradeable

At the checkpoint, liquidity is still above the $500 abandoned floor, the sell simulation comes back clean, price hasn't collapsed by more than 75% from scan, and no authority has flipped back on. Not a price judgement. Just: this market still exists, you can still get out.

Rugged

One of three things happened, in cost order. Liquidity dropped to less than 10% of the scan-time value (scan baseline above $500, so we don't trip on dust). The sell simulation comes back honeypot AND the on-chain backstop agrees (single-source flips don't count). Mint authority resurrected from null. Or, falling through to the slower check: the deployer sold more than 80% of the holding they had at scan. Any of those, the call is rugged.

Dumped

Price down 75% or more versus scan, but nothing rug-tier fired. Liquidity still above the floor, sell still works, authorities still null. The market exists, the value doesn't. From the buyer's seat the loss reads identical to a rug. Diagnostically the cause is different, and we keep it separate so the calibration math can see that.

Abandoned

Liquidity at check is under $500, but we have no independent on-chain evidence that the pool was drained maliciously. Could be a tiny launch that nobody ever bought into, could be a slow bleed where holders drifted out one by one, could be a pool reorganization the indexer hasn't caught. We don't over-claim a rug we can't prove. Abandoned is the conservative answer when the market is gone but the cause isn't pinned down.

How the classifier decides

Order matters. We check the cheap signals first and fall through to the more expensive checks only if nothing earlier fired.

• Liquidity dropped more than 90% from scan. Rugged.
• Sell simulation says honeypot AND on-chain shows no recent successful sell. Rugged.
• Mint authority that was null at scan is no longer null. Rugged.
• Deployer sold more than 80% of their at-scan holding. Rugged.
• Vendor returned no liquidity at all. Fall back to the on-chain pool verifier. If verifier returns transient, retry later; if it returns abandoned or rugged based on the live pool account state, stamp accordingly.
• Liquidity present but below $500. Abandoned.
• Liquidity present, price down 75% or more from scan. Dumped.
• Everything else. Tradeable.

Cost order isn't aesthetic, it's budget. RPC calls cost credits and time, and we resolve thousands of checkpoints per day. Cheap signals running in parallel up front means the expensive checks only run on the tokens where the cheap ones came back clean.

What gets captured at every check

The label is one field on a checkpoint doc that captures roughly thirty. We keep the raw data because the label is only as useful as the evidence under it:

• Liquidity at check, plus the percentage change from scan.
• Price, market cap, 24h volume, plus deltas from scan.
• Holder count and its change. A leading indicator for the next checkpoint.
• Mint and freeze authority states, plus whether either flipped since scan.
• LP lock state. Locked-at-scan but unlocked-at-check is a distinct late-rug pattern we catch by comparing the two.
• Sell-simulation outcome, round-trip cost, AMM type, and whether the math and the on-chain backstop agreed.
• Deployer holding at check, computed as a percentage of the at-scan position.

Every field is captured whether or not it influenced the label. That's the part that makes calibration possible later. When a scan we called SAFU resolves rugged, we already have the on-chain story of how it got there sitting in the outcome doc; we don't have to go back and reconstruct it.

When we can't tell

Sometimes the vendor is down. Sometimes Helius hiccups. Sometimes a pool account is in a state the indexer hasn't caught up to. A checkpoint that can't resolve doesn't immediately become an error. It gets retried, on a backoff schedule:

• Five attempts in the first round. If all five fail, the checkpoint reschedules with a six-hour delay.
• Another five attempts after six hours. If those fail too, another reschedule with a 24-hour delay.
• A final five attempts after that. Only then does the checkpoint get stamped permanently errored.

Total worst-case lifetime is fifteen attempts across about thirty hours. That's long enough to ride out a regional Helius or Solana Tracker outage without losing the data point, and short enough that a truly broken outcome doesn't sit unresolved for weeks. Errors are real, but they're rare; the retry budget is designed to make sure that when a checkpoint says error, it really means we couldn't get the data, not that we caught the indexer mid-blink.

Why this exists

Calibration. Every rule on a scan card has a weight, and every weight is something we have to justify. With outcome resolution, we can ask, for each rule, what fraction of the scans where it fired went on to land downside, at every horizon. Rules that fire often and predict nothing lose weight. Rules that rarely fire but consistently catch downside gain it. That's the whole reason the pipeline exists. Without the resolved outcomes, the weights are guesses; with them, the weights are answers.

It also forces honesty. A scan that doesn't get graded is theatre. Promising a verdict and never checking whether the verdict held up means the verdict isn't doing work. The five checkpoints are the part of the system that keeps the verdict honest.

The live numbers from this pipeline are on the metrics page. Per-tier accuracy at every horizon, broken out by category, misses included. Scan a token at doomer.wtf and the call you get back is one we'll grade five times.