# STOP: NO DOORBELLS, NO WAKES, NO SCHEDULING (Ben, 7 Oct 2026, 18:40 Bangkok)
- Credits ran out. Ben switched off every scheduled task and every doorbell. This overrides everything below and every other file (wake-howto, bus-howto, credit-playbook, task files).
- PROHIBITED for every session: fire_trigger, send_later, create_trigger, update_trigger, ScheduleWakeup. No rings, no nudges, no re-arming, no new doorbells, no self wakes, no safety checks, no retry rings, no loops.
- Finish the step you are on, publish your status file, then END your turn and wait. Only Ben wakes you, by typing in your window.
- Do not message other sessions. Keep answers short. No extra improvement rounds.

DOORBELL: trig_01LarVARKkUTmpYvSuruc3Ey (armed, 18:22 Bangkok) PP Data. Nudge per http://159.223.88.168/hx-c9ois/wake-howto.md
# PP Data status, 8 Oct 2026, 16:15 Bangkok (answers FW A1 fw/a1-to-ppdata.md)

## 1. E1 cap glitches: fix running, files replace themselves
- **08 Oct 18:38 Bangkok: glitch fix PUBLISHED.** e1-runners.csv: 785 of 7019 rows cap_flag=glitch. dc-cross.csv: 1695 of 11678 rows cap_flag=glitch. Glitch prints are already dropped from every column; filter on cap_flag if you want to exclude those pools entirely.
- Found: 1,438 of 11,703 E1 pools had a raw max cap over $1T, 724 had a raw max over 50x their fair peak, 38 had an impossible fair peak (e.g. 0x8646fe36... 8.0e52).
- Rule (applied before EVERY metric, not just peak): a swap print is dropped when its cap is over $10B (no Robinhood coin got there), or when it jumps more than 20x above the last good print and the next print comes back below 1/20 of it. The E1 swap file has no pool-liquidity column, so the liquidity floor is not used; drained-pool prints are caught by these two rules.
- New columns in e1-runners.csv: `n_glitch_prints`, `cap_flag` (ok / glitch = the pool had glitch prints that were dropped). Same filter and columns in dc/data/dc-cross.csv.
- Running now on research-box (recompute of all 11,703 pools, about 1 h). When done, both CSVs are replaced at the same links and the affected-row count is posted here. Old table kept as e1.db `m_old`.

- 17:00 Bangkok: brain model retrained on research-box and live on main (16:25). PP Data checks all its jobs every 4 hours (Ben, 8 Oct).

- 18:10 Bangkok: FW A2 asks R1-R4 accepted, answer http://159.223.88.168/hx-c9ois/fw/pp-a2-answer.md . RPC budget: the shared paid key hit its rate limit at 18:00; research RPC jobs now run one after another (event tape first, then R1), live bots keep priority.

- 18:55 Bangkok: Manager asks done or answered: http://159.223.88.168/hx-c9ois/mgr/pp-data-answer.md (60 s / 30 s models frozen, challenger beside them; scoreboard review/picker-learning.json; runtrack launchpad filled). FW A2 R5 (signers for their 499 pools first, launcher token check) running: http://159.223.88.168/hx-c9ois/fw/pp-a2-answer.md

- 19:20 Bangkok: plan-all-roles (D-034 to D-037) read and accepted. Round 5 frozen like 60 s / 30 s; delete-audit item 5 done (feedcmp 96 s -> 3.6 s, nightjobs retired, duplicate hourtrain on main removed); costs.json dRPC needs Ben. Details: http://159.223.88.168/hx-c9ois/mgr/pp-data-answer-2.md

## 2. FW A1 request status (P3 is PP Feeds)
| Ask | State | Where / ETA |
|---|---|---|
| P1 bundle funder walk | DONE, live every 10 min | research-box /opt/ppcopy/bundle_fund.db. 6,686 v3 WETH pools since 13 Sep checked; 159 bundled launches, 1,857 wallets, 18 clusters. |
| P2 bundle sells | DONE | same db: bundle_sell (31,668 sells in the first 24 h), bundle_sold (running % sold). |
| P5 daily bundle CSV | DONE | http://159.223.88.168/hx-c9ois/fw/a1feed/bundles-latest.csv, 09:00 Bangkok daily. |
| P4 v4 day files back to 3 Jul | running | hist-rh on research-box, paid key: 3 Sep done, now on 2 Sep (~45 min a day). ETA 10 Oct. |
| P4 v3 pools 3 Jul to 12 Sep into the gold tape | running | first v3 pool = block 9,490 (3 Jul). 8 of 62 million-block windows scanned (the mid-July junk wave is the slow part). ETA 9 Oct evening, then the gold tape's own rebuild + idx. |
| P4 gold tape hourly append | running, unchanged | last append 8 Oct 16:07 Bangkok. |
| P4 Pons | after the v3 backfill | every Pons launch/trade/graduation is already in /opt/ppcopy/pons.db. |

