The audit is complete. The findings file is written and validated. No source files were changed; the only artifacts are .imd-findings.json and the disposable test/scratch/ tests.

Result: no critical, high, medium or low defect in src/DerbyAuction.sol

The contract can be redeployed as it is with the stated constructor arguments. One info-level operational note is recorded in .imd-findings.json.

What I read

• src/DerbyAuction.sol in full, every state-changing function traced through guards, token calls and accounting against the Pashov checklist. git diff 5c5c30d on this file is empty, so it is the audited source.
• src/SwarmDerby.sol v2, specifically swing, draw, finalize, expire, dayClosed, board, _bump, and the token helpers, to confirm the two functions the auction depends on. src/DerbyOdds.sol and src/HouseDraw.sol were not reviewed beyond their role in those paths; they were out of scope.
• test/DerbyAuction.t.sol and the protected rehearsal test.

What I verified on Robinhood Chain over the public RPC (chain id 4663, the explorer itself is behind a Cloudflare challenge and could not be reached)

• The v2 derby at 0x53d9…831c has runtime bytecode identical to the local SwarmDerby build except the three imd immutable slots, which hold the IMD token address from the task. Its owner() is the same wallet that owns the live v1 auction, its house key is set with no pending key, and it has no swings yet.
• The live v1 auction at 0x0d81…ab7b has runtime bytecode identical to the local DerbyAuction build except the immutables, so the new deployment will differ from the audited live code only in the derby address.
• The IMD token at 0x5F7B…7127 is an OpenZeppelin v5 ERC20 wrapped in a LayerZero OFT (18 decimals, shared decimals 6). It has no paused, blacklist or EIP-1967 proxy slots, transfer and transferFrom return a 32-byte true, and it reverts on a zero receiver. That matches the return-data handling in _accepted and _pull.

Key conclusions from the code review

• v2 keeps the board-final guarantee the auction relies on: every swing of a day has committedAt at or before dayLastCommit, and finalize after that window is a foul, so board(0, day) cannot change once dayClosed(0, day) is true.
• Bid, settle, veto, payBonus, reclaim and withdrawRefund follow checks-effects-interactions behind a shared reentrancy lock. The _bps helper is an exact floor without overflow, share sums never exceed the bonus, and carry is conserved through settle, veto, payBonus and reclaim.
• The constructor makes no external calls, and a rehearsal test on an empty chain reproduced the protected harness: create2 through an etched factory, 9,520 bytes of runtime, no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Two scratch fuzz tests passed, one for the open-day and anti-snipe window and one for carry conservation across settle, payBonus and reclaim. The existing 145 project tests also pass.

Recorded as info (not a code defect): the live v1 auction holds a settled 2 IMD bonus for theme day 20735 whose payout is bound to the v1 derby's board. If players move to v2 before that day ends, payBonus on v1 parks the 2 IMD as carry on the abandoned contract. The owner should decide whether to keep v1 players for day 20735 or leave the bonus unpaid so the bidder can reclaim it after the grace period.

Accepted trust assumptions, unchanged: owner may veto settled auctions before the theme day, set the studio and a fee up to 1 IMD that applies at settlement, and payBonus and reclaim race after the grace period.

Prepared the DerbyAuction-only launch handoff. All contract source and ABI remain unchanged.

• forge build passed.
• forge test: 150 passed, no FFI.
• Added five regression tests; two local fork checks also passed.
• Corrected the audit note: earliest unpaid-bonus reclaim is 2026-10-17 00:00:01 UTC.

Changes and migration details are in ADAPTATION.md. No transactions were broadcast. The next manifest step must replace the existing SwarmDerby launch manifest.

Updated launch.json to deploy only DerbyAuction with the exact approved constructor arguments.

Schema and compiled ABI checks passed. forge build passed with existing warnings; forge test passed all 150 tests with FFI disabled.

Only launch.json changed.

The findings file is valid, the snippets match the tree, and the scratch test is removed. The review is complete.

Result: no critical, high or medium defect in DerbyAuction. The code should ship unchanged, as the brief intends. The findings file holds two low-impact items and 30 coverage rows.

What I traced (Execution Trace, Periphery, First Principles guides):

• bid: open window, settled guard, 5% ceil increment, answer screening, anti-snipe extension that never shrinks and caps at 19:00 UTC, exact-receipt token pull before the outbid refund. The concurrent next-day auction during an extension is by design.
• settle: exclusive with bid at the end timestamp, fee capped by the bid, carry taken only with a winner and strictly before midnight. Verified at midnight minus one second versus midnight.
• payBonus: gated on SwarmDerby v2 dayClosed, which I confirmed is final because a late reveal scores a foul and a late draw is rejected. Tip, 60/25/15 split, carry of unfilled shares and failed sends, and rollback on a failed tip all hold.
• veto and reclaim: return the bid less the fee, send inherited carry back to the pool, and are mutually exclusive with payment through the paid and vetoed flags. The accepted post-grace race holds as documented.
• Conservation: token balance equals unpaid bonuses plus carry plus refund credits across every sequence I ran, plus the repo's fuzz test.

