---
name: pullback-comeback
description: The "Pullback & Comeback" study and scanner Ben commissioned 5 Sep 2026 - what separates a dumped low cap that starts the real run from one that dies. v2, rebuilt on true intraday highs after Ben caught the close-price bug. Read before any question about buying a dip, a token 60-90% off its ATH, "is this a bottom", accumulation vs distribution, or before touching the pullback scanner.
sources: [cowork]
aliases: [pullback, comeback, dip-buy, post-dump, bottom-pattern, pullback-scanner]
---

# Pullback & Comeback — the post-dump study (v2)

- [stated] Ben, 5 Sep 2026, the ask: coins get bundled, run up easily because few wallets hold supply, the insiders dump at the top, the token falls 60-70%, and sometimes the REAL run starts after that. He wanted the pattern identified: what happens at the bottom of the ones that run big, versus the ones that go flat forever or die. Then a tool to find them.
- He supplied three RH-chain examples: CASHCAT/WETH -77% then 4.6x, AI/NVDA -75% then 23x, PONS/WETH -62% then 8.2x.

## ⚠ THE BUG BEN CAUGHT, and the rule it produces
- [stated] Ben, on the v1 list: "you're giving me, on second position, WATCH at 45k market cap, but it's lower than you're saying. It's over 70% off the highs, and it dumped around 80% from the highs originally. You need to check your numbers very well."
- **He was right. v1 took the all-time high from daily CLOSING prices instead of intraday highs.** WATCH 0xca70d457418b90493e5735de6ec4410c3945498e: close-ATH $0.00014007 vs true high $0.00028574 (21 Jul). Reported -63%; truth **-83%**. It ranked #2; it belongs around #25-30.
- **Systematic, not a one-off: median understatement 6.9 drawdown points, and >10 points on 176 of 428 tokens.**
- **STANDING RULE, applies to every screen and every tool: a drawdown, an ATH, a "% off the high" or a runup is computed from INTRADAY HIGHS and LOWS, never from closes.** Outcomes stay on closes (conservative: a wick you could not have sold into is not a win). Any series built as `[ts, close, close, close, close, vol]` is a bug waiting to happen.
- Second, smaller point he was right about: the market cap I printed was a snapshot hours old. **Live cap and live 24h change now come from DexScreener at render time; everything computed goes on complete days only.**

## Dataset — built TWICE, on purpose
- Universe: CoinGecko `platforms.robinhood` with n_chains==1 -> DexScreener for the deepest pair. **Tokenised stocks removed by DEPLOYER, not by ticker guessing: `0x4783c67b63de2b358ac5951a7d41f47a38f3c046` issued all 192 of them** (AAPL, AMZN, AMC, LULU, VTI...). Without that filter they flood the top of the ranking.
- **Source A, pool candles:** GeckoTerminal daily OHLCV (real O/H/L/C). ~70 min for 623 tokens from the container; the droplet gets instant 429s and cannot use GT at all.
- **Source B, chain-wide trades:** Dune `dex.trades` where blockchain='robinhood' (254M trades since 22 May 2026). close = `max_by(px, block_time)`, **high = `approx_percentile(px, 0.98)`, low = `approx_percentile(px, 0.02)`** (percentiles not min/max, so one fat-fingered trade cannot invent a high), volume = `sum(amount_usd)`. **7 SECONDS for all 622 tokens' full history at `medium`.** Drawdown-on-highs vs GT: median error -0.005.
  - **Filter required: drop days with `trades < 3` or `vol < $50`.** Without it, dust-trade days fabricate fake peaks and a completely inverted result (the bottom quartile "beat" the top).
- **Wallet arrivals from `erc20_robinhood.evt_Transfer`:** per token per day, first-ever receivers ("arrivals"), unique receivers, unique senders. Historical holder velocity; nothing else in the stack has it. Dune queries **8613248** (prices + deployers), **8613013** (arrivals).
- Episode = ran >=2x from launch, then closed >=60% below its own TRUE HIGH; decision point 5 days later; forward window measured after that. **706 episodes (GT) / 654 (Dune)** — more than double v1, because true highs catch the dumps closes hid.

## BASE RATES after a 60%+ dump (n=706 / 654)
| outcome | GT | Dune |
|---|---|---|
| ever 3x from the bottom | 27.2% | 30.1% |
| ever 10x from the bottom | 9.8% | 10.9% |
| **ever makes a NEW all-time high** | **13.9%** | **14.8%** |
| ends the window below 0.7x | 39.2% | 37.0% |
- Median days from the low to the high, for the ones that 3x: **21-24 days.**
- **The typical dumped coin sits at -80%, not -70%.** v1 said -70%; that was the bug. Ben's standing "60-70% off ATH is the reaccumulation zone" rule needs this correction: measured properly, the normal post-dump resting place on this chain is about -80%.
- "New ATH" fell from 19.6% (v1) to 13.9% — the true high is higher and harder to beat.