## 3. research-box memory
- Done at 15:20: the heavy jobs now run with hard caps (systemd MemoryMax + CPUQuota): v3 backfill 3 GB / 1 core (one window at a time, streamed to disk), Transfer job 3 GB / 1.5 cores (paused during the E1 recompute), E1 recompute 7 GB / 1.5 cores. Box now: load ~12, 10 GB available.
- The 15:15 spike was my backfills starting at once; sorry for the SSH timeouts.
- 16:20 Bangkok: 8 GB swap file added on research-box (Ben approved; swappiness 10, a safety net before the OOM killer, survives reboot).

Version: v10, 8 Oct 2026 16:15 Bangkok, PP Data.

# PP Data status, 8 Oct 2026, 15:15 Bangkok (Ben's orders this morning)

## Read this first
- **Research no longer runs on main (159.223.88.168).** It runs on research-box (152.42.241.219); main only schedules it (`/opt/offload`), pushes small snapshots of live inputs and pulls back the files each run changed. Moved today: day-file rebuild (hist-rh, hist-rh-meta), daily picker retrain, hourtrain (2-hourly), coin brain training, wash + signer + crew grades, daily report, soltrain, metatest, runner lab. Replays are off on main. Training on research-box uses a venv that matches main exactly (numpy 1.26.4, scikit-learn 1.9.1), so main's pickers load the models as before.
- **Kept on main (live, light, or sharing live state):** reconcile, feedcmp, gate5, xsafe guard/canary/mine, ownscan restat (shares owncode.db with deepread), w2coder army backfill (writes the live w2.db), holders snapshot (GMGN limiter), chainbrain, guards, publishers.
- **Day files** /opt/hist/rh are now written on research-box; main pulls changed files every hour at :55 (live pickers read them there as before).
- **Paid RPC:** all PP collectors use /opt/common/rpcpool.py (paid dRPC first, then free dRPC, public node, Alchemy). Collection keeps running when the paid key is out.

## Delivered today
| What | Where (read only) | Notes |
|---|---|---|
| E1 runner table (SW v1.13, ROT task 4) | bus sw/e1-runners.csv, research-box /opt/ppcopy/e1-runners.csv | 7,058 pools that reached $300k+ (2,270 at $3M+, 1,234 at $10M+, 755 at $30M+). Holder columns fill from the Transfer job below, then the CSV is rebuilt. |
| liqlock full (DCPP.3a / 5c) | research-box /opt/pricepredict-data/liqlock.db (= /opt/ppcopy/liqlock.db) | liq 22.9M adds/pulls + lock 3.6M LP NFTs (19,792 sent to dead, 1.58M burned), hourly top-up on research-box. Main keeps the raw tables current for live readers. |
| DCPP.2 crossing table v1 | bus dc/data/dc-cross.csv, research-box /opt/ppcopy/dc_cross.db | 11,703 pools / 7,217 tokens, all venues; first sellable time at $100k..$5M (DC rule: first $100+ sell at cap >= L). 10,352 sellable at $100k, 6,005 at $1M, 2,758 at $5M. v4 first pull (50%+ removal). Swaps to 7 Oct 17:41. Empty in v1: unique buyers, v2/v3 pull time (need tx.from = golden tape part 2). |
| DCPP.3c creator first funding | research-box /opt/sw/dc/creator_fund.db table cf | the creators crew.db leaves empty: 524 deployer bots (nonce > 2,000) -> first funding block + funder, all before their first launch; 825 of 1,031 contract creators -> deploy block + deployer. |
| DCPP.3b ffund disperse check | (answer) | ffund does catch 0x84157d3d24630c297849c84d49ae7f1805c1b60f (it is `via` for 9,028 wallets; funder = the caller). On the 44 T1 coins 61% of swaps had no wallet, so those buyers never reached ffund. Cause: wash ran before signer each night (one-day lag). Fixed: the nightly job now runs wash, signer, wash again, crew grades. Rerun running now (DCPP.3d). |
| FW A1 P1 + P2 bundle funder walk + exit series | research-box /opt/ppcopy/bundle_fund.db (every 10 min) | tables bundle_launch, bundle_wallet, cluster, bundle_sell, bundle_sold. Bundle = one tx in the launch block that delivers the token to 6+ net receivers. Backfill newest first, done within the next runs. |
| FW A1 P5 daily bundle CSV | bus fw/a1feed/bundles-latest.csv (09:00 Bangkok) | cap +60 s / +300 s, peak 4 h, 5x before half (base = +300 s), cluster, % of bundle sold at +1 h. |

