Experiment A

Bolo's Fomo-feed experiment: pipeline state, the signal, wallets and behaviours worth following, the latency edge, what to run tonight.

Rook, 2026-09-06 20:25 Beirut. Read-only diagnosis for Bolo. Nothing under research/call-sourcing/ was edited, no process was started, stopped or signalled. Every number below cites its file.

TLDR

1. Nothing is running. No mark, crowd, join or collect process exists on the box (ps -eo pid,cmd | grep experiment-a, empty at 20:10). Last write to data/experiment-a/mark-state.json was 19:29 Beirut. mark.lock and crowd.lock are gone, collector.lock and join.lock are stale. Restart is step zero.
2. The tape leg is dead, not slow. All 6 files in data/experiment-a/tapes/ were written between 00:34 and 00:50 Beirut, by the build that preceded the current scripts/mark-experiment-a.mjs (mtime 01:03). Since 01:03 the tape has made 3,269 attempts and 0 successes.
3. Root cause, one line: research/smartmoney/rpc.mjs:50 treats the node's own log query timed out as a transient error and burns ~64 s of retry before getLogs is allowed to split the range. mark-experiment-a.mjs:195 kills the tape child at 15 s. On any busy pool the child can never reach the first split. It is killed, forever.
4. Head-of-line blocking makes it total. mark-experiment-a.mjs:292 takes .slice(0, 1): one tape per cycle, sorted by tapeThrough (0 for never-taped rows, stable sort). Two rows on one pool, alrt_1788637873065_466 and alrt_1788637953286_478 (both token 0x275bd09e, pool 0x6f5b061f), hold the head and have 1,525 and 1,518 attempts, 93% of all tape work. The other 197 candidates have never been attempted once.
5. The one up60At we have is garbage. alrt_1788644433727_1896 records peak60mPct: 6.713068891519107e+55 because a swap drove the pool to sqrtPriceX96 = 4295128740 (MIN_SQRT_PRICE + 1, a drained pool) and buildCandidateTape has no sanity clamp.
6. D4 is trending to kill on a leg that never ran. Counting fomo-events-materialized.jsonl first-buys under 6 h with provenBefore === false: 80 rows, of which 14 have a proven wallet within 15 min after. D4 count = 14 against a threshold of 30, and the +60% leg contributes 0. 80 rows are unmeasured on that leg.
7. The crowd worker is a different bug with the same shape. crowd-experiment-a.mjs:65 calls rpcLogs('eth_getLogs', ...) directly instead of getLogs(...), so it gets no adaptive splitting. Nine cells fail forever on logs matched by query exceeds limit of 10000.

Evidence

The error counter reconciles exactly

data/experiment-a/mark-state.json: cycles 3428, errors 3281, tapes 25, lastError {"at":"2026-09-06T15:49:24.436Z","message":"fetch failed"}.

Summing tapeAttempts over data/experiment-a/marks.json: 3,269 across 9 rows. 3281 - 3269 = 12. So 12 of 3,281 errors are fetch failed (top-level throws from runMarkOnce, the only uncaught network call in it being ethPrice() against api.dexscreener.com, which is reachable now: HTTP 200, 31,778 bytes, 1.1 s). The remaining 3,269 are tape-child kills. The brief's fetch failed is a red herring; it is 0.4% of the errors.

Errors do not stop the cycle count because mark-experiment-a.mjs:258 does state.cycles++ and writes state before any network call, and the tape failure at line 295 is caught inline and never throws. Progress lines confirm the cadence: errors=3232 at 19:12 and errors=3276 at 19:27 in progress-experiment-a.md, 44 errors in 900 s, one per ~20 s, which is exactly one 15 s child kill plus the 5 s LOOP_MS. Every cycle for the last 19 hours has done one thing: kill one tape child.

The fetch, reproduced by hand

Row alrt_1788637873065_466, pool 0x6f5b061f24b34f0166c5c4c8c97d7ff4dc4634cc84975a7a1b989b15ee1bb194, observedBlock 55384286. Chain rate measured from two candidate rows 80 s apart (blocks 55384286 and 55385072) is 9.8 blocks/s, so one hour is about 35,300 blocks. One request each, against https://rpc.mainnet.chain.robinhood.com (the endpoint getLogs uses):

The endpoint is healthy. The range is too wide, and it says so. rpc.mjs:50 is if (e.rpc && !/timed out|timeout/i.test(e.message)) throw e, so log query timed out is not rethrown: it loops 8 times with backoff 500, 1000, 2000, 4000, 8000, 10000, 10000, 10000 ms, about 45.5 s of sleeping plus about 18 s of server time, roughly 64 s per level, before throwing rpcLogs failed after retries and letting getLogs (rpc.mjs:81) halve the range. Halved, it repeats. The first three levels of the tree alone cost 7 x 64 s. runTapeIsolated kills the child at 15 s. It cannot ever succeed on a busy pool.

Corroborating: the request rate matters too. Four probes at 1.4 rps returned Too Many Requests while the live follower was on the same endpoint. That is the README's 2 rps limit biting, and rpcLogs treats 429 as retryable as well.

25 tapes in state, 6 files, 5 rows

• state.tapes counts successful child returns, not files. The retape gate (mark-experiment-a.mjs:291) re-runs a row every cycle while tapeThrough < min(now, sourceTs + 60 min) - 30 s, and writeTape (line 154) rewrites the whole file. 25 successes over 6 event ids is about 4 passes each.
• All 6 files have mtimes 00:34 to 00:50; the script is 01:03. The current build has written zero tape files. All 5 tapePath marks carry tapeThrough: 2026-09-05T21:46:27.331Z, the moment the old build stopped.
• The sixth file, 3d7f43a7-85c4-43ea-a32e-32b40b110ebf.jsonl, belongs to alrt_1788643305005_1648, which is type: "thesis", not "buy". The current filter (line 253) excludes it, so no mark record points at it. It is an orphan from the pre-01:03 build.
• What was different about the 5 that produced peak60mPct: nothing about the rows, only the clock. They ran under the old build in a 16-minute window before the 15 s isolation was in place. Their pools were also quiet or short: the tapes are 10, 2, 6, 686, 8,121 and 8,243 lines.

