Implemented Crown, the immutable game hook, vendored dependencies, and deployment/security documentation.

Checks passed:

• forge build
• forge test: 59 tests, including 8,192 invariant calls
• forge fmt --check

The README documents deployment parameters, fee rounding, claim deadlines, and the fresh-PoolManager ETH-credit fallback.

I found no permission defects I could back with a reproduction. .imd-findings.json has an empty findings list and a coverage record with one row for each of the 11 entry points, all marked holds, plus a 12th row for the no-admin rule. I changed no files. The existing suite passes (59 tests, 0 failed). I didn't write any new test proofs, because I had nothing to prove.

What I checked under the access control, trust gap and asymmetry guides:

• No privileged roles: CrownHook has no owner, setters, pause, upgrade path or withdraw function. Crown is a standard OpenZeppelin ERC20 that mints its fixed supply once, in the constructor. ETH leaves the hook only through claim.
• Pool callbacks: beforeInitialize, beforeSwap, afterSwap, unlockCallback and receive all reject any caller except the PoolManager. The swap callbacks also reject any pool other than CROWN/ETH at the 12500 fee and 60 tick spacing.
• quoteSwap: only the hook itself can call it, and every path reverts. So nobody can use it to swap without paying the fee. Because the hook itself starts the preview swap, Uniswap v4 skips the hook's own callbacks during it, so there is no recursion.
• claim: only that day's king can claim, and only after the day ends and within 7 days. The pot is marked paid before the ETH is sent, a reentrancy guard covers it, and a failed send undoes the whole claim. The 7-day claim window and the rollover rule line up, so neither side gets an extra day.
• rollover and redeemFees: anyone can call them, but neither pays the caller. rollover moves an expired or kingless pot into today's pot. redeemFees only turns the hook's own pending credits at the PoolManager into ETH held by the hook.
• Who becomes king: buys crown tx.origin with a strictly larger amount; sells never crown anyone.

Two things to note, neither of which is a defect against the spec:

• Pool setup: beforeInitialize checks the pool settings but not which address initializes the pool. That's safe only because the factory deploys the hook and initializes the pool in the same transaction.
• Smart-wallet buyers: since the king is tx.origin, a buy sent through a smart-contract wallet (for example an ERC-4337 bundler) crowns whoever submitted the transaction, not the wallet's owner. The spec requires tx.origin, so this is a design choice.

I didn't follow up these static-analysis warnings:

• "Strict equality" in _redeem and _redeemAvailable: these are early-exit checks for a zero amount, and I saw no exploit from them.
• Ignored unlock() return value: I didn't trace any harm from it.

I didn't investigate fee rounding or price manipulation, which belong to the other three reviewers.

Created launch.json with matching contracts, constructor placeholders, permissions, pool settings, and implementation notes.

forge build passed. All 59 tests passed with the required fuzz seed. Only the manifest is submitted.

I found no math defects in CROWN, so .imd-findings.json has an empty findings list. Its coverage record answers all 11 entry points as holds, plus one row for the pot-accounting invariant.

How I checked it:

• Fee math, worked by hand. Every path charges floor(2% of the gross ETH):
  • Exact-input buy: keeps floor(req/50) on a full fill and charges floor(x/49) on a partial fill.
  • Exact-output sell: asks the pool for req + floor(req/49), and the hook's fee always adds back to exactly that amount.
  • The other two directions compute the fee after the swap.
  • The "fee equals 2% of gross" check inside afterSwap holds for every amount, so no honest swap reverts on it.
  • At a partial fill the trader can never be charged on ETH that didn't trade.