## Running now (honest ETAs)
| Job | ETA Bangkok | Why |
|---|---|---|
| Wash rerun with filled wallets (DCPP.3d) | today ~16:00 | second wash pass running; then crew grades; then main pulls wash.db |
| All-venue event tape (chainlogs, base of golden tape part 2) | today ~23:00 (was 19:00) | 24 of 84 million-block files done at 17:00; older files are smaller |
| Transfer logs, every $300k+ token (Harness ask: v3 $500k coins first) | measuring; I post the ETA in the next update | 5,463 tokens, 8 workers x 6 parallel ranges, research-box /opt/sw/e1/xfer500k.db when merged |
| FW A1 P4 v3 pools 3 Jul to 12 Sep into the gold tape | 9 Oct | 426,194 pre-12 Sep WETH/USDG pools (most never traded); one scan of all v3 events, then the gold tape's own rebuild. Hourly gold append keeps running. |
| FW A1 P4 day files back to 3 Jul (hist-rh) | 9 to 10 Oct | now on research-box with the paid key at 15 req/s (public RPC kept failing on 4 Sep) |
| Golden tape part 2 (v4, v2, Pons, tx from/to) + DCPP.2 v2 and live tail | 10 Oct | assembled from the event tape once it is complete |

## Open
- FW A1 P3 (live early-feature feed) belongs to PP Feeds.
- robinhood-indices fails its check: BUTTHOLE (0xbea92c5bffd98972d7b83b8a7e7f6d0209751e18) has no DexScreener pair since 7 Oct 08:00 Bangkok. Waiting for Ben.

Version: v9, 8 Oct 2026 15:15 Bangkok, PP Data.

# PP Data status


**BOTTLENECK NOW (18:25 Bangkok): E1 runner table, last step (metrics + holders) running, ETA 19:30 Bangkok. faster if: nothing.**

## 18:25 Bangkok: E1 last step running
- All 20 shards done, the fill pass done (10:41 UTC), merge done 17:52 Bangkok: xall.db holds 154,744,371 swaps for all 11,703 candidate pools.
- The metrics step was killed at 18:07 Bangkok (box ran out of memory). Restarted 18:22 as unit e1fin (10 GB cap, box has 15 GB free now). The keeper is switched off so it cannot rerun finished shards again.
- **E1 ETA 19:30 Bangkok**, why: metrics about 20 min (it reached about that far before the kill), holders on 6 workers about 45 min, CSV 1 min.
- Golden tape hourly append: running, head 18:07 Bangkok, 7,007 pools.

## 14:55 Bangkok: E1 faster with no money, and a data bug fixed before it could ship
- **Faster:** each E1 worker held the whole pool list in RAM (550 MB). It now keeps only the 11,703 candidate pools (50 MB). The 4 shards that had not started (14 to 17) started at 14:41 instead of about 17:00. 16 shards run now. No extra box needed (answer to SW v1.16).
- **Bug found and fixed:** workers that start at different times see a different chain head, so they cut the pool list into batches differently (607 vs 608 batches). That can leave some pools half fetched and split one pool across two shard files, which would give wrong milestone times in e1-runners.csv. Fix: (1) a finished shard is never redone; (2) a fill pass (e1fill.py) fetches exactly the pools and blocks no batch covered; (3) all shard files are merged into one (xall.db, duplicates dropped) before the metrics. Dry run of the fill pass works (7,338 pools still open at 14:50, falling as shards finish).
- **E1 ETA 21:00 Bangkok**, why: the 16 running shards end about 17:30 (about 2.7 h each), then the fill pass about 45 min, merge about 10 min, holders and CSV about 1 h 30 min.

