---
name: trench-model-4
description: Price Predict part 4, from 14 Sep 2026 after trench-model-3 neared its cap. The label correction (the $100k bar was measuring "launched big"), why a website is a negative signal, X post timing, and the minute-by-minute shape of the first fifteen minutes. Read with trench-model-3.
sources: [cowork]
aliases: [trench model part 4, price predict 4, label correction, website negative, x timing, first fifteen minutes]
---
Continues [[trench-model-3]]. Everything there still applies.

# THE BIGGEST CORRECTION OF THE PROJECT: THE $100k BAR WAS MEASURING THE WRONG THING. `timeline.py`, `realwin.py`
Of the eleven tokens in the clean sample that "reached $100k", **ten were ALREADY above $40k at minute one.** Median market cap at minute one for that group: **$72,000**. The median multiple from minute one to peak was about **2.5x**, and the single best was 3.5x.

**So "reaches $100k" has been measuring LAUNCHED BIG, not RAN.** Every hit rate quoted off that label, including the relay ladder's 75%, describes a population Ben does not trade. This is the same population error as the late-token leak, in a new costume, and it survived because the label looked like an outcome.

## MEASURED AS THE TRADE HE ACTUALLY MAKES
314 tokens still under $40k at minute one, median market cap **$22,742**:

| from the minute-one price | tokens | share |
|---|---|---|
| 2x or better | 13 | 4.1% |
| 3x or better | 3 | **1.0%** |
| 5x or better | **0** | **0.0%** |
| 10x or better | **0** | 0.0% |
Best in the whole sample: **4.4x** (0x37dfb1efd3425c6436a038ab0466e120aab17777, $7k to $30k).

**Zero 5x events in thirteen hours.** That is not a broken measurement, it is the expected count: the measured pyramid says 1 in 409 launches reaches $1M, and 314 small tokens is less than one expected event. **The model cannot learn what Ben wants until a real runner has been watched from minute one, and none has been yet.**

**THE FIX, and it must go into the label: score on PEAK DIVIDED BY THE PRICE AT THE DECISION, never on an absolute market cap.** An absolute bar rewards a token for being born big.

What weakly separates a 3x among the small ones (base 1.0%, and 3 events, so a direction only): smart money arriving later 6.5% (6.8x), holders above 10 at minute one 4.8% (5.0x). **Eyes, smart wallets present at minute one and eye size all scored 0.0% on this target.**

# WHY A WEBSITE IS A NEGATIVE SIGNAL. SOLVED. `whysite.py`
- [stated] Ben: "I'm baffled that a website is a negative to get smart money. Why is that?"

**Because on this chain a website is the signature of a launch factory, not of effort.**

| minute-one snapshots | median coins the dev has made | smart money later |
|---|---|---|
| **with a website (212)** | **561** | **1.4%** |
| without a website (553) | 26 | 4.6% |

A dev with 561 launches is generating a template site for every one. The effect **survives both controls**:
- within one launchpad (longxyz, 695 tokens): site **0.5%** (n=189) against no site **4.3%** (n=506)
- holding dev history constant: never-graduated site 0.8% vs no site 3.9%; graduated-before site 2.1% vs no site 5.4%

**So Ben's instinct is right in general and wrong for this population: a site would be evidence of effort if making one cost anything, and at 561 launches it costs nothing.** The tech check will only mean something once it can tell a hand-built site from a factory template, which is a Tech Score job, not a Price Predict one.

# X POST TIMING, MEASURED. `xtime.py`
29 of 76 tokens that got smart money had a post carrying the contract address inside their first hour.

| first post lands by | share of those tokens |
|---|---|
| 60 seconds | 14% |
| 2 minutes | 28% |
| 5 minutes | 45% |
| 10 minutes | 55% |
| 20 minutes | **83%** |
| 60 minutes | 100% |
Fastest 3 seconds, **median 5m52s**, slowest 59m19s.

**So the poller schedule is minute 2, minute 5, minute 10 and minute 20.** Asking at second thirty catches 14%.

**THE CAVEAT THAT HAS TO BE CHECKED BEFORE THIS SHIPS:** the same follower counts recur across tokens (325 on ten of them, 32,709 on four, 4 and 5 on others). **Those are feed bots posting every launch, and a bot that posts everything separates nothing.** The feature must count posts from accounts that do NOT post every launch, and the account filter has to be built before the number is trusted.

# THE FIRST FIFTEEN MINUTES, MINUTE BY MINUTE. `shape.py`, `shape2.py`, `timeline.py`
**First run had the population bug AGAIN** (medians taken over whichever tokens we happened to be watching by that mark, so market cap appeared to FALL from $76k to $32k as a token aged). Fixed by restricting to tokens first seen within 45 seconds, so every column describes the same tokens. **Rule: a time series across marks must use a FIXED COHORT, or the composition moves and looks like the tape moving.**