• Fee math, fuzzed against the real pool. I wrote a throwaway test: 3,000 random swaps across all four directions, from 1 wei to 90,000 ETH. It included swaps cut short by a price limit and a fresh pool seeded with tokens only, where the fee is held as a credit and paid out later. Every swap passed: the fee was exactly floor(2% of gross), the trader paid or received exactly the pool amount plus or minus the fee, and the hook's ETH plus pending credit plus amounts paid always equalled the fees collected. I deleted the test afterwards, so no files changed.
• Boundaries.
  • The claim window (1 to 7 days after the day) and the rollover window (more than 7) meet with no gap or overlap.
  • A day with no king can roll over as soon as it ends.
  • The crown needs a strictly larger buy, measured after the fee, so a tie keeps the earlier buyer.
  • Swap amounts are limited to the int128 range before any negation.
  • The fee can never push the swap amount past zero.
• Static-analysis leads. The strict-equality checks on pendingFees and the ignored return value of unlock() are harmless. The timestamp warnings are the intended day calculation.

Things I looked at but didn't report:

• Dust. A buy of 49 wei or less pays no fee but can still be crowned king, which on a sell-only day lets it win that day's pot for gas alone. The existing tests show this is deliberate and the brief allows it (any buy counts).
• Rolled-over days show claimed = true. dayInfo reports a rolled-over pot as claimed even though the king was never paid. This is documented in the code and isn't a math issue.
• Buying and selling back in one transaction. This is cheap, because the trader wins back their own 4% in hook fees. It is still allowed under the "single biggest buy" rule and outside my area.

What I didn't do: I covered all three assigned guides (Math Precision, Boundary, Numerical Gap) in full. The token's three functions are standard OpenZeppelin ERC-20 with no math of their own, so I didn't trace them deeply. A clean review doesn't prove the code has no defects.

git status wouldn't run because of a repository-ownership warning, so I couldn't use it to confirm the tree is unchanged. I didn't change the git config to get around it.

The review is complete and the findings file is in place. No tracked files were changed; only the ignored findings file and the scratch test exist.

Outcome

I audited the CROWN hook against the Economic Security, Invariant and Flow Gap guides and found one substantiated defect. The rest of the economic model holds. The result is written to .imd-findings.json with one finding and 15 coverage rows covering all 11 listed entry points plus four invariants I checked.

The finding (medium): the king rule can be satisfied with ETH that never leaves the buyer. The crown is awarded on the ETH the AMM debited for the buy, in CrownHook.afterSwap at src/CrownHook.sol:167. Liquidity provision is unrestricted, so a last-second buyer can add a huge just-in-time position just below the price, buy through it, and remove it in the same block. The ETH flows into their own position and comes back, with almost all of the LP fee. The only money that leaves is the 2% hook fee, which lands in the pot they now win. Measured on the repository fixture, dethroning a genuine 10 ETH buyer cost the attacker 0.23 ETH, and after claiming they ended 0.19 ETH richer while also holding slightly more CROWN. The proof test under test/scratch/KingCapture.t.sol fails on the current code for this reason and is self-contained. I also measured the plain buy-then-sell-back variant. In this thin fixture it loses 0.07 ETH, but it turns profitable once the existing pot exceeds roughly 2.5% to 3% of the buy needed to top the king, because both 2% fees return to the king.

What holds. I traced the fee math for all four swap modes including partial fills at a price limit, and the preview-then-charge design is consistent with the 2% check in afterSwap. The claim and rollover windows are disjoint with no gap. The three accounting invariants hold: hook balance plus pending credits plus paid equals collected, pots plus paid equals collected, and the PoolManager stays solvent for the hook's claims and for sellers' withdrawals after the mid-swap redemption. The Slither leads were benign strict-equality and timestamp uses. The full repository suite passes.

Not reached in depth. Access control and manifest concerns, including the tx.origin identity rule under account-abstraction bundlers, belong to the other specialists and are documented in the README. I did not attempt gas-exhaustion analysis of the reverting preview beyond confirming it cannot be used by third parties.

The review is complete. The findings file is valid JSON, the scratch directory is gone, and git status --porcelain is empty, so the tree contains only the required output.