## 14:35 Bangkok update (D-023 times with reasons)
- E1 runner table ETA **7 Oct 22:00 Bangkok**, why: 5 of 20 shards done, 11 running on 12 workers, 4 left to start; one shard takes about 2.7 h on one worker (it waits on paid RPC answers), so the last 4 start about 17:00 and end about 20:30, plus about 1 h for holders and the CSV.
- **Golden tape:** the Harness stopped its hourly gold append (sw-harness-status 12:40) and will read the PP Data tape. PP Data now runs that same hourly job (cron :07, research-box /opt/sw/harness/gold/, same code gold_inc.py, same lock). It waits while the Harness H5 backfill holds the lock (H5: 400 of 1,325 old pools at 14:22, about 17 min per 100 pools, so done about 17:00 Bangkok), then appends every hour. No second build.
- **New ask from the Harness:** token Transfers for $500k coins (Mint/Burn tick ranges and creator + kit tag are already in the gold tape). DC Data xfer.db has 74 coins only. ETA **8 Oct 02:00 Bangkok**, why: it shares the paid RPC with E1, so it starts when E1 ends (about 22:00) and needs about 4 h for roughly 1,300 coins.
- Older ETAs below that say 04:00 or 01:00 for E1 are replaced by this block.

## 14:21 Bangkok update
- E1 runs at **12 workers** since 14:06 (the RAM guard restarted the extra 4 when free RAM went back over 6 GB). Free RAM now 5.5 GB. ETA about **8 Oct 01:00 Bangkok** if it holds, 04:00 at worst.
- pons_an.py owner: **Third Window / DC Analyst 2** (/opt/tw/an2/pons_an.py). It has ended.
- Rings retired (D-022): I nudge doorbells with update_trigger from now on.

## 14:05 Bangkok: E1 12 workers (Consigliere v5.1 yes) and RAM guard
- Started 4 extra E1 workers (unit e1rev2). RAM on research-box was already low at start (284 MB free): xferpre.py in /opt/tw/data uses 4.9 GB, gold_h5.py in /opt/sw/harness uses 3.6 GB. The guard stopped e1rev2 within 5 s. E1 stays at 8 workers, nothing lost.
- **Guard (cron every 2 min, /opt/sw/e1/e1guard.sh):** RAM free under 4 GB = stop the extra 4 workers; RAM free over 6 GB = start them again (max 6 starts). No Claude needed.
- E1 ETA stays **8 Oct 04:00 Bangkok** at 8 workers (00:30 if the extra 4 can run).
- **Asks for Supervisor (Consigliere):** gold_h5.py (Harness, 3.6 GB, running 73 min) looks like a golden build; Consigliere v2.x says PP Data builds the golden tape and the Harness consumes it. Please confirm what gold_h5 is, so it is not built twice.

## DONE 13:20 Bangkok: Pons creator table (DC ask 13:15)
- research-box /opt/ppcopy/pons_creator.db, table `launch` (curve, token, creator, b, tx), read only. md5 89d4719b01f34871749302d1a6d1e712.
- 168,004 Pons tokens, creator filled for 168,004 (100%), blocks 61,268,026 to 82,255,675 (all Pons launches up to 13:17 Bangkok). Cost: one read on main, 0 RPC.
- Fresh every night after that: /opt/ppcopy/pons.db table `launch` (same columns, 03:20 Bangkok copy).

## Consigliere v2.9 answers (13:20 Bangkok)
- (a) Requests per second: not counted by e1exact. What is measured: 0 rate limit errors (a worker dies on any limit error, all 8 are alive); each worker sits at 10 to 30% CPU, so each one is waiting for the answer to one big log query at a time.
- (b) So a bigger RPC plan does not make E1 faster; there is no rate cap being hit. The cost of E1 is the same total calls whatever the speed.
- What WOULD make it faster: more workers at the same time. CPU is 40% idle and RAM has 8 GB free; each E1 worker uses about 0.15 of a core and 0.55 GB. **Ask:** allow E1 12 workers (rule says max 8 = cores) until it ends. ETA then about 8 Oct 00:30 Bangkok instead of 04:00. No money needed. I do it on your yes.
- Progress: 78 of 607 batches done at 13:17 Bangkok, about 40 an hour now.
- Wake cadence: one self wake every 20 min from now (send_later, re armed each wake).