We poll every **10 seconds** in the first fifteen minutes, so the resolution is there.

| median holders | 30s | 1m | 2m | 3m | 5m | 10m | 15m |
|---|---|---|---|---|---|---|---|
| ran to $100k | 46 | 60 | 80 | 45 | 38 | 32 | 33 |
| smart money came | 11 | 10 | 7 | 7 | 5 | 6 | 5 |
| went nowhere | 2 | 2 | 2 | 2 | 2 | 2 | 2 |

**Holders at minute one is the single cleanest separator we have: 60 against 10 against 2.**

## WHEN EACH SIGNAL FIRST APPEARS (median age, share of the group that ever gets it)
| signal | ran to $100k | smart money came | went nowhere |
|---|---|---|---|
| holders above 10 | 0m46s (90%) | 0m18s (80%) | 0m22s (**3%**) |
| holders above 50 | 0m57s (76%) | 1m00s (11%) | never |
| first smart wallet | 0m55s (100%) | 0m36s (100%) | 0m40s (**8%**) |
| any eye at all | 0m46s (100%) | 0m16s (100%) | 0m33s (**80%**) |
| first callout | 10m11s (52%) | 2m00s (21%) | 1m04s (0%) |

**Everything except the callout has already happened by minute one, for winners and losers alike.** So the answer to "where do the eyes come in" is: immediately, and for 80% of dead tokens too. **The eye's TIMING carries nothing; only its SIZE relative to the hour's field does.** The only genuinely late stage is the callout at about ten minutes, which is where X and the relay's stage 3 live.

# THE X CALLER TRACKER IS LIVE. 14 Sep 2026, patches 102-110. `xdiscover.py`, `xwatch.py`, `xcall.py`
- [stated] Ben: "you can already start building the X tracker. I wouldn't check at minute 2, 5, 10, 20. Shouldn't we check every 10 seconds, or is that too heavy?"

**He gets ten second resolution, but NOT the way he described it, and the arithmetic is why.** Searching each contract address every ten seconds for twenty minutes is 120 searches per token: **160,000 a day on Robinhood Chain and 2.2 MILLION on Solana.**

**POLL THE CALLERS, NOT THE TOKENS.** One query carries 26 handles, so the whole list is 7 searches every ten seconds: **about 60,000 a day covering BOTH chains**, two orders of magnitude cheaper, and FASTER, because a post is seen within ten seconds of being written rather than at the next per-token checkpoint.

## HOW THE BOTS GOT FILTERED, and it is not by follower count
Full discovery pass over **1,263 tokens**: 183 had a post, **247 distinct authors**.
- **Breadth, not audience, is the test.** The widest account on the chain, `longlaunches`, posted a contract address for **86 of 1,263 launches (6.8%) on 325 followers**. The loudest, `bankrbot`, has **116,403 followers** and posted 19 launches, choosing none of them. **A feed that posts everything separates nothing.**
- The first threshold (10% breadth) was useless: nothing on this chain reaches it, so every bot passed. Now **1% breadth** plus a name test (radar, scan, alert, bot, trend, viral, pairs, launch, caller, exchange, sniper, signal).
- Result: **13 feeds stripped, 234 callers kept**, capped at 140 by audience. The name test is a stopgap and says so in the code: the real test is whether an account's calls PREDICT anything, and every post is kept so that score can replace it.

## THE BUGS THIS BUILD PRODUCED, all found by checking rather than assuming
1. **A silent query-length cliff.** 26 handles (494 chars) returns tweets; 28 (535) returns an **empty list with no error**. Groups are now built by CHARACTER COUNT, and a long empty result is logged as "too long" rather than passing as "nobody posted".
2. **The gate deadlocked the collector.** The first X gate check wrote its fixture into the LIVE tracker database that `xwatch` writes to every ten seconds; five stacked gate runs sat on the lock until killed. **A test must never write to a database a service owns**: it builds a throwaway copy now.
3. **The worst one, and it was green the whole time.** `xcall.conn()` set a `_DEAD` flag on the first failure and never retried. Both collectors were restarted BEFORE the tracker database existed, so **every process gave up permanently at boot and the block read zeros for the life of the service**, with the gate passing. Caught only by checking a live row. A missing file is a "not yet", never a "never". Gate check added: the word `_DEAD` may not appear in xcall.py.
4. **The blind-period trap, caught before it shipped.** A snapshot from before the tracker existed has no posts for the same reason a blank page has no words. `xstat.started` is written once and never moved, and any row before it reads `x_has_data=0` rather than "nobody posted". Without this, every historical winner would have taught the model that silence is normal.

