Review complete. No tracked file was changed; the findings are in .imd-findings.json and the proof lives under test/scratch/.

Outcome

The hook and token build, the hook's runtime is well under the size limit, and all 142 project tests pass, including the factory-shaped launches in both token orders. The manifest's nine constructor arguments and five permissions match the code, and the route pool id in the notes matches its key. I found one substantiated medium defect, one low design risk, and recorded coverage.

Findings written

• Medium, with proof. The IMD/ETH route pool is hookless, so the hook only samples its price inside a batch attempt, and anyone can trigger one with convert. All three "block start" samples can therefore be produced inside the attacker's own transactions. The scratch test pushes the route price down, calls convert, and restores it, once per block for three blocks, with a narrow IMD band under the pushed price in the third. The hook sells its whole 1 ETH pile at about half the honest rate and the attacker nets roughly 0.45 ETH after fees, while the route's price at the start of every block was honest. The main duel is not affected, since every price change there passes through beforeSwap first. Loss is bounded per block by the batch cap and needs a thin route pool and an ETH-paired duel with volume.
• Low. When hookData is not exactly 20 bytes the bounty owner is tx.origin, so swaps relayed through smart accounts, bundlers or relayers pay the reward to the relayer. The author's own tests assert this default, so it is flagged for the adapter as a design decision.
• Info. Coverage statement: the hook, token, Strength, Rules, the engine interface, the launch files and the key test fixtures were read in full. Bitboard, Chess and ChessEngineV5 were not reached in the budget and are trusted as the already deployed engine's output. The protected OwnerChecks helper is not in the tree.

Checked and found sound

Fees are minted as claims, never taken from the manager's balance during a swap. Chests plus pile plus owed balance the hook's claims on every path. Callbacks refuse non-manager callers. A payout recipient that leaves a delta is refused and left owed. The factory's zero-liquidity fee collect runs no hook callback. No owner, pause, upgrade, delegatecall, selfdestruct or signer exists in either contract.

Fixed both reproduced audit findings while preserving the manifest, constructor arguments, token and compiler settings.

Validation passed: forge build, 171 Foundry tests with the supplied seed, and 5 helper tests.

ETH conversions now require authenticated price-proof publication. Every change and operational detail is documented in ADAPTATION.md.

I found one medium-severity issue in the permissions area (Access Control, Trust Gap, Asymmetry) and no high or critical ones. The findings are in .imd-findings.json, with a coverage row for all 14 entry points plus three invariant rows. I changed no files; the findings file is git-ignored.

Finding 1 (medium): when no reward recipient is passed, the swap router owns the bid, so on the Uniswap Universal Router whoever plays the move can take the bounty (src/IMDuelHook.sol:657)

• If a swap's hookData isn't a 20-byte or clean 32-byte address, _bidOwner makes the swap's sender the bid owner. That is the router contract.
• The bounty isn't paid in the bidder's own transaction. It's paid during the later trade that plays the move.
• On the Universal Router, the hookData is empty by default, and anyone can sweep the router's token balance with its SWEEP command. The trader who plays the move can add a SWEEP after their swap in the same call and take the earlier bidder's capture, check or mate bounty.
• On a router that accepts ETH, anyone can also push owed ETH there with withdraw(router, c) and sweep it. On a router that refuses ETH, the owed reward is stuck, because a router can't call withdrawTo.
• The existing test test_missingOwnerPaysTheSwapSender shows the 0.27-ether bounty landing in the router's balance (I re-ran it and it passes). The sweep step is the Universal Router's own public behaviour; I didn't test it here.
• The fix needs a design decision: either pay bounties only to a recipient named in hookData, or keep a router-owned reward owed and release it only when the owner itself withdraws. An earlier contributor deliberately chose the router fallback over tx.origin and told integrators to pass the recipient. What they didn't address is that, by default, the next trader gets the bounty.

What holds:

• No privileged roles: the hook's only guards are "PoolManager only" and "hook only". There is no owner, admin, pause, upgrade path or signer, and nothing changes its settings after construction. The token has no owner, mint or blocklist.
• Callers and approvals: unlockCallback only ever gets data the hook encoded itself. fundChest pulls tokens only from its own caller, so a token approval given to the hook can't be spent for anyone else.
• First pool: the first pool opened becomes the main duel, and nobody can initialize it before the hook exists. The opening surcharge applies to the main duel only.
• Payouts: the PoolManager-delta check on payouts and the "left owed" fallback keep the hook's balances consistent.
• Route prices: sampleRoute accepts only prices proven against a real block hash, for the configured hookless route. I recomputed the route pool id and it matches the notes.
• Engine: the code deployed on mainnet at 0xc21788… is byte-for-byte the ChessEngineV5 compiled from this tree.
• Manifest: the nine constructor arguments and five permissions in launch.json match the code, in declaration order.

Not covered: I didn't attempt a full math or economics pass (the batch price band, the strength formula, how bounty sizes interact with the opening surcharge), and I didn't re-audit the chess engine.

The manifest is written and verified. Only launch.json changed.

What launch.json now says

• "kind": "univ4_hook" is the first field.
• Hook contract IMDuelHook with its nine constructor arguments in declaration order: $poolManager, the deployed ChessEngineV5 address, the IMD pair address, the hookless ETH route's fee and spacing, the three batch minimums, and turnBlocks. They are identical to the project's own launch/hook.json with its engine placeholder filled in, and the engine address matches launch/deployed.json.
• Permissions are afterInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta, exactly what getHookPermissions returns in the source.
• Token IMDuelToken, name IMDuel, symbol IMDUEL, 18 decimals. I dropped the previous file's token constructorArgs and totalSupply entries, since neither is a schema field and supply is set by the launch policy.
• Pool: pair 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tick spacing 60, initialPrice 79228162514264337593543950336, as the launch facts give them.
• Notes were rewritten to describe the tree as it stands after the accepted audit fixes, at 3,537 characters. They cover the 0.5% hook fee split and burn, the 300-second opening surcharge on the main duel only, the batch pricing against the three latest sampled block-start prices and the once-per-block limit, the proof-based sampleRoute for the ETH route, the engine not being checked at construction, bid ownership from hookData or the swap sender, and payouts refused when the recipient touches the PoolManager's deltas and left owed for withdraw or withdrawTo. They also state there is no owner, admin, pause, upgrade path or signer, so no $owner or $factory argument exists.

Checks run

• forge build succeeds, with only pre-existing lint warnings.
• forge test with the verifier's fuzz seed: 171 tests passed, 0 failed across 23 suites, including the launch-file, admission and factory-shaped launch tests in both token orders.
• A node check confirmed the constructor arguments, permissions and pool block match launch/hook.json and that all addresses are lowercase.

The file is left as an uncommitted change in the working tree, ready for the submission step.

The findings file is valid, every snippet matches its line in the tree, and the coverage record answers all 14 entry points plus six invariant rows.

Outcome. Within the math area (Math Precision, Boundary, Numerical Gap) I found no defect that moves funds to the wrong party or breaks a guarantee. The fee, chest, bounty, conversion-batch and sample-packing arithmetic all trace clean, and the project's money, slice, strength, route, launch, bidding and token suites pass (68 tests).

What I reported in .imd-findings.json:

• Low: hookData of 20 or 32 zero bytes is decoded as an explicit owner of the zero address, which is also the hook's "timeout move, pay nobody" sentinel. The bid is taken and raises the bar for later bidders, but the bounty is silently forfeited. Reproduced in a scratch test.
• Info: the fee rounds to zero under 250 wei on the fee-bearing side, and such a dust trade still becomes the top bid at strength 0. The project's own fixtures rely on this, and the 2x payout cap bounds it.
• Info: the batch price limit's uint160 cast wraps only within 0.1% of the max sqrt price, and then fails closed (no batch) rather than trading at a wrong limit. Unreachable for two 18-decimal tokens.

