The review is complete. The findings file is written and validated, the working tree is otherwise untouched, and scratch files are removed.

Outcome: no fund-loss, accounting or access-control defect found in the IMDuel hook or token. The report in .imd-findings.json holds two low findings and two info entries.

What I checked

• Read in full: the hook, token, Strength, Rules, Chess, the engine interface, launch.json, the launch policy script, the test fixtures, the launch test for both token orders, and all four protected floor tests. The chess engine and bitboard libraries were read only at their entry points. Instead, I fetched the engine's code on chain 1 and it is byte-identical to this tree's build.
• Build and tests: forge build passes with lint warnings only. All 177 tests pass, including both token orders and the hostile-token and invariant suites.
• Slither 0.11.6 on src reports one reentrancy-no-eth in afterSwap, a false positive since the only external call is to the PoolManager. The arbitrary-send-erc20 detector did not fire on the low-level transferFrom.
• Leads traced and closed: fee deltas for exact-input and exact-output in both directions, hook solvency across pools, mate payout caps, timeout and expired-hash paths, reentrancy through withdraw and fundChest, HookSwap against URC-2's actual declaration (it matches), permission bits, PoolManager-only callbacks, and the absence of owner, pause, mint, proxy or self-destruct paths.

Findings written

• Low, relayer attribution. A smart-wallet trade without hookData credits tx.origin. Reproduced: the bid owner became the pranked relayer address, so a mate payout would be claimable by the bundler. The requester lists this as accepted.
• Low, gas after a window closes. A swap with 1.3× an ordinary swap's gas succeeds in the window and reverts in the first block after it. The hook's own frame runs out of gas, so the wrapped revert carries an empty reason rather than the documented NotEnoughGas. Measured: 343,912 gas in-window, 603,042 to resolve the opening position.
• Info, manifest. launch.json has two keys outside the schema (token.constructorArgs, token.totalSupply). Everything else in the manifest checks out, notes are 3,362 characters.
• Info, coverage. Which contracts were read, which were not, and the commands run.

No critical or high findings, so no proof files were attached.

Fixed the reproduced gas-budget issue and added factory tests covering both token orders. Manifest, constructors, compiler settings and dependencies remain unchanged.

forge build passes. All 184 tests pass with the supplied seed; seven isolated regressions also pass.

Relayed wallets still require hookData for correct attribution. All changes and audit dispositions are documented in ADAPTATION.md.

Updated launch.json, removing unsupported token fields and refining technical notes. Constructor arguments, permissions and pool settings are preserved.

forge build passed with existing warnings. All 184 tests passed using the specified fuzz seed, including both factory token orders.

Only launch.json changed.

The review is complete. The findings file is at .imd-findings.json, the tree is otherwise unchanged, and the scratch tests are removed.

Outcome. The permission model holds. The hook has no owner, admin, pause, upgrade or signer path. All three callbacks and unlockCallback accept only the PoolManager, and the manager only calls back its own unlocker, so every callback payload is hook-authored. I found one low-severity asymmetry and recorded one trust assumption as info. No medium or higher defect, so no proof file was warranted.

Finding 1, low. A 1-wei buy of a silent team's token places a bid for that team at 0% strength, owned by the buyer, and pays no hook fee because both fee terms truncate to zero. The silent team's move is then played by the next trade after the 3-block window. The brief says a silent side plays at 0% only after 600 s. A scratch test reproduced the exact state: bid size 1, strength 0, no change to either pot, and the forced move played 36 seconds after the team got the turn. This may be accepted design since every swap bids for its team, but it makes the 600 s rule bypassable for free.

Finding 2, info. The hook writes the engine's returned board without any legality check, and the constructor does not check the engine has code. I fetched the mainnet runtime code at the committed engine address over a public RPC and it is byte-identical to this tree's ChessEngineV5 build, so the trust assumption holds for this launch.

What I verified and found sound.

• A reward recipient trading inside its own claim's unlock leaves the books exact. A recipient that credits the hook 1 wei, or a hostile side-duel token that re-syncs the manager during fundChest, makes the whole call revert with no chest or claim change.
• Third parties cannot redirect anyone's reward through withdraw or withdrawTo.
• Permissionless side duels only touch their own pots and can only add to the main IMD pot.
• The manifest's constructor arguments, permissions and pool terms match the implementation.

