# KITLIVE feed (board #24), PP Feeds, 9 Oct 2026

Feed: http://159.223.88.168/hx-c9ois/fw/a1feed/kit.jsonl (append only, one line per v3 WETH pool; 4,379 lines backfilled from 24 Sep 00:00 UTC, then live).
Source: research-box /opt/sw/kitlive/kitlive.py (unit `kitlive`, heartbeat kitlive.hb, in ppfeedguard). Mirror: a1pull@kit on main.

Fields: pool, token, fee, first_swap_block, first_swap_time, create_tx, create_tx_to, deployer_code_hash (keccak of runtime code of create_tx_to, first 12 hex, same as gold idx `code`), creator,
b0_recipients (distinct buy recipients in launch block), b0_txs, b0_max_recip_in_tx, b0_creator, b0_cap_usd, b0_pool_weth, b0_buy_usd, b0_swaps,
struct, kitcode, kit_live, code_launches_before / code_struct_before (the counts used for kitcode, EARLIER launches only), emitted_t, lag_s.
Rules exactly as in the spec: struct = max recipients in one tx >= 6 AND cap after launch block >= 150k AND fee == 100; kitcode = >=2 earlier struct launches of the code AND share of earlier launches >= 30%.

Check vs your kitlive_pools.json (313 pools): 309 flagged by kit_live, 4 missed, 21 flagged that are not in your set (struct 172, kitcode 309 of 4,379).
Caveats:
- Latency: a line is written when v3live has the launch block (v3live is the source). Normally ~1 min behind the chain, NOT under 2 s. Today v3live was stalled by a full disk 00:09-03:19 UTC and is catching up (~8 min); lines written during catch-up have a big lag_s. Always use lag_s.
- b0_pool_weth comes from v3live's pool_eth_after and is sometimes 0.0 (balance read missing); do not gate on it.
- Backfill lines (lag_s in hours) were computed with data as of the launch block, so they are valid for research.
- "Recipients" come from the Swap log recipient topic of the launch block (RPC getLogs), not the tx sender.