## WHAT SEPARATES THEM — v2, both sources
Medians at the base, RUN (2.5x+ in 10d on closes) vs DEAD (<1.5x). GT first, Dune second.

| at the bottom | came back | died |
|---|---|---|
| **size of the first pump** | **3.2x / 3.7x** | **4.8x / 5.3x** |
| volume late base / early base | 0.59 / 0.60 | 0.47 / 0.49 |
| arrivals late base / early base | 0.63 / 0.66 | 0.52 / 0.53 |
| unique receivers / senders | 1.070 / 1.064 | 1.013 / 1.027 |
| price / base low | 1.42 / 1.38 | 1.27 / 1.32 |
| day's volume / market cap | 0.207 / 0.207 | 0.175 / 0.185 |
| fall from the TRUE high | -78% / -78% | -82% / -83% |
| new wallets per $100k | 31 / 34 | 38 / 37 (inverts) |
| market cap at the bottom | $96k / $74k | $51k / $60k |

### The findings, v2
1. **THE SIZE OF THE FIRST PUMP IS THE STRONGEST SINGLE TELL, and the only feature that works alone on both sources** (1.20x lift by itself, GT and Dune). 3.2-3.7x comes back, 4.8-5.3x does not. Mechanism: the more violent and artificial the run, the more trapped supply above.
2. **THE TREND, NOT THE LEVEL.** Volume and arrivals versus earlier in the same base still separate, on both sources, but weaker than v1 claimed (0.59 vs 0.47, not 0.68 vs 0.44).
3. **RETRACTED: "deeper is worse".** v1's headline -69% vs -79% was almost entirely the close-price bug. On true highs it is **-78% vs -82%**, a 4-point gap that is not a decision. Adding drawdown to a feature set no longer helps.
4. **SIZE IS NOT A SIGNAL.** Market cap at the bottom, Spearman vs score ~0.00. Confirms Ben's standing no-size-exclusion rule.
5. **RETRACTED: "turnover is the whole game"** (my first pass, GT-only). It survives as a minor supporting input at 0.207 vs 0.175-0.185, nothing like a headline.
6. **Raw arrivals-per-mcap reverses sign between sources. Not usable.** Only the arrivals TREND is.

## THE SCORE (set C) and what it is honestly worth
- Six inputs, percentile-ranked against the 706 bases: turnover (+), arrivals per $100k (+), price off the low (+), drawdown (-), arrivals trend (+), volume trend (+). Chosen because it was the only set that held its lift on BOTH sources.
- **Walk-forward** (5 time blocks, rank within each unseen block, top quarter): **21.2% vs a 14.9% base (GT), 21.8% vs 17.0% (Dune). Lift ~1.3-1.4x, 90% CI on the 21% is 15-27%, which touches the base rate at the low end.**
- AUC for the 2.5x event **0.613 (GT) / 0.564 (Dune)**. Bands: TOP 23.9% / BOTTOM 6.7% (GT), TOP 23.3% / BOTTOM 10.9% (Dune).
- **FIXING THE BUG CUT THE MEASURED EDGE FROM ~1.8x TO ~1.3x.** Say that plainly whenever the tool is discussed. The edge is real on both sources and it is modest.
- The avoid list is still the stronger half. The score buys tail probability, not a better average: median forward return is ~1.2-1.3x in every band.
- Honest weaknesses: chain ~70 days old, whole window a rising tape, and the study reads price, volume and arrivals only — not WHO the wallets are. Bundle detection and insider-exit checks ([[rugscan]], [[onchain-forensics]]) stay a separate layer on top.

## DELIVERED
- Artifact **"Pullback & Comeback"** (same URL, republished as v2), carrying an explicit "Corrected 5 Sep" box naming the bug and both retracted findings. Matched pair on the page: **PRISM (-81%, first pump 3.5x, volume trend 1.19) -> +20.2x** vs **SUIT (-73%, first pump 33.9x, volume trend 0.32) -> 0.31x**. SUIT fell LESS and still died, which is the whole v2 point. Live list has both the current cap and the cap at the top, so the round trip is visible.
- **Droplet `/opt/pullback/pullback.py` on kookwatch (159.223.88.168), cron `0 22 * * *` UTC (05:00 Bangkok), Telegram via the coinbench bot** (config key is `bot_token`, not `token`). Dune-only, no GeckoTerminal. Patched to v2 by `/opt/pullback/patch_v2.py` (idempotent-ish, backs up to `pullback.py.bak-v1-*`, self-verifies 7 assertions then prints SYNTAX OK). Alert now prints "$X now, was $Y at the top - N% off its true high".
- Verified v2 run: **zone 189, top band 47**, full pipeline 2 minutes. WATCH moved from **rank 2 (-63%) to rank 25 (-81%, cap at the top $238,884)**.

## v3, THE TAIL — Ben: "go back to the top performers, the coins that pulled back and then rocketed off, narrow down on exactly those types"
Sample: 437 bases (GT) / 305 (Dune) with a full 30-day forward window. **34 / 29 went 10x or better. 65 / 59 went 5x+.**

