The audit is complete. The findings are in .imd-findings.json at the repository root, and no source file was changed.

Verdict: no critical, high or medium defect. The code can ship as it is. Two low findings and one coverage note were recorded.

What was read and verified

• Both contracts in full, src/SwarmDerby.sol and src/DerbyOdds.sol, plus the 53-test suite, which passes on the pinned toolchain. Runtime size is under the EIP-170 limit and the bytecode has no forbidden opcodes, proxy, or initializer.
• Live Robinhood Chain over the public RPC. ArbSys serves hashes for exactly the last 256 blocks, so the 255-block reveal window and the day-close rule match the real precompile. Blocks arrive about every 100 ms, so the reveal window is about 25 s as documented.
• The IMD token at the requested address has code. It is a LayerZero OFT on an OpenZeppelin ERC20 base with an owner blocklist and a transfers toggle, currently enabled. It has no transfer fee and no receiver hooks, so there is no reentrancy path into finalize or settlement. Its verified source could not be fetched: Blockscout sits behind a Cloudflare challenge and Sourcify has no match for chain 4663, so behaviour was inferred from selectors, live view calls and the verified Ethereum sibling.

Low findings

• Constructor code check versus the deployment rehearsal. The constructor reverts when the IMD address has no bytecode. On the real chain it has code, but the protected harness deploys in a plain Foundry EVM with no fork, where that address is empty, so the rehearsal reports a constructor failure. The adapter should run it against a fork or etch the token first.
• A signed Session consent redirects the signer's own play. Any funded wallet that signs a Session message naming another account becomes that account's key. Its later purchases and swings are booked to the other account, and its own turns are unreachable until it calls leaveSession. This is a phishing surface rather than an authorization gap, and the signer can always leave. Narrowing it would change behaviour, so the decision belongs to the owner.

Traced and found sound: the 40/45/10/5 split and the pot, vault and ops conservation; per-day pots with in-order settlement and rollover; the last-target rule that prevents a reveal after a day is paid; commit binding to the player; the per-player arcade cap across session keys; one-to-one session binding with single-use nonces and signature checks; the top-10 board ordering; two-step ownership and the ops-only withdrawal. The items the owner already accepted were not re-raised.

Prepared the adaptation with both production contracts byte-identical. Added four regression tests, fixed test-only ArbSys compatibility, and documented changes in ADAPTATION.md.

forge build passes; forge test passes all 57 tests, including the original 53.

The independent protected rehearsal still requires IMD dependency state. Live RPC checks returned HTTP 403. No deployment was broadcast.

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

• Manifest schema and constructor ABI checks passed.
• forge build passed.
• forge test: 57 passed, including all 53 application tests.
• Only launch.json changed; contract sources remain byte-identical.

The review is complete. .imd-findings.json holds an empty findings list and a coverage record with all 12 entry points marked holds, plus 7 invariant and periphery rows. The scratch tests are removed and the tree is otherwise untouched; forge test still passes 53 tests (57 with the launch suite).

What I covered. I traced every entry point through the Execution Trace, Periphery and First Principles checklists, confirmed each trace with scratch Foundry tests, and then checked the two external dependencies against the live Robinhood Chain, since the RPC that returned 403 for the earlier worker now answers.

Why there are no findings. The control flow holds at every seam I could attack:

• Settle versus reveal has no gap. Settlement needs the block to reach the day's last target plus 256. At that same block a reveal already skips the hash and lands as a foul. One block earlier the reveal still scores and settlement reverts.
• Accounting is conserved on every failure path. Pots, vaults and ops are decremented before each transfer and restored when the token refuses. With all three winners refused, everything rolls over and the token balance still equals the five buckets.
• The board cannot be corrupted. An improving player moves up without duplicating, a tying newcomer stays off, and a full board replaces only its last slot.
• Session keys cannot be hijacked. The digest binds player, key, nonce, chain and contract. The same consent cannot rebind a key after it leaves or is rebound.

Live chain verification. Chain id is 4663. The ArbSys precompile at address 100 returns the real L2 block hash and reverts outside the 256-block range, exactly as the contract assumes. One thousand blocks spanned 103 seconds, so the 5-block delay and 255-block window are about 0.5 s and 25 s as the comments state. The contract's use of arbBlockNumber is correct: the L2 number is 82.1 million while block.number reports 26.1 million. A fork rehearsal against the real IMD token showed exact amounts on purchase, burn and ops withdrawal, with no fee and no recipient hook.

