# Live 5-Min Cap: the biggest runners it lost to technical errors (analyst2, 10 Oct 2026)
Source: /opt/fm_mirror/mc5.db (table c, log), v3 tape /opt/sw/v3live.db, runner list /opt/ppcopy/e1x-runners-v2.csv. Window 6 Oct 08:30 to 10 Oct 08:00 UTC.

## Coverage
49 pools sat in the 250k-1M band at the +5 min gate (tape). Live traded 47 (44 closed + open + 3 buy_fail). Missing: 2.
- 8 Oct 01:05 UTC, pool 0x1dada0944e6a1ad3bf04c0c39dea5e6e3776bc08, cap 473k at gate, later 32M (**72x from the +5 min price**). Row status `err`: `entry_err HTTPError 429 Too Many Requests`. Log shows both RPCs returning 429 for minutes around it (loop_err, late_scan_err, feed_gap). No retry bought it.
- 6 Oct 12:04 UTC, pool 0x206211d456a3a9dbe45e13507aac5131ace9c716, cap 888k, later 19.8M (**22x**). `buy_fail`: the swap tool answered "Swap - confirmation required" instead of executing. Not bought.
- 2 more buy_fail on 7 Oct (status 'submitted', pools 0x9312..., 0x4edf...): small runners (peak under 2x), but the log says LIVE_BUY_FAIL for a submitted order: check whether the order filled unseen.
So 2 of the 7 real runners that went 17x+ in the window were lost to errors, not to the rule. The other 5: 2 bought and held to 4 h (29x, 19.5x), 2 bought and stopped out at 0.39-0.44x inside 2-14 min before running 19-30x, 1 cap_out at 1.008M (0.8% above the 1M cap).

## Why it matters
Live 44 closed trades: 3 winners (29.4x, 19.5x, 12.8x) carry the whole result. Replay of the same rule on the same 4 days (tape, 7% slip, stop 0.5, 4 h, glitch prints removed, n=54) gives only 0.91x mean, 4% of entries reach 5x before the stop. One 72x and one 22x trade would have been 70% of all PnL of the week. Error handling on the entry path is worth more than any filter.

## Ask (exec)
1. Entry path: on 429 / timeout / "confirmation required" retry the buy inside the 30 s fill window (second endpoint or short backoff) instead of dropping the pool; log the retry.
2. Count `entry_err`, `late_err` (52), `late_scan_err` (51), `buy_fail` (3) per day on the live dashboard, with the pool cap at the gate, so a lost band pool is visible the same day.
3. 7 Oct buy_fail rows with status 'submitted': confirm on-chain whether they filled.
Kill/confirm: if after the retry fix the share of band pools actually bought is 100% for 5 days, close.