Coverage. All ten listed entry points have rows, plus five invariant and trust rows. Nine entry points hold, afterSwap carries finding 1. Nothing was left unreached. The tx.origin fallback is accepted in the brief and README, so I did not report it again.

The review is complete and the findings file is written. Here is the recap.

Outcome. The hook's money math holds under the Math Precision, Boundary and Numerical Gap passes. I found no defect that loses funds, pays the wrong party or breaks the game. Two informational boundary facts are recorded, each with a verified reproduction.

What I checked and found sound:

• Fee schedule: 0.325% from each leg into that token's pot plus the 0.1% slice on the slice side, taken before the swap on the specified leg and after it on the other. The PartialFill check matches v4's swapDelta semantics for both exact-input and exact-output orders.
• Casts and packing: the int128 fee cast is protected because the PoolManager's mint reverts first for oversized amounts. The game-inflow word (game number, two 112-bit halves) and the transient pending-fee slot (two 128-bit halves) cannot spill or interleave within a swap.
• Mate payout: the three caps (quarter of the loser's pot, twice the bid, the game's inflow into the losing pot) are all in the loser's token, overflow-free, and read before the resolving trade's inflow is written under the new game.
• Strength curve: monotone, capped at 9,000, zero at or below a 0.1% share, no overflow for pool-sized amounts.
• Repetition ring and engine history: lane, slot and parity arithmetic agree with each other.
• Deployed engine: the code at the constructor's engine address on chain 1 is byte-identical to this tree's ChessEngineV5 build.
• Token: plain ERC-20 with bounded unchecked arithmetic.

Findings recorded (both info):

1. Fee floor. A swap whose legs are under 308 wei pays no pot fee, under 1,000 wei no slice, emits no HookSwap, yet still places a full bid, at the 9,000 cap against an empty pot. The scratch test test/scratch/FeeFloor.t.sol demonstrates it.
2. Bid size, strength and the 2x payout cap use the pool's leg amounts, not what the trader paid or received. A 1e18 exact-input buy records a bid size of 996,750,000,000,000,000. Bounded by the 0.75% fee, so no bidding outcome changes.

Coverage. All ten listed entry points have rows, plus six invariant rows. The only unreached area is the internal evaluation arithmetic of the engine and bitboard libraries, which is outside the hook's money math.

Targeted suites (95 tests across the money, pot, strength, bidding, window, team and draw files) pass on this tree. No repository file was changed; the scratch tests live only under test/scratch/.

The control-flow audit found one low-severity defect and nothing critical, high or medium. The results are in .imd-findings.json: that finding plus 18 coverage rows, one for each of the 10 entry points and 8 for invariants I checked. No tracked files changed, and I deleted my scratch tests.

Finding

Low: a dust first bid one block before a window closes can still take a silent team's move (src/IMDuelHook.sol:456).

• Cause: only a first bid in the window's last block or later gets a new full window. A dust buy in the block before that gets no extension.
• Effect: the team has one block to answer. If no real buy lands, the dust bid owns the move at 0% strength. It costs one dust trade's gas (about 190k–200k on the fork), and the 0% move comes about 24 s after the previous one instead of at the 600 s timeout.
• Reproduced: with a 3-block window closing at block C, dust at C-1 kept the close at C and the next trade played it at 0%. The same dust at C moved the close to C+2.
• Not measured: how much repeated 0% moves raise a team's chance of being mated, which is what would cost it pot money.
• Fixing it is a design choice: launch.json states this exact rule and test_onlyALateFirstBidMovesTheWindow pins part of it. A fix means changing both and lets a first bid delay a move by up to 2 blocks, so I didn't include a proof test.

What I checked

• Execution Trace: I traced every entry point through fees, partial fills, move resolution, mate payouts and withdrawals. That included hostile tokens and recipients re-entering mid-call, and starving the engine of gas; none of them broke anything.
• Periphery:
  • Strength, Chess, Rules and the token all hold.
  • Bitboard matches expected move counts (perft) on 7 positions, including castling, en passant and queen-only promotion.
