302f7a37-77d2-4791-8b67-ea232af4e2e8IMD JOB

Recorded one **medium-severity** finding in [.imd-findings.json](.imd-findings.json): partial exact-output swaps can burn the trader’s existing output tokens while delivering nothing. Reproduced locally using the manifest’s pool parameters. Reviewed source, tests, and configuration remain unchanged.

Done. The manifest is written and validated, and only launch.json is changed. **What launch.json declares** - **Kind:** the first field is `"kind": "univ4_hook"`. - **Hook:** `BurnShareHook` with one constructor argument, the Sepolia PoolManager at `0xE03A1074c86CFeDd5C142C4F04F1a1536e203543`. Permissions are `beforeSwap` and `beforeSwapReturnDelta`, exactly the two flags the implementation returns from `getHookPermissions` (flags 0x88). - **Token:** `V4BurnToken`, name `v4-burn`, symbol `V4BURN`, 18 decimals, no constructor arguments. - **Pool:** paired with native ETH (address zero), fee 3000, tick spacing 60, initial price `79228162514264337593543950336000`. That is sqrtPriceX96 for exactly 1,000,000 V4BURN per ETH, the same fee and spacing the repository tests and protected suite use. - **Notes:** 3544 characters, under the 4000 cap. They describe the hook mechanics, token, pool, toolchain and checks. No supply, allocation, owner or chain policy fields are present. **Verification** - The manifest validates against the canonical JSON Schema with Python jsonschema, including the refinement that initialPrice is below 2^256 and fits uint160. - The PoolManager address matches the Uniswap v4 deployments page and returns runtime code on Sepolia over a public RPC. The operator's keyed RPC does not serve Sepolia. - Both protected suites pass locally against the compiled creation code with flags 136, the Sepolia PoolManager and decimals 18. A scratch test initialised an ETH/V4BURN pool with the hook at the declared price, fee and tick spacing. - `forge build` succeeds and `forge test` passes all 40 tests, 39 existing plus my scratch test. Git status shows launch.json as the only change. **Judgment call to flag:** the brief and DEPLOYMENT.md leave the pool pair and price to later stages, so I chose native ETH as the paired currency and a 1,000,000 tokens per ETH start price. If the launch policy expects a different pair or price, only the pool block needs editing.

Done. The fresh clone of the commit builds, passes all 39 tests, and passes `forge fmt --check` offline. The single unstaged file is a sample `.env` that came with the vendored v4-core repo; it is gitignored and untouched, as the rules require. ## What was delivered (commit `2f2c601` on `main`) **Contracts** in `src/` - `BurnShareHook`: Uniswap v4 hook enabling only `beforeSwap` and `beforeSwapReturnDelta` (flags `0x88`). It returns a positive specified delta of 1% of `amountSpecified`, so the trader pays or receives exactly what they asked for, and the hook is credited the 1%. It takes that share out immediately and burns it: via the token's own `burn` when available (supply goes down), otherwise to the dead address, and ETH to the dead address. If the PoolManager cannot release the share mid-swap (fresh one-sided pool), the share is held as an ERC-6909 claim and anyone can call `burnPending`. No owner, no setters, no pause, no upgrade. - `V4BurnToken`: zero-argument constructor, mints exactly 10^27 minor units to `msg.sender`, 18 decimals, `ERC20Burnable`, no mint path. - `HookFlags` and `HookMiner` libraries, used by the protected suite, the tests and the deploy script. **Tests** (39 passing): swap accounting in both directions and both swap kinds compared against a hook-less reference pool, fuzzed amounts, dust rounding, native ETH, supply-reducing burns, no-op `burn` fallback, deferred burns for ERC-20 and ETH, reentrancy of `burnPending`, caller checks on every callback, constructor address validation, and the token's supply, metadata and absence of admin entry points. The protected floor suite was also run in scratch against the real creation code with the Sepolia PoolManager as constructor argument and passed, and a wrong-flag control failed as expected. **Scripts, ABI and docs**: `script/DeployBurnShareHook.s.sol` (mines the CREATE2 salt, guards the chain, simulated successfully against Sepolia without broadcasting) and `script/DeployV4BurnToken.s.sol`; `docs/abi/BurnShareHook.json` and `docs/abi/V4BurnToken.json`; `README.md`, `docs/DEPLOYMENT.md` (manifest values, constructor args, compiler settings, operator responsibilities) and `docs/SECURITY.md` (assumptions, threat notes, measured gas overhead, checklist results). **Dependencies** vendored as plain files, no submodules: forge-std 1.16.2, v4-core 1.0.2, solmate 6.8.0, OpenZeppelin 5.7.0. ## Points for the manifest and review stages - Hook flags are `136` (`0x88`); the constructor argument is the Sepolia PoolManager `0xE03A1074c86CFeDd5C142C4F04F1a1536e203543`, which I confirmed has code on Sepolia today. The manifest assignment should re-check it against the Uniswap docs. - The share is 1% of the requested amount, not the filled amount, so a partial fill at a price limit still burns 1% of the request. This is inherent to charging the specified currency and is documented. - The verifier needs solc 0.8.26 in its local Foundry cache; the first build here downloaded it, and nothing else needs the network.