The audit turned up no defect in the contracts. There is one finding, and it is in the tests: forge test does not fully pass. It's recorded in .imd-findings.json. I changed no repository files.

Finding (medium): one test fails.

• Where: test/Launch.t.sol:137, assertGt(st().ply, 20); in test_launchPairedWithEth.
• Result: a full forge test (forge 1.8.3) gives 151 passed and 1 failed, with assertion failed: 8 <= 20.
• Cause: in this run, White checkmates at ply 23 (GameOver(gameNo 0, result 1, plies 23)). The hook then starts game 1 and resets ply to 0, so by the assertion the pool is at game 1, ply 8. The test reads the current game's move counter as if it counted moves across all games.
• Fix: change the test, not the contracts — count Moved events, or assert gameNo > 0 || ply > 20. The two IMD-paired launch tests use the same check and pass only because their games don't end that early.

What I checked and found sound:

• Engine: the code at 0xc21788f7…5a27 on mainnet is byte-for-byte the local ChessEngineV5 runtime (23,339 bytes), fetched from a public RPC.
• Accounting: the hook's claims always equal chests plus the conversion pile plus rewards owed, on every path that changes them. The fees taken before and after the swap net to zero against the pool, and the partial-fill check matches how v4 adjusts the swap amount.
• Callbacks and calls: every hook callback accepts only the PoolManager. unlockCallback only runs from the hook's own unlock. convertBatch can only be called by the hook itself.
• Reentrancy: withdraw, fundChest and convert can't run while another trade has the PoolManager unlocked. Nothing is sent to a reward owner during a trade; the only transfer inside a trade is the burn to 0x…dEaD, which runs no code.
• Conversion: batches are capped, run at most once per block, and buy only near the best of three block-start prices. That price can't be moved without passing through the hook, so a price pushed within one block can't overcharge the hook.
• Gas: a trade sent with too little gas for the engine reverts rather than playing a weaker move. A trade sent at the wallet's gas estimate still converts a due batch (the repo's own tests cover both).
• Launch rules: no owner, admin, pause, upgrade path or signer, and no minting after launch. Scanning reachable bytecode found no DELEGATECALL, CALLCODE or SELFDESTRUCT in the hook (17,403 bytes), the token or the engine.
• Manifest: getHookPermissions() matches launch.json exactly. The six constructor arguments are in declaration order, fee 12500 is accepted, and notes are 3,382 characters (under 4,000).
• Token: a plain fixed-supply ERC-20 (1,000,000,000 IMDUEL, 18 decimals) minted entirely to its deployer.
• Tests: the launch tests in both token orders and the blank-chain admission tests pass.

Coverage:

• Read in full: IMDuelHook.sol, IMDuelToken.sol, Strength.sol, IChessEngine.sol, Rules.sol, Chess.sol, launch.json and the other launch files, the four protected tests, and the relevant repo tests.
• Not read line by line: ChessEngineV5.sol and Bitboard.sol, the chess logic. I checked only that the engine doesn't depend on gas, sender or block values and that it matches what's deployed. Whether every move it plays is legal is left to the repo's chess tests.
• Not run: Slither, which I couldn't install here. The protected floor tests, which need verifier files that aren't in this repo; I ran their bytecode and permission checks myself instead.
• No helpers: I made the twelve specialty passes from the Pashov guide myself.

Two small manifest points, not filed as findings:

• The notes still say the engine address "is replaced… before this launch is opened", but the real address is already in the arguments.
• token.constructorArgs and token.totalSupply aren't schema keys, so they're dropped.

Fixed the reproduced test failure by counting moves across game resets. Added the exact SVG logo and documented all changes in ADAPTATION.md.

Contracts, launch.json, compiler settings, and dependencies remain unchanged.

Validation: forge build succeeded; all 152 tests passed with the supplied fuzz seed, including both token orders and blank-chain admission.

Updated launch.json only: removed unsupported token fields, corrected the engine notes, and preserved all constructor arguments, permissions, and pool values. Notes are within the 4,000-character limit.

forge build passed. All 152 tests passed with the required fuzz seed, including both token orders and blank-chain admission.

I added 8 tests in test/Edges.t.sol. The full suite passes with the verifier's seed: 160 tests in 24 suites, none failing or skipped. I found no serious defect, and I reported two minor ones in .imd-findings.json instead of writing tests that pass on them. I changed no contract source, configuration or launch file.

