The review is complete. .imd-findings.json is written at the repository root, test/scratch/ is removed, and git status shows no tracked file changed.

Summary

Verdict: no critical, high or medium defect. The code can ship as it is; nothing in the report asks for an ABI, constant, split, price or payout-math change, and src/DerbyOdds.sol is untouched.

What I read: src/SwarmDerby.sol (every state-changing entry point traced), src/DerbyOdds.sol, the 54-test suite (passes), web/derby-odds.js, e2e/Mocks.sol, DEPLOY/HANDOFF, the Pashov guide and the protected deploy test. Key invariants hold: CEI on every token call; pot[l] == Σ unsettled dayPot + rollover; the day queue is monotone; a swing can never score into an already-settled day (settlement needs arbBlockNumber > lastTarget+255, a non-foul finalize needs current−target ≤ 255); session consent is player-bound, nonce'd, malleability-checked; the commit binds player so copied commits are dead. Runtime is 12,599 bytes with no forbidden opcodes, no proxy/initializer/pause/blacklist.

What I verified live on Robinhood Chain (4663): ArbSys at 0x64 exists and answers; blocks run at ~103 ms so the 255-block window is really ~26 s and the chain never stalls; the IMD token at 0x5F7B… is a LayerZero OFT, delivers transfers in full with a 32-byte true (no fee), and has transfersEnabled()/blocked(address) as the docs state. Not reached: Blockscout is Cloudflare-gated, so the token's verified source was not read — its behaviour is established from bytecode selectors and simulated calls only.

Findings (4):

1. Low — src/SwarmDerby.sol:197: turns bought by an address before it is bound as a session key are stuck while bound (NoTurns despite turns(l,key)>0); recoverable via leaveSession. Confirmed with a scratch test.
2. Info — :505: setPrices/withdrawOps are owner runtime powers; recorded as the accepted trust assumption (floored price, pots/vaults unreachable) rather than a change request, since the brief freezes the ABI and accepts no-maxCost.
3. Info — :559: the token's block list / transfer switch can halt purchases, burns, tips and ops withdrawals; already in DEPLOY.md's known limits, handled where the contract can.
4. Info — :65: the ~26 s reveal window means a slow non-session finalize forfeits the turn; by design, covered by existing tests.

Adaptation complete. Both source files remain byte-identical.

• Fixed the ArbSys test fixture and added three launch tests.
• forge build passes.
• forge test: 57 passed—54 original plus 3 new.
• Supplied protected deployment rehearsal passes.

ADAPTATION.md records the exact arguments, changes and retained low-severity session-key limitation.

No on-chain transaction was broadcast.

Created launch.json for SwarmDerby only, with the exact approved constructor arguments.

Validation passed against the supplied schema and compiled constructor ABI. forge build succeeded; forge test passed all 57 tests (54 application + 3 launch tests).

Only launch.json changed. All accepted source remains unchanged.

Both files are in place at the repository root, and the harness's own exclude list keeps them out of git as intended. The review is complete.

Result: no defects found in the math area. The findings file at .imd-findings.json holds an empty findings list and 17 coverage rows, one for each of the 12 entry points plus five invariant and boundary checks.

What I verified, with numbers, using a scratch Foundry file under test/scratch/:

• Purchase split. Fuzzed single prices from 0.01 to 1e24 IMD and counts 1 to 1000. Burned, pot, vault and ops always sum to the cost, and ops absorbs at most 3 wei of rounding dust. The ops subtraction cannot underflow because the three floored shares sum to at most 95% of cost.
• Settlement. Paid amounts are floors of a 60/25/15 split of 90% minus a 0.5% tip, so paid never exceeds the day's amount. The invariant that a league's pot equals its unsettled day pots plus rollover holds through purchase, settle and the unpayable-winner re-add, so the pot subtraction cannot underflow. Fuzzed pots from 0.0045 to 4500 IMD with 0 to 4 scorers conserve to the wei.
• Slam payout. A vault under 10 wei pays zero without reverting and the homer still scores.
• Block boundaries. A reveal at target plus 255 scores, target plus 256 is a foul, expire opens at exactly target plus 256, and a day closes at the same block. Nitro's ArbSys serves hashes down to current minus 256, so the contract stays strictly inside the served range.
• Odds table. Closed forms for all five thresholds hold for every quality 0 to 100, strictly ordered so no tier inverts. The browser's floating-point floor matches the integer result for all 101 values. Feet bands never overlap and the slam band is exactly 550 to 620.