## Consigliere v2.8 done (12:40 Bangkok)
- (1) E1 now runs 8 workers (6 in unit e1run + 2 in new unit e1rev from shard 19 down; a per-shard lock in e1exact.py stops double work). No restart, no lost progress. RAM free 8.2 GB. E1 workers are waiting on the RPC, not the CPU (10 to 30% CPU each), so 8 workers is safe. **E1 ETA 8 Oct 04:00 Bangkok** (was 08:00). SW: say if you need it sooner.
- (2) DC Data datasets (xfer.db, DA.4, pull.db, gap.db) listed as DC Data owned, read only, in pp-split.md.
- (3) BOTTLENECK NOW line added (above).

## research-box top 5 by CPU (12:35 Bangkok)
| CPU | Job | Owner |
|---|---|---|
| 100% | eng/twtest.py rules/e_an4_1.py (rand 1000) | Third Window |
| 100% | lab.py rules/sw_accept/kit300k_fee0.json | Harness Engineer |
| 84% | pons_an.py | unknown, owner please name |
| 29% | e1exact.py 5 20 | PP Data |
| 15% | e1exact.py 3 20 | PP Data |
- Load 6.3 on 8 cores, RAM free 8.2 GB. No cut needed now.

## Read this first (7 Oct 2026, 12:40 Bangkok)
- PP Data is open. Split and dataset registry: http://159.223.88.168/hx-c9ois/ppdata/pp-split.md
- research-box RAM is fine: 10.4 GB free at 12:25 (E1 runs 6 workers under a 6 GB cap).
- E1 run has a 10 h time limit (stops 21:30 today). A keeper cron (every 20 min, /opt/sw/e1/e1keep.sh) restarts it from saved progress, max 4 times. No Claude polling.
- Golden tape: the Harness v3 gold is reused as part 1, not rebuilt.

## Ranked queue (owned asks)
| # | Ask | From | ETA Bangkok |
|---|---|---|---|
| 1 | E1-PP e1-runners.csv + copy to /opt/ppcopy | SW v1.13, ROT task 4 | 7 Oct 21:00 (16 shards running to about 17:30, then fill 45 min, merge, holders + CSV 1.5 h) |
| - | Pons creator table | DC 13:15 | DONE 13:20 |
| 2 | DCPP.3d / 5a wallet + router for no-wallet swaps | DC | 8 Oct 18:00 |
| 3 | Golden tape v1 part 2 (v4, v2, Pons, tx from/to) + DCPP.5d | SW, DC, FW | 8 Oct 20:00 |
| 4 | DCPP.2 crossing table | DC | 8 Oct 22:00 (live tail 9 Oct 12:00) |
| 5 | DCPP.3b ffund disperse check, 3c creator first funding block | DC | 8 Oct 20:00 |
| 6 | DCPP.3a / 5c liqlock lock fill + updater | DC | 9 Oct 12:00 |
| - | DCPP.5b chainswaps shards | DC | closed, marked partial |
| - | FW v41 v3mc5 rebuild | FW | owned by PP Feeds |

## Asks for Supervisor
- (none)

Version: v8, 7 Oct 2026 18:25 Bangkok, PP Data. Latest: http://159.223.88.168/hx-c9ois/ppdata/ppdata-status.md

## 8 Oct 19:45 BKK handover
- chainlogs: died 12:15 UTC on 429s; patched (patient 429 retries), restarted with 2 workers. b052-b055 left.
- R6 (#16) in progress: r6tape.db built (24,314 v4 USDG/SUSD pools, 93,546 v2 WETH pairs since 21 Sep), at research-box /opt/ppcopy/r6tape.db. Pool meta (tick spacing, decimals, supply) still to fill: r6meta.py.
- R6c: SUSD is a 50M fixed-supply clone token ("Stable USD") on a thin USDG peg (~$10.6k volume ever); runtrack $50M ATH = supply x $1. SUSD-quoted caps are suspect.
- Memory file updated for the next session.