New tests (they cover gaps in the existing suite):

• Who earns a bid (OwnerShapesTest):
  • A 20-byte address or a 32-byte encoded address in hookData gets the bid.
  • Otherwise the wallet that signed the transaction gets it, not the router. That covers empty hookData, a zero address in either form, a 32-byte value too wide to be an address, and lengths of 19, 21 and 64 bytes.
  • A fuzz test checks the rule exactly as the brief states it, over random addresses, values and byte strings.
  • A bid that is only 5% higher doesn't take the move from the current top bidder.
• Conversion batches (BatchCapTest):
  • A pile just over the cap converts exactly 10 minimums in one batch and leaves the rest waiting.
  • A pile under one minimum isn't converted by trades, but anyone can still convert it by calling convert().
  • Nothing converts before three blocks have been sampled.
  • The hook's IMD holdings still equal what it owes afterwards.
• previewMove (PreviewEdgesTest, three-block windows): it reports nothing before the window's last block, or when nobody has bid, and is ready only in that last block.

Reported in .imd-findings.json (both minor, each reproduced with a test I ran and saw fail):

1. A batch can spend up to 9 wei more than its cap (src/IMDuelHook.sol:451). Because of integer division, a pile between 10 minimums and 10 minimums + 9 wei is converted whole. With a pile of 10e15 + 9 the batch spent 10000000000000009 against a 10e15 cap. The amount is negligible, but the code doesn't hold its stated limit. The finding includes a one-line fix.
2. A minimum of 0 stops conversion for good. The constructor accepts 0, and then every batch spends nothing: a 1e18 pile stayed exactly 1e18 after convert(). This launch isn't affected because launch.json sets 10 IMD and 1,000,000 IMDUEL. It would matter only if the hook were reused with a zero minimum.

The existing suite already had invariant tests over random call sequences for the hook's holdings and the token's fixed supply, so I didn't add more. I haven't committed anything; the new file and the findings file are in the working tree.

The review is complete. The findings file is written with an empty findings list and a full coverage record, and the working tree is clean apart from it.

Outcome: no reproducible math defect in the assigned area. I checked src/IMDuelHook.sol, src/Strength.sol and src/IMDuelToken.sol against the Math Precision, Boundary and Numerical Gap checklists, confirmed the build and all 152 existing tests pass, and ran my own scratch probes against the live contracts before deleting them.

What I verified, with concrete inputs:

• Fee arithmetic. The chest share is amount * bps / 10000 with bps falling from 2540 to 40 over 300 seconds. It rounds down, so swaps under 25 wei pay no chest share and under 1000 wei no slice, which is a gas-bounded dust case, not a leak. An exact-output buy of 100 tokens at age 1 second delivered exactly 100 and credited 25.31 to the chest.
• PartialFill guard. v4 passes the raw pool delta into afterSwap before subtracting the hook delta, so the equality against amountSpecified + taken is exact in both swap directions and both order types.
• Conversion batches. Sample packing round-trips every sqrt price from MIN to MAX within a relative error of 2^-47 and fits 56 bits. The batch cap spends at most 10 minimums plus 9 wei at one boundary. Spent never exceeds the pile, so the subtraction cannot underflow.
• Strength curve. Fuzzed monotone in the payment and capped at 9000. Measured points are 0 at a 1e-5 share, 3065 at 1e-4, 6010 at 1e-3, 8998 at 1e-2, within the documented tolerance of the linear log fraction.
• Casts and packing. The int128 fee cast is guarded by the manager's SafeCast on mint. Bid size and cap fit uint128 because pool deltas are int128. The transient stash fields do not overlap.
• Token. Unchecked balance addition is bounded by the fixed supply, and self-transfers resolve correctly.

One boundary I traced but did not report as a defect: the uint160 cast of the batch price limit truncates only when the main duel's sqrt price sits in the top 0.1% of the range, and the truncated limit then simply skips the batch with nothing lost. It is recorded as a note in the coverage record.

Coverage has one row for each of the 12 listed entry points, all holds, plus three invariant rows. Nothing in my area was left unreached.

Both scratch checks pass: the hookData owner parsing behaves exactly as documented, and the zero-destination ETH burn in withdrawTo is confirmed. The findings file is written and its snippet matches the tree.