Chain facts checked against the public RPC. IMD at the launch address has 18 decimals and is an OpenZeppelin v5 ERC20 with LayerZero OFT functions, a blocklist view and a transfers switch, with no transfer fee. ArbSys at address 100 has code and advances about 10 blocks a second, so the 5-block delay and 255-block window match the documented half second and 25 seconds.

Not covered. I did not re-examine randomness steerability by a party who can shape a target block's contents, EIP-712 recovery details, or token blocklist governance beyond confirming the contract's documented handling. Those belong to the other specialists' areas.

The review is complete. The findings are in .imd-findings.json, the tree is otherwise unchanged, and the full suite still passes with 57 tests.

Outcome: no critical, high or medium defect in the Access Control, Trust Gap or Asymmetry areas. The code can ship unchanged under the brief.

What I checked, against the three Pashov guides:

• Permission map. Owner reaches only setPrices (floor-checked), withdrawOps (bounded by the ops share) and two-step ownership. The pot and vault have no owner path. A bound session key cannot call setSession or any owner function, its purchases credit the player, and every slam and board credit goes to the stored player. Consent signatures bind player, key, nonce, chain and contract, so another player cannot replay them.
• Asymmetry diffs. Buy vs. swing, whiff vs. contact, finalize vs. expire, settle vs. its preview view, pull vs. send. Accounting is updated before every external send, and the pot invariant holds across settlement and refused transfers.
• Live dependencies. The constructor's token address on Robinhood Chain has code, reports symbol IMD with 18 decimals, and ArbSys at address 100 answers. The launch arguments pass the constructor's checks with the owner taken from the explicit argument, not the factory.

Findings recorded:

1. Low. Turns a key buys for itself before binding are unreachable while bound. Recoverable by leaving the session. This is the known low the owner already chose to keep.
2. Info. The owner can raise prices with no ceiling or delay, so standing allowances pay the new price. Accepted by the owner in the brief.
3. Info. The IMD token's owner holds a blocklist and transfer switch. Blocking the burn address would stop every purchase. Current live state is unblocked with transfers enabled.

Coverage lists all 12 entry points plus the constructor and two invariants. The scratch tests that produced the exact reproductions were run and then removed.

The review is complete. .imd-findings.json is written at the repository root; git status shows no changes other than that file (scratch tests removed), and forge test still passes (54 + 3 launch tests).

Summary

Area: Execution Trace, Periphery, First Principles on src/SwarmDerby.sol and src/DerbyOdds.sol, judged against the Pashov guides.

Result: no critical, high or medium defect. The code can ship as-is under the brief's constraints. Two informational items are recorded, each with a concrete repro:

1. finalize foul-feet asymmetry (src/SwarmDerby.sol:323) — a late/expired foul emits feet = 0, a rolled foul emits 90–170 ft. Reporting only; no money or board depends on a foul's distance.
2. _trySend vs _pull return-data rule (src/SwarmDerby.sol:565) — _pull accepts any ≥32-byte true, _trySend requires exactly 0 or 32 bytes. Not reachable with the deployed token: I verified via cast on Robinhood Chain (4663) that IMD 0x5F7B…7127 is a LayerZero-OFT-style OZ ERC20 returning exactly 32-byte true, with transfers to 0xdead accepted and no hooks.

What I verified (all 12 entry points answered, plus 8 invariant/periphery/deployment rows):

• The core safety property — a day's board cannot change after settlement — holds by construction: finalize scores only while current ≤ T+255 ≤ dayLastTarget+255, settlement requires current > dayLastTarget+255; confirmed at both edge blocks with scratch tests, and per-league so one league never blocks the other.
• Conservation balance == pot₀+pot₁+vault₀+vault₁+ops traced through every writer including the slam and winner refund branches.
• Session mapping bijection sessionPlayer[K]==P ⇔ sessionOf[P]==K, no key chains, single-use EIP-712 consent, same-key rebind needs a fresh signature.
• Live chain facts: ArbSys at 0x64 is present; block cadence is ~10 blocks/s, so FINALIZE_WINDOW=255 ≈ 25 s as documented.

Not reached: sequencer-level block-hash steering and L2 liveness stalls — these are the trust assumptions DEPLOY.md already states, and I attempted no contract-level reproduction.

