The 2.1% we don't catch. Slow bleeds, abandoned pools, and what's on the scoring backlog.

Most of what doomer.wtf does is built around catching an event. A pool drains. An authority flips. A deployer dumps. Sniper wallets exit in a tight window. Every one of those leaves a fingerprint on chain, and most of our rules are pattern-matchers tuned to those fingerprints. The five-checkpoint pipeline grades us on whether we called them right.

This post is about the failure mode that doesn't leave a fingerprint. The slow bleed. The abandoned pool. The token that, at the checkpoint, isn't tradeable anymore, but never produced a discrete event we can point to and say "that was the rug." The rug anatomy piece listed five patterns covering downside outcomes at +24h. Four of them have fingerprints. The fifth, structural failure, accounts for 2.1% of resolved downside outcomes and is the one the scanner catches least well.

This is the postmortem of that 2.1%. Honest version: it's the part of the system we're least proud of right now. Worth writing down so we don't pretend otherwise.

The boundary between the three downside labels

A quick refresh from the five checkpoints for the part of the classifier that matters here.

At each checkpoint the resolver lands the token in one of four buckets: tradeable, rugged, dumped, or abandoned. The first three are well-defined. Tradeable means the market still works. Rugged means a malicious or quasi-malicious event fired (LP drained, authority back, deployer dumped most of their stack, honeypot confirmed by sell sim plus on-chain backstop). Dumped means price collapsed 75%+ from scan but no event-level rug fired; liquidity still present, sell still works, authorities still null. The buyer lost. The mechanism was the market.

Abandoned is the fourth bucket. It's the conservative answer to "the market is gone but we can't pin down why." Specifically: liquidity at checkpoint is below $500, the scan baseline was above $500, and the on-chain pool verifier didn't return evidence of a malicious drain. The pool just shrank to nothing.

The 2.1% slow-bleed share counts the abandoned-outcome tokens whose path didn't include any event-level signal at all. No drained-pool moment. No authority flip. No deployer dump. Thirty hours of slow attrition and then a pool nobody is in. From the outcome side, the buyer lost. From the rules side, no rule fired hard enough to call it.

What a slow bleed actually looks like

The shape on the outcome doc is consistent. At +1h, tradeable; liquidity slightly down (10-20%), volume light, holders flat. At +6h, liquidity slid further, volume fell sharply (no fresh buys), holders flat or slightly down. At +24h, liquidity materially below scan baseline but not yet under the abandoned floor, volume near zero, holders decayed; still tradeable on paper. At +7d, below $500, pool functionally dead, no event ever fired, label flips to abandoned.

It's slow because it has to be. The LP doesn't get drained in one transaction. No one panics out in one minute. No malicious code triggers. Death by attrition. By the time the resolver can call it, the pool has been bleeding for days.

The faster variant is a token that crosses the floor at +24h instead of +7d, usually a thin scan-time pool plus a small absolute volume sell that's enough to push it under. Same structural pattern, faster timing.

The "no signal" problem

Every rule on a scan card is a positive-evidence rule. It fires when something specific shows up. Authority is on. Mint authority returned. LP not locked. Bundler share above threshold. Deployer history dirty. Each rule asks a yes/no question of the on-chain state.

A slow-bleed token, at scan time, doesn't fire any of those to yes. Pool is fine. Contract is clean. Authorities null. Deployer history unremarkable. Bundler share low. Cap table reasonably distributed.

The token then dies anyway, because the market for it never developed and nobody held it long enough to keep the pool funded.

This is the absence-of-evidence problem. We don't have a rule that fires on "nothing is going to happen with this token," because that's not a state we can read from on-chain data at scan time. The information that would tell us the token is going to slow-bleed is information that doesn't exist yet: the volume that won't show up, the holders that won't appear, the attention that won't materialize. By the time those absences become visible, the bleed is in progress.

A rule engine isn't well-suited to absence detection. Rules are positive matchers. Detecting an absence requires either a different feature shape (continuous probability, not yes/no thresholds) or a different layer entirely. Neither is in the live scoring path yet.

What we have shadow-tested

A few rule shapes have been through the shadow-fire window looking for a way to catch this at scan time.

Thin-pool warning. Fire when scan-time liquidity is below a threshold (say $2,000). Result: too noisy. Plenty of tokens with thin scan-time pools attract real volume later. Hit-rate-above-base-rate too small to justify the fire rate. Retired in shadow.

Single-holder dominance. Fire when one wallet (excluding LP, burn, known CEX) holds more than 60% of float. Result: overlaps heavily with the existing top-holder concentration rule. Adding it was double-counting. Retired in favor of slightly raising the existing rule's weight.

Volume-to-liquidity ratio at scan. Fire when 1-hour volume at scan is low relative to pool depth. Result: useful at +6h, not at +24h. Correlates with the immediate next-hour outcome but picks up too much noise on the canonical horizon. Used internally for calibration adjustments, not a public rule.

Holder-count growth rate, post-scan. Fire when, between scan and +1h, holder count hasn't grown. Result: the closest we've come to a usable slow-bleed signal. The problem: it requires a second on-chain read after scan, which doesn't fit the scan-time rule shape. Considering it as a post-scan signal that updates the verdict at the +1h checkpoint, but that changes the contract (verdicts can shift after scan), so it isn't shipped yet.