Outcome. The permission model of IMDuelHook and IMDuelToken holds. I found no access-control bypass, trust gap or asymmetry that loses funds or breaks a guarantee. One info-level finding is recorded in .imd-findings.json, with a coverage row for all 12 entry points plus four invariant and trust-assumption rows.

What I checked, by guide

• Access Control. Every callback refuses callers other than the PoolManager. The main-duel binding in afterInitialize is one-shot and cannot be front-run, since a pool naming the hook before it has code fails the manager's return-data check and the factory deploys and initializes in one transaction. unlockCallback is only ever reached by the hook's own unlock, convertBatch only by the hook itself, and fundChest pulls only from msg.sender. No setter, owner, delegatecall or selfdestruct exists, and launch.json's constructor arguments and permissions match the source and the deployed engine record.
• Trust Gap. Permissionless convert cannot make the hook buy outside its 0.1% band or more than one batch per block. Permissionless withdraw only delivers to the owed party. A hostile recipient or token acting inside the hook's own unlock either hits AlreadyUnlocked or leaves a nonzero delta that reverts the whole claim. Rewards are never sent inside a trade, so no code runs while a trader's manager is unlocked.
• Asymmetry. Exact-input and exact-output fee paths, the ETH and ERC-20 branches of fundChest, withdraw versus withdrawTo, and the before/after fee split were diffed. The one asymmetry with an effect is the finding below.

Finding (info). withdrawTo passes its destination unchecked. For a native-ETH reward in an ETH-paired duel, which anyone may open on this hook, a zero destination burns the reward, while the same call on an ERC-20 reward reverts. Only the owed party can trigger it. The reproduction is in the finding and verified by a scratch test.

Verification. The full suite passes with the project's fuzz seed, 152 of 152. Nothing in src, launch.json or configuration was changed. The scratch tests live under test/scratch/ and are not part of the submission.

Not reached. Economics of the batch price band, engine gas pathologies and chess-rule correctness are outside this area and were not audited beyond what the permission paths touch.

The review is complete and the findings file is written. The working tree holds only the ignored findings file, so nothing in the repository changed.

Outcome. No reproducible defect in the control-flow area. The file .imd-findings.json holds one informational note and 17 coverage rows, one for each of the 12 listed entry points plus five rows for invariants, periphery helpers, the manifest and the unreached engine code.

What I checked, by guide.

• Execution Trace. The fee is minted as ERC-6909 claims on the specified side in beforeSwap and on the unspecified side in afterSwap, and each mint nets to zero against the hook delta the PoolManager accounts. The PartialFill check holds for both exact-input and exact-output orders. The transient stash cannot be clobbered between the two callbacks because the hook's own conversion swap runs without callbacks and the engine is called by staticcall. The unlock callback can only ever receive the hook's own encoding, since the PoolManager calls back only the unlock caller.
• Periphery. The sqrt-price packer keeps the mantissa under 48 bits and the exponent under 256 for any uint160. The samples word's five fields do not overlap. The assembly masks are 160 and 128 bits wide. The hookData owner parser accepts only 20 or 32 bytes. Block-hash lookups fall back to zero and become timeout moves. Engine replies are length-checked before decoding.
• First Principles. Chest, pile and owed balances move in lockstep with claim mints and burns, so held always equals owed. Stale bids carrying into the next game, timeout moves, late bids and the no-hash path all resolve to consistent state. A hostile token can only act inside the hook's own unlock, where a nested unlock reverts and a direct swap must settle itself.

The one note. The notes say nothing is ever sent inside a trade. That is exact for rewards, but the slice batch burns $IMDUEL to the dead address with a real transfer inside the trader's unlock. The goal still holds because the launch token has no callbacks and the call is wrapped in try/catch, so I filed it as informational with a concrete trigger.

Verification. The project builds with forge build. All 131 tests across 22 suites pass, including both launch token orders and the blank-chain admission tests. The manifest's six constructor arguments, permissions, fee tier, tick spacing and notes length match the implementation.

Not reached. The engine and bitboard move generation were outside my area and are marked unreached; only the hook's handling of their return values was traced.

The economics review is complete and .imd-findings.json is written with one substantiated finding and 18 coverage rows.

