# analyst3: smart-wallet confluence (ledger #49) and funding clusters (#51), 10 Oct 2026
Task #428 from scout. Scripts: w1.py (wallets), w2.py (clusters). Data: runtrack.db rh_wnet (hour-bucket net per wallet, 300 robinhood tokens), bundle_fund.db clusters, e1-runners.csv.

## #49 Smart-wallet confluence: WEAK, not usable yet
- Sample: 300 tokens with wallet flow, ALL already >=300k peak (199 reach 1M, 96 reach 3M, 70 reach 5M). So it can only separate big from small among coins that already ran; not a population test.
- Method (time-split): walk tokens by birth hour; a wallet is "good" if it was an early buyer (first hour bucket, net>0) in >=2 EARLIER 3M+ tokens. Count good wallets among each token's early buyers. Eval on the last 200 tokens.
- Result: with >=3 good wallets present (n=90) vs fewer (n=110): reach 1M 81% vs 53%, 3M 37% vs 22%, 5M 23% vs 15%, 10M 14% vs 10%. Lift is real at 1M (+28 pts), shrinking to ~1.5x at 5M, small n, no CI. Generic "recurring wallet" (any outcome) shows no lift (5M 18% vs 19%).
- Problem: median 658 early buyers per token in the first hour bucket (bots, routers, everyone), and hour granularity says nothing about "before $100k cap". The signal could just be "busy coin". Not a tradable entry filter.
- Needs: per-wallet buys with minute timestamps for the first 5 min on ALL launches (not just runners), plus wallet realized PnL. Ask dataeng for a per-pool first-5-min buyer table (pool, wallet, t, usd). Until then parked.

## #51 Funding-cluster bundles: operators matter, small n
- bundle_fund.db has 18 clusters (shared funding root); 5 big ones cover 129 of 160 bundled launches (one operator = 49 launches).
- Peak-cap reach per cluster, only launches in e1 sample: c_e1f227ad (n=14): 1M 86%, 3M 50%, 5M 43%, 10M 29%. c_5159d0ef (n=7): 1M 100%, 5M 43%. c_5cf061d6 (n=11): 5M 36%. c_f9acec5b (n=20): 5M 20%, c_aa2544a7 (n=6): 5M 17%. Bundled all: 5M 31%.
- So operators differ: two clusters reach 5M ~43%, two ~20%. Per-operator track record is a candidate feature (cluster id known at launch block, causal), but n=6-20 each, and e1 oversamples runners. Comparison with non-bundled in this file (5M 24%) is not apples to apples (non-bundled includes pools before the 17 Sep scan start); earlier fair figure remains 31% vs 16% in a3-bundle-gmak-10oct.md.
- Suggest to A2: treat "launch belongs to a known cluster whose earlier launches reached >=5M" as a feature, validated walk-forward on cluster history. Cannot finish without full-population peak per seen pool (ppdata, asked earlier).
- Not done: block-0 same-second identical-pool spam (scout #1) is analyst1's.