Not reached. The live IMD token is an owned bridged token with a custom transfer gate. I did not reverse its gating logic. The owner's power to block addresses or halt transfers stays the documented external trust assumption, and the contract already degrades safely when a transfer is refused.

The review is complete. The findings file is written at the repository root, the tree is otherwise unchanged, and the full suite still passes with all 57 tests.

Result: no math, boundary or numerical-gap defect found. The assigned area was covered in depth and every one of the 12 entry points has a coverage row, plus 8 invariant and boundary rows.

What I checked in my area

• Purchase split. The 40/45/10 shares floor and the remainder goes to ops, so burned plus held always equals cost. Fuzzed at 1000 runs with odd wei prices down to the 0.01 IMD floor.
• Settlement payout. The 90% cut, 0.5% tip and 60/25/15 shares all round toward rollover, so paid never exceeds the day's amount and the subtractions cannot underflow. A six-day fuzz with blocked winners confirmed pot equals rollover plus open day pots, and the token balance equals the contract's own accounting.
• Board. Scores only increase, so the bubble-up keeps the true top 10 sorted with ties resolved in favour of the earlier score. Verified through the real swing and finalize path with rigged block hashes.
• Reveal window. The 255-block finalize window and the day-closed check are exact complements, verified at both edge blocks. Slam payouts and failed sends keep the vault identity.
• Casts. The uint64 target block and uint32 day cannot truncate on any realistic timescale, and feet fits uint16.

Live boundary facts verified on Robinhood Chain

• IMD at the pinned address is a LayerZero OFT with 18 decimals. A forked transfer and transferFrom moved exactly the requested amount with no fee or receiver callback, and the dead address is not blocked.
• ArbSys exists at address 100 and serves hashes at distances 1 through 256 blocks, measured in a single eth_call, so the 255-block window sits inside it. On this chain block.number is the L1 number, so reading ArbSys is correct.
• Blocks arrive every ~100 ms even when empty, matching the timing in the comments.

One informational note, outside my area and not reproduced. The randomness argument assumes the player cannot affect the target block's hash. A player who lands a transaction in that block does change its hash. Grinding it would need a sub-100 ms race against the sequencer, which I did not attempt. I recorded this as info so the judge can weigh it. It does not call for a code change under the brief.

Review complete. The economics of SwarmDerby hold: no critical, high, medium or low defect was found in the Economic Security, Invariant and Flow Gap areas. The findings file carries one informational trust-assumption entry plus 17 coverage rows, and the tree is otherwise unchanged with all 57 tests passing.

What I verified

• Conservation. A 512-run lifecycle fuzz interleaving purchases, rigged homers, bombs and slams, token-refused winners and slam recipients, skipped days and settlements kept contract balance equal to pots plus vaults plus ops, and kept each league's pot equal to rollover plus its open day pots at every step.
• Settlement and reveal seam. A swing committed at 23:59:59 and settled at target plus 256 blocks finalizes as a foul, so no score or slam can land on a settled day. The settle bound and the reveal bound are the same number.
• Board integrity. With a full board of ten, a dropped player who then slams re-enters at first place with no duplicates and correct ordering.
• Live dependencies. The Robinhood Chain RPC answered this time. Chain id is 4663, ArbSys at address 100 serves recent hashes and reverts outside its window as the contract expects, and the IMD token moves exact amounts with a 32-byte true return, allows transfers to the dead address, and has no fee. A fork test confirmed this.
• Vault economics. At 0.8% slam odds the vault's steady state is roughly 12 to 19 IMD, so draining it is never profitable. Whale and sybil play in the agent league is net negative due to the 40% burn, as designed.

The one recorded item

The IMD token exposes an owner blocklist and a transfer switch on chain. If its owner disables transfers or blocks the derby or the dead address, purchases, ops withdrawals and the settlement tip revert and slam prizes stay in the vault until the token unfreezes. No accounting drifts and nothing is lost. DEPLOY.md already lists this as a known limit, so I filed it as info rather than a defect.

Not reached or out of scope

• DerbyOdds is byte-identical by requirement and only its monotonicity and parity tests were relied on.
• The sequencer-adjacent block-hash grinding scenario on a fully idle chain was reasoned about but has no Foundry reproduction, so it is not reported.
• One side note for the author: under via-IR Foundry caches block.timestamp across a mid-function vm.warp, which can mislead test harnesses. The contract itself is unaffected since every external call reads the timestamp fresh.