The 5 values are 32.3, 12.46, 0, 3.73 and 6.713068891519107e+55. The last is alrt_1788644433727_1896, token 0x7cbecee5, and its tape's final row is sqrtPriceX96 = 4295128740. That is MIN_SQRT_PRICE + 1: the pool hit its price limit, i.e. it was drained. With tokenIs0 === false, buildCandidateTape:163 computes (baseline / sqrt) ** 2 = 6.7e53, times 100. It is the only up60At in the dataset and it is an artifact. n = 5 is an anecdote; n = 1 for the outcome that decides D4 is not evidence at all.

The crowd worker: different cause, same shape

crowd.json has 823 completed horizon cells and 9 failing cells, all with the same error: logs matched by query exceeds limit of 10000. Total attempts across all cells is 6,166, so 5,343 failures, which is exactly crowd-state.json errors. That counter is per task, not per cycle, so "5,343 of 5,486 cycles" reads worse than it is. But measurements sat at 823 at 18:54, 19:10 and 19:25: the crowd worker has also made zero progress for hours. One cell has 588 attempts. The cause is crowd-experiment-a.mjs:65, which calls rpcLogs('eth_getLogs', ...) directly rather than getLogs(filter, from, to), so it never splits; and dueCrowdHorizons (line 28) only stops on status terminal, which the catch at line 88 never sets, so a poison cell retries every 60 s forever and eats 9 of the 16 task slots per cycle. Same disease as the tape (no terminal state, no backpressure), different immediate trigger (the 10k log cap rather than the server-side range timeout).

What is actually available to backfill

From fomo-events-materialized.jsonl: 211 D3 candidates, and all 211 already have observedBlock, poolId and alertSqrtPriceX96 set, and all 211 have c0/c1 in tokens.json. The gate at line 291 is not the blocker; nothing is missing from the inputs. All 211 first hours are fully in the past. The 211 rows sit on only 21 distinct pools and 29 merged first-hour block windows: 1,487,149 union blocks against 7,444,080 if taped per event, an 80% saving from keying the tape on the pool window instead of the event id.

The fix

Ordered. Steps 1 to 3 are what make the leg run at all; 4 to 6 are what make the number trustworthy.

1. Restart the four workers. Clear the stale collector.lock and join.lock first (acquireSingleton fails closed), then start collect, join, crowd, mark. Nothing else in this list matters until this is done.
2. Do not fix rpc.mjs. It is shared with the live watchtower and smartmoney lanes and D6 keeps Bolo inside research/call-sourcing/. Instead add a local tapeGetLogs(filter, from, to) in mark-experiment-a.mjs that never issues a wide query: fixed 1,000-block chunks, sequential, at most 2 requests per second, halving a chunk once on exceeds limit and rethrowing on anything else. Measured: 1,103 blocks returns 1,942 logs in 2.2 s on the busiest candidate pool. Replace the getLogs(...) call at line 159 with it.
3. Kill the head-of-line block. In runMarkOnce (line 291): sort the tape queue by tapeAttempts ascending, then tapeThrough, so a failing row can never re-take the head; and at line 295 set tapeStatus: 'terminal' after 5 attempts, excluded from the queue and reported in the progress line as tapeTerminal=N. Raise runTapeIsolated's timeoutMs from 15,000 to 180,000. Apply the identical terminal rule to dueCrowdHorizons in crowd-experiment-a.mjs:28, and change line 65 to getLogs(filter, from, to). That one word is the whole crowd fix.
4. Key the tape by pool window, not event id. tapes/<poolId>-<startBlock>.jsonl, one per merged window; each event reads its own offset. 29 fetches instead of 211.
5. Stop paying for per-swap timestamps. attachExactBlockTimes (crowd-experiment-a.mjs:42) fetches a header for every distinct swap block, 100 per batch. peak60mPct is a maximum over the window and needs no time axis at all. Fetch headers only for the window's two endpoints, the peak block and the first block crossing +60%: about 4 per window, about 120 total, on the fast lane. Today's design would need roughly 600 batched calls for the same answer. Also make a null ts a hard error rather than a silent drop: buildCandidateTape:165 filters on x.ts >= startMs, and null >= startMs is false, so a partially failed batch silently deletes swaps.
6. Clamp the price. In buildCandidateTape, reject any point with sqrtPriceX96 <= 4295128739 + 16 or >= 1461446703485210103287273052203988822378723970342 - 16 and record poolDrained: true with pricePct: null. Flag any peak60mPct above 100,000% as implausible and exclude it from the D4 count. Wire samplePeak/updatePeak (lines 145 and 209) into runMarkOnce or delete them: they are dead code today, state.peakOpen is always 0, and the tape is a single point of failure with no fallback.

Backfill cost against the README budget

The unit of work is 29 pool-hour windows, not 211 events. Per-pool swap density was probed once each over 300 blocks at the alert (analysis-2026-09-06/data/a3/pool-swap-rates.json, 20 of 21 pools returned, one hit a 429): 0 to 1,798 logs per 300 blocks, median 240. Extrapolating the alert-moment rate to a full hour gives 855k logs, but that overstates badly: the same probe says pool 0x1badd61a should hold 106,606 logs in its first hour while its actual tape holds 8,243 points over the first 22 minutes, a decay of about 5x. A defensible range is 100k to 250k swap logs across all 29 windows.