What holds, with the reasoning recorded per row: the PartialFill check for exact-input and exact-output in both token orders, the opening surcharge bound of 25.4% keeping v4's swap sign valid, the smaller-chest double mulDiv (cannot overflow since chest is below 2^128 and price below 2^128), the 56-bit sample packing and the max/min reference direction for both token orders, the Strength log curve, and the repetition-ring lane parity. The slither "incorrect-exp" and aderyn "shift order" leads are false positives.

Not reached in depth: the Bitboard and ChessEngineV5 internals beyond the hook's decoding of the engine's 224-byte answer, and the Merkle-Patricia proof library beyond confirming it is Optimism's audited code and that the verifier bounds the sampled block to at least two blocks back.

The review is complete and .imd-findings.json holds five findings plus coverage rows for all 14 entry points and three invariants.

What I found (economics area: Economic Security, Invariant, Flow Gap)

• Medium, payOut guard bypass (src/IMDuelHook.sol:398). The Unsettled check only compares the PoolManager's nonzero-delta count. During afterSwap the hook already carries a negative delta from its fee mints, and v4 books the offsetting hook delta only after afterSwap returns. A native-ETH reward recipient can call settleFor{value: 1}(hook) from its receive(), which leaves the count unchanged, so the payout "succeeds", the hook ends at +1 wei, and the swap reverts with CurrencyNotSettled. Every later swap on that duel repeats the resolve and reverts until the move decays to a timeout after about 8,191 blocks. It applies to any ETH-paired duel, not the main IMDUEL/IMD pool. The author's hostile tests cover a recipient opening a new delta, not one altering the hook's existing delta.
• Low, rewards default to the router when hookData is empty, so bounties land in router contracts and are sweepable.
• Low, strength is manipulable in-transaction by an LP pulling liquidity before a tiny trade and re-adding it.
• Low, conversion griefing: one block-end price spike blocks IMD batches for three blocks at the griefer's own fee cost.
• Low, ETH-slice conversion never fires from trades: it needs three route proofs submitted in the same block as the batch, with no keeper incentive.

What held: the 0.5% split and claim accounting net to zero in every path, the claims equal chests plus pile plus owed, the batch price band and once-per-block rule resist profitable manipulation, bounties stay capped at twice the trade's output from the team's own chest, and the token is a plain fixed-supply ERC-20.

Limitations: compiling the test suite is OOM-killed under this sandbox's 1.5 GB memory limit (via-IR, 119 files), so no Foundry proof file could be executed; forge build of src/ alone succeeds. All findings rest on traced source and the v4-core accounting order in lib/v4-core/src/PoolManager.sol. The route proof verifier and the chess engine internals were outside my area and only skimmed.

Review complete. The findings file is written and validated, no tracked file was changed, and the proof test fails on the current code for the stated reason.

Outcome. Two findings, both in src/IMDuelHook.sol, plus seventeen coverage rows with none unreached. The build and all 171 project tests pass as the baseline.

Finding 1, medium, with a Foundry proof. The payout guard in payOut compares the PoolManager's nonzero-delta count before and after sending a reward. While afterSwap runs, the hook already holds a nonzero delta in each currency it minted fee claims in, because the fee credit is accounted only after afterSwap returns. A reward recipient that gets execution during the payout, meaning native ETH or a callback token, can call settleFor on the hook for 1 wei. The hook's delta stays nonzero, the count is unchanged, the payout is accepted, and the swap then dies with CurrencyNotSettled. Every later trade of that duel replays the same move and reverts, in both directions, until the window's block hash expires after about 8,191 blocks. This is the same freeze a previous review closed with the DebtOwner fix, reached through the hook's delta instead of the recipient's. The main IMD/IMDUEL pool is not exposed because both tokens are plain ERC20s with no transfer callbacks, which I checked against the mainnet IMD bytecode. ETH-paired duels, which the design invites, are. The proof is test/scratch/PayoutSettleFor.t.sol: two tests fail now, the plain-recipient control passes.

Finding 2, low. A swap with empty hookData makes the router the bid owner. The bounty is pushed to the router or, for a router without receive, left owed to it with no way to collect. Reproduced in a scratch test showing 0.27 ETH owed to the test router.