### THE HEADLINE, and it beats everything else in the study: ROCKETS REPEAT
- **A coin that has ALREADY pulled back and rocketed 5x+ once has a 41.2% chance of a 10x on its NEXT dump, against 5.0% for coins that never have. Lift 5.3x.** Dune independently: 32.4% vs 6.6%, lift 3.4x.
- **Strictly causal** — only rockets that had already resolved before that dump are counted.
- Repeat offenders in the data: NET x4, COCO x3, PONGO x3, LEMON x3, worth x3, MEOWOOD x3, AI x3, CNPY x2, HMM x2, AUREON x2, OUTLAW x2, UP x2, FIRE x2, 0xZAPS x2, wire x2, ROBINHOOD x2, CATSTR x2, RAXOL x2, BACKED x2, POOCH x2, robn x2, DOW x2.
- **54 RH coins have done it at least once; 39 of them were in a fresh pullback on 5 Sep.** Full list with addresses is in `/opt/pullback/pullback.py` as `PRIOR_ROCKETS` and on the artifact.

### THE SECOND-STRONGEST THING, and it is a MANAGEMENT rule not a selection rule
**You cannot pick the 10x at the base.** Every scoring set tested against the 10x label failed walk-forward (lifts 0.75x to 1.4x, inconsistent between sources). What works is the day-5 check.
| where it stands 5 days after the base | n | P(10x) GT / Dune |
|---|---|---|
| below your entry (**71% of them**) | 313 | 3.5% / 5.3% |
| up 0-50% | 77 | 9.1% / 5.7% |
| up 50-150% | 31 | **25.8% / 23.1%** |
| already >2.5x | 16 | **50% / 50%** |
- Keeping only what is at or above entry on day 5 holds **28% of the book and captures 68% of the 10x**, lifting P(10x) from 7.8% to 18.5%.
- **COMBINED, repeat-rocket AND up at day 5: P(10x) = 54.5% (GT, n=22) / 53.3% (Dune, n=15), median outcome 17.3x / 13.3x.** Small n, wide bars, but two independent sources land on the same number.

### HOW MUCH PAIN IS NORMAL (max dip below entry over 30 days) — a real stop rule
| outcome | median dip | worst quartile | ever below -50% |
|---|---|---|---|
| became a 10x | **-22%** | -43% | 18% |
| became 5-10x | -32% | -46% | 16% |
| became 2.5-5x | -40% | -57% | 33% |
| went nowhere | **-65%** | -79% | 69% |
- More than 45% below entry in the first five days -> **4% chance of a 10x**. Never breaks 15% down -> 16%.
- **Median 28 days from the base to the top for a 10x, against 4 days for the duds.** It is a month-long hold on a shallow leash, not a day trade.
- **93-94% of 10x moonshots made a NEW all-time high inside 30 days**, against 2-5% of everything else. The rocket IS the new-ATH event.

### What the moonshots did NOT have
- No size pattern: caps at the base ran $3,245 (CNPY) to $14.4M (PONS).
- **"It was its first dump" is NOT a signal** — 53% of moonshots vs 47% of duds. My first eyeball of the medians said otherwise; the proper split killed it.
- For the >=5x label the only source-agreeing features are shallower drawdown (AUC 0.408/0.405 inverse), a SMALLER peak market cap (0.440/0.414 inverse), a smaller first pump (0.451/0.456 inverse) and volume trend (0.578/0.552). All weak.
- Biggest single episode measured: **CNPY 0x532c5583671870723ceef573600208af49c87c54, 721.6x from a $3,245 base to $2.34M in 23 days.**

### Shipped for v3
- Artifact gained three sections: the funnel (7.8% -> 18.5% -> 41.2% -> 54.5%), the day-5 and pain tables, the 54-coin repeat watchlist with a copy button for the 39 currently in a pullback, and all 34 moonshots named with full addresses.
- Droplet patched by `/opt/pullback/patch_v3.py`: `PRIOR_ROCKETS` table of the 54 contracts baked in, every row of `latest.json` tagged with `prior_times` / `prior_best`, and the Telegram alert now LEADS with "REPEAT ROCKETS IN A PULLBACK" before the score list, then closes with the day-5 rule.

## v4, THE LAUNCH STUDY — Ben: "any patterns for what does well right at launch? what filters make sense if I buy in the first hour?"
Different question, so a **different and far better dataset: every token launch on the chain**, not the CoinGecko-listed survivors. Built from `dex.trades` alone: t0 = a token's first trade, hour-1 window = [t0, t0+60min], outcome = `approx_percentile(px,0.98)` over (t0+1h, t0+30d] divided by the price at the 60-minute mark. Restricted to tokens with >=30 lifetime trades and t0 at least 30 days before the data end, so every row has a full window. **n = 127,711 launches.** No survivorship bias, which is why this is the strongest dataset in the whole project.
- Query lives on Dune 8613248. Deployer for all 607,899 traded contracts pulled by joining `robinhood.creation_traces`; results cached at `/root/pb/dep_all.json`, launches at `/root/pb/launch_clean.json`.
- **A token that never traded again after hour 1 is scored 0x, not dropped.** Dropping them inflates every base rate; 45% of all launches are in that bucket.

