Implemented the token, immutable hook, deployment script, and README launch attestation. No configuration or dependency files changed.

Verified: offline build passed; 36 tests passed, including 512 fuzz cases and 1,024 invariant calls.

Documented limitation: cumulative bracket catch-up can require extra ETH from a tiny final sell, so output-only routers cannot be guaranteed compatible. Production factory rehearsal remains pending its actual configuration and calldata.

This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. If you’re doing authorized security work that requires more cyber permissive safeguards, apply for Daybreak access via https://platform.openai.com/settings/organization/status-and-access before retrying.

Done. The deliverable is test/IMDO.t.sol, plus .imd-findings.json for what could not be tested around.

Result

How the suite works. The repository has no forge-std and no v4-core, and this task may only write one file. So the test file declares its own cheatcode interface and carries the real Uniswap v4 PoolManager as creation bytecode, compiled from the vendored v4-core. Every fixture deploys that manager, launches through a factory-style contract that creates the token, mines and CREATE2-deploys the hook, initialises the pool and seeds the launch position in one transaction, and funds a Merkle distributor stub. A hookless mirror pool with identical state supplies reference amounts, so every fee assertion compares against genuine v4 math rather than a re-implementation.

What is covered

• Buys free in both modes, identical deltas to the hookless pool, no treasury movement.
• Exact fee at every bracket boundary for exact-in sells (ETH to treasury) and exact-out sells (tokens burned), including the ceil edges one wei either side of 1%, 3% and 5%.
• Split sells billed cumulatively in one transaction, across two brackets, and in mixed exact-in then exact-out mode. The same legs as separate transactions pay nothing.
• Same-transaction liquidity inflation and donation do not lower the bracket. The lag expires exactly one block later.
• Factory LP fee growth, collection, payout split and position withdrawal are byte-for-byte equal to the hookless pool. Merkle claims are untaxed and unaffected.
• Treasury rejecting ETH or burning gas never blocks a sell. Fees become ERC-6909 claims that a permissionless harvest later delivers only to the treasury.
• ETH-only pool exercises the token-claim fallback and harvest burn. Token-only pool on a fresh manager exercises the buy path.
• Protocol fees are excluded from the reserve, and the reserve reconciles with the manager's inventory.
• Fuzzed random calldata and a curated admin selector list change nothing. Fuzzed sells of any size never revert.
• Token: fixed supply, exact transfers, allowance paths, burn, no admin calls, no escape opcodes. Deploy script constants, salt mining reproduction, and the chain guard.
• Invariant handler: random swaps, liquidity, donations, protocol-fee changes, treasury toggling, block rolls, harvests and burns. Invariants: hook holds nothing beyond accrued claims, every fee is at the treasury, burned or claimable, reserve reconciles, configuration immutable, factory position intact.

Reported rather than asserted in .imd-findings.json

• Medium: the deploy script reverts with InvalidConfiguration under the network's standard offline check, needs four environment variables, and forwards an opaque factory calldata blob instead of performing a reviewable deployment.
• Low: cumulative catch-up billing can make a tiny later sell leg's ETH delta negative, which output-only routers cannot settle.
• Info: all sells in the launch block pay the 2% cap, and tx.origin keying groups unrelated sellers under one bundler.

Not covered. The script's prepare() and run() paths need environment variables, and vm.setEnv is forbidden, so only their guard paths are tested.

Final README sentence fixed. All work is complete and verified; here is the recap.

Outcome. The medium finding reproduced and is fixed. The low finding reproduced against a real v4 PoolManager and is fixed with a small change in the hook's billing. The two info findings are confirmed behaviour that the brief specifies, so they are answered as disputed with no code change. All four answers are in .imd-responses.json.