## WHAT IS RUNNING
- `xwatch.service`, enabled, 140 callers in 7 queries, polling every 10 seconds, writing `/opt/common/xcalls.db` (shared, read by both chains, raw rows keyed by address so no chain pooling).
- **FEATS 265 to 275**: `XCALL_FEATS` appended at the tail per `feats.TAIL_BLOCKS`, which patch100 made the single source of truth, so `tailfill` and the gate picked the new block up with no edits. 4,044 Robinhood and 7,099 Solana snapshots topped up in seconds.
- `tailfill`'s block dispatch had a bare `else` that ran the relay builder for anything unrecognised: **the first block appended after relay would have been filled with relay numbers, silently**. Now an explicit dispatch that raises.
- **Both chains: all gate checks pass**, including seven new X checks (no post after the snapshot, no later caller raising an earlier row's audience, never a negative age, blind before the start line).
- First hour of collection: **127 address mentions across 94 distinct tokens**, cleanly parsed on both chains (EVM hex and pump.fun base58).

## NEXT, AND IT IS FREE
twitterapi.io has a **websocket with filter rules** (`wss://ws.twitterapi.io/twitter/tweet/websocket`, `/oapi/tweet_filter/get_rules` answers and is empty). That is push instead of poll: sub-second instead of ten seconds, and no polling cost at all. Not used yet because the rule billing is untested and an untested billing surprise on Ben's account is worse than a ten second delay.

# FULL SETUP VERIFICATION, 14 Sep 2026 ~09:45 UTC. `fullcheck.py`, patches 111-112
- [stated] Ben: "double check if everything is set up correctly. and break down what we are looking for as soon as a coin is launched, what are lead indicators"

`/opt/trench/fullcheck.py` is one read-only sweep: services, data freshness on both chains, vector widths, the X tracker, whether the block is really wired, cron, disk. **ALL CHECKS PASS**, and both chains pass the full gate.
- trench, trench-sol, xwatch all active, **zero restarts**.
- RH and SOL both observing, finding, freezing and predicting within minutes.
- Vectors: RH 537 short of 4,656 (the ancient 120/168 rows, dead before today), **SOL 0 short of 8,577**.
- X tracker after 30 minutes: **155 mentions on 112 tokens, 51 matching tokens we watch**, 140 callers.
- WAL set on `/opt/common/xcalls.db` too (patch112): one writer every ten seconds and two readers on every freeze is exactly the shape WAL is for.

## THE CHECK THAT WAS ITSELF WRONG, and it is a rule now
The patch110 gate check grepped `xcall.py` for the string `_DEAD` and went **red because the comment EXPLAINING the bug contains the word**. **A test of prose is not a test.** patch111 replaces it with behaviour: point the module at a missing file, let it fail, create the file, check it recovers. Same fix applied in `fullcheck.py`.

# THE LEAD INDICATORS, ASSEMBLED. Artifact "First Twenty Minutes"
Published as a private artifact for Ben to open while a coin is live. Everything in it is measured on 751 watched Robinhood Chain tokens, baseline 3.7% for the smart-money handoff.

**0 to 60 seconds, the only window where he is early** (all versus a 3.7% base):
curve filling in the top tenth 41% (11.0x) · fresh wallets top quarter 37% (9.8x) · more than 46 buys in five minutes 35% (9.5x) · more than 66 swaps 35% (9.5x) · three or more smart wallets already in 33% (8.9x) · eye above 30 30% (8.1x) · insiders flagged 26% (7.1x) · holders above 6 25% (6.8x) · ticker used by an earlier coin 11% (2.8x).

**1 to 10 minutes, the handoff and the trigger:** smart money actually arriving takes the price from $23,558 to $25,220, a **7% higher entry for a 5x better hit rate (7% to 36%)**. A real caller posting the address lands at a median of 5m52s. Eye in the top 5% of the same hour is 15.8x, and only the RELATIVE eye works.

**10 to 20 minutes, too late to be early:** callouts start at a median of 10m11s, by which point the median price is **$333,334, about 14x the entry**. Confirmation, not an entry.

**The kill list:** nobody ever looks in the whole first hour (549 coins, **zero ran**) · zero buys in five minutes · duplicate X handle 0.31x · has a website 0.38x · has an X account 0.60x · duplicate art 0.55x.

**Stated on the page rather than buried:** every number predicts SMART MONEY ARRIVING, not a 10x, and no coin entered near $23k did 5x in thirteen hours. Tech score and category are deliberately absent because only 65 of 1,244 coins could be scored.

# THE CALL BOOK IS LIVE ON BOTH CHAINS. 14 Sep 2026, `callbook.py`, patches 113-115
- [stated] Ben: "Are you able to build an early version now that marks coins that should be bought, and tracks how these callouts and these routes perform? Then we keep learning from our predictions and our actual results. Or is it too early?"

**Not too early, and the reason is the opposite of intuition: the model cannot fit BECAUSE we have almost no winners, and a call book is the cheapest machine there is for turning hours of collection into scored evidence.** Every launch that goes past becomes a row with an answer attached, whether or not anything learns from it yet.

## THE THREE RULES IT OBEYS
1. **Scored on peak divided by the price we called**, never an absolute market cap. That is the correction from earlier today, in code this time.
2. **Every rule runs at once and they are scored side by side.** Freezing one rule now would be picking a winner from three positive examples. The book is a competition, not a strategy.
3. **A control row called `all`**, which is "buy every launch". A rule that cannot beat it is not a rule, and without that row in the table it is arguable.
Nothing is signed or sent: these are marks in a table.

Calls fire ONCE per coin per rule at the first observation between 60 and 240 seconds of life, from what was visible then. Cron every 5 minutes on both chains, plus the board in the 07:41 daily.

## FIRST BOARD, ROBINHOOD (control: 1.7% do 2x, 0.9% do 3x)
| rule | calls | entry | >=2x | >=3x | dead | hold to peak |
|---|---|---|---|---|---|---|
| **combo** (curve above median + holders>5) | 103 | $26,285 | **6.8%** | **3.9%** | 3.9% | 5m |
| smart (3+ smart wallets) | 44 | $33,433 | 6.8% | 2.3% | 2.3% | 5m |
| holders (>10) | 45 | **$41,699** | 8.9% | 2.2% | 6.7% | 12m |
| curve (top decile) | 195 | $24,087 | 4.1% | 2.1% | 2.1% | 12m |
| eye (top decile of the hour) | 188 | $23,493 | 3.2% | 1.6% | 0.5% | 5m |
| buying (holder rate, top decile) | 286 | $23,744 | 2.8% | 1.4% | 1.4% | 12m |
| **all (control)** | 464 | $22,979 | 1.7% | 0.9% | 0.9% | 12m |
**`combo` is four times the control on both bars.** `holders` looks good but its entry is $41,699 against a $22,979 control: it is buying coins that already moved, which is the exact trap the label correction exposed. Entry price must be read next to every hit rate.

## FIRST BOARD, SOLANA, and it is a different game (control: 10.2% do 2x, 2.9% do 5x)
| rule | calls | entry | >=2x | >=5x | dead | hold to peak |
|---|---|---|---|---|---|---|
| buying | 397 | $46,740 | **31.7%** | **9.3%** | **65.0%** | **2m** |
| holders | 632 | $44,021 | 25.6% | 7.3% | 45.1% | 3m |
| combo | 778 | $27,953 | 23.7% | 6.9% | 40.1% | 3m |
| eye | 246 | $7,747 | 19.9% | 5.7% | 32.1% | 4m |
| all (control) | 2400 | $3,076 | 10.2% | 2.9% | 15.9% | 2m |
**Solana is alive in a way Robinhood Chain is not**: the control alone does 2x a tenth of the time. But read the last two columns before getting excited: **the peak arrives 2 to 3 minutes after the call and 65% of the called coins then collapse.** That is a scalp, not a hold, and the high entry ($46,740 against a $3,076 control) means the rules are selecting coins that have already run 15x from launch. Different trade, different risk, and it must not be described as the 10x hold Ben is looking for.

## TWO BUGS THIS BUILD PRODUCED, both in the honest-baseline direction
1. **The control was firing on coins with no price.** Minute-one market cap of zero scored 0.00x, dragging the only baseline in the book to nothing. No price, no trade: those are not calls.
2. **"buying" was "holders" under a second name.** It is now the RATE holders arrive at, which is what the shape study actually separated on.

# BEN'S REAL TARGET IS $1M / $5M / $10M, NOT 2x. Patches 116-120
- [stated] Ben: "I'm obviously not primarily interested mostly in a 2x or 3x. I'm interested in coins that go to 1 million, 5 million, 10 million, right?"

The board now leads with **absolute market caps reached**, and the multiples are demoted to what they actually are: the only columns with enough events to RANK a rule today. A rule that cannot beat the control at 2x will not beat it at 43x, so they are the early proxy, never the goal.

## AND THE FIRST VERSION OF THAT COLUMN WAS WRONG. THIRD TIME TODAY, SAME ERROR.
The `$1M+ / $5M+ / $10M+` columns counted any call whose peak passed the cap. Checked one by one before reporting, which is the only reason it was caught: **every eye-rule call that "reached $10M" had an ENTRY between $29M and $370M and a multiple of 1.0x.** They were never small, they were born enormous. The median entry of $7,549 hid it, because **a median says nothing about a tail.**

**patch118: an absolute cap tier is now only ever reported for calls that were SMALL (under $50,000) when called**, and the gate enforces it. Three appearances of one error in one day earns code, not another note, per Ben's standing rule.

## THE HONEST BOARD AT THE BAR HE ACTUALLY CARES ABOUT (small calls only)
**Robinhood Chain, ~15 hours: ZERO small calls reached $1M.** The biggest anything got from a small entry was **$718k**.
**Solana, same window: 4 small calls reached $1M**, and the field is at least alive:

| rule | small calls | entry | $1M+ | $5M+ |
|---|---|---|---|---|
| buying | 249 | $40,724 | **1.2%** | 0.4% |
| holders | 436 | $22,434 | 0.7% | 0.2% |
| combo | 614 | $5,724 | 0.5% | 0.2% |
| **all (control)** | 2,331 | $2,956 | 0.2% | 0.1% |
Three or four events. **A direction, not a result.**

## HOW LONG BEFORE THIS CAN ANSWER HIS QUESTION
Solana produces roughly **4 small-entry $1M events per 15 hours** across 2,331 calls. Ranking rules at that bar needs about 30 events, so **about five days on Solana and considerably longer on Robinhood Chain**, where the rate is currently zero. That is the honest timeline and it should be repeated rather than softened: the 2x columns will look decisive long before the $1M columns mean anything.

## THE X CHECK IS IN THE BOOK
`xcall` is one of the eight rules and fires when a non-feed caller has posted the contract address before the call. It read zero at first because the tracker was one hour old and every historical coin predates it; **7 Robinhood coins already had a caller post within 4 minutes of launch in that first hour**, so it fires from here.

## I WROTE A TEXT-MATCHING TEST AGAIN, TWO HOURS AFTER REPLACING THE LAST ONE
The new gate check grepped `callbook.py` for `"peak / f(mc)"` while the code said `best / f(mc)`: **red on working code.** patch120's fix is not a better grep. The multiple now lives in ONE named function, `callbook.multiple(peak, entry)`, called by both the scorer and the gate, so the test exercises the thing itself. **THE STANDING RULE: never test source text. Extract the behaviour into a function and call it.**

## AND THE LOCK CONTENTION GOT A MECHANICAL FIX
Three gate runs died on "database is locked", each colliding with a different writer. patch119: **every batch writer (`callbook.sh`, `scoreall.sh`, `rollup.sh`, `daily.sh`, and the gate) takes one shared `flock` on `/tmp/trenchw.lock`**, and `store.db()`'s busy timeout went from 20s to 60s. `score()` is also incremental now (it used to rewrite all 1,400+ rows every five minutes, forever).
**Both chains: all gate checks pass.**

# EXCLUSION CRITERIA, JUDGED ON MONEY. 14 Sep 2026. `exclude.py`, `flagcover.py`, patches 121-122
- [stated] Ben: "we can use certain criteria on GMGN as exclusion criteria. Honeypot, verified, renounced, top 10 holders, snipers, insiders, bundlers. Obviously we're looking for the sweet spot where we make the most money, and not necessarily where we have 100% accuracy and buy 1 coin every 2 weeks."

**That second sentence is the whole design and a hit-rate table cannot express it**, so `exclude.py` scores every candidate filter on TOTAL RETURN: put the same ticket on every call that survives, sum peak/entry, compare to buying everything. A filter that doubles the hit rate while cutting the calls tenfold LOSES money.

## FOUR OF THE CRITERIA HE NAMED DO NOT EXIST AT MINUTE ONE
`flagcover.py`, on 814 Robinhood and 2,916 Solana minute-one snapshots:

| field | Robinhood | Solana |
|---|---|---|
| **is_honeypot** | **0.0%** | **0.0%** |
| **open_source (verified)** | **0.0%** | **0.0%** |
| **owner_renounced** | **0.0%** | **0.0%** |
| **is_wash_trading** | **0.0%** | **0.0%** |
| total_fee | 48.0% | 96.7% |
| top_10_holder_rate | 35.9% | 60.5% |
| top70_sniper_hold_rate | 2.2% | 70.3% |
| suspected_insider_hold_rate | 2.5% | 5.0% |
| bundler_trader_amount_rate | 0.6% | 16.4% |
| entrapment_ratio | 22.0% | 21.5% |
**GMGN never fills honeypot, verified source, renounced or wash-trading on a fresh launch.** Those four cannot be exclusion criteria here, whatever the UI suggests. And on Robinhood Chain snipers, insiders, bundlers and dev-hold are set on 0.6% to 2.5% of launches, so there is nothing to exclude either: the whole safety panel is a Solana tool.

## NOT ONE EXCLUSION MADE MONEY (Solana, 2,631 small calls, baseline 6,910x total, 2.63x per call)
| exclude if | kept | total | per call | what it threw away |
|---|---|---|---|---|
| insiders > 15% | 2,615 | 6,882x | 2.632 | 16 calls, 28x |
| dev holds > 15% | 2,542 | 6,801x | 2.675 | 89 calls, 109x |
| snipers hold > 15% | 2,521 | 6,766x | 2.684 | 110 calls, 145x |
| top 10 hold > 25% | 2,508 | 6,504x | 2.593 | 123 calls, 407x |
| **dev has made 100+ coins** | 1,670 | 5,677x | **3.399** | 961 calls, 1,233x |
| **entrapment > 0** | 2,162 | 2,520x | 1.166 | **469 calls, 4,390x at 9.36x each** |
| **dev never graduated one** | 1,126 | 2,466x | 2.190 | **1,505 calls, 4,445x** |
| **any tax at all** | 93 | 96x | 1.029 | **2,538 calls, 6,815x** |
**Every filter lowers the total.** The safety flags are neutral at best: the biggest of them removes 123 coins out of 2,631. **Three would be actively expensive**, and "exclude anything with a tax" would destroy the strategy, keeping 93 calls out of 2,631.

**The one filter worth having, and only if he is attention-limited:** skip devs with 100+ launches. It raises return per call from 2.63 to **3.40 (+29%)** on Solana and 1.060 to 1.148 (+8%) on Robinhood, while keeping 63% and 72% of calls. Total money goes down; money per decision goes up. Which one matters depends on whether he is limited by capital or by how many he can actually watch.

## THE REAL FIND: ENTRAPMENT IS A BUY SIGNAL, NOT A WARNING
Excluding `entrapment_ratio > 0` threw away 469 Solana calls worth **4,390x at 9.36x per call against a 2.63x baseline**: the strongest single number in the table, and pointing the opposite way to the name. Added as the `entrap` rule, and on the absolute bar it is now **the only rule with a $10M from a small entry**:

| rule | small calls | entry | $1M+ | $5M+ | $10M+ | biggest |
|---|---|---|---|---|---|---|
| **entrap** | 406 | **$8,017** | 0.7% | **0.5%** | **0.2%** | **$29,273k** |
| buying | 270 | $40,375 | 1.1% | 0.4% | 0.0% | $5,926k |
| holders | 465 | $20,819 | 0.6% | 0.2% | 0.0% | $5,926k |
| all (control) | 2,554 | $2,961 | 0.2% | 0.1% | 0.0% | $29,273k |
Cheap entry AND the deepest tail. One $10M event, so it is a direction, but it agrees with the money table computed a different way on a different sample.

Also added `combo2`: combo plus "the dev has made 100 coins or fewer".

## AND A BUG THAT WOULD HAVE MADE BOTH NEW RULES USELESS
`_snapvec` asked for a minute-one snapshot at or before the first observation in the call window, **but the freezer writes that snapshot a few seconds AFTER the observation**. So **3,409 of 3,966 tokens read their entire 275-column vector as zeros** and `entrap` fired 72 times where about 800 were due. patch122: the snapshot only has to fall inside the call WINDOW, and the call's own timestamp is pushed to whichever of the two came later, so the recorded decision time is never earlier than anything it used. Zero-vector readings fell from 3,409 to 723 and `entrap` went from 72 calls to 640. **Caught only because a new rule firing 72 times when 21% of coins carry the flag did not add up: check that a new rule fires at the rate its input frequency implies.**

# BEN CAUGHT A REAL BUG: THE SAFETY FIELDS ARE WORDS, AND WE WERE READING THEM AS NUMBERS. Patches 123-124
- [stated] Ben: "I'm surprised that you're claiming that there are no honeypots on these chains. Obviously there are, and this is why GMGN filters for them. Why do you claim that they don't [exist]?" (with a GMGN screenshot showing NoHoneypot / Verified / Renounced all ticked)

**He was right and I was wrong, and the cause is a one-line bug.** GMGN sends these as TEXT: `is_honeypot` is `"no"` or `"unknown"`, `open_source` is `"yes"`, `owner_renounced` is `"yes"`, `s_qsafe` is `"yes"` or `"no"`. `store.f()` did `float(v)`, which raises on a word, so it returned **0.0 for every one of them in every row of every stored vector**. I then read "always zero" as "the field is empty" and told him the checks do not exist on this chain. **They exist. We were discarding them at the door.**

**THE STANDING RULE THIS EARNS: "the column is all zeros" and "the field has no data" are different claims. Before reporting the second, open one raw payload and look at the value.** `honey.py` does exactly that and took thirty seconds.

## WHAT THE RAW PAYLOADS ACTUALLY SAY (400 recent, each chain)
| field | Robinhood | Solana |
|---|---|---|
| is_honeypot | 288 `unknown`, 112 `no`, **0 yes** | field absent |
| open_source | **400 `yes`** | field absent |
| owner_renounced | **400 `yes`** | field absent |
| s_qsafe | 226 `yes`, 122 `no`, 52 absent | 396 `yes`, 4 `no` |
| burn_status | 385 `yes` | 400 `burn` |
So the practical conclusion survives but for a completely different reason than I gave: **on Robinhood Chain every launch comes off the same launchpad contract, so verified and renounced are `yes` for literally all of them and cannot separate anything**, and no launch in 400 came back as a honeypot. On Solana those three are not sent at all.

## AND THE FIND THAT CAME OUT OF HIS PUSHBACK: `s_qsafe` IS THE BIGGEST SPLIT YET
GMGN's own overall safety verdict, never read because it is a word. Small calls, total return at equal ticket:

| Solana | coins | per coin |
|---|---|---|
| **s_qsafe = yes** | **4,227** | **7.08x** |
| s_qsafe = no | 66 | 1.11x |
Six times the return per coin. On Robinhood it is noise and slightly backwards (no 1.121, yes 1.047), which fits a chain that has produced no real winner yet. Caveat: only 66 "no" coins on Solana.

## SHIPPED
- **patch123**: `store.f()` maps words to numbers, with **-1 for `unknown`**, kept separate from 0 (`no`), because unknown is 72% of Robinhood launches and is a real third answer, not a soft no.
- **patch124**: a new `safety` block (`sf_qsafe`, `sf_honeypot`, `sf_open`, `sf_renounced`, `sf_burn`, `sf_has_data`) appended at the TAIL. **Deliberately NOT added to RAW**, which sits in the middle of FEATS: a column inserted there would shift every stored vector, which is the append-only rule this project already broke once. **FEATS 275 to 281**, both chains backfilled.
- Historical rows mostly read `sf_has_data=0` because `obs.j` keeps the raw payload on only 15% of observations. That is the honest answer rather than a guessed verdict.

## STILL UNKNOWN, AND SAID PLAINLY RATHER THAN GUESSED
**I do not know what GMGN means by `entrapment_ratio`.** It is a number from 0 to about 0.2, non-zero on 22% of Robinhood and 21.5% of Solana launches. All that has been measured is that coins carrying it outperformed: excluding them threw away 469 Solana calls worth 4,390x at 9.36x each against a 2.63x baseline. The name suggests a warning and the data says the opposite, so **the definition needs to be found before that rule is trusted**.

## AND A COMMUNICATION FAILURE, RECORDED BECAUSE IT KEEPS HAPPENING
- [stated] Ben: "I don't understand your tables... I want you to use very simple language. This is in the presets of how you're supposed to talk. Remember this. Explain things to me like I'm 5 years old."
The exclusion table used a keep/drop layout with five numeric columns and no plain sentence saying what a row meant. **Every table needs a one-line "read it like this" in plain words, or it should be a sentence instead of a table.** He has now asked for this twice today.

# WHEN THE SAFE VERDICT ARRIVES, CHECKED NOT ASSUMED. `qsafe_when.py`
- [stated] Ben: "GMGN saying something is safe gives us 7x lift that is available from the second it launches, correct?"

**Available: yes, and it is stable.** First reading at a **median of 8 seconds** after launch (63% within 10s on Robinhood, 70% on Solana). It almost never moves afterwards: Robinhood 1,432 unchanged against 5 changed, Solana 3,491 against 27.

**"7x lift" needs correcting, in two ways, and neither was said clearly enough:**
1. It is not 7x better ODDS. It is 7.08x total return per coin against 1.11x for the "not safe" group. Driven by the tail.
2. **It is a tiny filter.** Only 45 to 66 Solana coins in the whole book read "no", about 1 in 60. Skipping them barely changes anything.
3. **It does not work on Robinhood Chain at all**, where 562 of 1,589 read "no" (35%) and that group did slightly BETTER (1.121 against 1.047). So this is a Solana signal only, and the RH split being large while the Solana split is tiny is itself a hint that the two chains mean different things by the word.

# THE FULL FIRST-MINUTES LIST, as it stands 14 Sep 2026. Artifact "First Twenty Minutes" v2
**Available in the first 60 seconds, strongest first** (against a 3.7% base for the smart-money handoff unless noted):
1. **Holders climbing** (60 for winners, 10 for maybes, 2 for the dead) — the cleanest single number
2. **Curve filling, top tenth** 41% (11.0x)
3. **Fresh wallets, top quarter** 37% (9.8x)
4. **Buys above 46 in five minutes** 35% (9.5x) and **swaps above 66** 35%
5. **Three or more smart wallets already in** 33% (8.9x)
6. **Eye in the top 5% OF THE SAME HOUR** 15.8x (the raw count is only 4.7x: relative or nothing)
7. **Insiders flagged** 26% (7.1x), counterintuitive and consistent
8. **Entrapment above zero** (Solana): 9.36x money per coin against 2.63x baseline. **Meaning still unconfirmed.**
9. **GMGN says safe** (Solana only, arrives at 8 seconds, rules out 1 coin in 60)
10. **Dev has launched under 100 coins**: +29% money per coin on Solana, +8% on Robinhood
11. **Ticker used by an earlier coin** 11% (2.8x)

**Says no:** nobody looks at all in the first hour (549 coins, zero ran) · zero buys in five minutes · **has a website** 0.38x · has an X account 0.60x · duplicate X handle 0.31x · duplicate art 0.55x · **dev has launched 100+ coins**

**Arrives later, not an entry:** smart money actually arriving at minute 1 to 10 (price moves $23,558 to $25,220, hit rate 7% to 36%: **the trigger**) · a real caller posts the address, median 5m52s · callouts at minute 10, by which point the price is already about 14x.

Artifact updated to v2 with the safe verdict, entrapment, the dev-factory filter, and a footer explaining why Honeypot / Verified / Renounced are deliberately absent.

# V1: THE TEN SIGNALS AS A SCORE, AND IT WORKS ON SOLANA. `v1.py`
- [stated] Ben: "if all ten are positive then what are the odds that this goes to 100K, 1M, 5M?" and "we build a system, maybe this is V1, we throw $100 in play money at this, watch it for 24 hours, learn, fine-tune."

**Built as a SCORE from 0 to 10, not an all-or-nothing gate**, because requiring all ten fires on almost nothing, which is the trap he named himself. Solana, 3,764 small coins (under $50k at minute one), 16 hours:

| score | coins | reached $100k | $1M | $5M |
|---|---|---|---|---|
| 0 to 1 | 1,098 | **0.0%** | 0% | 0% |
| 2 to 3 | 1,962 | 0.1% | 0% | 0% |
| 4 to 5 | 318 | 4.7% | 0% | 0% |
| **6 or more** | **386** | **21.2%** | **2.1%** | **0.5%** |
| (score 7 alone) | 181 | **24.9%** | **3.3%** | 0.6% |
**Monotone, and it fires 386 times in 16 hours: about 23 a day at score 6+.** That is the right frequency for a $100 play-money V1.

**Robinhood Chain: the same score does nothing.** 438 small coins, 0.0% reached $100k at EVERY score level including 9. The chain has produced no winner from a small entry in the whole window, so there is nothing for a score to separate. **V1 runs on Solana only.**

## WHAT THE SCORE TABLE ALSO EXPOSED
- **Two of the ten are empty on Solana**: `w_smart` (3+ smart wallets) and `visiting` (eye) fire on **0.0%** of coins. So it is really an eight-signal score there, and the eye, the single most-validated Robinhood signal, does not exist on Solana. That needs saying every time the score is quoted.
- **"GMGN says safe" fires on 98.4% of Solana coins**, so as a POINT it adds nothing. It belongs as a veto, not a score item.
- **Per-coin return is useless as a ranking column here**: score 5 reads 147x per coin because of one 20,082x outlier. Use the percentage columns.

# THE WEBSITE RULE IS WRONG, AND BEN CALLED IT. `sitecheck.py`
- [stated] Ben: "And you're also saying to walk away if it has a website, right? That's hilarious. Is that true? If it has an X handle, that's also bad?"

**It is not true at the bar that matters.** The original finding was measured on Robinhood Chain against SMART MONEY ARRIVING. Re-measured on Solana against REACHING $100k, on 3,764 small coins, it reverses:

| at minute one | coins | reached $100k |
|---|---|---|
| **has a website** | 797 | **5.5%** |
| no website | 2,967 | 1.8% |
| **has an X account** | 1,450 | **3.9%** |
| no X account | 2,314 | 1.8% |
| **duplicate X handle** | 856 | **5.7%** |
| original X handle | 2,908 | 1.7% |
Three times better WITH a website, not worse. The V1 veto list confirms it from the other side: removing the four "red flags" made the score-4-plus group WORSE (11.7% against 14.4% at $100k).

**THE GENERAL LESSON, and this is the third time today: a signal measured against a PROXY can reverse when measured against the real goal.** The proxy was "smart money arrives", the goal is "reaches $1M", and they are not the same question. **Every signal on the board has to be re-measured against the real bar before it is trusted, and the ones that were only ever tested on Robinhood have to be re-tested on Solana.** The website rule is retired for Solana and marked chain-specific and proxy-only for Robinhood.

# ENTRAPMENT: GMGN DOES NOT DOCUMENT IT
Checked their own docs and their published skills repo. `entrapment_ratio` has **no definition in either**. The word appears once in GMGN's security page, about blacklists: "reducing the risk of financial entrapment", which HINTS that it measures supply or volume caught by a blacklist, but that is a guess and is recorded as one. `s_qsafe` and `top70_sniper_hold_rate` are also undocumented. Defined fields, quoted: `fresh_wallet_rate` "ratio of fresh/new wallets among holders", `rat_trader_amount_rate` "ratio of volume from sneak/insider trading", `bundler_trader_amount_rate` "ratio of volume from bundle trading (bot-driven)", `top_10_holder_rate` "ratio of supply held by top 10 wallets".

# AND BEN IS RIGHT ABOUT THE SMART-MONEY ENTRY
- [stated] Ben: "smart money shows up in the first 10 minutes, but price barely moves. That's a good thing. It's not better if smart money shows up and price moves."
Correct, and it is the whole point of that row: $23,558 to $25,220 is a 7% worse entry for a five times better hit rate. **A signal that arrives WITHOUT moving the price is the only kind worth having.** The callout at minute ten fails exactly this test: by the time it fires the price is already about 14x.