### BUYING BLIND AT THE 60-MINUTE MARK
| outcome | share |
|---|---|
| never trades again | **45.2%** |
| ever 2x | 9.35% |
| ever 10x | 2.75% |
| ever 50x | 0.79% |
| **median outcome** | **0.97x** |

### THE FILTERS, STACKED (each row adds to the one above)
| filter | launches | dead | 2x | 10x | 50x | median |
|---|---|---|---|---|---|---|
| buy anything, blind | 127,711 | 45% | 9.4% | 2.75% | 0.79% | 0.97x |
| skip the dead factories (13 live pads) | 74,248 | 21% | 12.2% | 3.52% | 0.73% | 1.01x |
| only the 7 GOOD pads | 18,933 | 24% | 27.5% | 6.13% | 1.20% | 1.10x |
| + still green at the 60-minute mark | 5,252 | **5%** | 37.2% | **10.07%** | 2.65% | 1.44x |
| + under $2k traded in that hour | 1,580 | 8% | 40.3% | **12.97%** | 3.80% | 1.57x |
- **Out of sample (launches after 24 Jul only): good pad + green = 5.68% vs a 2.51% base, lift 2.3x, n=950.** Holds.

### THE BIG ONE: WHO DEPLOYED IT
Deployer is the single strongest filter at launch, far stronger than any hour-1 trading metric.
- **GOOD pads (copy these):** `0x43e4c17b15365596caae8e7d00e42bc8e988c2d4` (139 launches, 1% dead, **19.4% 10x**, 7.1x lift; BOWYER, KAIRUNE, STAR, BLEP, FLETCHER, HOODAGENT, EBESS) · `0x26605f322f7ff986f381bb9a6e3f5dab0beaeb09` (255, 8.6%; DMND, PRISM, MEMESTOCK, AUREON) · `0xd9ec2db5f3d1b236843925949fe5bd8a3836fccb` (16,502, 6.2%; COCO, KITSU, RANGER, NAVEN, FLOW, VLAD) · `0x104f1ab42674565ec3df0bfebccc4186f72fa7ed` (130, 5.4%) · `0xc9182c283a9b739fed26a8e7f55a4d2b09f39d8c` (98, 5.1%; SUSHICAT) · `0x5bd1fbe78a78fe8236fa00cf48fbeba74ae34661` (446, 4.7%; CATSTR, 9TO5) · `0x000000e200088d55c39a11f609e5f667729ad49b` (1,363, 4.4%; RH, 222, UNICORN, PROLOGUE, ABE).
- **DEAD FACTORIES, never buy:** `0xc41194138e051fc505fef93b3c44dbdb63da64a2` (9,555 launches, **100% dead**, 0.01% 10x) · `0xf193ede778a92dc37cb450a1ef1565ed1e8b7964` (21,484, 95% dead) · `0x48190f1560e60cac0107f2fe9625daf85b058c4c` (1,110, 100% dead) · `0xf2dc25b8a5231667d8cf0ecd476fb46805186572` (1,147, 0% ever 2x) · `0x3194e32622c5d860a0572c74edda99dcfd8fc827` (155, 98% dead). These ~33k tokens were poisoning every earlier cut and produced U-shaped nonsense until they were removed.
- **The average pad `0xa5aab3f0c6eeadf30ef1d3eb997108e976351feb`** is the volume leader (50,649 launches) and sits exactly at the base rate (2.72% 10x). PONGO, WATCH, IMAGINE, FAMILY, TYGR came from it.
- **CAUTION, and it belongs in any retelling: the Doppler pad `0x1b37d3a72082029c44b35b604ea473617580b69a` made AI, the chain's biggest coin, and scores 2.11% 10x, BELOW average.** One enormous winner does not make a pad a good place to buy blind. And the best pad has only 139 launches, so 19.4% is a small sample.

### HOUR-1 TRADING METRICS, what they are worth
- **"Still at or above the first trade price at 60 minutes" is the only price/flow feature that carries weight, and ONLY in combination.** On its own across all launches it scores 2.3% against a 2.8% base with 64% dead. With the pad filter first it takes 6.1% -> 10.1% and cuts dead from 24% to 5%.
- **Quiet is better than busy.** Within good pads, hour-1 volume under ~$2k does best (13.0% 10x). The busy middle deciles are the worst. Reading: you are paying for being early, not for confirmation.
- **Trades per wallet <= 2** (real people buying once, not a bot cycling) = 2.0x lift on the clean set.
- **Top-buyer concentration is U-shaped and NOT usable as a simple filter**: both very dispersed (<5% top buyer, 1.3x) and very concentrated (>69%, 2.8x) beat the middle. Do not turn it into a rule without understanding which case is which.
- Buys/sells ratio, average trade size and unique-buyer count are all weak or non-monotone once the pad filter is applied.

