Review complete. The findings file is written and validated against the tree.

Outcome

The math in PvP Pad v3 holds up under the Math Precision, Boundary and Numerical Gap checklists. I traced the bonding curve, the roll split, the finalize payout, the funded-release cap, the graduation liquidity math, the fee-collection delta decoding, the block-window boundaries and the gas floors, and found one reproducible defect, rated low.

Finding 1, low: the draw fallback seed is selectable by the committer. The lapsed-window seed is keccak of game, commit block and entry count, and the committer picks the commit block by choosing when to send the first draw call after signup ends. All inputs are public before the commit. An attacker evaluates candidate blocks off-chain, waits for one whose fallback excludes a chosen entrant, commits there, and lets the 25-second capture window lapse. The scratch test at test/scratch/SeedChoice.t.sol does this with 202 entrants and excludes the victim after evaluating 217 candidate blocks, about 22 seconds of waiting. It still keeps the hash seed as a second option at commit+4. Impact is limited to launches with more than 200 entries on a quiet pad, which is the case FIX 4 targeted. The docs disclose a two-way choice but not pre-commit selection among many fallbacks.

What traced clean

• Curve: ceil rounding on the new reserve, the sell-out branch is consistent with the overflow-to-pot path, and raised ETH never exceeds 4 ETH.
• Roll split is exact in wei, the 1% tip is conserved to the resolver or the pot, and expiry at commit+258 matches the ArbSys window exactly.
• Finalize: fee caps, triangular weights, carry pull and return use the same release cap, dust goes to carry.
• Graduation: the 512-bit mulDiv and sqrt are correct, the liquidity formulas match v4, and the 1 ppm haircut covers v4's round-up.
• Upkeep and crown gas floors satisfy EIP-150 for their stipends.
• Every slither and aderyn lead in my area reproduced as a false positive.

Coverage

All 42 listed entry points have a row, plus three invariant rows. The full existing suite passes, 164 tests. Nothing outside test/scratch/ and the findings file was written.

The review is complete and the findings file is in place. All three snippets match the tree, the coverage record answers all 41 listed entry points plus three invariants, and the proof test compiles self-contained and fails on the current code.

Result: one medium, one low, one informational finding, written to .imd-findings.json. The existing suite of 174 tests passes, so none of this is caught by the repository's own regressions.

Medium: pre-crown settlement stops at 16 pools, not at the gas budget. FIX 2 says settlement covers as many pools as fit the measured budget. The code clamps to a constant 16 before reading gas. With 18 real pools, a full bid used about 2.5M of its 5M stipend, yet the outgoing king got 16 pools of fees and the new king got the other two inside its own bid transaction, through the upkeep's distribute call. A bidder can time a bid to capture the uncollected tail. The attached proof test fails on this tree with the outgoing king short by exactly two pools' fees.

Low: the draw fallback seed can be chosen by grinding the commit block. The lapsed-window seed is keccak of game, commit block and entry count, all known before commit. The committer picks the block, waits 258 blocks, and completes the draw under a pre-selected seed. The scratch test excludes an attacker-chosen entrant from a 201-entry draw. Impact is limited to seating when entries exceed 200 and to the last tie-break key.

Info: upkeep never runs at wallet-estimated gas. Each step needs over 4.6M gas and is skipped otherwise, so gas estimators settle near 500k and player traffic never drives draws, resolution or tips. This follows from the FIX 5 design as specified and is recorded for the incentive model only.

What held in my area. I traced the roll split, tip reservation and expiry accounting, the carry release caps and the five-wallet chain economics, king refund and split conservation, PadLiquidity and PadGame balance invariants, burn-chunk accounting, and the manager-lock and gas preconditions on bids. The sybil carry chain loses at least 19 percent of what it rolls at small raises and about 4 percent at sell-out, so it stays unprofitable. I did not reach the deployed PoolManager's lock-slot constant on Robinhood Chain, which cannot be checked without an RPC call.

Review complete. The findings file is in place at the repository root and validated against the tree.

Outcome. The permission model holds across all 41 entry points except for one trust-gap defect, reported as low with a failing proof test.

Finding 1 (low), src/KingOfThePad.sol:98. A bid settles at most 16 pools for the outgoing king, switches the king, then runs the pad's upkeep, which collects two more pools for the new king. With more than 16 graduated pools, those two pools' fees from the previous reign are paid to the bidder inside its own bid transaction. The bidder can also steer the shared round-robin cursor with a public distribute call beforehand so the richest pools are the ones left over. The scratch test on the real v4 PoolManager with 18 pools shows the bidder gaining 0.1 ETH of old-reign fees while the old king gets only the 16 thin pools and nothing parked as claimable. The builder's own test asserts the trailing collection exists and the docs accept pools beyond 16 paying a later king, so I rated it low. The proof under test/scratch fails on current code for exactly this reason.

What held. Every privileged callee checks its exact caller. The game-only, king-only, pad-only, self-only and PoolManager-only gates are consistent across paired functions, the one-shot binders are atomic within the factory transaction as documented, the template initializers are sealed, and carry can only leave the pad through a game's own release cap. The pad, king and audit-v3 suites pass (47 tests).