Deploy script (medium, fixed). The old run() reverted on any chain other than Sepolia before reading configuration, and even there only forwarded an opaque factory calldata blob. The rewritten script reads only EXPECTED_CHAIN_ID plus an optional POOL_MANAGER, accepts chains 31337 and 11155111, and between the broadcast markers deploys the token with CREATE and the hook with CREATE2 through Foundry's default deterministic deployer, mining the salt for permission bits 0x25d4 in the script. On the local chain without a manager it first deploys an empty stand-in so the hook constructor's code check passes. After deployment it re-reads bindings, treasury, cap, supply and not-initialized state and emits an attestation event. Pool initialization stays with the launch factory.

Verified:

• EXPECTED_CHAIN_ID=0 forge script script/Deploy.s.sol:Deploy --offline succeeds and returns token, hook and salt.
• Wrong expected chain, missing POOL_MANAGER on Sepolia, and a codeless manager each revert with InvalidConfiguration() before deploying.
• run() also works when called from a forge test, with and without a real PoolManager, followed by a factory-style pool initialization.

Per-leg fee bound (low, fixed). Using Uniswap's own output-only settlement rule in a batching router, a sell of just under 1% followed by a 1 wei sell reverted on the second leg with a negative ETH delta under the accepted code. Now a leg is never billed more than its own size: the ETH fee is capped at the leg's gross ETH output and the IMDO fee at the leg's settled input. The uncollected remainder stays in the cumulative bill and is charged on the next leg of the same transaction. Single sells and ordinary splits bill exactly as before, and a transaction that ends on a tiny crossing leg never pays less than selling the already-billed earlier legs alone.

Checks run. Offline build, size check and forge fmt --check pass. Both protected floor suites pass against the revised creation code, 9 tests. A 10-test scratch suite on a real PoolManager passes, and the same tiny-leg tests fail against the old hook code, confirming the reproduction. The README's billing section, script section, attestation hashes and verification results are updated. Nothing outside src/IMDOFeeHook.sol, script/Deploy.s.sol and README.md was changed, and foundry.toml was left absent as before.

Work is complete. The suite builds offline, all 48 tests pass, forge fmt --check is clean, and the only modified tracked file is test/IMDO.t.sol. The untracked dotfiles in git status are the sandbox's read-only device nodes that were present before I started, not files I created.

What failed and why. The implementation node revised the deploy script to accept chain 31337 as a local dry run and added a per-leg bound to the hook's cumulative sell bill. My accepted test test_runRefusesTheWrongChain asserted that run() reverts on the default test chain, which is 31337, so it failed against the revised script. The previous repair attempt was rejected for a model-side content flag, so none of it survived.

Changes in test/IMDO.t.sol:

• Deploy-script tests rewritten for the revised script. run() now executes from a test on chain 31337: it asserts the fixed supply minted to one account, the hook at an address carrying exactly the permission bits, the stand-in manager with code, the returned salt equal to what mine finds for Foundry's CREATE2 deployer, the full LaunchAttested event payload, and that the real PoolManager cannot initialize a pool against the locally built hook. A fuzz test rejects every other chain id, and a Sepolia run without a configured PoolManager is refused. The suite reads the two environment variables with envOr only to detect a foreign configuration; it never sets them.
• Per-leg bound tests. A dust leg crossing a bracket surrenders exactly its own output and never leaves a negative ETH delta, the next leg pays the carried remainder, and the bill is complete by the end of the transaction. The exact-output analogue bounds the token fee to the leg's own input. A dust leg as the last leg leaves only a bounded remainder that does not carry into a later transaction and is never cheaper than separate sells.
• Fuzz property over three-leg splits. Total paid in one transaction is at least the sum of each leg billed at its own bracket and at most the final bracket on all proceeds, with every leg's ETH delta non-negative.
• Invariant handler. A new splitSell action runs two sell legs in one transaction, optionally mixing modes, so the random call sequences now exercise the bound path. Runs show 128 calls to it with zero reverts.

Findings. None. I checked the per-leg bound for an exploitable split and the carried-remainder accounting; the documented trade-off holds and the fuzz property confirms it, so no .imd-findings.json was written.

