The review is complete. The findings file is at the repository root and every quoted snippet matches the tree. The scratch directory has been removed and the tree is otherwise unchanged.

Result: no critical or high defects in SwarmDerby v2. The contract, the RSA draw check and the odds library hold up under the Pashov checklist, the existing 117 tests, and a scratch invariant fuzz I ran over random buys, swings, draws, reveals, expiries, settlements and ops withdrawals. Token balance always equalled pots plus vaults plus ops, and each league's pot always equalled its open days plus rollover.

Findings written to .imd-findings.json:

• Medium, launch blocker. The constructor's fifth argument is a dynamic bytes modulus. The launch recipe allows only static argument types, and the manifest schema caps each argument string at 96 characters, while the brief's modulus is 514. The manifest is rejected before any bytecode is built. The adapter can fix this in the constructor alone, either as eight bytes32 words concatenated before the key check or as an embedded constant. Neither touches the runtime ABI, and houseKey() must still return the exact 256 bytes.
• Low. Turns can be bought while the house key is revoked. The purchase burns 40% immediately, yet the turn cannot be swung until a new key activates at least two days later, or ever if none is proposed. A one-line revert in the internal buy path would close this without changing any signature.
• Info. Permissionless key activation is instant, so swings the house already signed with the old key are refunded rather than played. This is a runbook note for rotations, not a code change.
• Info, coverage. Read in full: SwarmDerby, HouseDraw and DerbyOdds. DerbyAuction was only skimmed since it is not in this launch. Not reachable: the live Robinhood IMD token and the chain's modexp precompile, both taken on the documentation's word.

Also confirmed for the adapter: the compiled runtime is under the EIP-170 limit and contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, and the supplied modulus is a well-formed 2048-bit odd number with no small factors.

Prepared SwarmDerby for factory deployment with eight static key words preserving the exact modulus. Fixed the reproduced revoked-key purchase issue; runtime ABI and payout math remain unchanged.

forge build passed. All 125 tests passed without FFI.

Changes and exact launch arguments are documented in ADAPTATION.md. No live deployment was performed.

Created launch.json for SwarmDerby only, using $owner, the approved prices and address, and the exact modulus encoded as eight bytes32 arguments.

Validated against the supplied schema and compiled constructor ABI. forge build passed; forge test passed all 125 tests with FFI disabled.

Only launch.json changed.

The review is complete. The findings file holds an empty findings list and 32 coverage rows, and the working tree has no other changes.

Result: no defect found in the assigned area. I checked the SwarmDerby arithmetic against the Math Precision, Boundary and Numerical Gap guides and could not produce a failing input for any formula, boundary or seam between them.

What I verified, by hand trace and by scratch tests that I ran and then removed:

• Purchase split. The 40/45/10 basis-point shares floor and the remainder goes to ops, so the three shares plus ops always equal the cost. The 0.01 IMD price floor keeps every share above zero.
• Settlement. Fuzzed across prices from 0.01 to a trillion IMD with zero to four winners. The tip and each prize equal what the preview reports, the total paid never exceeds the day's amount, and the pot equals the sum of open day pots plus rollover before and after. The divide-before-multiply that slither flagged is the same floor chain on both sides, so the preview and the payout cannot drift.
• Odds table. For every quality from 0 to 100 the five thresholds are strictly ordered and non-increasing in quality. Slam odds are 21 basis points at quality 1 and 80 at quality 100, as documented. The browser twin floors integers below 2^53, so parity holds.
• Time boundaries. The draw window, reveal window, expire and day-closed checks are exact complements of each other. At the boundary second a drawn swing still rolls and the day is still open. One second later it fouls and the day closes.
• Board. Eviction at a full board, tie handling and re-entry of an evicted player keep the list sorted.
• Narrowing casts and underflows. Day fits uint32, timestamps fit uint64, feet never exceed 620, and the arcade slot refund cannot underflow because a refunded swing cannot be expired twice.
• House draw. The PKCS1 padding constant is 205 bytes, giving a 256-byte encoding. The signature must be below the modulus, so adding the modulus is rejected. The modexp input is fixed-length fields, so aderyn's packed-hash lead does not apply.
• Launch inputs. The eight constructor words concatenate to the brief's modulus, whose first byte is 0x9b and last byte 0x3d, so the shape check passes. The live IMD token returns one 32-byte word of 1 and has 18 decimals, so the strict return-data check in the transfer helper matches it.

DerbyAuction is not deployed in this launch. I still traced its basis-point helper, minimum-bid rounding and carry arithmetic and found them exact, so its entry points are marked as holding.

The static-analysis leads for SwarmDerby all turned out to be false positives: the uninitialized-state lines are mappings, the strict equality on the pending key time is safe because that value is never zero once set, and the reentrancy sites update state before any transfer.

