Approved workflow

Done. The ETHF token and ETHOnlyFeeHook are implemented, tested against a real v4-core PoolManager, documented, and committed with all dependencies vendored as plain files.

Delivered (commit 4a6d52d, 150 tracked files, no submodules):

• src/ETHF.sol: OpenZeppelin ERC-20, 1,000,000,000 supply minted once to the deployer, no constructor args, no admin.
• src/ETHOnlyFeeHook.sol: extends the vendored v4-periphery BaseHook, constructor takes only the PoolManager, permissions exactly beforeSwap/afterSwap/beforeSwapReturnDelta/afterSwapReturnDelta (address bits 0x00CC). Constant 50 bps fee in ETH via return deltas, settled as ERC-6909 claims, permissionless donateFees to in-range LPs, PartialFill/SwapTooSmall/NoLiquidity/NothingToDonate reverts, unlockCallback gated by a transient flag.
• src/HookFlags.sol and test/mocks/MockERC20.sol at the paths the protected admission tests import.
• script/Deploy.s.sol with salt mining and a deploy function driven by constants and arguments, no env reads.
• docs/abi/ETHF.json and docs/abi/ETHOnlyFeeHook.json.
• README.md covering fee rules, reverts, assumptions, deployment parameters, operational responsibilities, and vendored dependency provenance.

Verification results

Tests cover the launch rehearsal (one-sided ETHF seed below the opening price, first buy into an ETH-less pool, then a sell), all four fee paths with the swapper's ETH change equal to the pool delta minus exactly the fee, partial fills, dust swaps, donation fee-growth delta, LP collection, and the claims invariant.

Two things worth flagging

• The invariant handler originally succeeded in far fewer swaps than it attempted because its bounds drained the 1:1 test pools. An afterInvariant guard caught this. The seeds and bounds are now scaled to depth, and the guard requires at least half of attempts to land.
• v4-periphery removed BaseHook from main in February 2026. The vendored copy is from the last commit that shipped it, which is noted in the README for the reviewer.

The launch.json manifest is left to its own assignment. The independent review should focus on the delta accounting in the two swap callbacks and the donateFees unlock path.

Done. launch.json is written at the repository root and is the only change to the tree.

What it declares

• Kind univ4_hook as the first key, hook contract ETHOnlyFeeHook with the single constructor argument, the Sepolia PoolManager address.
• Permissions beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta. I checked these directly against getHookPermissions in src/ETHOnlyFeeHook.sol:89, where exactly those four flags are true and the other ten are false. That set is flags 0x00CC, matching the deploy script and README.
• Token ETHF, name "ETH Fee", symbol ETHF, 18 decimals, matching src/ETHF.sol.
• Pool: paired currency native ETH (zero address), fee 3000, tick spacing 60, initialPrice as the decimal sqrtPriceX96 for tick 138180. That is the opening tick used by the accepted launch rehearsal tests, about 1,001,800 ETHF per ETH. I computed the value with TickMath in a scratch test and confirmed it round-trips to the same tick.
• Notes describe the fee mechanics, claims settlement, donation path, token, pool and toolchain, and state that supply, allocations, ownership, chain and authorization come from the launch policy and attestation rather than this file.

Checks run

• forge build and forge test: 46 tests passed, 0 failed.
• Schema validation with the local jsonschema package against the canonical LaunchManifest schema: zero errors. First key is kind, notes length is 3129 characters, initialPrice is below 2^256 and below 2^160.
• git status shows only launch.json as new. Scratch files live in the gitignored test/scratch/ directory.

One thing to note for the reviewer: the workflow text never states a numeric opening price, so the manifest takes it from the accepted test fixture's opening tick. If the factory is meant to open at a different price, that is a review finding against the fixture rather than a defect the manifest can resolve on its own.

Review complete. Findings are written to .imd-findings.json; no repository source or test file was changed.

Outcome: the swap delta accounting is correct in all four paths. I found no blocking defect. One medium design observation and one informational note are recorded.

What I verified, against the vendored v4-core Hooks and Pool libraries and by running scratch tests in a temporary copy of the repo:

• Delta sign and amount, all four paths. The specified/unspecified orientation in _ethIsSpecified matches how the Hooks library builds the hook delta, so the hook is credited exactly the fee in ETH in every case and the swapper's ETH change equals the pool delta plus or minus exactly the fee. This held with the pool's protocol fee set to the maximum in both directions, which does not disturb the specified component the PartialFill check relies on.
• Exact-output sell. The pool pays amount + fee, the seller receives exactly amount, and the router-visible delta is amount. A sell that needs more ETH than the pool holds reverts PartialFill rather than under-paying. At the pool's ETH boundary the last few wei cannot be filled due to pool rounding, so it reverts PartialFill, which is the specified behaviour.
• Rounding. feeOn is a true ceiling and never exceeds the amount, so eth - fee cannot underflow. A 1 wei buy reverts SwapTooSmall, 2 wei swaps 1. Dust exact-input sells either revert SwapTooSmall or leave the seller a positive amount. Dust exact-output buys pay a 1 wei fee on a 2 wei pool amount, which is the ceiling rule as specified.
• First swap into the ETH-less pool. Exact-input and exact-output buys both work with the fee minted as claims backed by the buyer's ETH. A first sell reverts PartialFill or SwapTooSmall as appropriate.
• donateFees unlock path. Burn and donate net to zero inside the unlock. The transient flag refuses a direct call from the manager's address and a callback driven from a foreign unlock. A nested unlock is impossible because the manager reverts AlreadyUnlocked. Per-pool accrual isolation holds across two ETH pools.

Findings recorded, ranked:

1. Medium, non-blocking design observation. Anyone can JIT-capture the whole donate pot. With 0.55 ETH accrued, adding 1e26 liquidity in a single 60-tick range around the current tick, calling donateFees, and removing it in one transaction yielded the attacker 549450549450549449 wei and cost 1 wei of ETHF. The resident LPs got 0.1 percent. This matches the approved "anyone may call, donate to in-range LPs" design, so it is flagged as a scope decision, not a defect in the implementation.
2. Info. ERC-6909 ETH claims a third party transfers to the hook are stuck forever, because unlockCallback burns only accrued[poolId]. This makes the documented identity "claims held == collected minus donated" hold only for hook-originated claims. No fee accounting is affected.

Implemented source, lockfile, static export, deployment manifest, and documentation.

Build/typecheck, 5 unit tests, and 27 browser checks passed. Export: 536 KB. ABI and asset hashes verified. No real transactions sent; live sell-quote reversion is documented.

Validation report · Design

Commit blocked: .git is read-only. Files remain ready for collection. Design documentation is under docs/ to respect the write scope.