Finding (medium, with a failing Foundry proof): a bid's strength is computed from the pool's spot in-range liquidity read in beforeSwap, and the hook has no liquidity callbacks. Anyone can add liquidity in the transaction before an opponent's trade and remove it in the next transaction of the same block, at zero cost (the bracketer even keeps that swap's LP fee). In the reproduction, Alice's 1% trade bids at 8987 bps, Bob's larger trade bracketed by 1000x liquidity bids at 271 bps, and the attacker's own trade afterwards bids at 9000 bps. Strength.sol documents the opposite guarantee. No funds are taken directly; the effect is on which team's bidders capture pieces and mates from the chests. The proof in test/scratch/JitStrength.t.sol fails on the current code with "271 < 8000".

What held after tracing:

• Fee and claim accounting sums to zero on every path, and the hook's claims always equal chests plus pile plus owed rewards. Full project suite with the documented seed: 152 passed, 0 failed.
• The PartialFill check matches v4's delta semantics in both swap directions. The only token ever sent inside a trade is IMDUEL to the dead address, backed by pool reserves.
• The ChessEngineV5 dependency has code on Ethereum mainnet identical to the local build.
• The conversion band resisted a multi-block push: holding a pushed price through three sampled blocks and converting for 12 blocks lost the attacker 4.8 to 20.9 IMD and drained under 18 IMD of a 101 IMD pile, so that stays coverage rather than a finding.
• The manifest's six constructor arguments, permissions, fee tier and notes length agree with the implementation.

Everything in the assigned area was reached. The scratch tests and generator script live under test/scratch/, which is not kept.

Review complete. The findings file is written at .imd-findings.json and no tracked file was changed.

Outcome. All five specialist findings reproduce against the code. None were duplicates of each other, so none were merged. My own pass with the auditor references found nothing further: the delta accounting, fee paths, PartialFill guard, bid and resolve logic, gas-starvation guard, withdrawal ordering, manifest, sizes and logo all hold, and the full suite passes with 160 of 160 tests.

Findings kept, in severity order:

• Medium, JIT liquidity collapses an opponent's bid strength (src/IMDuelHook.sol:269). Strength comes from spot in-range liquidity and the hook has no liquidity callbacks, so a bracketing add and remove in the same block forces a rival's move to about 3% while costing only gas. The economics specialist's proof fails on this tree exactly as stated, Bob at 271 bps against Alice at 8,987, and is attached to the finding.
• Low, withdrawTo accepts the zero address (src/IMDuelHook.sol:366). A native-ETH reward sent there is burned while the ERC-20 path reverts. Only the owed party can trigger it, so it is a footgun rather than an attack. Raised from the specialist's info to low because funds are lost.
• Info, batch cap slips by up to 9 wei (line 451), info, zero minimums disable IMD conversion (line 196, not this launch's arguments), and info, the burn transfer does run inside a trade (line 445), so the "nothing is ever sent inside a trade" statement is exact only for rewards.

Coverage. All twelve entry points are answered: eight hold, four carry findings. Extra rows record the solvency invariant, the manifest, size limits and the logo as holding. The one unreached row is the verifier's Slither pass, which I could not run because this machine has no pip. That is the one check left for the verifier's own run.

All findings were reproduced and answered. The revision is complete and verified.

Main finding (medium, fixed). The reviewer's proof failed on the starting tree with Bob's bid at 271 bps. The hook read the pool's live liquidity at the moment of each trade, so a same-block add-and-remove bracket shrank an opponent's share for free. The hook now samples each pool's in-range liquidity at the start of every traded block and measures a bid against the smallest of the three latest samples. A bracket has to be held through the start of three traded blocks to count, and then it weakens every bid including the bracketer's own. Permissions in launch.json stay exactly as committed, so no liquidity callbacks were added. The proof now passes with Bob near the cap like Alice and the attacker.

Advisory findings, all judged real and fixed.

• withdrawTo refuses the zero address, so a native-ETH reward can no longer be burned.
• A conversion batch now spends exactly ten minimums at most, with the never-minimum still safe from overflow.
• The constructor rejects a zero minimum. The launch's own arguments are nonzero and unaffected.
• The "nothing is ever sent inside a trade" note now says no reward is sent, and names the burn as the one transfer. Code unchanged there.

Tests. New suite test/JitStrength.t.sol covers the bracket, a one-block hold, a three-block hold that does count, a pool's first block, and per-pool samples. Money, Game and Size tests gained the other cases. The size test had encoded a stale argument shape with zero minimums and now uses the launch's six arguments.

Results with the verifier's fuzz seed:

Check	Result
forge build	passes
forge test	160 passed, 0 failed
Reviewer's proof (copied to test/scratch)	passes
Hook runtime size	17,628 bytes, under the 23,500 budget

launch.json, foundry.toml, the token, and every dependency are byte-for-byte unchanged. ADAPTATION.md records each change and the finding it answers, and .imd-responses.json answers all six finding ids, including the first-round Launch test fix, which was re-verified.

The protected suites from the reads do not compile standalone here. They import verifier-side scaffolding such as src/HookFlags.sol, mocks/ and floor/ that this repository does not carry, so the verifier supplies those when it runs them. That matches earlier rounds and is unrelated to the manifest. The scratch folder is removed and the working tree shows only launch.json modified.

Outcome: launch.json is updated and verified. Only its notes changed. The build passes and the full suite passes with the verifier's fuzz seed.

Check	Result
forge build	passed
forge test with the verifier seed	159 passed, 0 failed, 22 suites
notes length	3971 of 4000 characters
files changed	launch.json only

What was already correct and left alone. The committed manifest's first field is the univ4_hook discriminator. The hook contract is IMDuelHook with six constructor arguments in declaration order: the pool manager placeholder, the deployed ChessEngineV5, IMD, 10 IMD, 1,000,000 IMDUEL and 3 turn blocks. The permissions list matches what getHookPermissions returns: afterInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta. The token is IMDuelToken, IMDuel / IMDUEL, 18 decimals. The pool pairs IMD at fee 12500, tick spacing 60, with the one-to-one initial price from the launch facts.

What the notes now say that they did not before. The later revision of the hook, accepted after my previous manifest commit, left the notes stale in four places, and its change record asked the manifest step to fix the first:

• The claim that nothing is ever sent inside a trade is corrected to no reward is ever sent inside a trade. The one transfer a trade can make is the slice batch's burn of IMDUEL to the dead address, a plain token with no callbacks, inside a try/catch that cannot revert the trade.
• Bid strength is measured against the smallest in-range liquidity at the start of the pool's three latest traded blocks, so a just-in-time liquidity bracket cannot collapse an opponent's bid.
• withdrawTo refuses the zero address.
• The constructor rejects a zero engine, a zero minimum, or turn blocks outside 1 to 1000.

The change is uncommitted in the working tree, as in earlier rounds where the worker pipeline made the commit.

I found a new medium-severity defect in the hook's revised bid-depth sampling and reported it in .imd-findings.json. I also added 8 tests to test/Edges.t.sol. With the verifier's seed, the full suite passes: 172 passed, 0 failed (the scratch proof is excluded, as it is on the verifier).

Finding (medium): the fix for the earlier liquidity-bracket finding can still be beaten at no cost (src/IMDuelHook.sol:516, _sampleDepth)

• What's wrong: the hook records a pool's liquidity once per block, at that block's first swap, and treats that as the block's starting liquidity. The hook has no liquidity callbacks, so it never sees liquidity added earlier in the same block.
• The attack: an attacker opens three blocks with "add 1e27 liquidity, swap 100 wei, remove it". All three samples then read 1e27, though the pool never held it at any public moment. A victim trading later in the third block is scored against that inflated depth, without being sandwiched. The attacker only has to trade first in those blocks, which is easy on a quiet pool, and pays gas plus a fee on 100 wei.
• Effect: the code comment says liquidity must be held through two public blocks to count. That is false here.
• Proof: a self-contained test using the real hook in its launch shape. A control trade with a 1% share gets strength ≥ 8,000. After the attack, the same trade gets 0, and the test fails with "0 < 8000". Its source is in the finding's proof field. Since the hook can't see liquidity changes without new permissions, a fix needs a different sampling rule, or the comment should describe the limitation instead of claiming the property.

New tests, all passing:

• Batch size: a fuzz test (1,000 runs) of the batch limit over every pile and minimum. A batch never spends more than the pile or more than ten minimums, spends exactly ten minimums once the pile holds them, and never overflows. Plus exact checks at the largest values.
• Depth sampling:
  • Liquidity removed after a block's first swap doesn't strengthen later bids in that block.
  • Liquidity removed before a block's first swap counts at once.
  • Blocks with no trade take no sample.

The rest of the earlier Edges.t.sol is unchanged and still passes against the revised hook. I modified only test/Edges.t.sol and wrote .imd-findings.json. I committed nothing.

The review is written to .imd-findings.json. One medium finding is kept, carried from last round's JIT issue; the other four prior findings are confirmed fixed.

Settled from last round

• 9537d3ff (JIT bracket, medium): partially fixed. Both attached proofs now pass, and the author's new test file covers the reported same-block bracket. But the root cause survives in a different shape, below.
• c1752b40 (withdrawTo zero address): fixed. Line 392 reverts before the owed balance is touched. The author's test passes.
• 8c23f3ef (batch bound off by 9 wei): fixed. The bound is now exactly ten minimums, with the overflow-safe check kept first.
• 68825ec7 (zero minimum accepted): fixed. The constructor rejects either zero minimum. The launch's arguments are unaffected.
• 64cb1176 (burn inside a trade, docs): fixed. The contract notes now name the burn as the one transfer a trade makes.

Kept this round (medium, with proof)

The sampled depth in _sampleDepth is written by a block's first swap, but the hook has no liquidity callbacks, so an add in the same transaction before that swap is already inside the sample. Three one-transaction brackets of add, dust swap, remove across three traded blocks make all three samples inflated while the pool holds that liquidity at no block boundary. A victim trading later in the third block is measured against it and plays at strength 0; the attacker's next-block trade samples honest liquidity and plays at the cap. Cost is gas plus fees on 300 wei. The tester's proof fails on this tree with the stated message and is attached. The suggested fix is to enable afterAddLiquidity and record a block's start liquidity as the pre-add liquidity, with launch.json's permissions updated in step, or to document the limitation instead of the guarantee.

Other checks

• Full suite: 172 passed, 0 failed.
• All 12 entry points answered in the coverage record, plus two invariant rows. Only beforeSwap and afterSwap reference the finding.
• Static analysis leads (XOR in teamOf, strict equalities, reentrancy, uninitialized locals) were read and are not defects.
• The scratch copies of the proofs were removed, so no tracked file changed.

The responses file is excluded by the harness's own .git/info/exclude, so it is expected there in the working tree. The work is complete.

Finding 87c3e492 reproduced and is fixed. The reviewer's proof failed on the starting tree exactly as reported, with the victim's move at strength 0, and passes now.

Cause. The hook observed liquidity only at swaps, so one transaction of add, dust swap, remove at the start of three blocks made every sample the added liquidity. No swap-driven sampling rule can exclude liquidity that exists only inside a transaction.

Fix in src/IMDuelHook.sol. The hook now enables beforeAddLiquidity. The callback requires the PoolManager as caller, reads the pool's liquidity before the add and, if nothing has sampled the block yet, records it as the block's start liquidity. It never refuses an add and returns only its selector. A same-block add can therefore never raise a block's sample. I chose beforeAddLiquidity over the suggested afterAddLiquidity because it gives the pre-add liquidity exactly, with no in-range arithmetic. There is still no remove callback, so the factory's zero-liquidity fee collection is untouched, and an empty pool's add is not sampled, so the factory's seed-and-trade block still works from its first trade. The stale comment claiming the first swap sees the block's start liquidity was rewritten.

Manifest. The permission set grew by one, so launch.json and the two files under launch/ list beforeAddLiquidity and the notes sentence that said liquidity callbacks were unused was replaced. The launch cannot run without this: the address is mined from the manifest's permissions and the constructor rejects a mismatch. Nothing else in the manifest changed.

Tests. New in test/JitStrength.t.sol: the three-bracket attack with the victim and the attacker's own next-block trade both at the control's strength, a block opened by an add recording the pre-add liquidity, a remove before the first sample only lowering it, and the callback refusing an outsider. The admission, Game and LaunchFiles suites were extended for the new callback. A standalone copy of the bracket test fails without the source fix and passes with it.

Check	Result
forge build	passes
forge test with the verifier's fuzz seed	163 project tests pass, plus the proof copy
Hook runtime size	17,884 bytes, budget 23,500

Imported audit finding 57614ed6 no longer reproduces: it was fixed last round and the launch tests pass on both trees. Both findings are answered in .imd-responses.json, and ADAPTATION.md records every change and the rule or finding behind it.

I found a remaining defect in the hook's new depth sampling and reported it in .imd-findings.json. I also added three tests for the new beforeAddLiquidity callback. forge build passes, and forge test with the verifier's seed passes all 179 tests in 28 suites.

Context. Since my last round, the hook gained a beforeAddLiquidity callback. It records the pool's in-range liquidity before an add, so liquidity added inside a block can't set that block's "depth" (the liquidity a bid's strength is measured against). The existing 176 tests already passed against this change.

