Review complete. The findings are in .imd-findings.json (one medium defect with a Foundry proof, one info coverage entry). No tracked file was changed; the proof lives under test/scratch/, which git ignores.

What was checked

• Read in full: ChessEngineV5, Bitboard, Rules, Chess, Strength, IChessEngine, and IMDuelHook as the engine's consumer. Nothing in src/ was out of reach. The hook is not part of this launch, so its own behaviour was not audited beyond the engine call contract.
• Build and tests pass as committed: forge build succeeds and forge test passes 123 of 123. The engine compiles in the 200-run profile to 22,182 runtime bytes with no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT. It has no constructor, storage, owner, initializer, mint, pause or ETH path. The manifest has only kind, contracts and notes, with an empty argument list matching the absent constructor.
• Probes beyond the suite: 2,070 positions sampled from the random chess.js games, with random accuracy, seeds, quiet counts and real history keys, always gave a legal move whose result equalled the checked rules. Worst gas was about 600k at the 218-move position, far under the hook's 3M cap. The engine's repetition key matches how the hook fills the history array.

The finding (medium)

The second look in _exact only tests for stalemate when the enemy has at most three pieces left, and blocked pawns count. With a king and three immobile pawns, a capture of the enemy's last mobile piece scores as plain material gain and the engine plays it. Reproduction: white Kc1 Qb2 Bc4 pawns a6 c6 g6, black Kh8 Ra1 pawns a7 c7 g7, white to move in check. At every accuracy and seed, including 10,000, the engine plays Qxa1 and the game is a stalemate draw instead of a trivial win. Remove the c6/c7 pair so black keeps three pieces and the same call plays Kd2. In the hook this throws away a won game and the mate bounty. No funds move wrongly. The proof test in test/scratch/Stalemate.t.sol fails on the current code and passes once the piece-count gate is dropped or counts only mobile pieces.

Unverified lead, not filed: the engine tests at most six checks per choice for mate, in from-square order, so a mate in one preceded by six non-mating checks could be missed at full accuracy. The author documents this bound and I did not construct a failing position in the budget.

I've written the review to .imd-findings.json: three findings and 11 coverage rows. That covers all 9 entry points, plus ChessEngineV5 and one accounting invariant. All three quoted snippets match the tree, and no other file changed (git status is clean). There is no Foundry proof test, because none of the findings is high or critical, and I did not run forge test.

What this launch deploys. launch.json deploys only ChessEngineV5. It has no constructor, storage, owner or payable path, and play, playAny and choose are all pure. So the deployed contract has nothing to control access to, and constructorArgs: [] is correct. Every listed entry point belongs to IMDuelHook, which this launch does not deploy, so the findings below are about the hook.

Findings

1. Medium – convert(ETH) can be repeated in one transaction (src/IMDuelHook.sol:419).
   • The design: the ETH conversion swaps in the IMD/ETH pool at that pool's current price (line 495). Its only protection is a 0.2 ETH cap per batch (line 470).
   • The gap: anyone can call convert, and nothing stops repeat calls. One caller can push the pool's price once, then call convert about 24 times to sell all the ETH waiting to be converted (4.8 ETH in my example) at the pushed price, then sell back.
   • When it pays: I read the live route pool on mainnet: about 410 ETH of in-range depth. At that depth the attack profits once roughly 4 ETH is waiting, against roughly 20 ETH if only one batch could be sold per push.
   • How the ETH builds up: each trade adds 0.1% of its ETH side but converts at most 0.2 ETH, so trades over 200 ETH leave a growing amount (the existing test_anEthBatchIsCapped shows this).
   • Fix: anchor the ETH price once per block, as the main duel already does, or cap ETH sold per block instead of per call.
2. Low – rewards default to tx.origin (src/IMDuelHook.sol:588). When a swap doesn't pass the trader's address in hookData, the bid and its bounties go to whoever signed the transaction. For smart-wallet users that is the bundler, and for CoW or UniswapX orders it is the solver, not the trader.
3. Info – stale size in the manifest notes (launch.json:9). I rebuilt with the committed settings: ChessEngineV5 is 22,111 bytes, but the notes (and the task) still say 22,182. ADAPTATION.md already said the notes should be updated. Otherwise the manifest is schema-valid.

Coverage. I checked every entry point against the Access Control, Trust Gap and Asymmetry guides. All of these behave as intended:

• Manager-only callbacks: afterInitialize, beforeSwap, afterSwap and unlockCallback accept only the PoolManager.
• Self-only functions: payOut and convertBatch accept only the hook itself.
• fundChest: it takes tokens only from the caller, and the ETH amount must match exactly.
• withdraw: anyone can call it, but it pays only the address it was owed to.
• Accounting: the hook's balance claims match its war chests, waiting conversions and owed amounts.