Verified as holding. Fee deltas and the PartialFill check in both swap directions and both token orders, the transient stash and reentrancy lock, fundChest and the withdraw paths, the once-per-block batch rule and block-start sampling, the MerkleTrie and RLPReader libraries in full, the manifest's nine constructor arguments and five permissions, and that the engine, the IMD token and the IMD/ETH route pool with fee 10000 all exist on mainnet.

Not reached. The chess engine and bitboard internals, which are outside the control-flow area and already deployed, and economic cost modelling of the documented three-block price-hold manipulation, which the notes accept as a design bound.

Review complete. The findings file is at .imd-findings.json with four findings and a full coverage record, and both proofs fail on the current code.

What I kept, after reproducing each against the code

1. Medium, payOut's delta guard is bypassable. The two medium reports from the economics and flow specialists are one root cause, merged. The guard compares only the nonzero-delta count, and during afterSwap the hook already holds a nonzero delta from the fee claims it minted. A recipient paid in native ETH can call settleFor on the hook for 1 wei inside its receive, the count stays the same, the payout is accepted, and the trade then reverts with CurrencyNotSettled. Every later trade of that duel replays the same move and reverts for about 8,191 blocks. I confirmed it with test/scratch/PayoutSettleFor.t.sol: the plain-recipient control passes, the settleFor recipient fails with CurrencyNotSettled. Kept at medium because the main IMDUEL/IMD duel is not exposed, only ETH-paired and callback-token duels anyone can open on the hook.

2. Medium, bids without hookData belong to the router. Three specialist reports merged into one. Through any router the swap sender is the router, so the bounty is pushed to it or left owed to it. With a router that has no receive the ETH is stuck permanently. With the Universal Router anyone can sweep it. The in-tree BidOwner test already shows the router being paid. My proof test/scratch/RouterOwner.t.sol fails with 0.27 ETH owed to the router.

3. Low, strength depth is manipulable in one unlock. An LP can pull liquidity, swap a dust amount at the 90% cap, and re-add. Bounded by the 2x payout cap.

4. Low, a reversed end-of-block price spike holds the IMD conversion batch shut for three sampled blocks. Griefing only, at ongoing cost to the griefer.

What I dropped

• Zero-address hookData opting out of the bounty: the author documents it as an intentional opt-out, no third party loses.
• Dust-trade fee truncation and the uint160 price-limit wrap: fail-closed, no funds move, unreachable prices.
• ETH-route conversion needing a keeper: a documented limitation, the ETH simply waits as claims.

Coverage. All 14 entry points answered, plus one manifest row. The launch.json arguments match the constructor in order, the permissions match getHookPermissions, and the four project suites I reran pass with the committed seed. Nothing in the Mindset pass surfaced beyond what the specialists had found.

Both reopened findings reproduced on the accepted tree and are fixed; the two advisory lows are answered as disputed with reasons; the build and the full suite pass with the verifier's seed.

Fixed, finding 68f05aa8 (payout guard bypassed by settleFor). Reproduced: a recipient that calls settleFor on the hook for 1 wei during its ETH payout passed the count-only guard and the trade reverted with CurrencyNotSettled, as did every later trade of the duel. In src/IMDuelHook.sol, payOut now takes the pool key and snapshots the hook's own deltas in both pool currencies beside the nonzero-delta count. Any difference after the send reverts Unsettled and the reward stays owed. Four new tests in test/Hostile.t.sol cover a native ETH duel and a callback-token duel, settling in the payout currency and in the slice currency. All four fail when the own-delta check is removed.

Fixed, finding 5edd7f4d (router owns bids without hookData). Reproduced with the reviewer's proof. A trade that names no recipient now bids and plays for nobody: it still bids for its team's move, and its move pays no bounty, as timeout moves already did. The swap sender is no longer used. Updated tests in BidOwner, Game and Launch assert the router is never paid or owed. The invariant suite gets SP-07, which checks every Reward event names a recipient a trade gave. The proof passes on the result.

