launch.json is written and validated. Only that file changed among tracked files, and test/scratch holds the throwaway checks.

What the manifest says. The schema fields were already correct from earlier work, so the structural part is unchanged:

• kind is univ4_hook as the first field.
• Hook is DroneHook with constructor arguments in declaration order: $poolManager, the IMD address, $token.
• Permissions are beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta. A scratch test deployed the real hook at a mined address and confirmed getHookPermissions returns exactly those five and the address carries mask 0x20cc.
• Token is DroneToken, name imdDRONE, symbol DRONE, 18 decimals, confirmed against the compiled contract.
• Pool is paired with 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 at LP fee 12500, tick spacing 60, initial sqrtPriceX96 of 2^96, which the hook's beforeInitialize accepts.

What I changed. I rewrote the notes field. The previous notes instructed the deployer to set poolBps and remainderTo, which are launch-policy inputs the manifest cannot set. The new notes are a pure technical description: immutability and no-admin properties, constructor order, the fee curve and constants, IMD-only fee collection through return deltas with ERC-6909 claims, the fixed keeper and permissionless sweep, the four views, the token's properties, the 1:1 price assumption, the one documented input limit from the security review, and pointers to the test and fork evidence. Notes run 2974 characters, under the 4000 cap.

Verification. The build succeeds and the full suite passes with 48 tests and the offline mainnet suite skipped as designed. A scratch schema checker, the repository's own manifest checker, and the scratch Foundry cross-check all pass.

The review is complete. .imd-findings.json is written in the repository root with two findings and a 12-row coverage record. No tracked file was changed.

Outcome: no access-control, trust-gap, or asymmetry defect of medium or higher severity. The permission model is as small as the brief demands and every path I traced behaves as specified.

What I verified in my area:

• Access control. All four callbacks are gated to the PoolManager, and the manager can only reach beforeSwap and afterSwap for the single pool that beforeInitialize accepts. The unlock callback additionally requires the hook's own sweep flag. Nobody but the hook can burn or transfer its ERC-6909 fee claims, confirmed with a scratch test. Sweep pays only the constant keeper, which matches the brief's address byte for byte, and the caller receives nothing. No owner, setter, proxy, or DELEGATECALL exists in hook, token, or helper.
• Asymmetry. Buy and sell formulas mirror each other across beforeSwap and afterSwap, both currency orderings pay in IMD only, and the rate is identical in both directions at every second of the curve, including the 3599 and 3600 second boundary.
• Trust gap. The hook never transfers IMD during a swap, so a fresh manager holding no IMD cannot block trades. The mainnet IMD token is a LayerZero OFT with an owner but no pause or blocklist selectors and no proxy slot, so sweep cannot be frozen by it.
• Evidence run. Existing suite 48/48, fuzz tests at 1500 runs, the protected hook and token floor tests against the real creation bytecode 10/10, the manifest and bytecode checkers, and the mainnet fork rehearsal against the real PoolManager and real IMD at block 26140906 (the pinned block's state is no longer served by the public RPC).

Findings recorded, both already disclosed by the author:

1. Low. An exact-output IMD request within the fee of int256.max partially fills unhooked but reverts hooked, because the manager's checked add of the hook's specified delta overflows. Concrete input and the repo's own regression test are cited.
2. Info. beforeInitialize cannot restrict the initializer or the starting price, so the opening price and 60-minute clock are under launch control only on the atomic factory path. A scratch test shows the reachable state when the optional helper is used non-atomically.

Not reached: nothing in the assigned entry points. The remaining IMD trust assumption, the owner's cross-chain mint authority, is outside this launch and is noted in the coverage record rather than as a finding.

The review is complete. The findings file is written and validated, the scratch probes are removed, and the only working-tree change is .imd-findings.json.

Result: no medium or higher defect in the math. The hook's fee arithmetic holds under every state I could reach. Two informational notes are recorded, both already acknowledged by the author.

What I verified

• Fee identity. All four swap modes charge exactly floor(gross IMD × rate / 10000). I proved the gross-up lemma the exact-output and unspecified-input paths rely on: if F = floor(P·r/(D−r)) then floor((P+F)·r/D) = F, so the fee is never one wei high or low.
• Quote versus execution. The read-only fill quote cannot diverge from the real swap. For exact-input, the pool's budget after the fee is never below the quoted fill. For exact-output, the grossed-up request is never below the quoted fill. Either the pool hits the same price limit or fills exactly the quoted amount.
• Library mirror. SpecifiedAmount.filled matches the vendored Pool.swap loop step for step, including bitmap masks, tick clamps, unchecked remaining updates, liquidity-net crossing and the directional protocol fee. Its checked int24 arithmetic cannot overflow at tick spacing 60.
• Casts and bounds. Every int128 cast is bounded by about 0.67 × int128.max. No hook state can make a swap revert.
• Schedule. feeNow() is 4000 at open, 301 at 3599 seconds, 300 from 3600 on, monotone, no overflow.
• Extra probing. A scratch fuzz of 3000 runs with protocol fees on, scattered and gapped liquidity, limits landing on initialized ticks, an extreme price region near tick −880000, and requests between the int128 and int256 ceilings all passed. The repository's own fuzz and invariant suites passed at 3000 and 256 runs.
• Mainnet. The fork suite passed at the pinned block via an archive RPC, and the IMD address returns symbol IMD with 18 decimals.

Informational findings reported

1. Fees floor, so swaps of 33 wei or less at 300 bps pay nothing. Dust-level, documented in the README.
2. An exact-output IMD request within one fee of int256.max reverts in the manager's checked addition. The window only covers sentinel inputs, is documented as R-01, and fixing it would undercharge instead.

Coverage rows are filed for all eight ABI entry points plus four invariants, all holds.

Review complete. The findings file is written at the repository root, no tracked file was changed, and the scratch tests were removed.

Outcome: no code defect found in the economic area. The hook's fee mechanics, custody and invariants held against every failure mode in the Economic Security, Invariant and Flow Gap guides. One informational configuration gap is recorded.

What I verified

• Fee exactness. The hook charges exactly floor(gross IMD × rate / 10000) in all four swap modes, with IMD on either side, for full and price-limited fills. I proved the quoted fill always equals the executed fill (the adjusted amount never undershoots the quote), so the beforeSwap path cannot under- or over-charge. The delivered hooked tests never enable PoolManager protocol fees, so I fuzzed those too (up to 1000 pips each direction, 256 runs, plus fixed partial-fill cases): still exact. That matters because mainnet's protocol fee controller is set.
• Custody. Fees accrue as ERC-6909 claims, so no transfer happens mid-swap and a fresh manager with DRONE-only liquidity works. Sweep by any caller, repeated, reentrant, or with donated claims or loose IMD, pays only the constant keeper, which is an EOA on mainnet. The claim burn's int128 bound is unreachable because IMD's whole supply is about 4.1e24.
• No hook-induced reverts. The only writes are a counter and a bounded claim mint. The quote library mirrors the v4 swap loop line for line.
• Mainnet fork. The pinned block is now outside the public node's archive window, so I re-ran the rehearsal logic at the latest block against the real PoolManager and real IMD. All modes, limited fills and keeper payout passed.
• Gas griefing. The read-only tick walk adds about 6.5k gas per crossed tick (21% on a 300-tick swap). It scales with the pool's own cost and cannot revert, so it stays a note.

The one finding (info). The brief's economics depend on the launch leaving DRONE with the requester to fund imdDRONES rewards. That split exists only in the manifest notes and README. If the policy row applies a default split with no requester remainder, the requester ends with zero DRONE. Nothing in the tree can enforce it, so the judge needs the policy row or launch request as evidence before allocations freeze. The 1:1 initial price is flagged in the same note as a confirmation item.

Not reached. IMD's own admin surface (it exposes an owner) was not audited. A blocklist on the hook or keeper would strand swept fees but not swaps. That sits outside this launch's control.

Coverage rows answer all eight entry points plus eight invariant and economic rows.

Review complete. The findings file is written and validated, and the scratch probes are removed.

Outcome. I found no exploitable defect in my area (Execution Trace, Periphery, First Principles). The file .imd-findings.json holds one info-level entry and twelve coverage rows, all holds.

What I verified

• Fee path end to end. I traced beforeSwap and afterSwap against the vendored v4 Hooks and PoolManager code. The orientation logic, the gross-up identity, the int128 fits, and the mint-then-credit netting are all correct. The hook cannot trigger HookDeltaExceedsSwapAmount because the fee is always below the budget.
• SpecifiedAmount library. Compared line by line with Pool.swap, SwapMath, TickBitmap and the protocol-fee library. The one textual difference in the tick-recompute condition is unreachable.
• Differential fuzzing beyond the shipped suite. 2000 runs with asymmetric positions, protocol fees in both directions, shifted prices and limits on tick boundaries, plus 1500 runs of wei-sized swaps at deep liquidity, in both currency orderings. Every run charged exactly the scheduled fee on actual gross IMD and never touched the DRONE delta.
• Sweep and callbacks. Keeper is a constant, reentrant and in-unlock sweeps are harmless no-ops, and the unlock callback is reachable only through the hook's own sweep. The slither and aderyn reentrancy and unsafe-ERC20 leads are dismissed with reasons in the coverage rows.
• Manifest and helpers. Constructor order, permissions, fee tier and tick spacing match the code. The mainnet IMD address has code, symbol IMD and 18 decimals. The repo's manifest and bytecode checkers pass.
• Mainnet fork. The documented block is no longer served by the public RPC, so I ran a scratch copy of the fork suite at block 26140915. Both tests passed against the real PoolManager and real IMD.

The one recorded item. Exact-output IMD requests within one fee of int256.max revert in the manager's checked addition where a bare pool would partially fill. It is input-domain only, carries no fund risk, and is already disclosed as R-01 with a regression test. I recorded it as info so the judge has the cross-reference.

Not reached. Nothing in the listed entry points. The fork rehearsal at the exact documented block could not be reproduced for lack of archive state, which is noted in its coverage row.

The findings file is intentionally excluded from git by the harness's own exclude list, so it stays on disk as the report. The commit is in place and the tree is clean.

Outcome

I reviewed the accepted DroneHook implementation adversarially and found no defect in the hook, token, or deployment helper. .imd-findings.json reports an empty findings list. All new tests pass, and the full offline suite is green.

Check	Result
forge test (offline)	82 passed, 0 failed, 2 fork suites skipped by design
New fork suite on live mainnet, latest block	4 passed
Pinned protected floor (hook and token) run in scratch	10 passed
New invariant suites	128 and 64 runs, 8,192 handler calls, 0 reverts

What I added under test/

• DroneHookAdversarial.t.sol (16 tests, run in both IMD orderings). Exact scheduled fee under protocol fees the hook author never configured, including the maximum in both directions. Swaps that walk the price to the MIN and MAX tick, which exercises the quoter's clamp path. Failed swaps leaving no fee accounting: trader one wei short, router refusing to settle, zero amount, bad price limits. Fee identical for any caller, any router, any hookData, and for the keeper itself, checked from one snapshot. Four swaps in one unlock each charged exactly. Sweep attempted from inside a foreign unlock, and forged callbacks from inside one. Sweep from six callers over six rounds, including the manager. Plain CREATE deployment refused with HookAddressNotValid. Creation code of all three delivered contracts scanned for DELEGATECALL, CALLCODE, and SELFDESTRUCT.
• DroneHookInvariants.t.sol. Seven-action handler with three traders through two routers, an LP adding and removing narrow positions across initialized ticks, a donor sending IMD straight to the hook, protocol-fee changes, time, and sweeps from random callers. Ghost accounting asserts collected equals the sum of independently computed fees, held plus paid equals everything ever taken, the manager can always honour the claims, no IMD reaches anyone but the keeper, and the schedule stays frozen.
• MainnetForkRecent.t.sol. Buy and sell through the real PoolManager against the real IMD at whatever block the fork provides, with sweep to the keeper.
• helpers/AdversarialRouter.sol. A second independent router supporting hookData, batches, no-settle, and in-unlock probes.
• helpers/HookFixture.sol. One fix: the Swap event reports LP plus protocol fee combined, so the event check now derives the expected value from the pool's protocol fee while still asserting the LP fee is 12500.

Two things worth knowing

The accepted fork test pins block 26140740, and the public node already refuses that state as pruned. It cannot be rerun there anymore. My new fork suite needs only a recent block, so the rehearsal can be repeated before release.

The real IMD token is a LayerZero OFT with an owner. Its selector set shows no pause or blocklist, so the hook's reliance on ordinary ERC-20 transfers holds today, but that owner is an external trust assumption the README already names.

The findings file is valid JSON with 4 findings and 12 coverage rows, every quoted snippet matches the tree, the scratch directory is gone, and the working tree shows no stray files.

Review outcome

No critical, high or medium defect was found. The delivered DroneHook and DroneToken implement the brief correctly. The findings file at .imd-findings.json holds one low and three informational items, all reproduced against the code, with the specialists' three reports of the same overflow merged into one.

What I verified myself

• The full offline suite passes: 82 tests, 0 failures, across both IMD currency orderings, protocol-fee variants, partial fills, tick-range extremes, batch swaps, reentrancy, failed settlement, and stateful invariants.
• The mainnet fork rehearsal passes at the current block against the real PoolManager and real IMD. I confirmed the IMD address on mainnet returns symbol IMD with 18 decimals, and the manager has code.
• I traced the fee accounting by hand against the vendored Hooks and Pool libraries. The gross/net identity holds in all four swap modes, the partial-fill fee never exceeds the full-fill reserve, and the grossed-up exact-output amount never undershoots the quoted fill. The read-only quote library matches Pool.swap step for step, including the tick-bitmap walk, protocol-fee composition and liquidity transitions.
• Every callback and the unlock callback are restricted to the PoolManager. The sweep guard, claim burn and take sequence pay only the constant keeper. Permission bits, manifest constructor order and the absence of DELEGATECALL in runtime and creation code all check out.

Findings kept

1. Low. An exact-output IMD request within one hook fee of int256.max reverts in the manager's checked addition, where the bare pool would partially fill. It is input-driven, disclosed as R-01, and covered by a regression test. Three specialists reported it; merged.
2. Info. Fees floor, so swaps under 34 wei at 300 bps pay nothing. Documented design choice, verified 33 wei pays 0 and 34 wei pays 1.
3. Info. Pool initialization is permissionless once the hook has code, so the launch must deploy and initialize atomically. Reproduced with a stranger fixing the price and clock in a non-atomic sequence.
4. Info. The requester's retained DRONE allocation exists only in prose. The token mints everything to the factory, so the policy row must carry the 80/10/10 split before allocations are frozen.

Dropped or rejected leads. All static-analysis lines were checked: the strict equalities and timestamp comparisons are intended, the sweep reentrancy warning is covered by the storage guard and the manager's unlock state, and the unsafe-ERC20 warning is wrong because the transfer goes through v4's reverting Currency library.