The review is complete. The findings file is written and the tree is otherwise untouched.

Result: no defects found in the economics. .imd-findings.json holds an empty findings list and 16 coverage rows: one for each of the 12 entry points, three for the invariants and assumptions I checked, and one for the live token. All 12 entry points are marked holds. The full suite still passes (54 original tests plus 3 launch tests).

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• Purchase split and backing. The 40/45/10/5 split is exact at the launch prices, dust goes to ops, and state is credited before a pull that reverts on failure. A scratch fuzz of 400 random 120-step sequences (buys at random floor-respecting prices, reveals rigged to every tier, late reveals, expiries, blocked slammers and winners, settlements, ops withdrawals) never broke balance == pot + vault + ops, pot == unsettled dayPots + rollover, strictly increasing day queues, or turn conservation. The scratch test was deleted afterwards since it supports no finding.
• Settlement math. paid never exceeds the day's amount, pot is debited before transfers, refused prizes return to both rollover and pot, and the view and write paths use identical arithmetic. A settled day cannot be re-scored because settlement needs a block past every reveal window.
• Reveal incentives. A non-reveal and a foul are identical, so withholding a bad roll never pays. Slam payouts and board credit always go to the player, never the session key.
• Live dependencies, read from Robinhood Chain. The IMD address has code, reports IMD / 18 decimals, transfers are enabled, the burn address is not blocked, and a traced transfer is a plain full-amount move with no fee and no external calls. ArbSys answers at 0x64. The chain runs about 8–10 blocks per second with several transactions per block, so the 255-block window is the documented ~25–30 s and a player cannot own a target block's contents to grind its hash.

What I could not verify. The token is a LayerZero OFT with owner-only setBlocked and setV4Config; three zero-valued views and one (uint256) setter could not be named because the source is not verified on Blockscout (Cloudflare-gated) or Sourcify. If one of them is a future tax or transfer limit, the split accounting would under-collect, but that is the already-documented token-owner trust assumption, not a contract defect today.

Added failure-path tests, fuzz tests, and stateful invariants covering 16,384 randomized calls.

Verification: forge build passed; forge test finished with 73 passed, 0 failed, 0 skipped.

Only test/ changed. Production contracts and configuration remain unchanged. Integration checks use offline mocks; live-chain behavior remains unverified.

The review is complete. The findings file is written at the repository root and validated: all four snippets match the tree at their stated lines, and the coverage record answers all 12 entry points plus three invariants. The scratch tests were removed, so no project file changed.

Outcome: no critical, high or medium defect in SwarmDerby. The code can ship unchanged, which is what the brief asks for.

What I kept, after reproducing each in a Foundry scratch test on this tree:

• Low (finding 1): turns a wallet bought for itself before being bound as a session key are unspendable while bound, because purchase and swing both resolve playerOf(msg.sender) but at different moments. Recoverable via leaveSession or revocation, no loss. The owner's brief already accepts this.
• Info (finding 2): the owner's price power has only a floor, no ceiling, delay or event. Buyers with standing allowances pay whatever price lands first. Recorded as the trust assumption the brief states, with its bounds verified: ops withdrawal is capped by the ops balance, and pot and vault are unreachable by the owner.
• Info (finding 3): the IMD token's owner-controlled blocklist and transfer switch can halt purchases, burns and payouts. The contract fails closed in every case I traced, so this is a dependency trust assumption.
• Info (finding 4): a late or expired foul emits feet 0 while a rolled foul emits 90 to 170 ft. Reporting inconsistency only, nothing economic reads a foul's distance.

What I dropped: the flow specialist's claim that a token returning more than 32 bytes passes _pull but fails _trySend, leading to double-counted refunds. The burn inside the same purchase goes through _send, so the purchase reverts with TransferFailed and no turns or balances are credited. The contract never holds such a token's funds, and the launch token returns exactly 32 bytes anyway.

My own pass found nothing further. I traced the EIP-712 session binding (no chains, no self-binding, per-key nonce, malleability guards), the settlement ordering and pot accounting, the reveal window against ArbSys's 256-block hash range, board insertion and eviction, and the constructor against the launch manifest. Block-hash randomness remains a sequencer trust assumption the design already documents, and I did not re-read the live token state on Robinhood Chain in this review.

The full suite passes, 73 tests including the 54 originals.