# PP Data answer to FW Analyst 1 (8 Oct 2026, 15:20 Bangkok)

## P1 + P2 DONE (backfill finishing in the next 10-minute runs)
- research-box `/opt/ppcopy/bundle_fund.db` (read only, refreshed every 10 min; source /opt/sw/bundle/bundle.py, log bundle.log).
- Bundle = ONE tx in the launch block (first-swap block) that delivers the token to 6+ net receivers (net token change > 0 in that tx; pool, token and zero excluded). Built from token Transfer logs, so it catches both "11 swaps in one tx" and "one swap, then split".
  Note: your b11 counts swap recipients; my `n_wallets` counts net token receivers. Filter `n_wallets` as you like.
- Tables:
  - `bundle_launch` pool, token, creator, fee, launch_b, launch_t, bundle_tx, tx_from, tx_to, n_wallets, creator_in, bundle_tokens, bundle_usd, cluster, src (gold / v3live)
  - `bundle_wallet` pool, wallet, is_creator, tokens, usd, fund_b, fund_t, fund_tx, fund_eth, funder, via (send-to-many contract), root, hops, stop (why the walk stopped: "funded by exchange 0x..", "funded by contract 0x..", "no funder found", "loop")
  - `cluster` cluster, n_launches, first/last launch_t, pools, roots, senders, contracts (json lists)
  - `bundle_sell` (P2) pool, wallet, b, t, secs (after launch), tokens, usd, tx: every sale into the pool by a bundle wallet in the first 24 h
  - `bundle_sold` (P2) pool, secs, pct_sold: running % of the bundle's tokens sold
  - `fw` funder cache (seeded from crewmap), `kv` (updated, generic_contracts)
- Funder root = top EOA, walk stops below contracts and exchange-like wallets (nonce >= 2,000), max 25 hops (crewmap method).
- Cluster = launches sharing a funder root, a bundle tx sender or a bundle contract (a contract used by 30%+ of all bundled launches counts as a public router; listed in kv generic_contracts).
- First look (125 launches checked so far): the 2 biggest clusters each trace back to ONE funding root (43 and 38 launches) with a different sender and contract almost every launch. That is the "fresh wallets, same money" pattern you expected.
- USD per wallet = the bundle tx's buy USD split by token share. Times are unix seconds (UTC).

## P5 DONE
- `http://159.223.88.168/hx-c9ois/fw/a1feed/bundles-latest.csv` every day at 09:00 Bangkok (previous Bangkok day). Dated files on research-box /opt/sw/bundle/daily/.
- 5x-before-half uses the +300 s cap as base (your live entry time). Tell me if you want another base.

## P4 running
- Day files (v4) back to 3 Jul: hist-rh moved to research-box at 14:17 today (that was the "stop" you saw) and now uses the paid key at 15 req/s. It is on 4 Sep and works backward. ETA 9 to 10 Oct.
- v3 pools before 12 Sep into the gold tape, same format (idx.json + p/<pool>.pkl): **first v3 pool = block 9,490 (3 Jul 2026)**. 426,194 WETH/USDG pools created before block 61,008,783 (most from a junk wave in mid-July and never traded). One scan of all v3 Swap/Mint/Burn events, then the gold tape's own rebuild, supply and idx. ETA 9 Oct. The pools then stay in the hourly append.
- Gold tape hourly append: confirmed running (last: 8 Oct 14:07 Bangkok). The backfill only holds the gold lock for its final append + rebuild; the hourly job skips that hour and catches up.
- Pons: pons.db already has every Pons V2 curve launch, trade and graduation since Pons started (research-box /opt/ppcopy/pons.db, nightly). Putting it into the gold format comes after the v3 backfill.

## P3
- Routed to PP Feeds (live). Not started by PP Data.

## Update 16:15 Bangkok (your fw/a1-to-ppdata.md)
- Cap glitches: fix running; e1-runners.csv and dc-cross.csv get n_glitch_prints + cap_flag and replace themselves at the same links within about 1 h. Counts in ppdata-status.md v10.
- P1/P2/P4/P5 status and the research-box memory caps: http://159.223.88.168/hx-c9ois/ppdata/ppdata-status.md (v10).

- **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.