Outcome: no defects of low severity or above in the control-flow area. The Execution Trace, Periphery and First Principles passes all came back clean. Two informational notes are recorded in .imd-findings.json, alongside a coverage row for every listed entry point plus the invariants I checked.

What I verified

• Fee and delta flow in all four swap modes. I traced the hook against the vendored v4 Hooks.beforeSwap and Hooks.afterSwap code. In every mode the hook's delta is (+fee ETH, 0), the in-callback take or mint nets it to zero, and the fee equals floor(gross/50) for both full and limit-bound fills.
• Reverting preview. The self-call to quoteSwap is skipped by v4's hook-as-caller bypass, always reverts, and leaves no state. I argued from the capped-step math in SwapMath that the preview's consumed ETH equals the real swap's, then fuzzed it: 6,000 runs over a pool with liquidity gaps and random price limits produced no SettlementMismatch.
• Adversarial unlock flows. A caller that drains the manager's ETH inside its own unlock and then buys forces the mint path safely. A king claiming from inside such an unlock reverts and the pot stays claimable. A redeemFees call inside a drained foreign unlock is a harmless no-op.
• Claim and rollover windows. The claim window is days d+1 through d+7 inclusive, and rollover opens at d+8, with no gap or overlap. State is finalized before the ETH send, and a failed send reverts everything including redemption.
• Periphery. HookFlags bit positions and the 14-bit mask match v4, the 0x20cc flag set matches getHookPermissions, and the constructor re-validates the address.

Informational notes recorded

1. beforeInitialize admits only LP fee 12500 and tick spacing 60. The manifest, which does not exist yet, must state exactly those or the factory's initialize reverts in the protected floor test.
2. A sell-only day can be rolled over the second after it ends rather than after seven days. The brief's wording is ambiguous and the README documents this reading, so it is flagged for the author to confirm, not as a defect.

Not reached: nothing in the assigned area was left unexamined. The repository suite passes in full, 59 tests including the invariant runs.

Added differential, adversarial, and invariant tests under test/, covering swap fees, rounding ties, failed settlement, claims, rollovers, and pot conservation.

Verified offline with the required seed: forge build and forge test pass—73 tests, zero failures or skips. The new invariant campaign checks 20,480 random actions.

No implementation defects found in these checks.

I found nothing blocking in Crown/CrownHook. I kept one low-severity finding, and I did not run its reproduction: I traced it by hand. The results are in .imd-findings.json, which is valid JSON. The existing suite passes (73 tests, 0 failures, including the invariant runs).

The finding I kept (low): the specialist's just-in-time liquidity issue, src/CrownHook.sol:167. The crown goes to whoever's single buy debits the most ETH, and the code doesn't check who ends up holding that ETH. Anyone can add liquidity to the pool, so a last-second buyer can do this in one transaction:

1. Add a huge, narrow position just below the current price.
2. Buy through it, which records a buy bigger than the current king's.
3. Remove the position, which returns almost all of their ETH and the LP fee.

Their real cost is roughly the 2% hook fee, which goes into the pot they then claim, plus gas. The specialist rated this medium. I lowered it to low because the code follows the brief's literal rule ("pays the most ETH into the pool, measured after the fee"). It's a design weakness, not a broken stated guarantee. Fixing it means a design choice for the author, such as locking liquidity positions for the day.

The specialist's test for this (test/scratch/KingCapture.t.sol) isn't in the tree. I didn't write my own, so this finding has no attached proof.

What I dropped:

• Kingless days roll over right after midnight, not after 7 days. The README documents this, it matches the brief's "once it has ended", and nobody is owed a kingless pot, so there's no loss.
• The hook accepts only fee 12500 and tick spacing 60. launch.json already states exactly those values, so this isn't a defect.
• Slither's strict-equality and unused-return warnings on the fee redemption code: I checked both and they're harmless.

Coverage: all 11 entry points have a row. Ten hold, and afterSwap points to the finding. I checked the fee accounting for all four swap types and the claim and rollover guards, including that the pot stays claimable when the ETH transfer fails.