Findings recorded:

1. Low: the committed launch.json still names SwarmDerby with twelve arguments. If the manifest step does not replace it with the single five-argument DerbyAuction entry, the launch redeploys SwarmDerby and never deploys the auction. ADAPTATION.md already says it must be replaced; the judge should confirm it is.
2. Info: openDay() returns day 1 for timestamps below 18:00 on the first Unix day, which bid rejects. Unreachable on a live chain.

Checks run: the full suite passes with 150 tests, and three scratch boundary probes passed before I deleted them. The protected deploy rehearsal needs factory environment variables and was not run here.

Review complete. The findings file is written and validated, the scratch test is removed, and the tree is otherwise untouched (.imd-findings.json is ignored by git, so status is clean).

Outcome: no critical, high, medium or low defect in the Access Control, Trust Gap or Asymmetry areas of src/DerbyAuction.sol. The code should ship unchanged for this launch.

What I checked and confirmed

• Permission map. Owner holds only veto, setStudio, setBuildFee and two-step transferOwnership. Every storage variable has consistent guards across its writers. There is no owner sweep, no renounce path, and the constructor takes an explicit owner rather than the factory.
• Window disjointness. Veto runs only before the theme day, payBonus only after the board closes, reclaim only after the 7-day grace. I confirmed with a scratch Foundry test that the owner can still settle and veto at 23:59:59 after the 19:00 anti-snipe cap, and that a handed-over owner loses veto and fee powers.
• Token destinations. Every transfer goes to msg.sender's own refund, the auction leader, the studio fee, the caller tip or the top three board players. Carry is never paid to a bidder on veto or reclaim.
• v2 dependency trust. SwarmDerby v2 uses league 0 for the arcade, writes dayLastCommit only with the current day, and records dingers under the commit day, so dayClosed(0, day) becomes true within ten minutes of midnight and the board is final when the auction pays it.
• Launch inputs. Owner and studio resolve to $owner, fee is zero, both dependency addresses are nonzero and immutable, and the constructor makes no external call. The current launch.json still describes the SwarmDerby launch, which ADAPTATION.md explicitly defers to the manifest step.

Recorded

• One info entry, labelled as a trust assumption rather than a defect: the owner, who is also the studio, can raise the fee to 1 IMD before settle and then veto, keeping 1 IMD of a bid. This is bounded by the cap, already stated in DEPLOY.md's Known limits, and reproduced with concrete balances.
• Coverage rows for all 27 listed entry points plus 4 invariants. Seven SwarmDerby functions outside my area and not part of this deployment are marked unreached.

Added failure-path fuzz tests, stateful custody and lifecycle invariants, and coverage notes under test/.

forge build and forge test passed: 154 tests, zero failures. Source and configuration unchanged. Live Robinhood Chain integration remains unverified.

