Implemented the contracts, vendored dependencies, tests, and deployment documentation.

Validation passed: build, offline rebuild, formatting, and 58 tests. Mainnet fork tests skipped because MAINNET_RPC_URL was unset.

One verifier issue remains: its generic initialization fixture conflicts with the required atomic hook binding. Details and validation limits are recorded in verification.md.

The manifest is written and verified. Only launch.json was added to the tree.

What launch.json says

• "kind": "univ4_hook" is the first field.
• Hook is MadHook with constructor arguments $poolManager, $token, $owner, $factory, matching the declaration order in src/MadHook.sol:79.
• Permissions are beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta, exactly what getHookPermissions returns at src/MadHook.sol:104.
• Token is MadToken, name "Mutually Assured Destruction", symbol MAD, 18 decimals, empty constructorArgs (no-argument constructor), totalSupply 1e27 base units, which is the 1,000,000,000 MAD the constructor mints once to msg.sender.
• Pool is the launch's own: pairedCurrency 0xa0df17b5ac76ababa36e1450e2cbcd18a620c845, fee 12500, tickSpacing 60, initialPrice 79228162514264337593543950336. The hook's beforeInitialize accepts exactly fee 12500 and tick spacing 60.
• Notes run 3,179 characters and describe freeze mechanics, the atomic one-time binding, the decaying FWA-side fee split (0.50% Playground claims, 0.50% NFT share sold for ETH in-swap, rest burned), direct PoolManager-to-receiver payout to the immutable receiver, the owner's limited settings, and the NFT, oracle and award flow.

Checks

• The JSON parses, the kind is first, the supply string equals 10^27, and the price is below 2^256.
• forge build compiles cleanly with only lint warnings.
• forge test with the verifier's fuzz seed: 58 tests passed, 0 failed, including the fuzz and invariant suites. I skipped only the mainnet fork suite, which needs live RPC and does not touch the manifest.

No placeholder gaps remain. The receiver is immutable in the hook's code, so no address had to be written by hand in the manifest.

Review complete. The findings file is written and validated, and nothing in the tracked tree was changed (findings file and scratch tests are gitignored).

Outcome

Four findings, one with a self-contained failing proof, in .imd-findings.json with coverage rows for all 33 entry points.

1. Medium, with proof at src/MadHook.sol:277. The NFT conversion's minimum-output check reverts the user's MAD swap. The official market hook keeps 1% of the ETH, so with a consistent limit/minimum pair, any market price inside the ~1% band above the owner's floor makes every MAD swap in both directions revert with Slippage() until the owner changes the bounds. The price-limit branch retains claims gracefully; only this branch halts trading. Dust-sized trades hit the same branch via proceeds == 0. Proof: test/scratch/ConvertSlippageDoS.t.sol, which fails on the current code with a wrapped Slippage() from inside beforeSwap.
2. Low at src/MadToken.sol:110. The frozen-sender check is skipped once the sender has non-7702 code, so a frozen counterfactual CREATE2 address escapes its freeze by deploying the contract. Reproduced with vm.etch after a real freeze.
3. Low at src/MadHook.sol:257. The same-swap burn is funded by the PoolManager's existing FWA reserves before a post-paying router settles. A 99%-fee buy with input above roughly those reserves reverts with ERC20InsufficientBalance from the manager. The ETH leg guards this case; the FWA burn leg does not. Reproduced against the project's harness.
4. Info at src/MadHook.sol:236. FWA-specified swaps that stop at the trader's price limit revert with PartialSpecifiedFill instead of filling partially. The README documents this; recorded for the judge.

Coverage of my area (Execution Trace, Periphery, First Principles)

• Traced both swap directions and both exact modes through v4's delta accounting; fee, shares and burn sum to zero and no callback charges twice.
• Traced the atomic launch binding, round closing, NFT buy/claim/assign/award, and the oracle ask/result/failure/supersede/fallback state machine. All hold as specified.
• Periphery: IFWAV2 struct layouts and status codes match the verified FWA V2 ABI; IIntake.requestWithFailure and the callback signatures match the oracle reference; the question text matches the brief; OracleQuestion and OracleAttestation match the reference copies.
• Existing suite passes (58 tests), including oracle delivery under the 200k stipend.

Not reached

• Fork tests need MAINNET_RPC_URL, so live FWATokenHook behavior toward a hook as swap sender and the real PoolManager's FWA/ETH reserves are unverified.
• Whether IMD's production factory deploys the token, the hook and the pool in one transaction could not be checked offline. The binding design reverts the launch if it does not, as the README states.

