The review is complete. The findings file is written and validated, the scratch directory is removed, and the working tree holds no other changes.

Outcome: no critical, high or medium defects in the four contracts as they arrived. The hook's fee accounting holds against the real vendored v4 PoolManager in all four swap forms, including with a protocol fee set, on a fresh single-sided pool with no IMD in the manager, and at the rounding edges. All callbacks refuse non-PoolManager callers, nothing in the token or hook can mint, pause, freeze, seize or upgrade, the compiled runtimes contain no DELEGATECALL, CALLCODE or SELFDESTRUCT, and the manifest's constructor arguments, permissions, fee tier and paired currency agree with the code. The project's own 231 tests pass.

What I recorded in .imd-findings.json:

• Low: surcharge bypass via single-sided LP. With flags 0x20CC the hook never sees liquidity changes, so a holder can park MONEYBACK just above the price, let buyers fill it, and withdraw IMD during the 30-minute window paying zero base fee and zero surcharge. Reproduced with concrete amounts on the real PoolManager. The README already acknowledges it and the brief fixes the flags, so this is for awareness rather than a change request.
• Low: opening price contradiction. The manifest's initialPrice is exactly 2^96 (parity, 1e9 IMD whole-supply valuation), while the README and notes claim a 2,500 IMD valuation that the deployer will derive instead. One of the two is wrong for the deployer. The adapter should settle which, and I gave the sqrtPriceX96 for the documented valuation in both currency orderings.
• Info: beforeInitialize ignores the initializing sender. Safe in the factory's atomic deploy-and-initialize flow, noted so deployment is never split across transactions.
• Info: scope statement. Lists every contract, test and document read, the checks run, and what could not be reached offline: the live IMD token bytecode, the live PoolManager and public ETH/IMD pool, and the factory and MerkleDistributor sources that implement the supply split.

Nothing further is pending on my side. The adapter's only decision points are the opening-price inconsistency and whether the requester accepts the documented LP bypass of the surcharge.

The work is done and verified. Summary:

Outcome. The pinned contracts launch as they are: no production source, script, foundry.toml or launch.json changed. I reproduced all four imported audit findings against the real vendored v4-core PoolManager, added eight regression tests, and wrote the launch documentation. Build, tests and format check all pass with the pinned compiler.

Check	Result
forge build	exit 0
forge test	239 passed, 0 failed, 0 skipped
forge fmt --check	exit 0

Findings and dispositions (full detail in docs/LAUNCH_REVIEW.md):

• LP bypass of the surcharge (low): reproduces; the existing real-v4 test already demonstrates it in both currency orders. Left unchanged because the brief fixes the flags at 0x20CC and forbids fee changes. Documented as a limit of a swap fee.
• Manifest parity price vs. 2,500 IMD valuation (low): reproduces as a documentation gap only. The launch rules require the literal in pool.initialPrice and have the deployer derive the opening price. I computed both candidate sqrtPriceX96 values (one per sort order), put them in the README, and added tests that open the pool at each derived price, seed 81% single-sided with no IMD in the manager, make a first buy at the documented valuation, charge the fee as an IMD claim and sweep it.
• beforeInitialize ignores the initializing sender (info): reproduces. Left unchanged because fixing it means a new constructor argument, a re-mined address and a changed manifest, against the instruction to launch the pinned code; the factory's single deploy-and-initialize transaction leaves no window. A new test pins both the window and that a bound hook refuses every later initialize.
• Audit scope (info): nothing to fix; the unreached live-chain items are restated.

Also done. Confirmed the logo matches the brief (1024 square, one yellow umbrella on flat navy). Fixed a README link to a response file that is not in the tree, and refreshed the deployment-parameter and operational-responsibility sections.

Open items for the launch, not for this repository: the deployer must initialize in the same transaction as the hook deployment and record the opening price actually used; the requester must then run the auxiliary script for RoundPayout and the router and fund RoundPayout by hand. Slither runs only on the verifier.

Updated only launch.json to document the authorized two-phase deployment, preserving constructor arguments, permissions, pool settings, and fees.

Checked schema-reference fields and compiled ABI consistency. Notes are 3,151/4,000 characters.

forge build succeeded; all 239 tests passed.

The review is complete. The findings file is written at .imd-findings.json with one finding and 29 coverage rows, and the scratch tests are removed.

Outcome: the fee math holds. I traced every division, cast and inversion in the hook and router against the Math Precision, Boundary and Numerical Gap guides, then exercised them on the real vendored v4 PoolManager in both currency orders. Nothing in my area reaches high or critical severity, so no proof file was needed.