These static-analysis leads were not real problems:

• "Locks Ether" (aderyn): rejected. fundChest passes all its ETH on to the PoolManager.
• Reentrancy (Slither): the leads concern calls to the trusted PoolManager or the hook's own self-calls, which a lock or a gas cap bounds.

The risk of someone opening a fake main duel first is closed, because the hook launch opens the main duel in the same transaction (per launch/hook.json).

Not done: I ran no test to reproduce findings 1 and 2. A build alone took about 5 minutes, and medium and low findings don't require a proof. The reproductions in the file are worked through by hand, using the live mainnet pool figures.

Review complete. The findings file is written and validated.

What I audited. My area was the math guides (Math Precision, Boundary, Numerical Gap) against the ChessEngineV5 launch and the IMDuelHook entry points the verifier listed. I traced every division, cast, shift, mask and unchecked block in the engine, Bitboard, Rules, Strength and the hook, and reproduced the two hook leads with a scratch test under test/scratch/. The engine itself, the only contract this launch deploys, has no reachable arithmetic defect for positions the hook can feed it. Its piece-square tables, EDGE table, packed-value masks and bitboard compress/spread masks were checked bit by bit.

Findings written to .imd-findings.json:

• Low: fundChest reverts for tokens whose transferFrom returns no data (USDT class). The IERC20Min bool decode fails on empty return data, so a duel paired with such a token can never have its chest funded, although fee claims reach it normally. Reproduced: the funding reverts with empty data while the same transferFrom succeeds on its own.
• Low: bid size and payout cap come from the pool delta, not from what the trader paid and received. An exact-output trade's stored cap was 2.488e18 against a receipt of 1e18 during the opening window, and 2.008e18 in normal time, against the documented "at most twice what its trade received". Recorded size also differs by swap mode for equal cost.
• Info: _swapClaims computes the batch price limit without clamping to v4's sqrt-price bounds. Within 0.1% of MIN or MAX the conversion reverts or the uint160 cast wraps and the batch is silently skipped. Only reachable at a ratio near 2^128, so reported for completeness.

Coverage. All nine listed entry points have rows: six hold, afterSwap, fundChest, convert and convertBatch point at the findings above. Extra rows cover the engine's play and playAny, the lone-king conversion scoring, the bitboard pack/unpack masks, the strength curve, the repetition ring and the manifest.

Checks run. forge build succeeds. The Money, Hostile, Adaptation, Launch and Size suites pass, 42 tests. No repository file was changed; the scratch test is the only thing I added.

The review is complete and written to .imd-findings.json. The tree is unchanged apart from that ignored file, and my scratch test is removed.

Outcome. The ChessEngineV5 launch is sound from a control-flow standpoint. No critical, high or medium defect was found. Two findings are recorded, one info and one low.

What was verified on this tree

• forge build succeeds with the committed configuration. The suite passes with the documented fuzz seed: 133 tests, 0 failed.
• The engine's compiled runtime is 22,111 bytes. A reachability scan of that bytecode finds no DELEGATECALL, CALLCODE or SELFDESTRUCT, matching the protected floor test.
• The engine is pure, has no constructor, no storage and no ETH path. The manifest has schema keys only, one contract, and an empty constructor argument list.
• Engine gas against the hook's 3,000,000 cap stayed between roughly 0.2M and 0.6M on a 218-legal-move position and a nine-queen position at strengths 0, 5,000 and 10,000. The engine always returns the 224-byte shape the hook's caller requires.
• The hook's fee deltas, PartialFill check, transient stash, self-swap callback skipping and unlock dispatch were traced against the vendored v4 Hooks.sol. Exact-output swaps are exercised by the existing Money tests.

Findings

1. Info. The manifest notes give the runtime as 22,182 bytes. The committed source, after the accepted stalemate fix, compiles to 22,111 bytes. Nothing deploys wrongly, but the figure is stale.
2. Low. In the hook, a swap with empty hookData credits the bid to tx.origin. For a smart-account or relayed swap that is the bundler or relayer, which then receives the bounty. The existing Launch test asserts this exact behaviour through the router contract.

Coverage. All nine listed hook entry points have rows, eight holding and the internal play path referencing finding 2. Extra rows cover the engine's three external functions, the periphery libraries and the manifest. One row is marked unreached for move-generation re-verification against chess.js, the strength curve and the hook's economics, which fall outside the control-flow area.

The findings file is complete and verified against the tree. Git shows no tracked changes, so the only writes are the findings file and the scratch tests, which are permitted.

Economics review of IMDuelHook: result