Created launch.json with matching constructors and permissions, native ETH pairing, and documented price assumption.

Schema validation and forge build passed. forge test: 48 passed, zero failures.

Only launch.json changed outside exempt scratch artifacts.

The review is complete. The findings file is written at .imd-findings.json, no repository file was changed, and the working tree is clean apart from ignored build output.

Outcome: no arithmetic defect found in the hook or token. I traced every value-moving formula against the Math Precision, Boundary and Numerical Gap checklists and confirmed each by hand and, where it mattered, empirically against the real v4 PoolManager embedded in the existing suite. Specifically:

• Bracket thresholds are exact ceil(reserve * bps / 10000) without a large product, and map to the brief's bps table at the 10000 and 10001 reserve edges.
• Cumulative bill Q*r - P cannot underflow because both the rate and the quote total are monotone within a transaction. Exact-in legs credit paid exactly; exact-out legs round the credit down by under a millionth of a wei. The 512-bit mulDiv is the standard OpenZeppelin construction with the correct inverse seed and six Newton steps, so the aderyn "caret" lead is a false positive.
• Casts int128(delta) and int128(delta >> 128) correctly extract amount1 and amount0 for a pool that beforeInitialize forces to be ETH/IMDO. The headroom check is unreachable below roughly 2^126 token units. The aderyn casting and reentrancy leads do not reach a defect.
• Reserve tracking reconciles with the manager's pool-attributable balance. Protocol fees are subtracted from the input side only, and v4's pool-favouring rounding means no outflow can underflow liveReserve, so the factory's liquidity and fee collection cannot be blocked.
• Boundaries probed live: a 9.9e21 wei exact-out sell burned exactly 2% of its gross token input, a 1 wei exact-out cost 3 wei of token and no fee, and the treasury address on Sepolia is an empty account, so direct ETH payment will not fall back to claims.

Three recorded items, all design limitations rather than math errors, each with reproduced numbers:

1. Low. Out-of-range token-only liquidity counts in the bracket denominator. A deposit at ticks -660 to -600 one block earlier let a 5% sell pay zero instead of about 10 ETH, with the position withdrawn in the same transaction and no price exposure.
2. Info. Per-transaction counters plus a block-constant snapshot mean six transactions in one block sold 5.99% of the reserve for zero fee, where one transaction paid 10.08 ETH. This follows the brief's "within one transaction" wording.
3. Info. A zero lagged reserve maps every size to the 2% cap, so a 1 bps sell in the launch block paid 20,000 ppm.

The coverage record answers all 12 listed entry points plus four invariants. Two entry points carry finding references for items 1 and 2. None are unreached. No proof files were attached since nothing reached high or critical severity.

The findings file is in place at the repository root and the task's own exclude rules keep it and the scratch directory out of git, so no tracked file changed. The review is complete.

Outcome. .imd-findings.json holds 3 findings and a 17-row coverage record answering all 12 listed entry points plus 5 invariants. No source, script, README or manifest file was modified. Scratch tests live under test/scratch/ and their build output was removed.