What I verified empirically

• Tiny amounts in all four swap forms, at every surcharge boundary (0, 1, 899, 1799, 1800, 5000 s): the inverted buy fee stays within 1 wei and the inverted sell fee within 2 wei of the floored pool-leg fee, and sells never under-charge the gross leg.
• A protocol fee enabled on the pool does not disturb the full-fill check for specified-IMD swaps.
• Repeated trade and sweep cycles deliver exactly the claim balance to the immutable payout.
• Int128 guards, the sign extraction from packed deltas, the surcharge formula, and the router's dust subtractions cannot underflow or overflow for any reachable input.

The one finding (low)

RoundPayout counts a leg as paid whenever the transfer returns true. A recipient equal to the RoundPayout contract itself satisfies that without moving tokens, so the same balance is reported as distributed in every later round. The reproduction in the file funds 100 IMD and pays it "twice" across two rounds while the contract still holds all 100. No funds are lost, but the documented conservation invariant and the ledger the off-chain engine reconciles against are wrong. The suggested fix is to reject a recipient equal to the contract address.

Not reported as defects

• Fee truncation to zero below 24 wei of IMD leg is real but worth less than the gas to exploit.
• The manifest's parity initial price versus the 2,500 IMD valuation is already documented as resolved by the deployer's derivation in the launch review.

The review is complete. The findings file is written and the working tree is unchanged apart from it.

Result: no defects found in the assigned area (Access Control, Trust Gap, Asymmetry). The file .imd-findings.json holds one info-level note and a coverage row for all 24 entry points plus four invariant rows.

What I checked and how:

• Permission model. Every state-changing function of the four contracts was mapped to its guard. The hook's three callbacks and its unlock callback are PoolManager-only, the swap callbacks also require the bound key, and the unlock callback additionally requires a sweep in flight. The router's callback runs only for the exact data it just passed to unlock. RoundPayout's privileged functions are all owner-gated behind a two-step handoff. The token has no privileged surface.
• Scratch probes against the real vendored PoolManager. A third party cannot transfer or burn the hook's IMD claims, direct callbacks from a non-manager are refused, a random EOA's sweep delivers the full claim balance to the payout wallet, and a second key with a different fee tier cannot bind the hook. All passed, so those "holds" rows are backed by execution, not reading alone. The scratch file was removed afterwards.
• Asymmetry. beforeSwap and afterSwap use the same "IMD specified" predicate and the same fee inversion, so the PartialFill check cannot disagree with what beforeSwap charged. Router buy and sell mirror each other on lock, deadline, slippage and refunds. RoundPayout's retry and write-off paths clear debt and the counter symmetrically. The one asymmetry I saw, writeOffFailed lacking the pause check, is owner-only bookkeeping and not a defect.
• Trust gap. Fees can only ever reach the immutable payout. Fee avoidance through hookless pools or single-sided liquidity is inherent to the fixed 0x20CC flags and is already documented in the README and launch review. The manifest's constructor arguments, permissions, fee tier and paired currency all match the implementation.

The single info note records that beforeInitialize does not check the initializing sender. With the key fully constrained, an outsider could only choose the opening price and start the surcharge clock, and only if the hook were ever left deployed but unbound. The factory's atomic deploy-and-initialize makes that state unreachable, the repository already documents and tests it, and fixing it would change the constructor and mined address the brief forbids. It is recorded for completeness, not as a request for change.

Existing suite: 239 tests pass on the pinned tree.

The review is complete and .imd-findings.json is written with both findings and a full coverage record. The working tree is clean apart from that file.

Outcome: no critical, high or medium defect in the economics. The hook's fee accounting is correct in all four swap forms against the real vendored v4 PoolManager, the claims-based fee custody is fully backed, sweep only ever pays the immutable paying wallet, and the router nets its IMD and ETH deltas to zero on every path. Build and the existing 239 tests pass.

Two substantiated findings, both reproduced with scratch tests against the code as it is:

• Low, RoundPayout. Failed-leg debts are not reserved. After a leg fails, a later payRound or sweep passes the balance check against the tokens the header says are "held" for retry. The retry then reverts with insufficient balance. Only the owner can trigger it and no holder loses funds, so it is a bookkeeping gap against the contract's own stated invariant, not a loss path.
• Info, MoneyBackHook. The fee and surcharge apply only to the one bound pool. Anyone can initialize a hookless MONEYBACK/IMD pool and sell there during the surcharge window paying only that pool's LP fee. This is inherent to a hook-only fee on a plain token, is partly acknowledged in the README, and cannot be closed within the fixed flags. Recorded so the requester weighs it explicitly.