• eth_getLogs, public RPC at 2 rps: chunking at 1,000 blocks costs 36 calls per busy window and 1 to 4 per quiet one. Expect 220 to 350 calls, about 3 minutes of pacing and 10 to 15 minutes of wall clock for all 211 candidates. Within the README's 2 rps rule, but it is the endpoint the live follower shares, so run it as one sequential process and watch for 429s.
• eth_getBlockByNumber: about 120 calls on the fast lane under step 5, versus roughly 60,000 block headers under the current per-swap design.
• Alchemy: zero. No eth_getLogs on Alchemy, per README rule 2. Blockscout: zero.

Cheaper still, and worth it if the 2 rps lane feels tight against the follower: getLogsBM in research/smartmoney/rpc.mjs:122 serves eth_getLogs from rpc-robinhood.blockmachine.io in 9,999-block chunks on its own lane, which would cut the 29 windows to 149 chunks on a host the follower does not touch. That endpoint is not in the README's budget table, so it needs Thomas or Rook to bless it before use.

What this decides

D4 is counted at 23:00 tonight. Right now the count is 14 of 30, from 80 first-buys with no proven wallet before them, and the +60% leg contributes 0 rows out of 80 unmeasured. A kill taken tonight would be a kill on a leg that has never run for a single candidate. Steps 1 to 3 plus the backfill are a 10 to 15 minute job on the RPC and should be finished before the count is taken, or the count should be deferred and the deferral written into the freeze file as a coverage failure rather than a population result.

Sources