Review complete. The findings file is written and verified against the tree, and no tracked source file was changed.

Outcome: 5 findings in .imd-findings.json, with coverage rows for all 33 listed entry points (27 hold, 6 carry findings, none unreached).

Findings

1. High. Exact-output MAD buys pay about half the launch tax. In afterSwap, when FWA is the unspecified input, the fee is computed on the pool-side amount and charged on top, so the effective rate is rate/(1+rate). At open that is 49.7% instead of 99%. Buying 50 MAD by exact output cost 100.76 FWA with a 50.13 FWA fee, while 100 FWA by exact input bought 0.99 MAD. The exact-output-FWA path in beforeSwap grosses up correctly, so this is a one-sided asymmetry. The attached proof test fails on current code and passes once afterSwap grosses up the same way.

2. Medium. Permissionless closeRound with no minimum round length. With two kept NFTs, a contract that freezes a 100-wei wallet (cost 1 wei) and calls closeRound in one transaction becomes leader of a one-block round and gets the second NFT assigned. Verified with a scratch test.

3. Medium. Conversion revert path blocks all MAD trading. When the ETH/FWA price sits one unit below the owner's sqrt limit, the sale sells dust for 0 ETH and reverts with Slippage, reverting the user's swap. An attacker pinned the price with one swap and every MAD buy and sell then reverted. The at-or-above-limit branch silently retains claims, so the two edges are treated asymmetrically.

4. Low, trust assumption. Owner setters redirect every reward flow. Signer rotation lets the owner author winners, a fake FWA V2 drains the ETH budget through buy(), and an owner pool plus a 1-wei minimum sells all NFT FWA claims to the owner. The spec permits these setters and the oracle-consumer reference shows an owner-set signer, so this is documented, not reported as a bypass.

5. Low. Counterfactual wallets escape freeze. A CREATE2 address can be frozen while empty, then deployed and emptied in the same block because the send-time check exempts addresses with code. Verified with a scratch test; the freezer's 1% payment is wasted and the target keeps the 0.5% remainder.

Not reached in depth: ERC-6909 claim balances held inside the PoolManager let a pre-funded frozen wallet still sell without any ERC20 transfer. I did not substantiate it with a test and left it out. Fork behavior, FWA transfer rules for the PoolManager-to-receiver payout, and the oracle body's explicit evidence field were outside my area and only read, not tested.

The review is complete. The findings file is written, the tree is untouched apart from the ignored findings file and the scratch proofs, and both high-severity proofs fail on the current code and pass under a candidate fix.

Findings written to .imd-findings.json (4 findings, 35 coverage rows, none unreached):

1. High: exact-output MAD buys pay about half the launch tax. The unspecified-FWA buy branch in afterSwap charges r of the pool-side base and adds it as a surcharge, so the effective rate is r/(1+r). At open the buyer pays 49.7% instead of 99%. The proof shows the same 2.015 FWA yields 1 MAD via exact-output but 0.0199 MAD via exact-input. The README documents this convention, but it contradicts the brief's single schedule and gives sophisticated buyers a dominant path that also shrinks the Playground and NFT shares.

2. High: anyone can halt all MAD trading. The in-swap NFT conversion sells up to the owner's price limit. If the ETH/FWA market sits one sqrt-price unit below the limit, the bounded sale fills 1 wei of FWA for 0 ETH and the Slippage check reverts the user's swap, bubbled through the PoolManager. A griefer parks the price there with one exact-input sell using a price limit of limit - 1, paying only the market's 1% fee on a tiny amount, and can re-park after every owner adjustment. The proof reproduces the revert and the candidate fix (tolerant rounding plus a pre-swap price check, never reverting the trade) makes it pass.

3. Medium: a 1-wei freeze plus an immediate closeRound captures each kept NFT. Rounds have no minimum length or spend, so the first freezer after each close can lead and close in the same block, draining a queue of kept NFTs one per block. This follows the brief's literal closure rule, so the fix is flagged as a scope decision.

4. Low: a frozen counterfactual CREATE2 address escapes by deploying code, because the frozen check in _update is skipped once the sender has code. The freezer's cost is wasted and the target nets half of it.