The review is complete. The findings file is at .imd-findings.json, the scratch tests are removed, no source or config file was changed, and the full suite still passes (53 original tests plus the 4 launch tests).

Outcome: no critical, high or medium defect in the Access Control, Trust Gap or Asymmetry area. The code should ship unchanged.

What I covered

• Permission map. All 12 state-changing entry points traced: three are owner-only (setPrices, withdrawOps, transferOwnership), one is pending-owner-only, one is bound-key-only, and the rest are intentionally public. Every guard matches its effect. The owner cannot reach pots or vaults because the ops debit reverts on underflow, and ownership cannot be renounced.
• Session keys. Binding needs the key's own EIP-712 signature with a per-key nonce, chain id and contract address. A key cannot rebind, cannot be bound by a second player, cannot have its own key, and cannot spend its player's token allowance. Its only powers are swinging on the player's turns and revealing. I confirmed each of these with scratch tests.
• Asymmetry pairs. Buy versus settle, finalize versus expire, view versus mutate settlement math, slam versus daily payout on refused transfers, and the two session writers all mirror each other. The reveal and expire windows are disjoint and complete around target plus 255 blocks, so a day's board is final before it is paid.
• Live dependency. The public Robinhood RPC answered this time. Chain id is 4663, and the pinned IMD address holds the "Identity.md" OFT token with 18 decimals. A fork rehearsal with the exact launch arguments showed a purchase pulls the exact price, burns to the dead address, and leaves the contract holding precisely pot plus vault plus ops. No fee, no receiver hooks. The token owner does hold blocked(address) and a transfer switch, which the deploy notes already document.

Two informational notes recorded, neither opens a revision

1. With no pending owner, a call from the zero address would pass the acceptOwnership check. No real transaction can have that sender, and OpenZeppelin's Ownable2Step has the same shape.
2. The protected launch rehearsal still needs code at the IMD address or a Robinhood fork, as the earlier low finding already states. The live-chain evidence above confirms the constructor succeeds in the real environment.

Not reached: sequencer and block-hash randomness, which belongs to another specialist's area.

Added 23 tests covering failure paths, signatures, events, rounding and stateful invariants.

• forge build: passed.
• forge test: 80 passed, 0 failed.
• Invariants: 256 sequences, 16,384 calls, zero unexpected reverts.

Only test/ changed. Both production contracts remain byte-identical. Live IMD and ArbSys behavior remains unverified; tests use offline fixtures.

The findings file is in place at the repository root, excluded from git by the harness's own exclude rule, and the working tree is otherwise clean. Nothing else is needed from the tools.

Verdict: no critical, high, medium or low defect reproduced in SwarmDerby. The code can ship as it is. The findings file holds four informational notes and a coverage record answering all twelve entry points plus two invariants.

What I verified beyond the specialists' reports

• Full suite passes: 80 tests, which include the original 53, the four launch tests and the tester's failure and invariant suites.
• Live Robinhood Chain reads today: chain id 4663, IMD at the launch address with symbol IMD, transfers enabled, 0xdEaD not blocked, and ArbSys serving hashes for distances 1 through 256 and reverting outside that. The contract's 255-block finalize window and its day-closing bound are therefore consistent and conservative.
• A scratch fork test deployed the exact launch constructor against the live token. One turn plus one pack pulled 0.65 IMD, burned 0.26 to 0xdEaD, and left 0.39 held equal to pots plus vaults plus ops. The owner withdrew the ops share. The scratch file has been deleted.
• DerbyOdds.sol hash matches the accepted record, and launch.json lists only SwarmDerby with the brief's four arguments.

How the specialist findings settled

1. Protected harness reverts NotAContract in an empty EVM. Reproduced via the existing launch test. Kept as info, since it is the already dispositioned low 980f397e and the guard is correct for the real chain. The gap is in the verifier's rehearsal setup, which needs a Robinhood fork or an IMD fixture.
2. acceptOwnership from the zero address with nothing pending. Reproduced in Foundry, unreachable from any real transaction. Info.
3. IMD token admin can pause all value flows. Confirmed the switches exist on the live token. Funds stay accounted and resume. Info, as a trust assumption.
4. A player who lands a transaction in the target block influences its hash. Not reproducible offline and not demonstrated on chain. Kept as an info note that DEPLOY.md's threat model should state this precondition.

No duplicates existed across areas, so nothing was merged. My own pass with the Pashov mindset over sessions, boards, settlement ordering, rollover accounting, slam payouts and the ArbSys window found nothing the specialists missed.