The review is complete. The findings file is in place and the tree is otherwise untouched (the findings file is excluded by the repo's own git exclude rule, scratch tests removed, git status --porcelain is empty).

Outcome: no critical, high or medium defect in the assigned area. The arithmetic and time boundaries of src/DerbyAuction.sol hold under the Math Precision, Boundary and Numerical Gap checklists, so the code should ship unchanged as the task requires.

What I verified, with concrete inputs:

• _bps is an exact floor of amount*bps/1e4 for the whole uint256 range, never overflows (fuzzed 2000 runs against a 512-bit identity).
• minNextBid is ceil(lead * 1.05) floored at 2 IMD (fuzzed 2000 runs, including the 2e18+1 case).
• Payout math: tip and the 60/25/15 shares sum to at most the bonus, dust to carry is at most 2 wei, and the bonus is always at least 1e18 because MIN_BID exceeds MAX_BUILD_FEE, so nothing rounds to zero.
• Anti-snipe end is monotonic, never below the default close and capped at 19:00 UTC; walked to the cap, the final bid at cap minus one second leaves one second.
• Veto, reclaim and _releaseBonus never underflow and never refund inherited carry.
• Derby closure boundary: a dinger can only be recorded while ts <= committedAt + 10 min, and dayClosed needs ts > dayLastCommit + 10 min, so the board the auction pays is final.
• Full suite in a clean environment: 150 tests passed, 0 failed.

Findings written to .imd-findings.json (3, none needing a proof file):

1. Low, outside my area: launch.json at HEAD still describes the prior SwarmDerby launch (twelve arguments), not the five-argument DerbyAuction deployment this task names. ADAPTATION.md says a later manifest step replaces it; if that step is skipped, a second SwarmDerby is deployed instead of the auction.
2. Info: once the lead exceeds about 20/21 of uint256.max, minNextBid and bid revert with panic 0x11 instead of BidTooLow. Unreachable with any real supply; settle and payout of such a bid still work.
3. Info: before timestamp 64800, openDay() returns day 1 while bid(1, …) always reverts BadDay. Only affects the first 18 hours of 1970.

Coverage: all 27 listed entry points have a row (10 DerbyAuction, 17 SwarmDerby), plus 5 invariant rows. The SwarmDerby functions that feed the board or dayClosed were traced; the rest are marked holds on the grounds that nothing the auction reads depends on them.

Review complete. The findings file is written and validated against the tree, and the scratch test directory is removed.

Outcome: no critical or high defect in src/DerbyAuction.sol. The code can ship unchanged, as the brief prefers. Two findings are recorded in .imd-findings.json, with 31 coverage rows covering all 27 listed entry points plus three invariants and the manifest.

Findings

• Medium, launch.json. The manifest in the tree still describes the earlier SwarmDerby launch (one SwarmDerby entry, 12 constructor words). The brief requires one DerbyAuction entry with five words. Admitted as is, it would deploy a forbidden second game and no auction. The adaptation notes already say the manifest step must replace it. This is a configuration gap, not a code change request.
• Low, src/DerbyAuction.sol payBonus. On an empty arcade board, anyone can call payBonus the moment the day closes, which is seven days before the reclaim grace opens. The winner's entire bid then sits in carry, and nothing can release it except a later winning auction settled before its theme day. At end of life, which this very migration from v1 shows happens, the carry is stranded for good. Bounded loss and a design limit, so any fix needs an owner scope decision.

What I verified

• Economic flows: bid, outbid refunds, settle fee and carry folding, veto, payBonus split, reclaim grace, refund credits. The split is exact and never exceeds the bonus, carry is never double counted, and the balance conservation invariant holds through every writer. Full suite passes at 150 of 150.
• Flow-gap seam with SwarmDerby v2: the board that payBonus reads is final once dayClosed is true, because draws and scoring reveals are gated strictly inside the ten-minute window and purchases never touch the closure timestamp.
• Dependencies on Robinhood Chain at block 83,730,046: the v2 derby has code, reports the expected IMD address, and answers dayClosed and board. The IMD token has no pause, blacklist or proxy selectors. The local DerbyAuction runtime equals the live v1 auction after masking its five immutable slots.

Not reported as defects: owner powers on fee and studio, the post-grace race, the 19:00 extension cap, and the known limit that a bidder can also top the arcade board and recover their bid plus carry. These are accepted in the brief or the spec.

The findings file is in place, excluded from git by the harness's own rule, and the scratch directory is removed. The review is complete.

Outcome. No critical, high, medium or low defect reproduces in src/DerbyAuction.sol. The findings file holds two info items and a 31-row coverage record. The tree is otherwise unchanged.

Specialist findings, settled:

• Stale launch.json (economics, math, flow): dropped. At HEAD the manifest already lists one DerbyAuction entry with the five constructor words from the brief, so the three reports no longer reproduce. Merged as one dropped item.
• Owner fee-then-veto (permissions, info): kept as info. I reproduced it in a scratch test. It is the owner-accepted settlement-time fee read, bounded to 1 IMD per auction and not triggerable by anyone else.
• Empty-board payBonus strands the bid in carry (economics, low): kept, recalibrated to info. The attached proof passes and shows the state. The WP3 spec orders exactly this behaviour and DEPLOY.md documents it for the day 20735 migration, so it is a design limit, not a defect.
• minNextBid overflow near uint256 max (math, info): dropped as unreachable. IMD total supply on chain is about 5.2e22, far below the 2^256 scale needed.
• openDay names day 1 before 18:00 on 1 Jan 1970 (math and flow, info): merged and dropped. The window is not reachable on any live chain.

My own checks beyond the panel:

• Full suite passes: 154 tests, no ffi, including the invariant runs.
• The local runtime equals the live v1 auction byte for byte except the immutable address slots, which confirms the brief's byte-identity claim.
• The live SwarmDerby v2 runtime equals the local build except its IMD immutable, and it answers the three read selectors the auction depends on.
• I traced all ten DerbyAuction entry points and all seventeen SwarmDerby entry points myself, including the seven the permissions specialist could not verify. HouseDraw's RSA check is strict PKCS#1 v1.5 with a below-modulus guard, so draw holds.

What is left for others. Admission, attestation and the deployer's simulation happen after this review. The operator still has to decide how to handle the 2 IMD bonus left on the v1 auction, as DEPLOY.md already notes.