Coverage notes. All 31 listed entry points have rows. The oracle callbacks, award and fallback paths, claim budgets, payout separation, binding and round-boundary logic traced clean against the Economic Security, Invariant and Flow Gap guides. Not reproduced in this budget: a proof test for finding 3 (it needs the FWA V2 mock flow), and any live-integration behavior of the real FWA token and market hook, which the mocks only model.

Added adversarial, fuzz, and invariant tests under test/.

• forge build passed.
• Seeded suite: 95 passed, 0 failed, optional fork suite skipped.
• Separate mainnet fork run: 2 passed.
• No reproducible implementation defects found.

NFT acquisition and oracle delivery remain mock-tested; live swap integration passed.

The review is complete. The findings file .imd-findings.json holds 8 findings and a 35-row coverage record, and the project's own 95 tests pass as a baseline. No repository file outside test/scratch/ was changed.

What I kept, after reproducing each lead against the code

• High, exact-output MAD buys pay half the launch tax. The afterSwap branch at src/MadHook.sol:238 charges floor(base × r) on the pool-side FWA and adds it on top, so the trader-facing rate is r/(1+r). At open the same MAD that costs 100 FWA by exact input costs 1.99 FWA by exact output. Three specialists reported this; merged into one. Proof attached, fails on current code.
• High, anyone can halt MAD trading. The post-sale check at src/MadHook.sol:277 reverts the trader's whole swap when the NFT-share sale fills a rounding-sized amount. One FWA sell parking the ETH/FWA market one unit under the owner's limit makes every later MAD swap revert, and a 300-wei buy reverts on its own. Four specialists reported variants; merged. Proof attached, fails with the wrapped Slippage error.
• Medium, 1-wei freeze snipes each kept NFT. With no minimum round length, freeze on a 100-wei wallet plus closeRound in one transaction wins the oldest NFT. Reproduced end to end through award on the repo harness. Needs a scope decision since the code follows the brief's wording.
• Low, three items. A frozen counterfactual address escapes by deploying code. The same-swap burn is funded from the manager's existing FWA reserves, so large early buys revert under post-settling routers. The owner setters are a full trust boundary, with setFwaV2 able to send the whole NFT budget to an owner contract on the next public buy.
• Info, two items. FWA-specified swaps revert instead of partially filling at a price limit, as documented. Hook binding requires the token constructor and pool initialization in one transaction, which the brief asserts but the factory structure would have to confirm.

Dropped or declined

Nothing from the specialists failed to reproduce. The slither and aderyn lines were all either the above root causes, intentional patterns, or benign (the divide-before-multiply is the exact 0.50% share split; the "locked ether" is the NFT budget that buy() spends).

Coverage

All 33 entry points are answered, 25 hold and 8 point at findings, plus two invariant rows for the equal-share accounting and the manifest and contract sizes. The fork tests were not run, since no RPC is configured, so live FWA and Intake behavior rests on the mocks and the references.

I updated launch.json, and it still matches the code: the hook's constructor arguments, its permissions, and the token's constructor and supply are unchanged. forge build succeeds and forge test with the verifier's fuzz seed passes 68 tests, skips 1, and fails none. No other file changed. The manifest was checked by reading it against the code; nothing here runs the schema itself.

What the manifest says, checked against the source:

• Hook: MadHook(IPoolManager, IMadToken, address owner, address factory) is written as ["$poolManager", "$token", "$owner", "$factory"]. Its permissions are beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta, which is exactly what getHookPermissions returns.
• Token: MadToken takes no constructor arguments and mints 1000000000000000000000000000 (1 billion MAD at 18 decimals) to msg.sender, the launch factory.
• Pool: FWA 0xa0df…c845, fee 12500, tick spacing 60 and the one-to-one starting price, all as given. The hook's beforeInitialize only accepts fee 12500 and tick spacing 60, so these agree.

The only edit is to notes, which now describe the hook changes accepted since the last version:

• Round limits: closeRound() only closes a round that is at least 7,200 blocks long and whose leader has spent at least 1,000 MAD.
• Deferred burn: when the PoolManager doesn't hold enough FWA to burn the fee during the swap, the amount is kept as a burn-only claim and anyone can burn it later with flushBurn().
• Exact-output buys: the fee is grossed up so these pay the same share as every other swap type.
• NFT-budget sale: the sale of the NFT share for ETH is checked before it runs and can never make a MAD swap fail.
• Rewards contract: MadRewards is deployed by the hook.

notes is now 3,541 characters, under the 4,000 cap.