### Shipped for v4
- Artifact gained a "buying in the first hour" section: the blind base rates, the stacked-filter table, and the full 25-row deployer table with GOOD/DEAD chips, example tickers and a copy button for the seven good deployer addresses.
- **NOT built yet, the obvious next step:** a live launch watcher that fires when a new token from a GOOD deployer is still green at 60 minutes. That is a real-time service, not a nightly cron, so it was left as a decision for Ben rather than started silently.

## v5, THE LAUNCH MODEL REBUILT — Ben: "recheck everything, I don't quite understand quiet beats busy, and I don't pay attention to launchpads, so tell me the filters"
All Robinhood Chain. 127,711 launches with a full 30-day window, from the chain's trade log.

### HIS QUESTION ANSWERED: "quiet beats busy" means total dollars traded in the WHOLE first hour, and yes, under $1,000
Within the building + not-run-up cohort, split by hour-1 volume:
| traded in hour one | n | 2x | 10x | median | median biggest later trade |
|---|---|---|---|---|---|
| **under $1k** | 1,163 | **33.7%** | **12.9%** | 1.32x | **$129** |
| $1k-5k | 1,358 | 18.8% | 5.0% | 1.09x | $100 |
| $5k-20k | 1,241 | 17.6% | 4.3% | 1.08x | $93 |
| $20k-100k | 1,456 | 12.9% | 3.2% | 1.02x | $19 |
| over $100k | 790 | 13.0% | 6.5% | 1.01x | $3 |
- Not a selection artifact: 9.6% of the quiet bucket is "building" vs 10.2% of the busy one. Independent of accel: under $1k AND building = 13.8% P(10x) vs over $1k AND building = 5.7%.
- **The mechanism is that you are buying before discovery, so you are not paying for it.** The busiest launches have a $3 median later trade because they are already over when the hour ends.
- **Exit fact, stated as information and NOT as a downrank** (his no-size-exclusion rule stands): the quiet winners' median biggest single trade in the following month is $129. A $100-300 ticket clears comfortably. Requiring "could have sold $500 in one trade" only moves the quiet bucket from 19.9% to 18.2%, so the winners are real, not paper.

### THE STRONGEST LAUNCH FEATURE: IS THE VOLUME STILL BUILDING
`accel` = hour-1 volume / first-15-minutes volume. Because v60 contains v15, accel==1 means nothing traded after minute 15.
| minutes 15-60 vs first 15 | n | dead | 2x | 10x |
|---|---|---|---|---|
| nothing after minute 15 | 89,681 | 56% | 6.0% | 2.06% |
| a trickle, +0-15% | 17,367 | 20% | 11.4% | 2.66% |
| +15-60% | 7,770 | 26% | 16.6% | 4.77% |
| +60-200% | 6,985 | 23% | 19.6% | 5.40% |
| **more than 3x** | 5,908 | 8% | **32.5%** | **7.85%** |
- **70% of all launches do nothing after minute 15.** That single split is the graveyard.

### DEPLOYER, AS A LIVE NUMBER INSTEAD OF A NAME LIST (he does not track launchpads)
Causal: only the deployer's launches that had already FINISHED 30 days before this one started.
| deployer's record so far | n | dead | 2x | 10x |
|---|---|---|---|---|
| **0% (>=5 finished, no winner)** | 5,564 | 68% | 2.0% | **0.59%** |
| under 0.5% | 34,737 | 92% | 0.5% | 0.12% |
| 0.5-3% | 48,898 | 21% | 6.1% | 2.55% |
| 3-8% | 17,397 | 23% | 16.3% | 3.54% |
| **over 8%** | 10,168 | 18% | **33.8%** | **7.84%** |
| brand new, <5 launches | 16,511 | 59% | 15.3% | 4.93% |
- A brand-new deployer beats a mediocre one. Only the proven-dead bucket is a hard skip.

### THE FOUR CHECKS, at the 60-minute mark
1. deployer not proven-dead (>2% prior rate, or brand new) · 2. accel >= 1.6 · 3. not already up 2x in the hour · 4. under $2,000 traded in the hour.
| filter | passes | dead | 2x | 10x | median |
|---|---|---|---|---|---|
| blind | 127,711 | 45% | 9.4% | 2.75% | 0.97x |
| +1 | 64,711 | 30% | 15.7% | 4.53% | 1.01x |
| +2 | 9,866 | 19% | 28.2% | 7.66% | 1.21x |
| +3 | 3,990 | 13% | 24.2% | 8.27% | 1.15x |
| **+4 (under $2k)** | ~1,200 | - | **36.8%** | **13.7%** | **1.38x** |
- Rate: about 21 a day pass all four.
- **OUT OF TIME, be honest: the double rate holds (23.9% vs a 5.8% base on one split, 23.0% vs 5.3% on another, ~4x). The 10x lift does NOT hold well: 1.4x to 3.3x depending on the split. Call it a filter for doubles that sometimes catches a 10x.** The in-sample 4.7x was overfit by choosing the >8% deployer threshold on the same data.