The review is complete. Findings and coverage are in .imd-findings.json; no source file was changed.

Scope

Files read in full: src/SwarmDerby.sol, src/DerbyOdds.sol, src/HouseDraw.sol, the launch and fixture tests, DEPLOY.md and ADAPTATION.md. src/DerbyAuction.sol was read once from line 120 on, since it is not part of this launch. The Economic Security, Invariant and Flow Gap guides were applied against every value-moving path. The existing suite passes with 125 tests, and five scratch probes under test/scratch/EconProbe.t.sol all pass.

Severity counts: 0 Critical, 0 High, 0 Medium, 1 Low, 2 Info

Findings

• [L-1] Brief wording vs constructor ABI. The assignment says to pass one 256-byte houseKey_ argument, but the compiled constructor takes eight bytes32 words. ABI-encoding the brief's five-argument form makes the constructor revert BadKey, so a manifest written from the brief literally fails the deploy rehearsal. The twelve-argument table in ADAPTATION.md is the correct input. Reproduced in the probe test.
• [I-1] Surplus IMD is unrecoverable. Every outflow is bounded by a tracked balance, so tokens sent directly to the contract are stuck forever. Consistent with the stated design.
• [I-2] Revoking the house key strands prepaid turns. After revokeHouseKey, turns can only be whiffed, and a new key needs at least two days. This is the documented owner power with the largest player-side effect, recorded as a trust note.

What held

• Conservation. Contract balance equals pots plus vaults plus ops after purchases, slams, settlements with blocked winners, and ops withdrawals.
• Per-league pot. The pot always equals the open days' pots plus rollover. Failed prizes return to both.
• Settlement boundary. A finalize at exactly the last commit plus ten minutes still rolls while settlement reverts. One second later settlement succeeds and finalize fouls, so no dinger can land on a settled day.
• View vs write. The tip shown by nextSettlement equals the tip paid by settleNextDay on odd amounts.
• Turn and cap accounting. Expire refunds exactly one turn and one arcade slot once.

Static analysis leads

All slither and aderyn lines were checked. The uninitialized-state, weak-prng, divide-before-multiply, incorrect-equality and encodePacked items are false positives here. The settlement reentrancy line is harmless because every state write precedes the sends and the token is a fixed ERC-20.

The coverage record has 32 rows: all 27 listed entry points plus the constructor and four invariants. Nothing is marked unreached.

The review is complete. The findings file is on disk at the repository root, excluded from git by the harness's own exclude rule, and the working tree is otherwise clean with the scratch tests removed.

Outcome: no critical, high, medium or low defect in the assigned area. The SwarmDerby v2 control flow holds under the Execution Trace, Periphery and First Principles checklists. Two info-level notes are recorded for the judge, both trust-model observations rather than code defects, and no code change is warranted. The full suite passes with 125 tests and no ffi, which is more than the 117 the brief mentions.

What was verified beyond reading

• HouseDraw's PKCS#1 v1.5 padding and DigestInfo were checked byte-for-byte against a real Node crypto.sign signature from the test key. The existing suite could not catch a padding error because it signs with modexp on both sides. The parity scratch test passed.
• The brief's 256-byte house key has the right length, a top bit set and an odd last byte, so it passes the constructor's shape check when split into eight words.
• The live IMD token on chain 4663 has code, returns the word 1 from transfer, and reverts allowance errors OZ-v5 style, which matches what _pull and _trySend expect.
• Scratch probes confirmed the cross-day refund restores the commit day's cap slot, the full-board eviction and re-entry ordering, and the pot and rollover conservation after an empty-day settlement.

The two info notes

• A finalize sent before the draw lands reverts and leaves the salt in public calldata. The key holder can then compute that swing's result before drawing and withhold a losing draw. This only happens if the player's own client races the house, and the fix is client-side gating on status Drawn.
• The live IMD is an owner-controlled LayerZero OFT with a blocklist and a transfers-enabled switch. Blocked winners are already handled by rollover. Blocking the dead address or the derby itself would halt purchases and payouts until unblocked, with no loss of funds. Today transfers are enabled and neither address is blocked.

Coverage answers all 27 listed entry points plus four invariant rows: 30 hold and one carries the info finding. DerbyAuction rows are marked as light traces since it is not part of this deployment.

The review is complete and the findings file validates: both snippets match the tree at their cited lines, all 27 listed entry points have a coverage row, and no tracked file changed.

Outcome: no defect in the assigned area. I traced every SwarmDerby entry point through the Access Control, Trust Gap and Asymmetry checklists and found the permission model sound. The two items in .imd-findings.json are informational only and open no revision.