Finding (medium): src/IMDuelHook.sol:297. The callback records nothing when in-range liquidity is zero (if (liquidity != 0)), and zero samples are skipped when the depth is taken. If the price sits outside every liquidity position's range at the start of a block, two attacks work:

• Bracket still works. One transaction of [add 1e27, 100-wei swap, remove 1e27] at the start of three such blocks makes the depth 1e27, even though the pool never held that at a block boundary. A victim's 1% trade then plays at strength 42 instead of 8987. This is the same attack the last fix was meant to stop.
• No bracket needed. Parking the price out of range at the start of three blocks makes all three samples zero, so the depth is zero. The victim plays at strength 0 instead of 8987.

The launch pool is seeded across the full price range, so the main duel is only exposed if someone pushes the price past that position. Any duel with liquidity in a narrower range is exposed directly.

The proof is the file test/scratch/EmptyRangeBracket.t.sol; its source is embedded in the finding. Both of its tests fail on the current code. To check it can be fixed, I tried a fix on a temporary copy of the source and then restored it (git status shows only my test file changed). With that fix, both proof tests pass, and so does every test in test/JitStrength.t.sol. The fix:

• When in-range liquidity is zero and the pool already has a sample, mark the block as sampled but keep the earlier depths.
• Call _recordDepth from beforeAddLiquidity every time. An empty pool with no samples is left alone, so the launch's first block works as before.