I reviewed the money flows of src/IMDuelHook.sol against the Economic Security, Invariant and Flow Gap guides. The findings file holds three findings and fourteen coverage rows, one for each of the nine listed entry points plus five invariants.

Finding 1, high: a permissionless convert() loop defeats the ETH batch cap. The ETH leg of conversion relies on a per-batch cap and a 0.1% band around the route pool's current price. Nothing limits how often convert() runs in a block, so each call starts a fresh batch from the price the last one left. An attacker pushes the IMD/ETH price, loops convert(ETH), and unwinds. In the proof test the hook sold 4.9 ETH of slice in one block, nearly ten times the cap, and the attacker ended with 10.80 ETH from 10 ETH. The proof is test/scratch/EthBatchLoop.t.sol and fails on the current code. Minimal fix: one ETH batch per block, or anchor the route band to a block-start price as the main leg already does.

Finding 2, low: fundChest reverts for tokens whose transferFrom returns nothing. USDT-style tokens pass the pool's own transfer helper but fail the hook's bool-decoding pull. Verified with test/scratch/NoReturnFund.t.sol. No funds lost, fees still fill the chest.

Finding 3, low: bounties default to tx.origin. Contract wallets, bundlers and relayers submitting swaps without hookData see the bounty paid to the submitter. This is a documented choice, so it is recorded as a design note with a concrete case.

What holds. I traced the conservation invariant (claims equal chests plus pile plus owed) through every writer, the 2x payout cap, the full-fill check for exact input and exact output, the before/after fee split, the transient lock against nested swaps from an ETH payee, and the main-duel batch band anchored to the block's first price. Cross-block sandwiches of the main leg cost more in fees than the band can return. All nine entry points have a row: convert and fundChest carry findings, the other seven hold.

Not reached. I did not exercise exact-output trades or the EIP-2935 path in a live test, and I did not assess whether the mainnet IMD/ETH pool is deep enough to make finding 1 unprofitable at the launch's 0.02 ETH minimum. That depth decides its practical severity.

I added test/EngineV5Launch.t.sol with 16 tests of the launched ChessEngineV5, and reported one engine defect in .imd-findings.json. The full forge test run passes (149 tests, 0 failed) with the verifier's fuzz seed. I changed nothing in src/, foundry.toml or lib/, and committed nothing.

What the tests check. They load the 200-run engine build through vm.deployCode("ChessEngineV5.sol:ChessEngineV5"), which also keeps rebuilds fast.

• Deployment: it deploys with no arguments, fits under the 24,576-byte limit and has no storage. It rejects ETH (plain sends, unknown selectors, and value sent to play()), and unknown calls revert.

• Failure paths:

  • Any strength above 10,000 reverts in play() and choose(), including the maximum value and a position with no legal move; 0 and exactly 10,000 work for both colours.
  • A checkmated side (fool's mate) and a stalemated side make play, choose and playAny all revert with "no legal move".
  • When only one legal move exists, every strength and seed plays it.

• Random-input tests: on positions reached by random play, for any strength, seed, history, game number and quiet count:

  • play() picks the same move as choose();
  • the move is legal and gives exactly the result of the separate rules check;
  • the same inputs always give the same answer;
  • playAny() is legal and picks by seed modulo the move count.

• Random call sequences: a handler plays whole games through play and playAny and keeps sending ETH. After every sequence:

  • every move matched the rules check;
  • the engine's balance, code and storage are unchanged;
  • both kings are still on the board;
  • games end at the 200-move and quiet-move limits.

  The engine holds no funds, so this mainly guards against it ever holding any or keeping state.

The finding (low severity). The engine can miss a mate in one at full strength.

• Position: White Kh3, Ra1, Rd7, knights on e5, g5, d6, f4, h4; Black Kh8, Qb1, pawns g7 and h7; White to move.
• Expected: Rd7-d8, which is checkmate.
• Actual: at 10,000 bps the engine plays Ra1xb1 (taking the queen) for every seed tried. The engine only tests six checks for mate (MATE_TESTS = 6, src/ChessEngineV5.sol:361). Here seven other checks come first in move order, so it never looks at Rd8.
• Who it affects: only direct callers asking for 10,000 bps. The hook caps strength at 9,000, where the engine already skips some mates on purpose. Funds are not at risk.
• Why it matters: this is the open lead from audit 6959cb3f, which ADAPTATION.md left alone because nobody had built such a position. It also contradicts the claim in test/EngineV5.t.sol that a mate in one is always taken at full strength.

The finding includes a test that fails on the current code. I also kept a passing test showing that with two knights removed (five checks before Rd8), the engine does play the mate.

The task brief gives the engine size as 22,182 bytes, but ADAPTATION.md says the stalemate fix brought it to 22,111. My test only checks the size limit, so the figure in the launch notes may be out of date.