Coverage record. All 41 entry points answered, 39 holds, 2 finding, none unreached, plus three invariant rows.

Not reached in depth. Economic soundness of the sybil release-cap math and the dice-resolution timing belong to other areas. I checked them only as far as the trust-gap seam required.

The review is complete and the findings file is written. Both snippets anchor to the tree, the JSON parses, and the working tree is otherwise untouched (only the findings file, which is the deliverable).

Result

The control flow of PvP Pad v3 holds up in my area. I traced every state-changing entry point across KingOfThePad, PvPPad, PadLiquidity, PadGame, PadToken and PadHook, plus the PadLib helpers (clone, push, mulDiv, sqrt), and found no loss-of-funds or wrong-party-payment defect. The six external-audit fixes are implemented as specified, and the twelve AuditV3 regression tests pass on this tree with the 16-pool settlement measured at 4.57M gas inside the 5M stipend.

Findings written to .imd-findings.json (2 findings, 43 coverage rows):

1. Low, launch.json line 36. The manifest notes still describe v2 rules: "collect up to 8 pools" (code uses 16), "all entries fund the burn bucket" (the first entry fee is now the draw bounty), and "carry moves into a game when its raffle seats >= 5" (v3 pulls carry only at finalize). The validator passes because it checks schema and length only. The published description of settlement, entry economics and carry custody is wrong.
2. Info, PadLiquidity.sol line 210. Pre-crown settlement covers at most 16 pool indexes, so with 17 or more pools, fees earned during the outgoing reign in the uncollected pools go to the incoming king on the next distribute. This is disclosed in AUDIT.md item 21 and matches the brief's "at least 16", so it is recorded for the judge rather than claimed as a defect.

What I verified and ruled out: nested-unlock bids blocked by the exttload read on both paths; strict settlement reverts the whole bid on any unflagged failure or gas shortfall and no caller-reachable way to make a healthy pool's collection fail; in-kind payment to the king captured before the crown changes; claim locks cannot double-pay; roll split exact; expiry boundary at commit+258 matches ArbSys semantics; draw commit is single-shot with a deterministic fallback and a once-paid bounty; carry is pulled only inside finalize up to the unused cap; every upkeep sub-call is gated by cap plus the EIP-150 margin and try/caught, so enter and roll cannot revert on foreign work; one-shot binders rely on the atomic deployment, which is documented.

Static-analysis leads checked: the mulDiv caret and divide-before-multiply are the standard OpenZeppelin algorithm, msg.value-in-loop in fundGames is correct remainder accounting, and the reentrancy flags are all behind guards or 30k gas pushes. None rose to a finding.

Not reached: no fork of the live Robinhood PoolManager, so the deployed manager's exttload support and the 300k per-pool stipend against real chain state remain the deployer's pre-opening check, as AUDIT.md already states.

Added regression tests, fuzz properties, and two invariant campaigns under test/.

Verified: 186 tests passed, forge build passed, and manifest validation passed. New invariants exercised 20,480 randomized calls.

Coverage and gas report

Review complete. The findings file is written and validated.

Outcome

.imd-findings.json holds 2 findings and a 44-row coverage record answering all 42 listed entry points plus two invariants.

Findings kept

1. Medium, src/PadLiquidity.sol:210. Pre-crown settlement clamps to a constant 16 pools before looking at gas, instead of the brief's "as many as fit the measured budget". With 17+ pools, the bid's own trailing upkeep runs distribute(2) under the new king and pays the outgoing reign's fees on the unsettled pools to the bidder. The bidder can steer the public cursor beforehand to pick which pools. Both specialist proofs fail on this tree for exactly that reason, and the stronger one is attached as proof. This merges three specialist reports (economics medium, permissions low, flow info) into one root cause.

2. Low, src/PadGame.sol:193. The lapsed-window fallback seed depends only on the game address, the frozen entry count and the commit block the first caller chooses, so a sole caller can grind the commit block to pre-select seating. Bounded to launches over 200 entries on a quiet pad. Merged from audit_math and audit_economics.

Dropped

• The audit_flow note about stale v2 wording in launch.json: the manifest was rewritten in a later commit and now describes v3 correctly. The validator passes it.
• The audit_economics info note that wallet-estimated transactions skip upkeep: that is the requested FIX 5 behaviour, not a defect.

Own pass

Traced the Lock transient slot against the vendored library, hook flag mask, runtime sizes (largest 18,665 bytes), reentrancy paths through the gas-capped pushes, carry release at finalize, roll split and expiry accounting, and the one-shot binders. Nothing beyond the two findings reproduced. I did not rerun the full repository suite within the time budget; only the two proofs were executed.

Everything is green and the work is complete. Final state:

Finding 8b022036 (medium, pre-crown settlement): fixed and verified. The reviewer's proof failed on the starting tree exactly as reported (the bidder gained 0.1 ETH of the old reign inside its own bid) and passes now. Two changes in the contracts:

• settleCrown in src/PadLiquidity.sol now walks every pool from the cursor while the forwarded gas fits another collection, and reverts only if fewer than 16 pools were visited. takeCrown forwards all gas above its 600k reserve instead of a fixed 5M, so a bid can settle more pools by sending more gas (5M remains the minimum).
• Each settlement closes a reign. PadLiquidity records the outgoing king per reign and stamps every pool with the reign it is settled for. A pool the walk did not reach, or that was flagged broken, keeps its old stamp, and its next collection by anyone pays that reign's king instead of the new one. The bidder can neither starve the walk nor steer the cursor to pick pools, whatever the pool count.

Finding 779d74d2 (low, fallback seed): disputed. It reproduces as described, but the formula is the one the brief prescribes for Fix 4, the limitation was already disclosed, and the suggested replacement inputs are equally observable by the first committer. Recorded as item 30 in docs/AUDIT.md with the reasoning and the keeper mitigation.

Checks run locally:

Keeping the deployment under the 13M target needed two size measures: the reign stamp is packed beside liquidity, and ten PadLiquidity constants that no contract or test reads became internal with unchanged values.

Tests: new test/CrownSettlement.t.sol (seven tests: the cursor-steering scenario on 18 real pools, 60 real pools with a minimum-gas bid where 41 settle and the rest are later paid to the old king, 60 pools fully settled with a generous bid, the 16-pool floor revert, non-king settlement, first-crown reign, and a broken pool skipped by two crowns paid to the earliest reign). Three existing tests that asserted the old 16-pool cap or paid a retried broken pool to the new king were updated to the fixed semantics.

Docs: README crown section and gas table, docs/AUDIT.md items 3, 21, 29 and 30, docs/TEST-REPORT.md counts, gas and sizes. The answers to both findings are in .imd-responses.json. foundry.toml, remappings.txt and launch.json are untouched.

One documented imprecision remains by design: fees an unreached pool earns between the crown change and its next collection also go to the earlier king, which the new king avoids by collecting promptly.

The revision is complete. The full suite passes again, with only two files under test/ changed.

What was wrong. One test from my previous round, test_successBetweenFailuresRequiresThreeNewDistinctBlocksToBreakPool, failed against the current sources. After my round was accepted, another contributor changed the settlement rules (AUDIT.md item 29): a pool that a crown change skips, because it is broken or out of the bid's gas reach, now pays the king of the earliest reign it was never settled for on its next collection. My test still asserted the earlier rule, where the bidder received the broken pool's fees on retry.

What I changed.

• The test in test/V3FailureEdges.t.sol now asserts the documented semantics. The broken pool does not veto the bid, stays stamped with the outgoing reign, and its permissionless recovery pays the outgoing king both ETH and tokens in kind. The bidder receives nothing from that reign, the pool takes the new reign's stamp, and fees earned afterwards go to the new king only. It keeps its distinct failure mode, a token transfer returning false, which the other contributor's settlement tests do not cover.
• test/V3-CONTRIBUTOR-REPORT.md has a revision note explaining the change, refreshed test counts, updated mapping rows for fixes 1 and 2, and current gas and runtime-size figures.

Verification.

No new implementation defect was found, so no findings file was written. The accepted imprecision in item 29, where fees a skipped pool earns between the crown change and its next collection also reach the earlier king, is a documented design choice and is noted in the report rather than asserted either way.

Review complete. .imd-findings.json holds one new low finding plus a 42-of-42 coverage record, and both findings from my previous round are settled.

Prior finding (medium), pre-crown settlement cap: fixed. I ran my attached proof (Proof_8b0220368ef8.t.sol, copied to test/scratch/) against the revised tree: it now passes, with the bidder receiving 0 in its own bid transaction (previously ~0.1 ETH of the outgoing king's fees). The fix is sound on inspection: settleCrown closes a reign into reignKing[], stamps every pool with settledReign, walks every pool while gas fits with a min(16, poolCount) floor, and takeCrown forwards all gas above its 600k reserve. I traced the payee logic for every boundary (first crown, broken pools skipped by two crowns, unswept pools, pools graduated after a crown change) and found no path where stale-reign fees reach the incoming king. The author's regressions all pass, including the unlock-replay, gas-starved bid, in-kind fees, broken-pool, and cursor-steering cases.

Prior finding (low), seed fallback: accepted, dropped. The formula is exactly what the brief prescribes for Fix 4, the limitation is disclosed in AUDIT.md #23 and #30 and in the README, and changing it would contradict the approved spec. No defect against the agreed design.

New finding (low): launch.json notes still say a crown transition "settles up to 16 pool indexes", which was the pre-fix rule. The revised walk settles every pool the bid's gas fits (16 is only the floor); the author's own test asserts 60 pools settled in one bid, and docs/VERIFY.md:66-67 still calls the notes "historical v2 prose" when they are now v3 prose. Published description only, no effect on constructor arguments, custody, or limits; a one-clause rewording fixes it.

Supporting checks all green: 194/194 tests pass, runtime sizes well under 24,576 bytes (largest is PadGame at 18,665), deployment code-deposit 10.1M gas and combined deployment plus opening 12,974,791 under the 13M target, and the manifest validator accepts launch.json (schema, argument order, notes length).