What I checked

• Access map. Every writer of every storage variable was traced to its weakest guard. Owner powers are limited to prices (floored), the house-key proposal lifecycle, the 5% ops share, and two-step ownership. Pots, vaults and rollover are unreachable by the owner. activateHouseKey is permissionless but can only install the owner's own proposal inside its window.
• Sessions. Binding needs the key's EIP-712 signature with a per-key nonce and the contract's domain. Keys cannot have keys, a player with a key cannot become one, and rebinding the same key needs a fresh signature. Prizes and board credit always go to the player, never the key.
• Draw and reveal. The house message binds the commit, so a player cannot grind salts, and sig < modulus plus a full padded-message comparison leaves one valid signature per swing. draw, finalize and expire have complementary time boundaries, so no state exists where the two closing paths disagree.
• Admin variants and in-flight value. Revoke, rotate and price changes were diffed against the user paths. Each either refunds, reverts cleanly, or is a limit the brief already accepts (no maxCost, no consent deadline, outsider-timed activation).
• Launch inputs. The eight key words rebuild the brief's modulus byte for byte, owner_ is explicit and not the factory, and DerbyOdds.sol and HouseDraw.sol are identical to the audited commit.

The two informational notes

1. revokeHouseKey clears a pending proposal without the HouseKeyProposed(0, 0) log that cancelHouseKey emits. State is correct. Only event-driven watchers are affected.
2. The constructor now takes twelve static arguments. A manifest written from the brief's five-argument wording would fail, since a single 514-character key exceeds the 96-character argument limit. The manifest must use the twelve values from ADAPTATION.md with contract set to SwarmDerby.

Verification. The full suite passes at 125 tests. Eight scratch probes under test/scratch/Perm.t.sol confirm the edge cases above. That directory is mine and is not kept.

Next. The manifest step should carry the twelve arguments in ADAPTATION.md's order. The accepted trust limits remain as documented: the key holder must not play, and purchases pay the price in force when they land.

Added failure-path tests and four stateful invariants.

forge build and forge test pass: 145 tests, zero failures. Invariants passed 16,384 randomized calls.

All changes are under test/. No reproducible contract defect found; live-chain integration remains unverified.

I found no defects to report, so .imd-findings.json holds an empty findings list plus a coverage row for all 27 entry points and two invariants I checked. No tracked files were changed.

What I checked

• Full test suite: forge test passes with 145 tests and 0 failures. The brief expects 117; the extra 28 come from tester work already accepted into the tree.
• Constructor and manifest: launch.json passes 12 arguments. Arguments 5–12 are bytes32 words that join, in order, into exactly the 256-byte modulus from the brief. The owner comes from $owner, not the factory, and the constructor calls no other contract and accepts no ETH.
• Source changes since the fix commit: apart from formatting, only two things changed in src/SwarmDerby.sol. The constructor now takes the key as eight bytes32 words, and purchases revert NoHouseKey while the key is revoked. Function signatures, events, the EIP-712 domain, drawMessage, the split and the payout math are unchanged.
• Unchanged files: src/DerbyOdds.sol and src/HouseDraw.sol have no changes.

SwarmDerby entry points: I traced all 17 by hand and each behaves as intended. The ones most worth a second look:

• A late reveal cannot change a board that has already settled. finalize still scores at exactly 10 minutes after the commit, while dayClosed only turns true after that moment.
• Daily payouts keep the pot balanced. A prize the token refuses rolls over to the next day instead of being lost.
• expire cannot underflow the arcade cap counter, because the slot it gives back was taken when the swing was committed.
• Session binding blocks key chaining and replay: each consent is signed for one player and carries a nonce that changes on every bind.

Specialist findings, all dropped:

• Five-argument brief vs twelve-argument constructor (economics low, permissions info): the manifest already uses the correct twelve words, so there is no defect in the code or manifest.
• Tokens sent directly to the contract are stuck; turns are stranded while the key is revoked; the IMD token owner can block addresses: these are by design or already listed as trust assumptions in DEPLOY.md under Known limits.
• A finalize sent too early leaks the salt: this needs the player's own client to misbehave, so it is not a contract defect.
• revokeHouseKey drops a pending proposal without emitting HouseKeyProposed(0, 0): this does reproduce, but the contract's state is correct and it only affects off-chain watchers. You said to keep the code unless something critical or high turns up, so I noted it in the coverage row rather than as a finding.

I did not trace the 10 DerbyAuction entry points, so they are marked unreached. This launch doesn't deploy DerbyAuction. The static-analysis leads I checked turned out to be safe or deliberate. For example, the "uninitialized" _board/_days are mappings, and the strict equality in activateHouseKey is a zero check.