The throughline of those failures: the things that would predict slow bleed are either too noisy at scan time, already caught by an existing rule, or only readable in a window after scan that doesn't fit the rule engine's current shape.

Why we don't over-claim

A simpler approach would be to call slow-bleed tokens "rugged" at +24h since from the buyer's seat the loss is the same. We chose not to. Two reasons, both about keeping the calibration math honest.

Mixing categories pollutes the rules' hit rates. If we labeled abandoned as rugged, every rule's apparent hit rate would jump, because rules that didn't fire on the slow-bleed tokens would suddenly be "missing" them. The calibration loop would respond by adding weight to rules that have no business catching slow bleeds, which would hurt their performance on actual contract failures.

It would hide the gap. Counting slow bleeds as rugged would let the headline accuracy look slightly better without us having done anything. The 2.1% would disappear into the rugged column. The cost of that story is that it would obscure the failure mode we most need to keep working on. The structural-failure line on the rug-anatomy breakdown is there specifically because we want it visible.

We'd rather take the 2.1% as a visible gap.

The dumped/abandoned/rugged corner cases

A few tokens land in awkward spots between the three downside labels.

• Dumped on a thin pool. Price collapsed 75%+ from scan, no event fired, pool still above $500 but thinning. Label: dumped. The classifier prefers the more informative label.
• Rugged on a slow burn. Deployer sells off the position slowly over 24 hours. No single transaction is the rug, but by the checkpoint the deployer holds less than 20% of their scan-time stack. Label: rugged. The deployer-sold-out rule fires even when the path was gradual.
• Abandoned that started as something else. Pool drained by a known-malicious authority flip, but vendor reads came back too noisy to confirm; the on-chain backstop shows the pool below the floor. Label: abandoned, conservatively. We don't claim a rug we can't prove cleanly.
• Slow bleed that resolves tradeable. Pool slid for days but recovered before +30d. Label: tradeable at +30d. Half the slow-bleed-looking tokens at +6h are tradeable at +30d. A rule that fires on the +6h shape would have a hit rate not much above the base rate. That's the noise floor we're working against.

What's on the backlog

Directions we have queued, with the real reason each isn't live.

Post-scan rescore at +1h. Holder-count-growth-rate is the closest usable signal. It's not live because of the UX contract: scan-at-t=0 wouldn't always match scan-at-t=1h if rescore fires. Working through whether to ship it as a "verdict updated" badge or as additional context only.

Continuous structural-failure probability. A regression that combines weak structural signals and produces a probability that the token resolves abandoned at +7d. The probability would feed the cope score as a graded contribution. Calibration-wise harder; the loop is built around per-rule updates and would need to expand.

Holder-attention proxy. Slow bleed is fundamentally an attention failure. Some attention signals are on-chain (scan-bot lookups, similar-token clustering), some are off-chain (telegram volume, social posts). We're not currently reading off-chain attention. Long horizon.

Similar-token reference. A k-nearest-neighbor layer using outcome history of structurally-similar past tokens as input. Worth doing, big project.

None of these are imminent. The point of listing them is that the gap is known, the directions are sketched, and the silence on the slow-bleed line isn't going to last forever.

How to read a scan that might slow-bleed

Knowing what we just walked through, here's how the read on a thin or quiet token should feel.

If the card is SAFU, cope score is low, no rules fired, and the structural breakdown shows a thin pool and low volume, you're in the slow-bleed-vulnerable zone. The verdict is correct on the structure (nothing malicious is happening) but the token has no momentum. The risks list won't tell you that; nothing fired. The structural breakdown will.

The cope score is silent on this because the score is a downside-event meter, not a momentum forecaster. SAFU on a token that has no buyers is structurally correct and operationally limited.

A few things that help in this zone:

• Read the structural breakdown, not just the verdict word. Pool depth, holder count, age, and volume are the four numbers most relevant to slow-bleed risk.
• Rescan after a few hours. The information you need (did holders grow, did volume pick up) only exists in time.
• If both the original scan and the rescan are thin, the slow bleed has begun. The pool may still be fine on paper. The market for it isn't there.

The scanner isn't going to make that call for you yet. Probably will, within a few rule versions.

Where this fits

When you find a gap in a model, there's a temptation to assume the rest of the model is also wrong in ways you haven't found. The 2.1% line isn't that. The other 97.9% file under categories the scanner does catch well, and the per-tier accuracy at +24h reflects it. Most rugs are made of evidence, and we read evidence well. Some failures are made of absences, and we're learning to read those, slowly. The 2.1% is the homework we haven't finished.

If we ever ship a layer that catches a meaningful chunk of this category, the rule-version bump will say so, the metrics page will reflect it, and the share on the rug-anatomy breakdown will move.

TL;DR

2.1% of resolved +24h downside outcomes are slow bleeds, abandoned pools, structural failures with no fingerprint at scan. The rule engine catches them worst because rules are positive-evidence matchers and slow bleed is an absence pattern. We've shadow-tested four candidate rules; one is held for UX reasons, the others were retired or rolled into existing weights. The classifier keeps abandoned distinct from rugged so the calibration math stays clean and the gap stays visible. The structural breakdown on a scan card is where slow-bleed-vulnerable tokens reveal themselves; the verdict word doesn't yet.

Scan a structurally thin token at doomer.wtf and read the breakdown, not the verdict. That's where the slow-bleed-vulnerable signal lives today.