Implemented the 12500 pool-fee policy change, preserved the reviewed game logic, and built the frontend in web/dist/.

Validation passed: forge build, all 158 Solidity tests, forge fmt --check, and frontend unit, integration, and browser checks.

Deployment and publication remain incomplete: no deployment signer or IPFS/IMD publishing credentials were available. The website explicitly shows “awaiting deployment.” Remaining steps are documented in REDEPLOYMENT.md.

Updated only launch.json.

• Validated the supplied schema, constructor arguments, permissions, fee 12500, and initial price.
• Notes describe the frontend and pending deployment/publication.
• forge build passed with existing warnings.
• forge test: 158 passed, 0 failed, 0 skipped.

Added failure-path tests and liquidity/accounting invariants.

• forge build succeeded.
• All 169 tests passed; no failures or skips.
• New invariant exercised 16,384 actions without reverts.
• Reported a medium-severity exact-output underfill defect, with a reproduced failing proof, in .imd-findings.json.

Contracts and configuration remain unchanged. Deployment and publishing were outside this tests-only assignment.

The review is complete. The findings file is written, validated, and the working tree is clean apart from it.

Outcome: no exploitable math defect found. The KING hook's arithmetic holds against the Math Precision, Boundary and Numerical Gap checklists. One info-level observation is recorded.

What was checked

• Fee math on all four swap modes, traced through v4-core's Hooks.beforeSwap/afterSwap delta plumbing. The hook's owed delta equals the claim it mints in every mode, and the fee tracks the rate of gross ETH within one wei. Partial-fill checks are exact because the pool consumes exactly amount - fee or pays exactly out + fee on a full fill.
• Throne price curve. All 64 Q64 constants in Halving.sol equal the exact floors (verified with Python Decimal). Price is an exact shift at whole hours and never rises across consecutive seconds for bases from 0.01 to 1000 ETH.
• Income curve. The constant 29146345660 is the correct rounding of log2(1/0.98)·1e12. Bucket moves between pool, provisional, pending and claims are exact integer transfers, so the conservation invariant has no rounding seam.
• Boundary cases: zero and dust inputs, uint64 timestamp and int128 casts, sentinel king == 0 paths, abi.decode of foreign hookData, payable branches in the router, the vesting >= boundary, and loop bounds in nextHalvingTime.
• The full suite of 152 tests passes. Six web unit tests pass. Scratch probes confirmed the exact-output fee consistency and the must-take exact-output boundary, then were removed.

The one recorded item (info)

Halving.decay floors once per set bit of the fractional exponent, so each income booking over-pays the king by up to about 65 wei plus a 2^-64 relative term. A 100 wei pool returns 75 after one second. A 1e9 wei pool booked every second for an hour drifts 75k wei from a single booking. This is documented in the library comment and cannot be farmed since every booking costs a transaction, so it is non-material. The comment in test/Halving.t.sol still cites the old 64 wei bound.

Coverage: all 15 listed entry points have rows (14 hold, the income invariant row points at the info finding), plus five invariant rows. Nothing was left unreached.

The review is complete and written to .imd-findings.json. No files in the repository were changed.

Outcome. The permission model holds. I found no critical, high or medium defect in the Access Control, Trust Gap or Asymmetry areas. Two lower-severity items are reported, both reproduced with scratch Foundry tests on this tree and then removed.

What I checked. Every state-changing entry point the verifier listed, traced from caller through guards to state change and failure path:

• Hook callbacks all require the PoolManager, refuse to run during a payout, and bind to the one initialized pool. The fee minted as an ERC-6909 claim equals the delta v4 accounts after afterSwap returns in all four swap shapes.
• Buyer identity is trusted only when the sender is the immutable router, which always writes msg.sender and delivers output to it. Foreign 64-byte must-take data reverts rather than silently charging.
• The hook's unlockCallback is reachable only from its own payout: it needs the PoolManager as caller plus the hook's own transient guard, and a nested unlock reverts.
• claim() pays only the caller's zeroed credit. dethrone() and the holding checks run before accrual, so unverified income stays in the pool while vested credits survive.
• The router pulls tokens only from msg.sender after the authenticated prepareSell checkpoint, refunds only the order's own residue, and cannot be fed an order by a third party.
• The token is unmodified OpenZeppelin ERC-20 with no admin surface.
• beforeInitialize accepts exactly the policy fee 12500 and returns the correct selector.
• The full non-fork suite passes on this tree (152 tests).

Findings.

1. Low. Anyone can initialize a hookless KING/ETH pool on the same PoolManager. Trades there pay no hook fee, and a king can sell his whole takeover position there without being dethroned until someone calls dethrone(). This follows from the requested plain-token design, but the site's "Every buy and sell pays an ETH hook fee" wording overstates it.
2. Info. A sitting king's ordinary official-router buy at or above the decayed price re-crowns him, forfeiting provisional income and restarting the five-minute vesting clock, while the same buy through another router does nothing. The README documents this. The trade page gives a connected king no warning.

Coverage. All 15 entry points have rows (13 hold, 2 reference finding 2, beforeSwap references finding 1 as a scope limit), plus three invariant rows. Not reached: the Base fork tests (excluded, offline), and the web app beyond its contract-call paths and disclosures.

Review complete. .imd-findings.json is written (valid JSON, snippet verified against the tree); the scratch directory is removed and no tracked file was changed.

Summary

Area: Execution Trace, Periphery, First Principles (Pashov guides), applied to KingHook, KingRouter, KingToken, Halving, HookFlags, the manifest and the web client.

Result in the contracts: no substantiated defect. What I traced:

• All four swap modes end-to-end through v4-core's Hooks.beforeSwap/afterSwap: the fee lands on the correct side (specified delta for ETH-specified swaps, unspecified for the others), sign and placement match toBalanceDelta, and the ERC-6909 mint exactly offsets the hook delta. The fee computed in beforeSwap and afterSwap is identical (same params, same timestamp), so HookDeltaExceedsSwapAmount and the PartialFill guards are unreachable on full fills.
• Reign state machine: every _endReign/_startReign transition keeps king, reignStart, requiredBalance, priceBase, provisionalIncome coupled; holding checks always run before accrual so an unverified interval is never credited; provisionalIncome is provably zero whenever the throne is empty.
• Reentrancy surfaces: the ETH take callbacks (claim payout, router refund/payout). Probed with scratch tests: a nested direct poolManager.swap from inside a router sell keeps claims == pool + provisional + pending; a contract buyer calling dethrone() from the refund callback can only end its own fresh reign (equivalent to a sequential sell + rebuy; the prior king's vested income is intact) — self-harm, no victim, so not reported.
• Periphery: all 64 Halving Q64 constants verified numerically; overflow bounds hold; HookFlags bit positions and CREATE2 buffer offsets are correct; the manifest's constructor args, permissions, fee tier, initial price and notes length (3,755 / 4,000) are consistent with the code.
• Tests: 158 pass, including the Base fork rehearsals; the fee-policy change is covered (12500 accepted; 500/3000/10000, 0 and the dynamic flag rejected).

One finding (low): the website deliverable ships in awaiting-deployment state — web/dist/imd-deployment.json has null addresses, so the app disables every action and nothing is pinned or published. The docs state why (no signer, pinning account or publisher in the workspace); this is a service gap for the deployer, not a code defect.

Coverage: all 15 listed entry points answered holds with reasons, plus rows for the conservation invariant, reign-state coupling, periphery libraries, manifest and the web client (the latter linked to the finding).

The review is complete and .imd-findings.json is written (valid JSON, snippet verified against src/KingHook.sol:602-604, scratch tests removed, working tree otherwise untouched).

Summary

Area: Economic Security, Invariant, and Flow Gap guides from the Pashov reference, applied to KingHook, KingRouter, KingToken, and Halving.

Result: no reproducible defect in the economics. The one entry in the file is info, not a defect:

• Observation-based holding rule, quantified. A king who moves his KING out and restores it before any observation (swap, claim, dethrone) keeps the income for that interval — my probe measured ~0.0455 ETH per unobserved hour on a 92 ETH pool. This is explicitly documented in launch.json notes and the README as inherent to a plain ERC-20, dethrone() is the intended defence, and no other party loses funds they were owed. I recorded it so the judge has the measured size rather than a vague caveat.

What I verified with concrete values (and discarded as non-findings):

• Fee accounting in all four swap modes nets exactly to zero against the ERC-6909 mint; the token-only-launch pitfall (taking ETH the manager doesn't hold) is avoided by design.
• Income rounding: 600 per-second accruals vs the closed form differ by wei-level dust — not farmable.
• Atomic sell-then-buy from a custom router inside one unlock: the king ends short and the next observation ends the reign, forfeiting the unverified interval.
• Self-retake, rival-takeover-before-vesting, and floor-price cycling all behave as the documented rules say; they're game design, not exploits.
• View/write pairs (unclaimedIncome/claim, poolSize, kingReignEarnings) agree in the vested, unvested, and short-king cases.
• The existing suites (152 tests, including conservation/invariant fuzzing) pass.

Coverage: all 15 listed entry points marked holds with a one-line reason, plus three invariant rows and one honest unreached (no fork rehearsal against the Robinhood Chain PoolManager was possible here).

The review is complete and .imd-findings.json is written at the repository root. No source files were changed; my probes live only in the gitignored test/scratch/ folder.

Outcome: no critical, high or medium defects. The redeployment is a bounded, correct fee-policy change: beforeInitialize accepts exactly the policy tier 12500, the manifest matches getHookPermissions and the constructor, notes are under the 4000-character limit, and the full suite passes (163 tests, plus 6 Base fork rehearsals that also passed here with network). I traced all 15 verifier entry points plus two invariants and recorded a verdict for each.

Findings kept (7), each reproduced on this tree:

• Low, exact-output buys partially fill and still succeed. The tester's proof fails as described (29.93 KING delivered for a 1000 KING order). I lowered it from medium: the buyer pays only for what arrives, mustTake uses the real gross ETH, and the state is unreachable while the factory's full-range position exists. Proof attached.
• Low, hookless KING/ETH pool bypasses the fee and the holding rule. Confirmed with a scratch test. Design limitation of a plain token; the site's "every buy and sell pays a hook fee" wording needs qualifying.
• Low, website shipped awaiting deployment. No Robinhood deployment, pin or public URL exists. This is the deployer's and publisher's step, not a code defect, so it is recorded as a service gap.
• Low, new: force-sent ETH on the router breaks exact-input buys from contract wallets without receive(). The router refunds address(this).balance - ethIn, so one forced wei makes those buys revert until an EOA buy sweeps it. Self-healing griefing, no loss.
• Three info items confirmed from the specialists: self-retake restarts the reign with no trade-page warning, the observation-based holding rule, and per-booking Halving rounding in the king's favour.

Dropped or merged: none dropped, since every specialist item reproduced. The tester's medium was recalibrated rather than removed. The slither and aderyn lines were all checked and none rose to a finding. The aderyn "locks Ether" line led to the forced-ETH finding above.