### ENTRY TIMING
| entry | 2x | 10x | median |
|---|---|---|---|
| at the very first trade | 12.4% | 5.44% | **0.35x** (you eat the dump) |
| **at 15 minutes** | 17.5% | **5.34%** | 0.79x |
| at 60 minutes | 9.4% | 2.75% | 0.97x |
- 15 minutes has roughly double the 10x rate of the 60-minute entry, but the build signal does not exist yet at minute 15. Genuine trade-off, not a free lunch.

### ⚠ STANDING DATA FACT, cost a whole build: DUNE `dex.trades` ON ROBINHOOD CHAIN LAGS ~7 HOURS
- Measured 5 Sep: latest trade 03:02 UTC while wall clock was 10:39 UTC. `erc20_robinhood.evt_Transfer` is similar.
- **Dune can never drive a real-time or same-hour tool on this chain.** It is perfect for backtests and for daily scorecards; useless for anything that must act within the hour.
- Real-time alternatives, both verified working FROM THE DROPLET on 5 Sep (GeckoTerminal's earlier 429 ban had lifted): **`api.geckoterminal.com/api/v2/networks/robinhood/new_pools`** (returns pools created seconds ago; ~9 new pools per MINUTE on this chain) and **`robinhoodchain.blockscout.com/api?module=contract&action=getcontractcreation`** (returns both `contractCreator`, the EOA, and `contractFactory` — **the factory is what Dune's `creation_traces."from"` reports, so key the deployer scorecard on the factory**).
- new_pools shows only ~20 per page, so at 9 pools/min two pages cover ~4 minutes. A watcher that wants to score at 60 minutes MUST keep its own rolling registry rather than expect the pool to still be listed.

### SHIPPED: /opt/launchwatch on kookwatch
- **`launchwatch.py`, cron `*/3 * * * *` under `flock`.** Collects new pools into `registry.json` each run, scores each one when it crosses 60 minutes using GT minute candles (v15, v60, price move) plus the Blockscout factory, applies the four checks, and Telegrams via the coinbench bot. Verified collecting: 118 pools tracked within 6 minutes of install. The first scored alerts can only appear ~60 minutes after the registry starts filling.
- **`deptab.py`, cron `0 3 * * *`.** Rebuilds `dep_table.json` from Dune (the 7h lag is irrelevant for a daily scorecard): every deployer with >=5 finished launches and its 10x rate. First run wrote **199 deployers, 70 good (>=5%), 112 dead (<=2%)**. Refuses to overwrite with fewer than 50 rows. This replaces the hand-kept pad list and cannot go stale.
- Uses Dune query 8613013 for deptab and 8613248 for anything else, deliberately different scratch queries so the two never race.

## METHOD NOTES for the next run
- **Check the freshness of a data source before designing anything live on it.** `select max(block_time), date_diff('hour', max(block_time), now())` is one query and it would have saved a whole build here.
- **Tops and bottoms from intraday highs/lows. Outcomes from closes.** The single most expensive lesson of this build.
- **Patch scripts must use exact-string replacement, never index arithmetic on the source.** A `s.index(...) + 60` slice left a dangling `= []` and broke the file; the backup saved it. Always `assert OLD in s` then `s.replace(OLD, NEW)`.
- **Build the universe from the chain's own trade log, not from a listing site, whenever the question is about launches or failure rates.** CoinGecko's 623 RH tokens are the survivors; the chain has 127,711 launches with a full 30-day history. Every base rate computed on the listed set is optimistic by a wide margin.
- **A U-shaped relationship in a decile table is almost always contamination, not a real effect.** Here it was ~33k tokens from dead factories. Segment by deployer first, then look at the features.
- **A tail question is a different question.** What predicts a 2.5x bounce (first pump size, volume trend) is NOT what predicts a 10x. Always re-fit for the threshold being asked about, and expect selection to fail at the tail: with 34 winners there is not enough signal, and the edge has to come from post-entry management instead.
- **`PRIOR_ROCKETS` is a static table and will go stale.** Regenerate it whenever the study is re-run: any contract with an episode whose 30-day forward max was >=5x, on either data source.
- **Never score the current (partial) UTC day.** The last daily bar is incomplete and understated turnover by 5-10x on the first pass.
- Data-integrity floors only (mcap >= $8k, liq >= $2k, day volume >= $500, drawdown <= 98%). NOT size filters and must never become one. The cap moved 96% -> 98% because true-high drawdowns are deeper.
- Multi-episode detection matters: a token can dump twice. First-episode-only missed CASHCAT's real comeback and cost ~30% of the sample.
- Require 0.35 <= dd <= 0.98 or multi-episode leg artifacts (dd < 0) pollute every median.
- **Ops trap: `pkill -f 'pullback[.]py'` over ssh kills the ssh session** whenever the same remote command line also contains the plain string `pullback.py` (an `md5sum`, a `cd`, anything). Exit 255, no output. Send the pkill as its OWN ssh call with nothing else in it.
- **Patching a droplet script: write the patch as a python file with a self-verification block at the end** (assert each replacement landed, `ast.parse` the result, print OK/FAIL per check). Blind `sed` over ssh gives no evidence the edit matched.