The implementation was revised after my previous round, and five of my tests broke against it. I updated them, added a new suite for the changed code, and reported three issues instead of writing tests that treat them as correct. The full forge test run with the supplied seed passes: 109 passed, 0 failed, and the optional mainnet fork suite skipped because no RPC URL is set.

Repaired tests (they failed because the rules changed, not because of bugs):

• Round closing: closeRound now also needs a minimum round length and a minimum spend by the leader. The question-text test and the repurchase test now read the real block window, and the rewards invariant setup rolls forward far enough to close a round.
• Conversion bounds: the setter now rejects a minimum price higher than the price limit allows, so my conversion handler sets the strictest minimum it will accept.

New suite, test/MadBurnDeferral.t.sol:

• Deferred burns: a random-sequence (invariant) test that makes buys too large for the PoolManager's FWA balance during the launch decay, mixed with sells, payouts and flushBurn. Over 256 sequences (15,360 calls, no reverts) it checks that the deferred-burn claim:

  • stays separate from the Playground and NFT budgets;
  • is never paid out or sold;
  • is destroyed exactly once.

  It also checks that every claim is backed by FWA held in the PoolManager and that FWA supply is conserved.

• Exact-output fee: a 1,000-run fuzz test of exact-output buys and sells. It checks the fee is exactly ceil(rate × gross FWA paid), the smallest fee that covers the schedule, checked against what the trader actually paid or received. There is also one fixed 1% rounding case.

Reported in .imd-findings.json:

• Medium: closeRound now requires rounds of at least 7,200 blocks (MIN_ROUND_BLOCKS) and a leader spend of at least 1,000 MAD (MIN_LEADER_SPEND). The brief only requires an unassigned NFT and a round leader. These limits change when and to whom NFTs go, so the requester should confirm them. My tests do not treat them as correct; they only move far enough ahead to meet them.
• Low: the owner's minimum ETH-per-FWA price (minEthPerFwaX128) is no longer checked against what the NFT-share sale actually returns. I confirmed this with a market hook that takes 50%: 1 FWA sold for 0.4995 ETH against a configured minimum of 0.998, and nothing reverted.
• Info: when the PoolManager holds too little FWA, the burn above 1% is not done in the same swap as the brief asks. It is kept as a claim and burned later by anyone calling flushBurn(). The new suite shows the accounting stays correct.

The low finding has a written reproduction but no standalone proof file, since proofs are only required for critical and high findings.

The fork tests have not been run against the revised hook, so live checks on real FWA are still owed. test/TESTING.md now records this, along with the new suite and the findings. All changes are under test/, apart from .imd-findings.json in the repository root.

The review is complete and written to .imd-findings.json with 4 findings and a 37-row coverage record.

Settlement of my earlier findings

• Exact-output buy tax (high): fixed. My attached proof now passes on the revised code. Buying the same MAD by exact output costs 100.0002 FWA against 100 FWA by exact input at the 99% opening rate.
• Conversion halts trading (high): fixed. I re-ran the griefing sequence. With the ETH/FWA market parked one unit under the owner's limit, buys and sells in both modes execute and the NFT claims wait. A 300-wei buy also executes.
• 1-wei round capture (medium): fixed. A dust freeze plus closeRound now reverts, a 999 MAD leader cannot close, and a leader above 1,000 MAD closes once the round spans 7,200 blocks.
• Counterfactual freeze escape (low): fixed. Etching code at a frozen address no longer lets it transfer until the deadline passes.
• Large buy reverts at open (low): fixed. A buy of three times the manager's FWA now executes, defers the burn as a separate claim, and flushBurn burns exactly that amount once.
• Owner setters, partial fills, transient binding (disputed): I accept the author's reasoning on all three. The brief grants the setters, v4 cannot refund a specified-side delta in afterSwap, and the brief itself requires the atomic binding. The owner powers stay in the file as an info trust note only.

What remains in the file

• Low: the conversion minimum is now compared only with the price at the sqrt limit. With the official market's 1% fee, a sale at a minimum equal to the bound price returns 0.989 ETH per FWA against a stated 0.998 floor, and nothing skips or reverts. Fix by validating the pair net of the market fee or by documenting the parameter as a consistency check.
• Info: the new round floors deviate from the brief's wording and need the requester's confirmation. The deferred burn path needs acknowledgement. The owner trust boundary is documented.

The full suite passes with 110 tests, and all three contracts are within the runtime and initcode size limits. Scratch files were removed and no repository files were changed.