• research/call-sourcing/scripts/mark-experiment-a.mjs lines 154, 156 to 175, 192 to 200, 251 to 310
• research/call-sourcing/scripts/crowd-experiment-a.mjs lines 27 to 29, 42 to 48, 62 to 71, 86 to 90
• research/smartmoney/rpc.mjs lines 40 to 58 (rpcLogs, guard at 50), 81 to 95 (getLogs), 122 to 131 (getLogsBM)
• research/call-sourcing/data/experiment-a/: mark-state.json, crowd-state.json, marks.json (tapeAttempts, tapeError, peak60mPct, up60At, tapePath, tapeThrough), crowd.json (crowd<H>sError, crowd<H>sAttempts), fomo-events-materialized.jsonl (observedBlock, poolId, alertSqrtPriceX96, provenBefore, provenAfterSec, ageAtAlertSec, mcapAtAlert), tokens.json, tapes/*.jsonl
• research/call-sourcing/progress-experiment-a.md lines for 18:44 to 19:27
• research/call-sourcing/EXPERIMENT-A-ORDERS-2026-09-06.md sections 2 (D2, D3, D4) and 3 (steps 3 and 4)
• Live probes 20:03 to 20:16 Beirut against https://rpc.mainnet.chain.robinhood.com and https://api.dexscreener.com, raw per-pool result in analysis-2026-09-06/data/a3/pool-swap-rates.json

Rook, 2026-09-06 21:00 Beirut. I lead the experiment. This file supersedes the night-one orders (EXPERIMENT-A-ORDERS-2026-09-06.md) where they conflict and stands on the A3 diagnosis (analysis-2026-09-06/A3-TAPE-DIAGNOSIS-2026-09-06.md), which cites every number. Bolo writes only under research/call-sourcing/. Nothing under executor/, watchtower/, data/executor/, data/watchtower/, services, crontab or git is touched. research/smartmoney/rpc.mjs is shared with live lanes and is not edited.

The one decision on the table tonight

D4 (the day-one population kill) is deferred, not taken, at 23:00. The kill rule from night-one orders counts young first-buys with no proven wallet before them that either had a proven wallet within 15 min after or printed +60% within 60 min. The +60% half of that rule has never produced a single measurement: the tape leg made 3,269 attempts and 0 successes since the 01:03 build. The count right now is 14 of 30 on the lead-lag half alone, with 80 rows unmeasured on the +60% leg.

Killing tonight would close the experiment on a leg that never ran. That is not the coverage result D4 was written to protect against; it is an instrumentation failure wearing a population result's clothes.

So: at 23:00, write the deferral into the freeze file as a coverage failure, not a population verdict. Record the 14-of-30 lead-lag count as-is, mark the +60% leg uninstrumented, and set the real kill decision for after the backfill lands (target: before Monday morning). The clock does not reset (D1 stands); we are extending only the measurement, not the window.

Bolo, in this order

Steps 1 to 3 make the leg run at all. Steps 4 to 6 make the number trustworthy. All of this lives under research/call-sourcing/.

Step 1. Restart the four workers. Nothing else matters until this is done. Clear the stale data/experiment-a/collector.lock and join.lock first (acquireSingleton fails closed), then start collect, join, crowd, mark. mark.lock and crowd.lock are already gone. Confirm with a progress line inside 5 minutes.

Step 2. Do not touch rpc.mjs. It is shared with the live watchtower and smartmoney lanes and D6 keeps you inside research/call-sourcing/. Instead add a local tapeGetLogs(filter, from, to) inside scripts/mark-experiment-a.mjs that never issues a wide query: fixed 1,000-block chunks, sequential, at most 2 requests per second, halving a chunk once on exceeds limit and rethrowing on anything else. Measured on the busiest candidate pool: 1,103 blocks returns 1,942 logs in 2.2 s. Replace the getLogs(...) call at line 159 with it.

Step 3. Kill the head-of-line block and add a terminal state. In runMarkOnce (line 291): sort the tape queue by tapeAttempts ascending, then tapeThrough, so a failing row can never re-take the head. At line 295, set tapeStatus: 'terminal' after 5 attempts, exclude it from the queue, and report it in the progress line as tapeTerminal=N. Raise runTapeIsolated's timeoutMs from 15,000 to 180,000. Apply the identical terminal rule to dueCrowdHorizons in crowd-experiment-a.mjs:28, and change line 65 from rpcLogs('eth_getLogs', ...) to getLogs(filter, from, to). That one word is the whole crowd fix.

Step 4. Key the tape by pool window, not event id. tapes/<poolId>-<startBlock>.jsonl, one file per merged first-hour window; each event reads its own offset. The 211 D3 candidates sit on only 21 distinct pools and 29 merged windows, so this is 29 fetches instead of 211, an 80% saving in union blocks.

Step 5. Stop paying for per-swap timestamps. peak60mPct is a maximum over the window and needs no time axis. Fetch block headers only for the window's two endpoints, the peak block and the first block crossing +60%, about 4 per window and ~120 total, on the fast lane. Also make a null ts a hard error rather than a silent drop: buildCandidateTape:165 filters on x.ts >= startMs, and null >= startMs is false, so a partially failed batch silently deletes swaps.

Step 6. Clamp the price. In buildCandidateTape, reject any point with sqrtPriceX96 <= 4295128739 + 16 or >= 1461446703485210103287273052203988822378723970342 - 16 and record poolDrained: true with pricePct: null. Flag any peak60mPct above 100,000% as implausible and exclude it from the D4 count. Wire samplePeak/updatePeak (lines 145 and 209) into runMarkOnce or delete them: they are dead code today.

Backfill and budget

The unit of work is 29 pool-hour windows, not 211 events. Expect 100k to 250k swap logs across all 29 windows.

• eth_getLogs, public RPC at 2 rps: ~220 to 350 calls, about 3 minutes of pacing and 10 to 15 minutes of wall clock for all 211 candidates. Within the README's 2 rps rule, but it is the endpoint the live follower shares, so run it as one sequential process and watch for 429s. The live watchtower is already seeing intermittent 429s on this endpoint tonight; do not run the backfill and a burst of live detection into the same rate ceiling.
• eth_getBlockByNumber: ~120 calls on the fast lane under step 5.
• Alchemy and Blockscout: zero eth_getLogs, per README rule 2.

Blessed alternative if the 2 rps lane feels tight against the follower: getLogsBM in research/smartmoney/rpc.mjs:122 serves eth_getLogs from rpc-robinhood.blockmachine.io in 9,999-block chunks on its own lane the follower does not touch, cutting the 29 windows to 149 chunks. Rook blesses its use for the Experiment A backfill only, read-only, because it removes contention with live money on the shared RPC. Do not add it to any live lane.

What stays from night-one orders

D1 (clock does not reset), D2 (young = under 6h with a known launch time), D3 (quote budget to the candidate population only), D5 (repair scope) and D6 (kickoff non-negotiables, Bolo confined to research/call-sourcing/) all stand unchanged. Only D4's timing moves, and only because its instrument was never live.

Sources

• analysis-2026-09-06/A3-TAPE-DIAGNOSIS-2026-09-06.md (full evidence, live probes 20:03 to 20:16 Beirut)
• EXPERIMENT-A-ORDERS-2026-09-06.md sections 2 (D1 to D6) and 3 (steps 1 to 4)
• scripts/mark-experiment-a.mjs lines 154, 159, 192 to 200, 251 to 310; scripts/crowd-experiment-a.mjs lines 28, 42 to 48, 65, 86 to 90
• data/experiment-a/: mark-state.json, crowd-state.json, marks.json, crowd.json, fomo-events-materialized.jsonl, tokens.json

Lane: Rook. Written: 2026-09-06, 10:30 to 11:00 Beirut (07:30 to 08:00Z). Snapshot boundary: every number below is computed against the frozen copy at analysis-2026-09-06/data/experiment-a/snap/ taken at 2026-09-06T07:30:19Z (snap/SNAPSHOT-AT.txt). Bolo's live pipeline kept running past that point; nothing here reads or writes the live directory except read-only re-checks that are labelled as such. Scorer boundary: --before 2026-09-06T07:33:12Z, explicit ISO. See section 3 for why --before now cannot be used.

TLDR

1. The pipeline is healthy on capture and broken on outcomes. 7,040 rows, 0 holes, 0 collector errors, ingest lag 8.6 s median. But 148 of 184 candidates are marked, and only 5 of 185 marks have peak60mPct, because the A3 tape worker is still stuck. Every path-dependent question in this brief is unanswerable as a result.
2. 144 marks sit on 14 tokens. Four tokens (LIGER 40, 🅿️ 31, UNIPCS 24, BELL 20) carry 115 of the 144. Every event-level cross-tab below is really about 14 observations. Nothing here is statistically real. Treat all of section 2 as hypothesis generation.
3. The strongest event-level signals are token age under 15 min (n=14 marked, median mark60 -1.5%, 43% at or over +60%) and alert ticket at or over $10k (n=32, median -2.6%, 25% at or over +60%), against a baseline of median -44.8% and 19% at or over +60%. Both survive only because they select for the two good tokens.
4. The 5.4 minute lead is a conditional number, not the population lead. Measured unconditionally against feed.jsonl on the 55 tokens both feeds touched: Fomo is first on 45 of 55, median lead 38.2 min, but on tokens under 6 h old the median lead collapses to +13 s, and on tokens under 60 min old the proven wallets actually lead by 40 s. The Fomo edge is in stale mid-cap tokens, which are exactly the ones Gold v2 refuses.
5. On the 15 young tokens both feeds hit, Gold v2's own gates skipped 12 and let 3 through. Skip reasons: heat ceiling 7, mcap over $1M cap 4, age over 60 min 2, liquidity floor 1, band 1. The bottleneck is not detection, it is the universe.
6. No scout survives the scorer. 516 young first-buys, 409 traders, 102 with any mark, and 0 eligible at --min 2 or higher. Seven pass at --min 1, which is one token each and is not a follow list.
7. The smartmoney cohort re-ranked at 8 or more entries gives 6 wallets that clear rug rate under 0.15, m60 hit at or over 50% and m60 median above 0: bluntz_capital, NotARandomUser, macdegods, threem, econoar, FullPinkYak. Three of the 24 wallets with 8 or more entries are not in FOLLOW-LIST.json: ethersole, threem, macdegods.
8. D4 passes on a technicality. 34 events, 33 traders, but only 5 tokens, and 24 of 34 sit on PEZ and 🅿️. All 34 qualify through the proven15m leg; 0 qualify through the +60%-in-60-min leg, because that leg needs peak60mPct, which the stuck tape worker has not produced. Judge D4 at 23:00 on token count, not event count.

1. Pipeline state now

Verified from the frozen files, not from Bolo's progress lines. Re-check commands in Sources.

1a. The A3 tape worker is still stuck, and it is the single biggest hole

mark-state.json at the snapshot: cycles 1840, errors 1692, lastProgressAt 07:20:21Z, lastRunAt 07:32:24Z, phase "tape:alrt_1788637873065_466". That is 92% of marker cycles ending in an error, and the phase is pinned to one alert.

Two alerts account for 1,467 of the 1,693 tape attempts:

Every error is the same string: isolated tape worker failed: Command failed: node .../mark-experiment-a.mjs --tape-worker <id> 1788643281055 <end>. The child exits non-zero and the parent re-queues it with no attempt ceiling, so two dead alerts have consumed the whole tape budget for four hours. There is no terminal_no_route state on any tape row even though D5 pre-registered one.

Consequence: peak60mPct on 5 of 185 marks. No peak path, no drawdown path, no time-to-peak. That kills the Gold v2 ladder replay (section 5) and it kills the second leg of D4 (section 1c).

1b. Error trends, from Bolo's 15-minute progress lines

quoteMisses is pinned at 36 (joins/marks) and 33 (crowd) and has not moved since 07:59, so the D3 quote gate is holding. walletResolved is pinned at 228 to 229 since 08:45, so handle-to-wallet resolution has stalled too.

1c. D4, both legs

D4 (ORDERS section 2): day-one first-buys that are young (under 6 h, known launch time), had no proven wallet before them, and either a proven wallet within 15 min after or +60% within 60 min. Kill if the count is under 30 or it spans fewer than 10 traders.

Token spread of the 34:

Capped at 5 events per token, D4 falls to 20 events, 19 traders, which fails the count threshold and barely clears the trader threshold. The pre-registered rule counts events and traders and says nothing about tokens, so as written D4 passes. It passes because 24 of 34 rows are 24 different people piling into the same two tokens inside a few minutes. That is one observation of a crowd, twice, not 34 observations of an upstream population.

The +60% leg reads zero purely because of section 1a. If the tape worker were running, that leg would be the one that actually tests "the Fomo feed is upstream of price", and it is the one currently unmeasured.

2. The signal

Leakage boundary used: rows are only those with sourceTs before the snapshot at 07:30:19Z; marks were written by Bolo's marker at wall-clock times after each horizon elapsed (leakage-check.mjs verifies markedAt against the horizon, and it does not flag any mark). leakage-check.mjs returns FAIL on the materialized file, with exactly 2 problems, both receivedAt before sourceTs (alrt_1788645437839_2177 at -2,012 ms, alrt_1788645484433_2187 at -3,611 ms). Those are clock-skew rows in the ingest path, not forward-mark leakage. No duplicate ids, no negative provenAfterSec.

Outcome distributions (all marked candidates, net of the $50 executable quote both sides):

Read: the median Fomo alert is down 9.5% at 15 min and 44.8% at 60 min after paying a median 7.8% round-trip cost to get in. The tail is real (19% clear +60% at 60 min) but the body is a bleed.

Cross-tabs, event level, mark60m. Every one of these is 14 tokens wearing 144 hats.

Four things to say honestly about that table:

• Age under 15 min is the best cut and it is 7 tokens. All 14 marks come from 7 distinct tokens, and the 15-to-30 and 30-to-60 buckets directly beneath it are the worst two buckets in the table. A monotone age story does not exist here; what exists is that two of the seven very young tokens ran.
• Net quote flow is U-shaped, which is a measurement artefact, not an edge. The winning tails are outflow under -$2k (n=8) and inflow over $2k (n=15); the losing body is the near-zero bucket (n=114). Near-zero net flow almost certainly means "the crowd measurement found nothing", so this cut separates tokens with real order flow from tokens without, in both directions. Do not build a rule on it.
• proven15m = false beating proven15m = true is a token effect, not an inversion. The 28 marks in the false bucket sit on UNIPCS and 🅿️. It says nothing about proven wallets.
• Wallet confidence tracks nothing. ambiguous (n=12) has the best median at +117 and unique-match (n=20) has -55.5. That is the concentration again, and it means resolution quality is not usable as a filter yet.

Token level, which is the only level with independent observations. 14 tokens.

Three of 14 tokens closed the 60-minute mark above zero. One cleared +60%. That is the whole signal, and n=14 tokens over 11.7 hours is not enough to reject or accept anything. Aggregated by token, no cut separates: youngest-age bucket under 15 min gives 2 tokens with a median-of-medians of -17.8 and 0% at or over +60; the buyers-30s and mcap cuts have 1 to 8 tokens per bucket. The only cut that survives at token level is proven15m (3 tokens with a proven wallet inside 15 min, 67% positive, versus 11 tokens without, 0% positive), which is small enough to be a coin flip and is also circular, since it uses the outcome feed as the predictor.

3. Wallets we could start following

3a. Experiment A scouts: the scorer returns nothing

scripts/score-scouts.mjs was run against the frozen materialized file.

--before now does not work. The script does Date.parse(opt('--before')), and Date.parse('now') is NaN, so BEFORE = NaN, every tsMs(r) < NaN is false and the run reports rowsBeforeBoundary: 0, boundary: null, traders: 0. That is a silent zero, not an error. The brief asked for --before now; I ran it, recorded the result, and then used an explicit ISO boundary. This is a bug worth fixing before the 23:00 scoring run, because the freeze at 23:59 would silently freeze an empty scout set.

With --before 2026-09-06T07:33:12Z:

Eligibility requires nScored >= min, mark60Median > 0, rugRate < 0.34, lateShare < 0.5. No trader in the experiment has two scored young first-buys with a positive median. The seven at --min 1:

Do not follow any of these. Six of the seven have exactly one scored event, four have no resolved wallet, and fmpumpguy is already in FOLLOW-LIST.json as a proven wallet, so it is not a scout discovery at all. pUp60 is null on all seven, again because of the tape worker.

The wider scout table (young first-buys, no proven wallet before, proven within 15 min) shows the same shape: 25 handles with an upstream count of 1 or more, and only xfilesboy has 2. The lead times are noisy and short: skoqv 9 s, googoo22 28 s, dingalingts 56 s, Yoshinvests 58 s, up to macdegods at 1,211 s. Handles with 4 or more young first-buys: xfilesboy (n=4, 75% first, upstream 2, 1 mark at -36.5), Binkieee (n=4, 25% first, upstream 0, 2 marks median +44.2), frankdegods (n=5, 20% first, upstream 0, 1 mark at -51.0, and already on handlesDeny after last night's rugs).

Verdict on 3a: there is no scout list yet. Come back after the tape worker is fixed and 24 more hours have run.

3b. Smartmoney cohort, re-ranked for a follow decision

From snap/smartmoney.json (updatedAt 07:28:02Z, 40 wallet rows, 100 tracked). hit is the percentage of marks above zero (watchtower/smartmoney.mjs:180), not a count. 24 wallets have 8 or more entries.

All 24 are inside Gold v2's universe today in the sense that Gold v2 triggers on the first on-chain buy by any proven wallet and takes its cohort from FOLLOW-LIST.json. 21 of the 24 are in that file. ethersole, threem and macdegods are not, so Gold v2 does not currently see their buys at all. Two of those three (threem, macdegods) sit in the top 4 by m60 hit rate with zero rugs, which makes them the only actionable "add" on this page.

Who survives a 0.15 rug-rate ceiling (which is already live: universe.maxWalletRugRate: 0.15, minWalletEntriesForRugRate: 8, shipped this morning by the rug lane, fixes-2026-09-05/FIELDS.md):

• Survive at 8 or more entries: bluntz_capital (0/8), NotARandomUser (0/9), macdegods (0/8), threem (0/9), econoar (1/19), FullPinkYak (1/12), ethersole (0/9), SolSwizzle (1/11), iruletrenches (0/10), Milliardi (1/10), m0f0 (1/9), 0xdedrater (0/9). 12 of 24.
• Blocked by the ceiling: facap (0.20), FartmanSacks (0.20), ericzhong (0.25), TheHappySwan (0.25), Binkieee (0.235), Aurelius0121 (0.222), seralberttrades (0.273), fr3ak (0.167), elliotrades (0.222), frankdegods (0.154, just over), Rowdy (0.231), rasmr (0.375). 12 of 24. frankdegods is also on handlesDeny in executor/follower.json, so it is now blocked twice.
• Wallets with fewer than 8 entries are not judged by the gate and pass. That includes 0xAvast (m60 5/60/+13.1), ogle (6/67/+12.1), BTCdayu (6/67/+8.6), brrrgrrrz, AvgJoesCrypto, Tsukikage, soby0x. soby0x at m60 5/80/+2.9 is the best hit rate on the whole board and has 6 entries.

The follow shortlist, wallets clearing rug rate under 0.15 and m60 hit at or over 50% and m60 median above zero:

n is 6 to 19 marks per wallet. This is a shortlist, not a proof.

4. Behaviours worth following

Patterns, not people. Evaluated over all 3,221 Fomo buy rows, with the mark subset attached. provenIn5m is the fraction of rows where a proven wallet bought the same token within 5 minutes after; the unconditional base rates are 7.1% at 5 min and 14.8% at 15 min.

Reading:

• The brief's example behaviour, B2 ("first Fomo alert on a token under 15 min old and under $300k, followed by a proven-wallet buy within 5 min"), has n = 0. Not a weak result: it never happened once in 11.7 hours. The Fomo feed's alerts on sub-15-minute tokens all landed at mcaps of $450k or above. That rule cannot be tested on this data and should be widened or dropped.
• B1 and B8 are the two candidates worth carrying forward. Both roughly double the proven-follow rate over baseline (13% and 10% versus 7.1%) and both lift the +60% rate (43% and 25% versus 19%). Both are computable from what we already log at the instant the alert arrives, no chain call, no 30-second wait. B1's n of 14 marks across 7 tokens is the whole caveat.
• Crowd-count behaviours (B5, B6, B7) are anti-signals. Requiring more Fomo traders makes the median outcome worse (-46.9 at 3+, -58.1 at 5+) while barely moving the proven-follow rate. The crowd arrives after the move, which matches the token table: LIGER had 40 marked events and a -63% median.
• B9 and B10 are the only cuts with a genuinely elevated proven-follow rate (39% and 33%), but they need a 30-second chain measurement, which is 30 seconds of the 8.6-second edge spent, and their n is 18 and 3.
• B11/B12 ("we saw it first") do not pay. Being upstream of the proven wallets is worth nothing at these medians: -54.9 and -60.0.

5. The latency edge

5a. What the lead actually is

REPORT-capture.md states a 5.4-minute median Fomo lead. That number is the median of provenAfterSec over the 23 D4 rows, and D4 conditions on a proven wallet arriving within 15 minutes. It is a truncated distribution bounded at 0 to 900 s, so 5.4 min is "given that a proven wallet showed up soon, it showed up 5.4 minutes later". It is correct as written and it is not the population lead.

Measured unconditionally against data/watchtower/feed.jsonl (1,421 proven-wallet rows, 200 of them in the Fomo window on 112 tokens):

Lead buckets across the 55: over 15 min 32 · negative 10 · under 60 s 8 · 1 to 5 min 3 · 5 to 15 min 2.

The Fomo feed's real lead lives entirely in old tokens. The top of the lead table is HOTDOG (+464 min, token age 72 h), PROLOGUE (+421 min, age 19 days), MOO (+372 min), CHROME (+314 min, age 45 h). On young tokens the two feeds are simultaneous, which makes sense: both are watching the same launches.

There are also 104 tokens the Fomo feed saw that the proven wallets never touched, and 57 the proven wallets touched that never appeared in the Fomo feed. The overlap is 55 of 216. These are largely different universes, not one leading the other.

5b. Where the edge actually is: Gold v2's own gates

Every one of the 15 young overlapping tokens carries a Gold verdict from feed.jsonl:

Skip reasons: heat ceiling 7, mcap cap 4, age ceiling 2, liquidity floor 1, band 1. Three went eligible, and the three are exactly the ones whose 1-hour run was under the 500% ceiling Gold v2 now carries (MUPPETS +222%, LIQLORACLE +298%, hoodrat +480%). The verdict strings quote a +200% ceiling because they were written by the feed under the older config; the current universe.maxRunH1Pct is 500.

So the latency edge does not convert today. Even if a Fomo trigger were wired straight into the executor, 12 of 15 co-occurring young tokens would still be refused, and the refusals are dominated by the two gates that were both fitted on last week's tape: the heat ceiling and the $1M mcap cap. UNIPCS, the single best token in the whole experiment at +112% median over 24 marked events, is refused for mcap $3.5M.

5c. The replayed outcome distribution

Ticket $50, hold to the mark, marks already net of the executable quote both sides. netUsd is the mean outcome times the ticket times n, that is, what the book would have made or lost across every trigger it fired.

With a 120-minute per-token cooldown applied (the same entry.cooldownMinPerToken Gold v2 uses), every book collapses to a handful of trades because there are only 14 marked tokens: T0 goes to 351 signals and 14 marked, median -53.6, net -208. T3 goes to a single marked trade. The cooldown is the honest view and it says the sample is 14 trades, not 3,221.

Three books are positive at 60 minutes (T3, T4, T6) and all three are positive because of UNIPCS and 🅿️. T10, the closest thing to a Fomo-triggered Gold v2, is the worst of the filtered books at -74.9% median with 71% of trades at or below -50%.

5d. What is missing for a Gold v2 ladder replay

A Gold v2 ladder replay is not computable from the marks on disk. The ladder is a path-dependent policy: exit.stopLossPct -45, exit.noProgressMin 30 at noProgressPct 10, clips at +60% (half) and +200% (a quarter), trailingStopPct 40 relative stepping to 25 after +200% is seen, timeStopMin 90, breakevenAfterClip. Evaluating it needs a price series between the entry and the exit. The marks are three point samples at 15, 60 and 240 minutes.

Precisely, the missing field is peak60mPct, which is set on 5 of 185 marks, and its companions up60At (1 of 185) and poolTick15m (2 of 185). The intended source is the per-alert tape under research/call-sourcing/data/experiment-a/tapes/, and there are 6 tape files for 148 complete entries. Without the tape there is no way to know whether a trade that shows -44.8% at 60 minutes touched +60% at minute 12 and would have clipped half the position, or whether it fell straight through the -45% stop at minute 3. Those two histories produce opposite books from the same mark.

Fix the tape worker and this section can be rerun properly. That is the one dependency.

6. What to run tonight

6a. The single unblocking change: the A3 tape worker

Highest value change on the whole page, and it is small:

1. Cap tape attempts. alrt_1788637873065_466 has 736 attempts and alrt_1788637953286_478 has 731. Add an attempt ceiling (5 is plenty) that moves a row to terminal_no_route, which D5 already pre-registered as one of the four legal mark states and which currently appears on zero rows. Two dead alerts have consumed 87% of the tape budget for four hours.
2. Surface the child's stderr. Every one of the 9 errors is the same truncated Command failed: node ... --tape-worker <id> <from> <to> with no captured stderr, so nobody can tell whether this is an RPC problem, a pool problem or a decode problem. One line of e.stderr in the catch is the whole diagnosis.
3. Reconcile the counter. mark-state.json reports tapes: 25; tapes/ holds 6 files. One of the two is lying, and the progress digest reads the counter.

Everything else on this page (the +60% D4 leg, pUp60 in the scorer, the ladder replay, peak-based exits) is downstream of these three.

6b. Two shadow sets to run on paper tonight

Both are expressible in the existing watchtower/rules-v2.json vocabulary. Neither is live, neither alerts, both are logSkips: true so the refusals are countable in the morning.

Set A, "Gold-wide". kind: "wallet". Tests section 5b directly: is Gold v2's universe, not its detection, what is costing us the Fomo-adjacent tokens? Identical to Gold v2 except three gates:

universe.maxMcapUsd      1000000 -> 4000000     (would admit UNIPCS $3.5M, RKST $5.1M stays out)
universe.bands           + "1M to 3M"           (would admit the 🅿️ skip)
universe.maxRunH1Pct     500 -> 1200            (would admit RSTR +633%, hoodrat +480%, TEST +1040%)

Everything else held: minAgeMin 2, maxAgeMin 60, minLiquidityUsd 25000, maxLiquidityUsd 400000, rugRatio {maxLiqToMcap 0.85, underAgeMin 60}, maxWalletRugRate 0.15, minWalletEntriesForRugRate 8, entry.maxOtherCohortWallets 1, entry.maxChasePct 25, entry.minBuyUsd 100, and the Gold v2 exit ladder unchanged. The feed.jsonl verdict string records only the first failing gate, so the exact number of extra entries this set would have taken on the 15 co-occurring tokens cannot be read off the table; what can be read is that 12 of the 15 refusals cite one of these three gates as the first failure. Reading it in the morning: if Gold-wide's paper median beats Gold v2's over the same night, the universe is the binding constraint and the mcap cap is the first thing to move.

Set B, "Fresh-flow". kind: "momentum". Tests B1 (age under 15 min) without needing a wallet trigger, because shadow.mjs already supports kind: "momentum" and fires it from the pair scan (evaluateMomentum, shadow.mjs:920), no new plumbing:

universe: { minAgeMin: 2, maxAgeMin: 15, minLiquidityUsd: 25000, maxMcapUsd: 1500000, quoteAllow: ["WETH","USDG"] }
entry:    { minM5VolumeUsd: 15000, m5PaceX: 2.0, m5MovePctMin: 5, m5MovePctMax: 400,
            minBuyShareM5: 0.60, maxAboveLowPct: 120, minHistSamples: 3, cooldownMinPerToken: 120 }
exit:     Gold v2's ladder verbatim

The minBuyShareM5: 0.60 is the tuning lane's buys-to-sells idea in the one place it is already implemented. Known gap, say it out loud: momentum sets do not run rugRatioSkip() or walletRugRateSkip() because there is no wallet on the signal, so Set B has no rug gate beyond the liquidity floor. It must stay live: false until that is addressed. Given last night's ZEP/PEZZED/PEZ write-offs, that is not a formality.

6c. What the D4 kill decision at 23:00 should be judged on

The pre-registered rule (ORDERS D2/D4) is count 30 and traders 10, and it was written so it could not move. It should not move. But the count it produces should be reported next to what it is actually made of:

• Report the token count alongside the event count. Right now D4 reads 34 events / 33 traders / 5 tokens, with 24 of 34 on PEZ and 🅿️. Capped at 5 events per token it is 20 events / 19 traders, which fails. The freeze file should record both numbers, so that a later reader can see that D4 passed on a crowd rather than on a population.
• Report the leg split. 34 from proven15m, 0 from the +60%-in-60-min leg, and the reason for the zero is the tape worker, not the market. A D4 that passes on one leg with the other leg instrumentally broken is a weaker pass than the rule text implies, and the freeze should say so.
• Do not let --before now write the freeze. Date.parse('now') is NaN and the scorer silently returns zero traders and zero scouts (section 3a). At 23:00, pass an explicit ISO boundary. Confirm rowsBeforeBoundary is non-zero in the output before writing the freeze file, and note that score-scouts.mjs refuses to overwrite an existing freeze (exit 3), which is correct and should not be worked around.
• Do not treat "D4 passes" as "start following scouts." Section 3a is unambiguous: 0 eligible traders at --min 2. Whatever D4 says, the day-two ticket rule has no roster to hand it.
• Projection, for what it is worth: 2.9 D4 events per hour over 11.7 hours. If the rate holds to the 23:00 close the raw count lands near 70. The rate is not the question; the token spread is.

Sources

All computations against the frozen snapshot at analysis-2026-09-06/data/experiment-a/snap/, taken 2026-09-06T07:30:19Z.

Not answered from disk: whether the tape worker's child process fails on RPC, pool state or decode. The error string is truncated at Command failed and no stderr is captured. Reproducing it would mean running mark-experiment-a.mjs --tape-worker, which is Bolo's process and out of scope for a read-only lane.

Digest for Thomas 09:00

Experiment A, day one, hour 8.4 of 24 (20:05Z Sat to 04:27Z Sun).
Rate: 648 events/h, 297 buys/h, 5637 rows, 2586 buys, 1735 traders, ingest lag median 8.7 s.
Coverage by token age at alert (buys): under 15m 136 · 15 to 60m 174 · 1 to 6h 426 · 6 to 24h 229 · over 24h 1292 · unknown 329.
Candidates (D3, under 6h and mcap under $3M at alert): 139. Upstream (no proven wallet before, one after): 16.
Wallet resolution: 813 of 2586 buys carry a wallet, 31%, up from 12% at hour one.
Holes: 0. Quote misses: 36 of 139 candidates, 26%.
D4 count now: 23 young first-buys, 22 traders. Thresholds are under 30 or under 10 traders at Sun 23:00.
D4 trend: NOT trending to kill on the count (23 at hour 8.4 projects to about 66), and already clear on traders.
Caveat that decides it: the +60% leg of D4 has fired 0 times because peak60mPct exists on 5 rows of 5637.
The whole D4 count is the proven-within-15-min leg, and 13 of 23 sit on one token, PEZ, which then rugged.
Read: the Fomo feed is real but shallow. It leads our proven wallets by a median of 5.4 minutes, not hours.
Bigger hole: 10 of the 12 tokens that ran +100% overnight with no proven-wallet buy are not in the Fomo feed either.

Built 06/09/2026 22:10:01 Beirut. Source files under projects/crypto-2026-09/analysis-2026-09-06/.