Approved workflow

The WHAL token and WhaleTaxHook are implemented, tested and committed on main (commit 83b6b90). forge build, forge test (55 passed, 0 failed) and forge fmt --check all pass with solc 0.8.26 pinned in foundry.toml, and the build has zero warnings.

What was delivered

• src/WhaleToken.sol: OpenZeppelin ERC-20, zero constructor arguments, 1,000,000,000 WHAL minted once to the deployer, no admin surface.
• src/WhaleTaxHook.sol: permissions are exactly beforeSwap, afterSwap and afterSwapReturnDelta (address bits 0x00C4), validated in the constructor. beforeSwap stores the pre-swap sqrt price in a transient slot keyed by PoolId. afterSwap computes the move with FullMath, clears the slot, applies 30 + floor(470 × min(m, 500) / 500) bps to the unspecified leg as a positive return delta, mints itself ERC-6909 claims, and emits WhaleTax. burnFees(currency) is permissionless and sends claims only to the dEaD address inside the hook's own unlock callback. Non-ETH pools get zero deltas and no other effect.
• src/HookFlags.sol and test/mocks/MockERC20.sol, which the protected floor tests import. I rehearsed both protected suites against the built creation code with the verifier's env vars and all 9 passed.
• script/DeployWhaleTax.s.sol: reference deploy with constants only; its deploy function is exercised in the tests.
• docs/abi/WhaleTaxHook.json and docs/abi/WhaleToken.json, plus a README covering assumptions, deployment parameters, operational responsibilities and the surfaces the adversarial review should attack.
• lib/ vendors forge-std, v4-core, solmate and OpenZeppelin as plain files with upstream commits recorded in lib/VENDORED.md. No submodules.

Test coverage highlights

• Launch rehearsal: initialize at the rehearsal price, one-sided WHAL seed, first buy into an ETH-less pool, sells, exact-out buys, burns.
• Exact-in and exact-out in both directions, dust, a tiny swap paying 30 bps, engineered 2.5% moves up and down paying 265 bps, and any move of 5% or more paying 500 bps (fuzzed).
• Two and three swaps in one transaction each using their own pre-swap price, a pool whose currency0 is not ETH, zero-liquidity jumps to both limits, direct callbacks from non-PoolManager addresses reverting, and a fuzzed sequence of swaps and burns asserting claims always equal unburned fees.

Things worth knowing

• The rehearsal price (tick 154,200, about 5,000,000 WHAL per ETH) and the 500M WHAL seed are placeholders. The manifest assignment fixes the real values.
• The move formula is asymmetric by definition, so a fall floors at 9,999 bps, and a rise past a 2^64 sqrt-price ratio reports a saturated value in the event. The fee is capped long before either matters, and both are documented.
• Forge 1.8 rewrites new inside tests into a cheatcode, so the constructor-rejection test uses raw CREATE through a helper rather than try/catch.

Created launch.json with matching contracts, constructor, permissions, and pool parameters. Initial price uses rehearsal tick 154,200.

Schema validation and offline forge build passed. All 65 tests passed, including protected checks and manifest integration. Only launch.json is deliverable; check artifacts remain under test/scratch/.

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.

The findings file is in place at the repository root, the harness excludes it from git by design, and no tracked file was modified. Review complete.

Result

I reviewed src/WhaleTaxHook.sol and its tests against the five attack surfaces in the assignment. The build and all 55 existing tests pass. I verified each candidate finding with throwaway Foundry tests in the gitignored test/scratch/ directory, then deleted them. Three findings survived, written to .imd-findings.json.

Medium: phantom pre-swap price after a zero-liquidity jump. The hook measures the move from whatever slot0 held when beforeSwap ran. After a swap runs through zero liquidity the price sits parked at the swap limit, and the next swap is measured from that artificial point. In the launch state the pool holds no ETH, so a 1 wei sell parks the price at the maximum for zero cost. The buyer who follows then pays 500 bps instead of 30 bps on a 0.001 ETH buy. The same state arises organically whenever a sell exceeds the ETH in the range. The existing test for the harmless sell stops one swap too early to see this. A fix changes the agreed measurement, so I flagged the scope decision rather than prescribing one.

Low: double rounding in priceMoveBps. Both branches round twice, so an exact-integer move is reported one bps low when the intermediate is not an integer. Pure calls with inputs 10 and 3 return 9099 instead of 9100. I reproduced it on chain by landing the pool exactly on two chosen limits, giving fee 408 bps where the spec says 409. The fuzz test masks this with a tolerance of one.

Info: claims sent to the hook by third parties are stranded. burnFees moves only accruedFees, not the actual claim balance, so a donated claim stays at the hook forever and the documented invariant no longer holds. No funds are at risk.

Areas checked and found correct: the FullMath bounds in both branches, the saturation threshold, the leg-selection direction against v4-core's Hooks.afterSwap, the int128 narrowing, fee never exceeding 5% of the leg, the transient slot across sequential swaps in one transaction, and the burn path's caller checks and delta neutrality.

Implemented the frontend, static export, deployment manifest, and validation documentation.

• Build/typecheck passed; 9 unit tests and 22 browser checks passed.
• Export hashes and live read-only buy simulation verified.
• Complete candidate Git bundle: 2.08 MB.
• No transactions broadcast.

Design documentation stays within the allowed scope.

The original .git is read-only, so the deliverable files are ready but uncommitted.