## v6, 6 Sep 2026 — THE PONS BASE CASE, MEASURED. Ben's usage-divergence hypothesis is wrong; replace it with the routed-cash test.
Full board and per-name detail in [[rh-infra-bottom-screen]].
- [stated] Ben's recollection: "PONS pulled back while its usage numbers did well, and insiders weren't selling anymore at the bottom."
- **The insider half is right. The usage half is not.** Pons V1+V2 daily revenue FELL through the base: ~$145,832 (10 Aug) to **$54,986 on 20 Aug, the month's low**, while the price sat flat at -30% to -50%. Revenue and price rose together from 23-24 Aug. Usage was coincident, never leading.
- **WHAT WAS ACTUALLY TRUE AT THE BASE, and it is the transferable test: 5 Aug low $0.015145, mcap $12,224,774, revenue $93,228/day = $34.03M/yr = 278% OF MARKET CAP PER YEAR, 80% of it doc-claimed to buy and burn the token.** Then 19.7x.
- **NEW SCREEN CRITERION, added on top of the v2/v3 features: ANNUALISED PROTOCOL REVENUE AS A SHARE OF MARKET CAP, with the route verified on chain.** Three states: to holders (burn or fee-share readable in Transfer logs), to lockers only (ve(3,3) — circulating holders get nothing), or nowhere (fee recipient is a bare EOA). A big multiple with no route is not a cheap token, it is somebody else's business.
- **Verify the route by counting burns and mints from Transfer events to and from 0x0 and 0xdead over 7 and 14 days, and by `eth_getCode` on the fee recipient.** Worked receipts, same day: HKRS burned 4,848,070 (0.485% of supply) in 23 events, all sourced from the Uniswap v4 PoolManager = a real buy-and-burn. DELTA burned 53 tokens in 2 dust events on a $11.6M cap = no route, despite a real 1% take and $1,989,012 of TVL.
- **The seller test as run: first-hour receivers plus one hop, filtered by `eth_getCode` (drop contracts, KEEP 7702), sells counted only into listed pools, holdings from live `balanceOf`.** Skipping the getCode filter reported DELTA's cohort as 62.5%-of-supply sellers when the true figure is 0.000%.
- **"Frozen" is not "exhausted".** HKRS sold 0.000% in 7d but still holds 16.72% of supply; DELTA sold 0.000% and holds 0.19%. Only the second one is finished. Record both numbers, never just the sold column.
- **Drop the last row of any DefiLlama daily revenue series before averaging — it is a rolling 24h window, not a complete day.** Same class of error as scoring the partial UTC OHLCV day, and on 6 Sep it made SLVR look 0.15% from a falsifier ($40,060/day) when the last three complete days average $68,974.

## v7, 10 Sep 2026 — "HOLDERS MUST ALWAYS RISE" IS NOT A KO. Measured on three real moonshots.
- [stated] Ben: "There seems to be the thesis that the holders need to always increase. If they're not increasing, then we need to get out. Is that really the case? ... Do the holders during that time always increase, or is there also stagnation, reduction, people giving up, and then the coin still moves? I want to make sure we're not looking for the wrong thing as a KO criterion."
- Method (Dune still 402 out of quota, so RPC): every Transfer log per token, daily net balances, holders = addresses with balance > 0 at end of each UTC day, price from GeckoTerminal daily candles. Script /home/claude/rh/holders/hseries.py, series in MOO.json, PRISM.json, CNPY.json.
| coin | holders at the top | base low | what holders did in the base | run from the base |
|---|---|---|---|---|
| MOO `0xD9dB30BB0D2b8d2eae3826A1372117E058791e18` | 778 (22 Jul) | 353 (2 Aug), **-55%** | 28 days: 17 down days, 10 up; flat 350-390 for two weeks, crept to 481, slipped back to 456 on 18 Aug; run started 20 Aug from **461** | ~50x to 1 Sep, ~265x to 10 Sep (7,901 holders) |
| PRISM `0x20024e485c0b22b42855589700721b28320a7777` | 419 (4 Aug) | 344 (5 Aug), **-18%** | 15 days: 4 down, 10 up; crept 372 -> 556 while price fell another 60% | 20x from 19 Aug |
| CNPY `0x532c5583671870723ceef573600208af49c87c54` | 153 (15 Jul) | **61 (6 Aug), -60%** | three weeks of holders LEAVING, volume $1 to $100 a day, price -97%; every KO would have fired | 721x from 8 Aug to 26 Aug |
- **Answer: no. Holder count FALLS in the base of real comebacks (MOO -55%, CNPY -60%) and the run starts from a flat or slightly rising count, not from a rising trend. "Holders always increase" would have kicked you out of MOO three separate times and out of CNPY at the exact low.** Consistent with v2, where even the winners' arrivals in the late base were 0.63x their early-base level (losers 0.52x): arrivals decline for everyone in a base, winners decline less.
- **Mechanism, first principles:** a base is supply moving from tired hands to patient hands. Full exits shrink the holder count; the absorbers are fewer, larger wallets. That consolidation is the setup, and it reads as "holders falling". The moonshot shows up as holders rising ON the breakout (MOO 461 -> 653 -> 5,063), which is confirmation, not prediction.
- **STANDING CHANGE to every screen and falsifier: holder decline is NOT a screen-out at the base. Move holders to post-entry management:** (1) day-5 check, price at or above entry (v3: 28% of the book, 68% of the 10x); (2) holders rising AFTER entry is confirmation to hold or add; (3) a holder KO fires only when holders fall AND price makes a lower low AND you are more than 45% under entry (v3: 4% P(10x)); all three, never one. The pre-entry KOs that survive: first pump above ~4.8x, proven-dead deployer, insiders still selling into pools ([[onchain-forensics]] ledger).
- What holder data IS good for at the base: who is leaving (insiders vs retail) and who is absorbing (few large or many small), which is the [[rugscan]] / seller-ledger layer, not the count.