New tests, in test/Edges.t.sol as AddCallbackEdgesTest:

• Fee collection: the launch factory collects fees with a zero-liquidity change, which v4 treats as a removal. The test checks it pays the LP fees, moves no liquidity, and doesn't change the depth.
• Adds are never refused (fuzzed, 256 runs): any tick range, in range or not, sizes up to 1e30, before or after the block's first swap.
• Adds into empty ranges: adds into an empty or out-of-range pool, and twice in one block, are accepted.

The fuzz test only adds liquidity and doesn't remove it again. When removing a tiny position returns zero tokens, an assert in v4's test router fails. That is a quirk of the router, not the hook.

The findings file is written and verified against the tree. Recap of this round:

My earlier finding 87c3e492 is fixed. Both attached proofs pass on the revised code, the new beforeAddLiquidity callback records the pre-add liquidity as claimed, and the whole project suite passes (179 tests).

What I kept, in .imd-findings.json:

1. Medium. The fix covers only blocks that start with liquidity in range. When in-range liquidity is zero at a block's start, the add callback skips the record (the if (liquidity != 0) guard at src/IMDuelHook.sol:297) and the depth minimum skips zero samples. I reproduced both consequences in a self-contained proof: the one-transaction bracket again inflates the depth (victim at strength 116 against a control of 8,987), and simply parking the price outside the range at three block starts zeroes it (victim at 0). This is reachable in any concentrated-only duel, and in the factory's main duel too, since the single-sided seed has the opening tick as its boundary. This merges the tester's finding 7bbfb875.

2. Low. In the token-above-IMD address order, the factory's seed is out of range at the opening tick, so the block of the very first buy samples depth 0 and every bid in it plays at 0%. A 2.5% share bids at 0 in that block and at the cap one block later. Deterministic, one block, no attacker, so low. A proof is attached.

3. Info. The launch.json notes still claim nothing is ever sent inside a trade, while the contract notes now correctly qualify the in-trade burn to 0x…dEaD. Documentation only.

Dropped: audit_permissions' zero-address withdrawTo note is already fixed at line 418 of the hook. audit_economics' JIT finding is the original defect, now fixed, and its proof passes. Slither and aderyn leads did not reproduce as defects: the caret in teamOf is an intentional XOR, the strict equalities are block-number stamps, and the reentrancy sites are gated by the transient lock and try/catch.

Coverage: all 13 entry points answered, 11 holding and 2 carrying finding 1, plus two invariant rows. Scratch files under test/scratch/ are mine and are not part of the submission.