Coverage: all 24 listed entry points have a row. Twenty-two hold, two point at finding 1. I added four invariant rows and one honest unreached note. The one thing I could not verify from this tree is which opening price the deployer actually uses, since the manifest carries the 2^96 policy literal while the README says the launch service derives the 2,500 IMD valuation price. The hook accepts either.

The review is complete. The findings file is written and the tree contains no other changes.

Outcome: no substantiated defect in the Execution Trace, Periphery or First Principles area. The file .imd-findings.json holds an empty findings list and a coverage record with a row for every one of the 24 listed entry points plus five invariant rows, all marked holds.

What I verified, beyond reading:

• Hook swap paths on the real v4-core PoolManager. The delivered suite already covers all four swap forms, partial-fill rollback, decay boundaries and both currency orders. I added scratch tests for paths it did not touch: a swapper paying input and hook fee entirely with ERC-6909 claims followed by a sweep that still delivers real IMD, two swaps of different forms inside one unlock, and a sweep attempted from inside another unlock. All passed, and the scratch file has been removed.
• Vendored v4-core honesty. A whitespace-insensitive diff against the upstream checkout at the pinned commit shows only formatting differences and the documented solmate import-path change, so the integration evidence rests on real pool math.
• Router settlement. The sync, transfer, settle sequence, the digest-gated callback, the quote revert-and-catch, and the refund paths net every delta to zero and keep user funds attributable to the caller.
• Manifest and brief. Constructor argument order, permissions, fee tier, tick spacing, lowercase paired currency, token metadata and notes length all match the implementation. The PNG and SVG logo match the brief exactly.
• RoundPayout and token were traced outside my area with no severe defect found. Owner powers there are the documented trust assumption.

Items I deliberately did not report: the unbound-hook initialization window and the single-sided LP surcharge bypass are already recorded imported findings answered by design, and the sub-wei rounding on dust-sized exact-output sells stays inside the contract's own stated two-wei bound.

Added real Uniswap v4 stateful invariants, token balance/allowance ledger tests, and failure/recovery coverage. Existing invariants now reject unexpected handler reverts.

Validation: forge build passed; all 266 tests passed, with zero failures or skips.

All changes are under test/. No new production defect was reproduced.

The review is complete. The findings file is written at the repository root and the working tree is otherwise unchanged (the scratch tests were removed after running).

Outcome: no blocking defects. The launch code deploys under the factory model and behaves as the brief specifies. All four specialist findings reproduced against the code, none rose above low, and my own pass found nothing they missed.

What I verified

• The full existing suite passes, 253 tests across 10 suites, including the real vendored v4-core PoolManager suites in both currency orders.
• The hook's fee accounting matches v4-core's actual delta flow: afterSwap receives the pool-only delta, hook deltas are credited after the callback, and the inverted fee for IMD-specified swaps cannot trip the manager's exceeds-swap-amount check.
• The manifest matches the implementation: three constructor arguments in order, permissions equal to the declared flags 0x20CC, fee 12500 accepted by beforeInitialize, paired currency equal to the hook's IMD constant, notes under the 4,000-character limit.
• Contract sizes are well inside the limits, and an opcode scan of all four compiled runtimes finds no DELEGATECALL, CALLCODE or SELFDESTRUCT, so the protected hook and token floors pass.
• The logo is a single yellow umbrella with a hooked handle on a flat navy square, 1024 by 1024, nothing else.

Findings kept, with reproductions run

1. Low. RoundPayout counts a leg paid to itself as Paid without tokens leaving, breaking the stated conservation invariant. Owner-only bookkeeping.
2. Low. RoundPayout does not reserve failed-leg debts, so a later round or sweep can spend them and retryFailed reverts until the owner tops up. Owner-only, no loss.
3. Info. Fees apply only to swaps through the bound pool. A hookless pool, a single-sided LP position or an OTC transfer bypasses the surcharge. Merged the hookless-pool and LP-conversion reports into one root cause. Documented in the repo and inherent to the fixed flags.
4. Info. beforeInitialize ignores the sender, so an unbound hook could be bound by anyone. Closed by the factory's atomic deploy-and-initialize.

Coverage. All 24 entry points are answered, plus three invariant rows. One row is marked unreached: the manifest's initial price is parity while the docs say the deployer derives the opening price from the 2,500 IMD policy valuation, and that deployer behaviour cannot be checked from this tree.