Findings (all reproduced on the real PoolManager bytecode the repository's suite embeds):

1. Medium, access control. beforeInitialize binds the hook to the first pool anyone initializes. It ignores the sender, the tick spacing and the starting price. The delivered flow is two transactions: the deploy script creates the hook and the README says the factory initializes later. In that window an outsider initialized a fee-500, tick-spacing-1 pool at the minimum price, and the factory's intended initialization then reverted with InvalidPool. No function can rebind, so the attested hook is dead and must be re-mined and re-attested. If the production factory deploys and initializes atomically the window closes, but the hook itself offers no defence and the script and README prescribe the vulnerable order.
2. Low, economics × asymmetry. The per-leg fee bound in _bill lets a boundary-hugging split underpay. Selling exactly 5% of the lagged reserve in one swap paid 19,999 ppm. Selling the same total as a 4.99% leg plus a dust leg in one transaction paid 11,890 ppm. The README discloses the behaviour, and cross-transaction splitting is unaccumulated by the brief anyway, so the impact is bounded.
3. Low, branch asymmetry. In the launch block the lagged reserve is zero, so every sell pays the 2% cap, including sells under 1% of the reserve that the bracket table says are free. The repository's own launch-block test asserts this behaviour.

What held. All seven callbacks are manager-only, reentrancy-guarded and pinned to the bound pool. harvest and unlockCallback can only move recorded claims to the constant treasury or burn them, and the callback is gated by a transient flag only the guarded harvest sets. Hook deltas net to zero on the direct-pay and claim paths. No setter, owner, delegatecall or upgrade path exists for brackets, cap, treasury, token or manager. The token's four entry points are plain ERC-20 with a self-burn. The treasury address has no code on Sepolia, so the 80,000-gas payment cap is sufficient for it.

Verification notes. The baseline suite passes, 48 tests, when compiled without via-ir. With via-ir, as the README's attested build command specifies, solc 0.8.26 segfaults on the test file's embedded PoolManager literal, so I could not run the suite under the attested compiler settings. Aderyn's three high-severity lines were checked and dismissed: the caret is an intentional XOR in _mulDiv, the state writes after external calls in unlockCallback are reachable only by the trusted treasury inside the hook's own reentrancy guard, and the int128 casts intentionally extract BalanceDelta halves. No Slither run was performed beyond the supplied output, and no live factory rehearsal exists in the workspace.

The review is complete. The findings file is written and validated, no tracked files were changed (the findings file and test/scratch/ are excluded by the repository's own git exclude list, which is expected).

Summary

I audited the IMDO token and IMDOFeeHook against the Pashov Economic Security, Invariant and Flow Gap guides, running the shipped suite (48 tests pass) and my own scenarios on a real v4 PoolManager. Results are in .imd-findings.json: 6 findings, 3 with failing Foundry proofs under test/scratch/, and 17 coverage rows (all 12 listed entry points plus 5 invariants).

Findings

1. Medium. The cumulative catch-up bill in _bill is bounded only by a leg's own output, so when two unrelated sellers share one tx.origin (ERC-4337 bundler, relayer) the later seller pays the earlier seller's catch-up. Reproduced: a 0.20% sell that pays 0 alone pays 27.7% of its ETH output when preceded by a 4.90% sell in the same transaction, breaking the 2% hard cap per principal. Proof: ProofSharedOrigin.t.sol.
2. Medium. Exact-output sells take the token fee physically inside afterSwap. A router that syncs the token before the swap (a valid v4 order) settles short by the fee: the seller pays the fee twice, the second copy is stranded in the PoolManager, and with a tight max input the sell reverts. OpenZeppelin's BaseHookFee mints claims instead. Proof: ProofPayFirstRouter.t.sol.
3. Low. beforeInitialize accepts any initializer, tick spacing and price, so in the window between script/Deploy.s.sol and the factory's initialization anyone can bind the hook to a different pool, permanently blocking the intended launch pool for that hook address. Proof: ProofPoolSquat.t.sol.
4. Low. With a zero lagged reserve (launch block), every sell pays 2%, including dust, contradicting the "under 1% pays 0%" bracket.
5. Low. A token-only out-of-range position held across one block inflates the lagged reserve at zero cost. A 5% sale paid 0 after parking tokens for one block. This is within the brief's stated one-block scope, reported as residual exposure.
6. Info. Brackets bind only per transaction: ten same-block transactions sold 9.89% of the reserve for no fee. By design per the brief.

Verified as holding: reserve accounting (no undercount or underflow path), protocol fee exclusion, hook custody equals recorded claims, harvest and unlockCallback guards, factory LP fee accounting and Merkle claims unaffected, and all four token entry points. Each proof was confirmed to fail on the current code and pass against a patched copy with a candidate fix.

The review is complete. No tracked file was changed; the findings file and scratch tests are untracked, as required.

Outcome. .imd-findings.json holds 3 substantiated findings and 19 coverage rows, one for each of the 12 compiled entry points plus invariants, the attestation hashes, the manifest and the deploy script. The repository's own 48-test suite passes on this tree, and the README's attested creation and runtime code hashes reproduce byte-for-byte under the attested compiler flags.

Findings, most severe first:

• Medium, src/IMDOFeeHook.sol:325. The sell bill is keyed only by tx.origin and is collected retroactively from whichever leg crosses a bracket. When one origin settles sells for several principals in one transaction (ERC-4337 bundle, batch-auction solver, multicall relayer), a later unrelated seller pays the earlier seller's catch-up. Reproduced with a batch settler: Alice sells just under 5% and pays her correct 1%; Bob, selling 0.5% (0% bracket on his own), pays 12.5% of his proceeds, and with a 0.05% sale receives zero ETH. The brief's 2% hard cap is broken for that seller. The key is the brief's choice, so I state the design trade-off and a cap-preserving alternative rather than a one-line fix.
• Low, src/IMDOFeeHook.sol:372. For exact-output sells the hook pulls its token fee with an immediate ERC-20 take instead of a claim. A router that calls sync, pre-funds its maximum input, swaps, then settles sees its credit reduced by the fee, so the seller pays the fee twice and the duplicate tokens are stranded in the PoolManager with no owner. Reproduced; the hookless mirror pool is unaffected under the same router. Minting the claim, as the fallback path already does, removes it.
• Info, launch.json:26. The manifest's initialPrice decodes to exactly 1 IMDO per 1 ETH, which prices the fixed supply at 10^9 ETH. Outside my area and disclosed as an inherited fixture value, but it is a concrete launch input to confirm.

What held. Caller gating, pool binding, delta decoding and netting, headroom bounds, the before/after protocol-fee reconciliation, the one-block lag, the ETH direct-pay with claim fallback, harvest and its callback gate, the token's four entry points, and the manifest's permission and constructor agreement. The one-block lag can be worked around by adding liquidity in the previous block, but that is exactly the protection the brief specifies and the README says so, so I did not report it.

Not covered. The protected floor suites need forge-std and v4-core, which are not on disk, so I did not rerun them. No fork or live-factory rehearsal was performed, and no audit is claimed.

The review is written to .imd-findings.json: five findings kept, all reproduced on a real v4 PoolManager, and all 12 entry points answered. No critical or high defects were found, and no repository file was changed.

Findings kept, after merging duplicates

1. Medium, shared-origin over-billing. The cumulative bill is keyed only on tx.origin and collected from the current leg, bounded only by that leg's output. In the economics specialist's test, a seller in the 0% bracket lost 277,457 ppm of their ETH after another user's sell in the same bundle. The fix is a requester trade-off between the 2% cap and full retroactive billing, so I attached no proof that would force one choice.
2. Medium, exact-output fee double-charged. The token fee is physically taken from the PoolManager inside afterSwap. A router that synced IMDO before the swap pays the fee twice, and the second copy is stranded. The economics specialist's proof fails for this reason and is attached.
3. Low, pool binding can be squatted. beforeInitialize accepts any tick spacing, price and sender. In the two-step flow of the deploy script, anyone can bind the hook to a wrong pool and kill the mined address. The window does not exist if the factory deploys and initializes atomically.
4. Low, launch-block sells pay 2%. A zero lagged reserve maps every sell to the cap. A 1 bps sell in the launch block paid 20,000 ppm, against the bracket table's 0%.
5. Info, out-of-range liquidity inflates the bracket denominator. A token-only position parked across one block boundary dropped a 5% sell from the 2% bracket to a zero fee. This conforms to the brief's one-block lag and is recorded as residual exposure only.

Specialist findings dropped

• Boundary-hugging split: the seller gains nothing. They pay what selling just under the boundary alone would cost, and the dust leg forfeits its whole output.
• Cross-transaction splitting: this is the brief's own rule, which accumulates within one transaction only.
• Manifest initial price of 1 IMDO per ETH: no intended price is supplied to check it against, and the manifest notes already disclose it as an assumption. It still deserves the requester's confirmation before launch.

Other checks

• The repository's own suite passes: 48 tests.
• The deploy script dry run succeeds offline.
• The static-analysis leads did not reproduce: the caret operator is the standard modular-inverse seed, the casts select the token half of the delta, and the flagged state change follows a zeroed counter.

My own read of the remaining entry points found nothing the specialists missed. Delta accounting balances on every path, the reserve tracker cannot underflow, and harvest moves only recorded claims to the fixed destinations.

Revision complete. All five findings are answered in .imd-responses.json, four fixed and one disputed, and only the three allowed files changed.

What reproduced and what changed

• Shared-origin catch-up billing (medium), fixed. A bundler running two principals' sells under one origin charged the second leg 27.7% of its gross on the accepted code. The per-leg bound in _bill is now 2% of the leg's own size for both exact-in and exact-out, while the bracket stays cumulative. I took the reviewer's first option and recorded the trade-off in the README: catch-up is weaker within one transaction, which matches what cross-transaction splitting already allowed.
• Exact-output take between sync and settle (medium), fixed. The attached proof failed on the starting tree and passes now. The token fee is always an ERC-6909 claim, never a take inside afterSwap. The permissionless harvest() burns it, and its ETH leg is wrapped in try/catch so a treasury that rejects ETH no longer blocks the token burn.
• Pool squatting (low), fixed. The hook now pins the full launch key: fee 3000 and tick spacing 60 as constants, compared along with currencies and hook address. The deploy script attests those constants. The README states that deploy and initialize must happen in one factory transaction, because pinning cannot stop someone initializing the exact key at a bad price in a two-step window.
• Launch-block 2% rule (low), fixed by documentation. Code unchanged. The README bracket table now has an explicit row for sells while the lagged reserve is zero. Seeding from live inventory would reopen same-block inflation in the launch block, and the existing test suite asserts the current behaviour.
• Out-of-range liquidity in the denominator (info), disputed. The brief asks only for a one-block lag, which the hook provides. The README now names this residual exposure explicitly.

Verification

• Default and attested offline builds succeed, forge fmt --check passes, and the deploy dry run on chain 31337 succeeds.
• A 13-test scratch suite on a real v4 PoolManager passes, including the reviewer's proof, both bundler scenarios, the squat case, brackets, free buys, claim-then-burn, independent harvest legs, split billing, and same-transaction inflation.
• Attested hook runtime is 7,105 bytes with no forbidden opcodes. The README's code hashes were recomputed from the attested build.

One note: the repository has no foundry.toml or lib/, so scratch tests were compiled against the vendored forge-std and v4-core via remappings on the command line. Nothing outside src/, script/ and README.md was changed.

Done. The test revision is complete and verified.

What was wrong. The accepted suite in test/IMDO.t.sol encoded the pre-revision hook. The revised hook caps every leg's fee at 2% of its own size, records the exact-output token fee as a claim that harvest() burns instead of burning it inside the swap, and no longer reverts harvest() when the treasury rejects ETH. Nine tests failed against the current code for those reasons. The earlier attempt at this task never produced a tree, so I redid the work from the accepted file.

What changed in the suite.

• The exact-output helper now checks that the token fee is a claim, that nothing burns inside the swap, and that a permissionless harvest burns exactly that claim. Four tests depended on it.
• The three-leg, mixed-mode, and three dust-leg tests now assert the documented per-leg cap: a crossing leg pays exactly 2% of its own output or input, a following leg carries the remainder, and a trailing leg leaves it uncollected.
• The treasury-rejects test now expects harvest() to succeed, skip the ETH leg, and keep the claim intact.
• New tests: a shared-origin bundler case in both swap modes, a mixed-mode catch-up below the cap collected exactly, and a harvest that burns the token claim while the ETH claim stays because the treasury rejects ETH.
• The split-sell fuzz test now checks each leg against a reference model of the README's bill formula. The invariant handler calls harvest() unguarded and asserts the two-leg independence on every call.

Results. All 51 tests pass offline, including 5 invariants over 48 runs with zero reverts. The file is forge fmt clean. Only test/IMDO.t.sol is modified.

Reported rather than asserted. .imd-findings.json holds one low-severity finding: the per-leg cap means a sell split across legs of one transaction can pay less than the cumulative bracket, with the exact wei amounts from the three-leg scenario. The README records it as an intended trade-off, so no proof file is attached.

launch.json has been re-derived from the revised tree. Only that file changed.

What changed in the manifest. The structural fields were already correct and stay as they were: hook IMDOFeeHook with constructor arguments $poolManager then $token, the same seven permissions, token IMD Offsets / IMDO / 18 decimals, native ETH pairing, LP fee 3000, tick spacing 60, initial sqrtPriceX96 of 2^96. The notes were rewritten where the revised source contradicted them:

• Pinned pool key. beforeInitialize now accepts only fee 3000 and tick spacing 60, not any of the three tiers. The notes say so and that 3000 is the only tier the hook initializes with.
• Per-leg hard cap. A leg never pays more than 2% of its own size, even when carrying catch-up for earlier legs under a shared tx.origin. The old text said catch-up could exceed 2% of a leg.
• Exact-output fee. The IMDO fee is now always an ERC-6909 claim, never taken inside afterSwap, and is burned by harvest. The old text described an immediate burn.
• Harvest independence. A treasury that rejects ETH leaves the ETH claim recorded while the IMDO claim still burns, and harvest no longer reverts. The old text said harvest could revert.
• Deploy script. Noted that the dry-run script attests the pinned key and that the factory must deploy and initialize in one transaction.

Checks run.

The initial price remains an explicit assumption carried over from the previous round, since neither the brief nor the deploy script sets one. The scratch test lives in test/scratch and is not part of the deliverable.

All five earlier findings are settled and I found nothing new, so .imd-findings.json holds an empty findings list plus a coverage row for each of the 12 entry points, all holds.

I ran the four attached proofs against the revised code on a real v4 PoolManager, and the repository's own suite; all pass (4 of 4 proofs, 51 of 51 tests, invariant run with 0 reverts).

• Shared-origin catch-up billing (medium): fixed. _bill now caps each leg at 20,000 ppm of its own size in both swap modes, and the shared-origin proof passes. The weaker retroactive catch-up on split sells is stated in the README as the requester's trade-off.
• Exact-output fee charged twice with a pay-first router (medium): fixed. The token fee is now always an ERC-6909 claim, with no take inside afterSwap, and the pay-first proof passes. harvest() burns the token claim even while the treasury rejects ETH.
• Pool squatting via beforeInitialize (low): fixed. The full launch key (fee 3000, tick spacing 60) is pinned and the squat proof passes. Initializing the exact key at a wrong price is still possible in a two-step deploy; the README limits that flow to dry runs and requires atomic deploy-and-initialize.
• Launch-block sells pay the 2% cap (low): settled by documentation. The code is unchanged and the rule is now an explicit row of the README bracket table, which was one of the two options I offered.
• Out-of-range liquidity inflating the reserve across a block (info): dropped. The author's dispute holds: the brief asks only for a one-block lag, and the README now states this exact scenario as residual exposure.

I checked the fix for new problems and found none: quote * rate - paid cannot underflow because each leg adds at most the outstanding amount to paid, and the mint and harvest deltas net to zero.

The repository suite only compiled without --via-ir here (solc 0.8.26 segfaulted on test/IMDO.t.sol with it); the proofs ran with --via-ir. The scratch copies and build output are removed, and no tracked file changed.