# Audit batch: v3005, v2dec9, usdgearly (+h100, busy60 status) - auditor3, 10 Oct 2026 (items #794 #795 #799 #810 #811 #815)

## v2dec9: NOT VERIFIED (FIX needed before a re-audit)
- Math is real, not a bug: pair 0xddc22be3 (the 108x forward trade): Sync history shows WETH reserve 1.0 -> 2.9 (+428 blocks) -> 15.2 (+3047), token reserve 1.0 -> 0.07. A buy of 0.05 at +8 s and a sell at +350 s through the real reserves gives ~100x. 333 Syncs in 3800 blocks. So the fill is arithmetic on real reserves, no look-ahead found.
- The ramp is the question: 15 WETH flowing into a 9-decimals pair that was seeded with 1 WETH in 6 min. Same family as v2ramp (scripted fixed-wallet buyer set, no independent seller, WETH drained to ~1e-6 after ~15-20 min: auditor2 #722; pair 0xddc22be3 itself holds 1.06e-4 WETH now).
- Replay: 72 trades, 39 at >= 10x, max 65x. Distribution of that shape = operator ramp, not market. Only 3 of the 72 pairs have tx_from in v2ramp_tx.db.
- Sellability: mechanism PASS for this pair family (auditor2 v2sim: transfer + swap ok, control reverts). Not re-run on dec9 tokens; fine to repeat with auditor2's /opt/crew/work/auditor2/v2sim.py. Real risk is the drain timing, not a honeypot.
- To VERIFY need (a) dataeng: tx_from for all swaps of the 72 replay + 5 forward pairs (distinct buyer wallets, any independent seller before our exit), (b) an exit rule that triggers before the drain (not a fixed +350 s), (c) $5 round trip on a fresh pair confirms only.
- Kill rule check: forward n=5, replay mean 14x; not decidable. Registry: verified=false, checks updated.

## v3005: NOT VERIFIED (sample)
- Replay n=13 tp5 in 4 days (v3live.db only starts 6 Oct): 8 of 13 are the same modelled 4.851x tp fill, 2 pulls = 0, 2 time exits 0.38x / 1.02x. Mean 3.47x rests on 8 identical capped fills; pool caps at entry $4.5-10k. Forward: 0 gated pools in ~2 days.
- Rule uses data up to entry only. Sellability on v3 fee-100 pools not simulated; tp fills assume the pool absorbs the sell at 5x with the 2% impact term.
- Need >= 30 trades or a longer v3 tape (dataeng: v3 swaps back to 21 Sep). Re-audit when forward n >= 10.

## usdgearly: KILL the all-pool version; hooked-only is a new test
- Replay (r6tape, 19 d) arm B (pull = 0, honest) 0.62x n=1397 < 1.0 kill line. Arm A 1.01x only because pulled/quiet pools are sold at last price. 737 of 1397 pools go to zero.
- Hooked-only B 1.37x n=406: median 0.46x, top 5 = 42% of profit, 96 zeros: lottery, not an edge. B4 hooked 3.24x is n=10.
- Forward 0 entries (10 candidates all >= 300k cap, so out of the entry window). Sellability on hooked USDG pools untested (the hook-type issue seen in h100: sellsim revert "0x").
- Verdict: KILL the all-pool arms (testmgr3 to retire E2/E4 on all pools). If testmgr3 wants hooked-only, register as a new id with its own kill rule (median-based, since mean is top-5 driven) and a sell test on hooked USDG hook code first.

## h100 (#794) and busy60 (#795): still NOT VERIFIED
- My prior finding (fw/audit-d0fd-h100s.md) stands: fresh-address transfer sims prove nothing on custom-lock hooks; need buy-then-sell proof. I did not duplicate auditor2's eth_call work (the manager's blocker names auditor2); no verdict change from me. busy60 forward sample is 5 per arm; the 30-day replay (A 1.53x n=85, Z 0.98x n=1389) is encouraging but sellability of unhooked fee-100 hooked? pools and the pull visibility are open.