Disputed, no change, finding b3605770 (LP pulls liquidity inside one unlock). The trace holds, but a block-start liquidity sample is set by the same unlock that pulls the position, and the only robust fix is a liquidity callback, which changes the permission set the task fixes. Impact is bounded by the 2x payout cap. Documented as an accepted limitation.

Disputed, no change, finding 573a4330 (spike delays the IMD batch). The most-favourable-of-three rule is the designed defence against selling the pile into a pushed price. A median would weaken it. The grief delays conversion only, at an ongoing fee cost to the griefer.

Results:

Files changed: src/IMDuelHook.sol, ADAPTATION.md, and seven test files. The responses file at the repository root answers all seven finding ids, including the three imported audit findings from the previous round. launch.json, foundry.toml, the token and the chess sources are untouched.

The committed launch.json already describes the accepted build exactly, so no edit was needed. This revision round listed no findings, and every check I ran against the manifest passed.

What launch.json declares, verified against the source

• "kind": "univ4_hook" is the first field, with hook, token, pool and notes as the only other keys.
• Hook contract is IMDuelHook with nine constructor arguments in declaration order: $poolManager, the deployed ChessEngineV5, IMD as the pair currency, the hookless IMD/ETH route pool's fee and spacing, the three conversion minimums, and turnBlocks. No route-hook, owner, factory or launch-number argument exists because the constructor takes none.
• Permissions are afterInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta, which is exactly what getHookPermissions returns and what the IMDUEL_HOOK_FLAGS constant encodes.
• Token is IMDuelToken, named IMDuel, symbol IMDUEL, 18 decimals, matching src/IMDuelToken.sol.
• Pool is paired with IMD at fee 12500, tick spacing 60, initial price one to one, as the launch facts give them.
• Notes are 3,537 characters, under the 4,000 cap, and cover the fee split, the opening surcharge, the no-owner design, the conversion batching rule, the refused-payout and withdrawTo behavior, and the unchecked engine.

How I checked it

• A shape check confirmed lowercase addresses, no stand-in addresses, numeric fee, spacing and decimals, and a string initialPrice below 2^256.
• A scratch Foundry test deployed IMDuelHook from the manifest's own constructor arguments on a chain where the engine has no code, then compared getHookPermissions, engine, imd, turnBlocks, and the token's name, symbol, decimals and supply against the file. It passed.
• forge build succeeds, and forge test with the verifier's fuzz seed passes all 175 repository tests, including the factory-shaped launches in both token orders.

The working tree is clean. No contract source, constructor argument, compiler setting or configuration file was touched, and the scratch test lives only in test/scratch.

I added one test file and found one defect, which I've reported rather than asserted. forge build succeeds, and forge test passes with the verifier's fuzz seed: 201 tests in 26 suites, none failing or skipped (test/scratch excluded).

New tests: test/PayoutGuard.t.sol (7 tests). They run on a native ETH / IMD duel where the side to move must capture a queen, so the bounty is paid inside the trade that plays the move. They check the rule that a payout is refused if the recipient touches the PoolManager's deltas:

• Not refused: a plain recipient, and one that only reads deltas, are paid during the trade.
• Refused: a recipient that settles 1 wei for the router is refused. The reward stays owed and nothing it did sticks.
• Fuzzed: settling any amount for the hook is refused, and the trade still settles.
• Owed rewards only reach their owner:
  • withdraw fails, and the reward stays owed, while the owner still touches deltas.
  • A stranger's withdrawTo moves nothing.
  • The owner's withdrawTo collects it elsewhere, once.
  • Anyone's withdraw delivers it to the owner once the owner accepts payment.
• After each case, trading continues both ways and the hook's holdings equal its reward pools plus what it owes.

Finding (medium), in .imd-findings.json with a proof test.