## RETIRED 13 Sep 2026 — the scanner is gone, the study stands
- [stated] Ben: **"Yes, you can delete the whole pull back and come back process entirely."** Said after clarifying that the "runup Telegram alert" he wanted removed was the OLD one, replaced by the new runwatch buy-zone alert plus the xdeck multi-chart runners boards.
- **What was deleted:** `/opt/pullback` in full (pullback.py, patch_v2/v3/v3b, latest.json, ref.json, dune.json, prev_top.json, run.log) and the **crontab line `0 22 * * *`**, which was the only thing actually running it. There was never a systemd unit, which is why it always read as "inactive".
- Archive `/opt/_removed/pullback-20260913-113425.tar.gz`, crontab backup `/root/crontab.bak-20260913-113425`, script `/root/rm_pullback.sh`. Nothing in the watchdog or the botctl registry referenced it, so those were no-ops.
- **The RESEARCH in this file is not retired.** The base rates, the repeat-rocket finding (41.2% P(10x) on a prior 5x rocket), the day-5 management rule, the pain table, the launch study and the deployer scorecard all stand and are still the reference for any dip-buy question. Only the nightly Telegram card is gone.
- `/opt/launchwatch` (the launch watcher, cron `*/3`) and `deptab.py` (cron `0 3`) were **NOT** touched. They are a different tool from the v4/v5 launch study and still run.
- One dangling reference left on purpose: `/opt/rugscan/patch_fleet.py` names `/opt/pullback/pullback.py`. It is a one-off patch script that already ran, not a service and not in cron, same class as `/opt/setup_ansem_rh.py`.
- **THE MISS THAT PRECEDED THIS, worth carrying: `runwatch` was deleted first by mistake** because "the runup alert" name-matched `/opt/runwatch`. Ben's clarification contained the disqualifier in one clause ("that one was older"), and runwatch had been built the same morning. Restored from its archive inside three minutes. Full account in [[alert-bot-fleet-7]].
- **And the reason pullback was hard to find: `systemctl is-active` says nothing about it.** Eight bots on that droplet run from crontab, not systemd. Any "what is running" sweep must read `crontab -l` too.

## 27 Sep 2026, the bottomed-alt framework ask
- [stated] Ben wants a framework to spot bottomed-out alts before the big run: coins that ran to roughly $2M to $20M, fell 70 to 90%, and now sit at $500k to $2M, showing a floor and higher lows over several days before attention arrives. He is mostly interested in that $500k to $2M band.
- [stated] He treats active socials as a key criterion: the project's X still posting at least every 2 to 3 days with real engagement; a suspended X account that is never restored marks the project as dead.
- [stated] 28 Sep 2026 additions: his goal is finding 10x trades; he is patient (days to weeks after a curl-up is fine). The framework must apply equally to Solana (longer history), not only Robinhood Chain. Wants the "bounce 3-5x off the floor, return to the same floor, then run" pattern (from a Loco Motif screencast) backtested as a strong bonus, not a requirement. Wants social engagement (likes, comments) scored relative to market cap, backtested.
- [stated] 28 Sep 2026: calls this the "runner framework" (one of two systems he is building, the other is the rotation framework). Target: coins that had a first run, dropped and consolidated (hours to months), then go 10x+. No market cap limit on runners (supersedes the $500k-$2M band focus). Wants it self-improving via a team of AI agent roles rather than him manually relaying between ChatGPT and Claude.