• First Principles:
  • A bid can't be changed once the block hash is known, and low gas can't force the fallback move.
  • The stats never affect play.
  • The game-inflow record stays correct across games.
• Static analysis leads: the ones I traced in the hook are false positives, including teamOf's ^, the "locks Ether" flag and the afterSwap reentrancy flag. I didn't trace the Bitboard and engine lint items individually.

Evidence from running it

• Project tests: forge test passes 184 of 184 with the README's seed.
• Engine: the deployed bytecode at the launch.json address is byte-for-byte identical to this build.
• Mainnet fork: a launch using the real PoolManager, real IMD and the deployed engine ran 240 swaps in each token order, playing 237–239 moves. The hook's claims matched its books, and burn, withdrawTo and factory fee collection all worked.
• HookSwap: the event matches the URC-2 draft's signature and signs, though the draft is still under discussion.

Limits

• Fork block hashes: the fork can't serve hashes for future blocks, so I set them by hand. I called the live EIP-2935 history contract directly, but no fork swap resolved a move through it; the local tests cover that path with a stub.
• Engine gas: the worst case I measured was 2.65M against the 3M cap, on a contrived position, and this wasn't an exhaustive search. Going over the cap only falls back to a legal move at 0%.
• IMD token: I exercised it through normal transfers only and didn't review its owner powers.
• Economics: I only touched bidding and pot strategy where they crossed control flow, such as whether a large low-strength bid is worth making.

Sources:

• URC-2: Custom Accounting Hook Swap Event

I added 57 tests for the IMDuel launch, and the full suite passes with the verifier's seed: forge build succeeds and forge test shows 241 passed, 0 failed, 0 skipped in about 15 s. I changed nothing outside test/ apart from writing .imd-findings.json, and made no commit.

The earlier tests mostly used a test harness with setters at fee 3000. The new ones run the production hook and token, launched in one factory-shaped call with the committed constructor arguments, at fee 12500 and spacing 60, in both token orders.

New files

File	What it covers
test/LaunchFixture.sol	The two launches, plus a scriptable engine at the committed engine address and a stand-in for the EIP-2935 block-hash history contract.
test/LaunchMoney.t.sol	Every wei of the 0.65% and 0.1% fees and HookSwap across all swap shapes, side duels, and with a protocol fee on. Also pots at their limit, the mate's least-of-three payout, and everything that must pay nothing.
test/LaunchFailures.t.sol	Failure paths: caller checks, no privileged functions, refused openings and orders, malformed hookData, and exact edges (110% raise, 600 s timeout, 256 and 8,191 block hashes). Also claims, hostile tokens and recipients, and engine failures.
test/LaunchInvariant.t.sol	Random call sequences with fail-on-revert on: 64×100 per invariant with the scripted engine, 16×120 with the real engine, in both token orders. It keeps its own books from the brief, and a fixed walk confirms every ending and claim path is actually reached.

How strong the tests are

I ran 27 deliberate mutations of the hook in a temporary copy, without the invariant file. Four survived at first; I added tests for those gaps and all 27 now fail the suite.

Findings (.imd-findings.json)

Neither is critical or high, so neither carries a proof file.

• Low – bid size and strength use the raw swap amounts: the brief says what the trade "paid" and "received", but the hook measures before its own fee. A 1e18 IMD exact-input bid records 0.99675e18, so the 2× cap is 1.9935e18 rather than 2e18. This may be intended, and three new tests pin the current behaviour, so they would change if you want the literal reading.
• Info – a malformed engine answer reverts the swap: a 224-byte answer with an out-of-range word reverts instead of falling back, though launch.json says a failing engine never reverts a swap. I reproduced it against the production hook, but the committed engine can't produce such an answer.

No test asserts the malformed-answer case either way.

Limits

• Scripted endings: most mate and draw paths use the scripted engine, which plays legal moves but reports the ending the test asks for. Real-engine runs reach few natural mates; mates on real positions are covered by the older harness tests.
• No fork tests: the task named no fork blocks, so the code at 0xc217…5a27 and the real IMD token are still unchecked on mainnet. Those fork runs are still owed.
• launch.json not pinned by a test: fs_permissions stops tests reading the repo root, so I compared it by hand. It matches launch/hook.json except for the engine placeholder in the constructor arguments and the notes text.