• The defect: the payout check in payOut (src/IMDuelHook.sol:397) compares the open-delta count and the hook's own deltas, but not which currency the PoolManager has "synced". A recipient whose receive() only calls manager.sync(IMD) changes no delta, so the hook pays it (Reward … paid: true).
• The effect: that synced currency stays set for the rest of the trade. When the trade pays in ETH, the router's settle{value} then reverts with NonzeroNativeValue, and the whole trade reverts. Every ETH-paying trade of that duel reverts the same way until a trade paying in the other token plays the move. The owner can repeat this for every move its bid wins.
• What it doesn't do: no funds are lost, and trades paying in the token still go through; one test checks that.
• The proof: it is self-contained and fails on the current code for exactly this reason. It passes once the check also compares the synced currency and reserves, which is the fix suggested in the finding. It deploys its own hook subclass by the artifact name Proof_SyncRecipient.t.sol:PositionHook, so the file must keep that name.

.imd-findings.json doesn't appear in git status because the repo's .gitignore excludes it. It is in the repository root, where the task asked for it. The protected suites in .imd/reads need toolchain helpers that aren't in this repo, so they weren't run locally.

The review is written to .imd-findings.json and the working tree is unchanged apart from that file.

Settled from last round

• payOut settleFor bypass (medium): fixed. The guard now snapshots the hook's own deltas in both pool currencies beside the nonzero-delta count. The author's four Hostile tests and the PayoutGuard fuzz test exercise exactly my scenario, and the full suite passes at 201 of 201.
• Router-owned bids (medium): fixed. A trade without a 20-byte or clean 32-byte recipient now bids for nobody and its move pays no bounty. My attached proof passes on the revised code, and the nobody owner flows cleanly through resolve, apply and payout.
• Two disputed lows (liquidity-at-swap-start strength, end-of-block spike delaying conversion): the traces still hold, but the author's reasons not to change them are sound within the fixed permission set. Both are documented in ADAPTATION.md. I kept them as info notes so they no longer hold the launch.

One open finding, medium, with proof

The tester's new finding reproduces: payOut checks the delta count and the hook's own deltas but not the PoolManager's synced currency. A reward recipient whose receive() only calls sync(IMD) is paid, then the ETH-paying trade that played its move reverts with NonzeroNativeValue when the router settles native ETH. Every later ETH-paying trade of that duel reverts the same way until a token-paying trade plays the move. The author's own PayoutGuard test comment acknowledges this case. Only ETH-paired and callback-token duels are exposed, not the main duel, and no funds are lost. The suggested fix is to snapshot the synced currency and reserves in payOut and refuse the payout if either changed.

Coverage: all 14 entry points answered, two marked finding (afterSwap and payOut, both pointing at finding 1), the rest holds, plus rows recording the four settled items and the manifest check.

launch.json is complete and verified. No changes were needed this round: the committed manifest already describes the accepted tree, and no findings were attached to the revision.

What I verified in the working tree:

• Constructor arguments. The hook's constructor takes nine parameters in this order: manager, engine, imd, ethFee, ethSpacing, minImd, minEth, minImduel, turnBlocks. The manifest lists "$poolManager", the ChessEngineV5 address, the IMD address, then 10000, 200, 10 IMD, 0.02 ETH, 1,000,000 IMDUEL and 3, all as strings, addresses lowercase. There is no route-hook argument, matching the hookless IMD / ETH pool. The hook has no owner or factory parameter, so no placeholder for either is written.
• Permissions. getHookPermissions in src/IMDuelHook.sol enables exactly afterInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta, which is what the manifest declares. afterInitialize satisfies the launch's initialize-callback requirement.
• Token and pool. token.contract is IMDuelToken, named IMDuel, symbol IMDUEL, 18 decimals, matching src/IMDuelToken.sol. The pool block is IMD at the given address, fee 12500, tick spacing 60, initial price one to one.
• Schema shape. The first key is "kind": "univ4_hook", only schema keys are present, and notes are one string of 3,537 characters, under the 4,000 cap. The notes cover the fee split, the 300-second opening surcharge, the batched conversion pricing and once-per-block limit, the refused payout and withdrawTo path, and the unchecked engine code.

Checks run:

• The root manifest's hook, pool and permission blocks are byte-identical to launch/hook.json with the engine placeholder filled in. The repository's LaunchFiles test deploys the hook from that file and asserts the permission flags and every argument land correctly. It passes.
• forge build succeeds, and forge test with the verifier's fuzz seed passes all 180 tests across 24 suites, with no failures.
• git status is clean, so no file other than the manifest exists as a change.

I've added tests for the hook's new payout check, and they found one more way past it, which I reported in .imd-findings.json instead of writing a test that accepts it. forge build passes, and forge test with the verifier's seed passes all 210 tests in 27 suites (206 before).

What I changed (only test/PayoutGuard.t.sol, building on my accepted version):

• New test router, PrepaidRouter. It pays for its trade before swapping, either by transferring its token first or by sending ETH up front. It then pays and collects exactly the amounts the swap reports, so anything an outsider changes in its balance with the PoolManager leaves it unbalanced and the trade fails.
• Four new tests:
  • A reward recipient that syncs a token is now refused when the trade pays in ETH. The trade goes through, the reward stays owed, nothing is left synced, trading continues both ways, and withdraw collects the reward later. Before this round's hook change, that trade reverted.
  • A recipient that re-syncs the router's input token after the router has transferred it is refused by the new reserves check. The router gets its output and pays exactly its input.
  • Plain recipients are still paid during the trade through both router styles.
• I removed my old comment saying the ETH-paying sync case was reported as a defect, because the hook now handles it.

Finding (low), at src/IMDuelHook.sol:400 (payOut): a reward recipient can still make some trades fail. Its receive() sends the PoolManager 1 wei of ETH on behalf of a router that is already owed ETH by the PoolManager at that point. That happens with a router that pays before swapping, or a multi-step trade that passes through the payout currency. None of the hook's three checks notice, so the payout goes through. The router is left 1 wei over, and the trade that would play the recipient's move reverts with CurrencyNotSettled, again on every retry.

The damage is limited: no money is lost, and the next trade through an ordinary router plays the move and leaves the reward owed, so the duel isn't stuck. The finding suggests a fix: also compare the trader's balance with the PoolManager in the payout currency.

The finding has no standalone proof file. Reaching a reward needs the forced-capture position, which only the test harness's setPosition can set up, and proof files can't import test files. Instead the finding includes a reproduction that uses my test file's setup: the trade fails with CurrencyNotSettled(), and a follow-up check confirms an ordinary trade then plays the move. A proof is only required for critical or high findings, so this should be acceptable for a low one.

Nothing is committed; the changes are in the working tree.

The review is written to .imd-findings.json and the scratch tests are removed. The working tree is clean apart from the findings file.

Outcome of the round

• My earlier medium (payOut ignored the synced currency) is fixed. The author's dispute of the proof was right: it failed in its own setup because of the artifact name. With the harness etched from its own creation code, as the author described, the proof passes on the revised code, and the new Hostile and PayoutGuard sync tests pass too. Dropped.
• One low finding kept, from the tester. The guard still accepts a recipient that settles 1 wei for an address whose delta is already nonzero. The swap's router has one when it prepaid its input or is mid-route through the payout currency. The trade that plays the move then reverts with CurrencyNotSettled. I reproduced it with the tester's probe on the PayoutGuard fixture. No funds are lost and the next plain trade plays the move with the reward owed, so it stays low. The suggested fix snapshots the swap sender's deltas in the pool's two currencies as well.
• Specialist findings dropped as already fixed. The settleFor(hook) bypass and the router-owned bid both describe the tree before this revision. payOut now compares the hook's own deltas, and a bid without hookData is nobody's. BidOwner and Hostile tests confirm both.
• Other specialist leads dropped. Zero-address hookData now matches the documented "nobody" design. The dust-fee and uint160 notes are not defects. The ETH route needing a keeper is stated in the manifest notes as the intended behaviour.
• Two info rows carried over as accepted limitations: strength read from swap-start liquidity, and the end-of-block price spike delaying IMD batches.

Verification on this tree

Coverage answers all 14 entry points: 12 hold, afterSwap and payOut carry the low finding.