Added boundary, failure-path, invariant, and v4 dethrone tests. forge build and seeded forge test pass: 67 tests, zero failures or skips.

Reported two defects with reproducible proofs in .imd-findings.json:

• Fees charged on unexecuted input.
• Malformed registry responses blocking swaps.

Also documented the contradictory unchanged-king-token requirement. Production contracts and configuration remain untouched.

The hook reads cleanly on re-inspection, and the shell is still refused by the sandbox, so I cannot run the compiler here. The work is complete; here is the recap.

Outcome. Both reproducible findings are fixed in src/CrownHook.sol, the advisory one is disputed, and the answers are in .imd-responses.json. I could not run forge build or forge test: every shell command on this machine, including true, fails before starting with this sandbox error:

apply-seccomp: write /proc/self/setgroups (nested userns is capability-restricted; caller must provide CAP_SYS_ADMIN): Permission denied

So the changes were verified by reading the vendored v4-core sources against the two proof scenarios, not by executing them. I say the same in the responses file.

Finding 1, fee charged on unfilled input (fixed). The old beforeSwap took bps of the order before the pool ran. Now it calls a rehearsal: a new simulateSwap self-call runs the exact swap the pool is about to execute through poolManager.swap and always reverts, returning the pool's delta in the revert data. v4's Hooks library skips a hook's own callbacks when the hook is the swapper, so there is no re-entry and the revert discards everything. If the pool fills the whole rehearsed amount, the cut stays bps of the order, so 1 ETH in still pays 0.01 ETH. If it stops short at a price limit or in an empty pool, the cut is bps of the ETH actually moved, which is zero for no fill, so the caller's delta is zero. A failed rehearsal yields no cut rather than a revert.

Finding 2, malformed 96-byte registry answer (fixed). The beneficiary word is now loaded by hand and any bits above the address mark the answer as malformed, which skips the cut with the existing REGISTRY_READ_FAILED event. No abi.decode of registry data remains.

Finding 3, unchanged king token (disputed). The brief's finalize rule requires the registry to point at the challenger token after a flip, and the finding itself says it does not ask otherwise. Nothing changed.

Tests and docs. Five tests were added to test/CrownHook.t.sol: an empty-pool order that costs and pays nothing, price-limited partial fills on an exact-input buy and an exact-output sell with the cut exact to the executed ETH, the rehearsal refusing outside callers, and the dirty-registry skip in both swap directions. The mock router gained a swapWithLimit helper. The README documents the rehearsal, its roughly one-extra-swap gas cost, the strict decode, and the hook's full list of external calls.

What to check first on a working machine. Run the two proof files and forge test with the given fuzz seed. The one place a compile slip is most likely is the try this.simulateSwap(...) block in _fillableEth, since I could not compile it here.

All 87 tests pass with the verifier's fuzz seed (78 delivered, 9 scratch), forge build is clean, and the only modified paths are test/CrownHook.t.sol, test/invariant/CrownHookInvariant.t.sol and test/README.md.

What I settled

• High, fees on unexecuted input: fixed, verified. The author could not run Foundry, so I ran their four new tests first. They pass. I then attacked the new rehearsal path directly. Partial fills on the two afterSwap shapes pay the cut on executed ETH only. An empty pool charges nothing in any of the four shapes. A hooked pool after a 1 ETH buy lands on the same price, tick, output and LP fee growth as a hook-less pool after a 0.99 ETH buy, so the rehearsal leaves no trace. A random-limit fuzz over all four shapes holds the cut to bps of the ETH actually moved. A gas sweep over the amount forwarded to the swap finds no window where the rehearsal fails but the trade still completes, so the "no cut on rehearsal failure" fallback is not a fee bypass.
• Medium, malformed 96-byte registry reply: fixed, verified. The author's dirty-word test passes. I removed the stale exclusion of 96-byte replies from the reply-length fuzz. 96 zero bytes now asserts a "no king" skip and every other length a failed-read skip.
• Info, unchanged king token: author's answer accepted. The brief requires the king record to change on a flip. The end-to-end test already asserts the registry address, pool key, traded currency and token code are byte-identical across the dethrone, which is the reading that holds. Not re-reported.

One observation, recorded in the README rather than reported. On a full fill of an ETH-specified order the cut is bps of the order, while on partial fills and token-specified orders it is bps of the ETH the pool moved. The two bases differ by the cut itself. The brief leaves the base open, so the tests assert the implemented behaviour exactly and bound the cut between bps of the user's ETH and bps of the pool's ETH.

Invariants. The hook handler now mixes price-limited partial buys and sells into the 256 random sequences, with a partial fill forced at the end of every sequence. Payment accounting and zero-custody invariants hold.

No .imd-findings.json was written because no open finding remains. Changes are left uncommitted in the working tree, as in the previous round.

Implemented the CROWN frontend, source, lockfile and static export under dist/.

• Build and typecheck pass.
• 78 Foundry tests pass.
• Chromium and WebKit suites pass.
• All 16 design checks pass.
• Submission files total approximately 4.82 MB.

No deployment handoff was supplied, so the app shows “Awaiting launch” and disables financial actions. No live transactions were broadcast.

Setup, design and validation details are documented in README.md, DESIGN.md and validation/README.md.

Created launch.json matching the contracts, constructor arguments, permissions, and required pool values.

forge build succeeded; all 78 tests passed with the supplied fuzz seed. Only the manifest is delivered.

Notes document required setup and pending live deployment.

The review is complete. The findings file is written and valid, no repository source was changed, and the scratch tests confirm each reproduction.

What I found

• High, with a failing proof test. A king whose beneficiary is a contract can block every swap on the pool. The hook pays the cut through poolManager.take while the manager's unlock is open. A beneficiary that accepts the ETH and then records a one-wei unsettled delta for itself makes the swapper's unlock revert with CurrencyNotSettled. The hook's try/catch sees a success, so the "never block a swap" guarantee fails. Anyone becomes beneficiary by winning an undefended challenge for a refundable 0.05 ETH, and the blockade can be armed, disarmed, or made selective. The proof in test/scratch/HostileBeneficiaryBlocksSwaps.t.sol fails on the current code with that exact revert.
• Medium. The incumbent can occupy the single challenge slot forever with self-challenges against a throwaway token. A failing self-challenge costs 0.001 ETH per seven days. A self-flip to its own alt token costs nothing and restarts the seven-day minimum reign. Rivals can only enter in the one block where each lock expires. Reproduced in test/scratch/RegistryEconomics.t.sol.
• Low. The stake window ends at a fixed public timestamp with no extension, so the last staker in the final block wins and takes 10% of the loser. Reported as a design trust assumption with exact numbers.
• Low. registerPool does not check that the ticker has a king, so binding a pool before the king registration lets a front-runner crown themselves and collect that pool's cut for at least seven days.

Coverage

All 26 listed entry points have a row. The ERC-20 tokens, owner functions, claim, treasury withdrawal, and the simulateSwap rehearsal hold. The swap callbacks, registry challenge flow, and pool binding carry findings. I verified the escrow conservation and hook zero-delta invariants by trace. One row is marked unreached: a gas-exhaustion divergence between rehearsal and real swap, and reentrant beneficiary swaps inside the payout gas, which I reasoned about but did not execute.

Suggested fix for the high finding

Route the payout through a self-call that reads the manager's nonzero-delta count before the take and reverts if it grew by more than the hook's own slot. The outer catch then skips the cut, and the inner revert undoes the beneficiary's side effects while preserving pay-at-source.

The review is complete. .imd-findings.json holds 5 findings and a 28-row coverage record (all 26 listed entry points plus two invariants), and no repository file was changed. The scratch directory is gitignored.

Findings, by severity

• High: a contract that wins a challenge can brick every swap on the pool. CrownRegistry.openChallenge makes any msg.sender the future beneficiary, and winning with no defenders costs 0.05 ETH that is fully refunded. CrownHook._payCut then pays that contract with poolManager.take while the manager is unlocked. The try/catch at src/CrownHook.sol:344 only catches a reverting payment. A beneficiary that instead leaves a 1 wei unsettled delta on itself (one mint call) returns normally, and the PoolManager rejects the whole unlock with CurrencyNotSettled. Buys and sells both fail, for at least 11 days per cycle, at zero cost. The proof test fails on the current code with exactly that error.
• Medium: the incumbent can lock every outsider out of challenges forever. In the first challengeable second the king's beneficiary opens a challenge against itself with a throwaway token and stakes quorum. Outsiders get ReignTooYoung before and ChallengeLive after. The "flip" names the same beneficiary, restarts the 7-day clock, and the full stake is refunded. Verified across three cycles with the incumbent's balance unchanged.
• Low: the hook owner picks the registry after launch. setRegistry accepts any contract with code, so the fee recipient the pool follows is whatever the owner binds, not necessarily the rule-based CrownRegistry. Reported as a trust assumption with the one-step ownership noted.
• Low: per-staker floor rounding strands wei permanently. Two losing stakers of 3 wei each leave 1 wei nobody can claim. Confirmed numerically.
• Info: registerKing is first-come with no cost, so any ticker not crowned in the constructor can be squatted ahead of a pool binding. By the brief's rule, so documented rather than counted as a bypass.

Coverage. Every hook callback, owner function, and registry action is traced. The ERC-20s are unmodified OpenZeppelin code and hold. simulateSwap, registerPool, stake, finalize, and withdrawTreasury hold against the Access Control, Asymmetry, and Trust Gap checklists. I did not have budget to exercise the web frontend or the deploy script's broadcast path, which fall outside the assigned area.

The review is complete. .imd-findings.json holds 4 findings and 29 coverage rows, and no repository file was changed. Git shows nothing tracked as modified; the findings file and test/scratch/ are ignored.

What I audited. The Math Precision, Boundary and Numerical Gap guides against CrownRegistry, CrownHook, ThroneRegistry and the two tokens. All 78 existing tests pass. The slash split, quorum, strict lead, per-staker flooring, escrow conservation, the _abs/MAX_AMOUNT/int128 casts, and the beforeSwap rehearsal for partial fills in all four order shapes all hold under concrete values. The aderyn "unsafe casting" and slither reentrancy leads are not defects as reported, but the reentrancy lead pointed at the real issue below.

Findings, most severe first:

1. High, src/CrownHook.sol:344. The beneficiary's receive() runs inside the PoolManager unlock. A contract beneficiary can call poolManager.mint(address(this), 0, 1) within the 150k gas cap and return normally, so take succeeds but the unlock then reverts with CurrencyNotSettled. Every swap on the pool fails, in both callbacks. An attacker gets the beneficiary slot by winning a challenge against an undefended king with fully refundable stake, then holds it for at least 11 days. Proof in test/scratch/BeneficiaryBlocksSwap.t.sol fails with exactly that error, and the honest-beneficiary control passes.

2. Medium, src/CrownRegistry.sol:188. Liveness and cooldown are keyed on the ticker only. The king opens a puppet challenge and ties it from the king side; honest challengers are rejected for 96 hours of window plus 72 hours of cooldown, repeatable forever. Net cost per 7-day cycle is 0.001 ETH. The scratch test runs four cycles and shows the honest challenger rejected for 28 days. This is a rule-set defect and a fix needs a scope decision.

3. Low, src/CrownHook.sol:340. When the cut exceeds the manager's ETH balance, the whole cut is skipped rather than partially paid or minted as a claim. A buy of about 100,099 ETH against a 1,000 ETH manager pays nothing while a 1 ETH buy pays 0.01 ETH.

4. Info, src/CrownHook.sol:44. DEFAULT_CUT_BPS is never applied; registerPool accepts 0 and the binding is immutable.

Coverage. All 26 listed entry points have a row, plus three invariants I checked. Not reached: the site, deploy script, README compiler settings and launch manifest, which are outside the math area.

The findings file is written, its three snippets match the tree line for line, and both reproductions ran as described. Here is the recap.

Outcome: I audited CROWN's control flow against the Execution Trace, Periphery and First Principles guides and recorded three substantiated defects plus a 29-row coverage record in .imd-findings.json. The existing suite of 78 tests passes on the current tree.

Findings

• High. A king's beneficiary contract can brick the pool. The hook pays the cut with a native take to the beneficiary while the PoolManager is unlocked. A beneficiary whose receive function calls take for 1 wei to a sink leaves an unsettled delta. The hook's try/catch sees success, records the payment, and the swapper's unlock then reverts with CurrencyNotSettled. Every buy and sell on the ticker's pools fails, against the "never block a swap" requirement. Anyone reaches that position through an ordinary challenge at zero net cost, since winning stakes are fully refundable. The proof test under test/scratch/BeneficiaryReentryBlocksSwaps.t.sol fails on the current code. The suggested fix wraps the payout in a self-call that checks the nonzero-delta count and the beneficiary's delta after the take, so the existing catch path skips the cut instead.
• Medium. Cheap perpetual challenge lockout. One live challenge per ticker plus the 3-day cooldown lets whoever opens first at each cooldown expiry hold the ticker for 7 days per cycle. With no stakers the sham fails, the opener recovers 0.008 ETH and the lockout costs 0.002 ETH per week. Reproduced over three cycles in test/scratch/ShamChallengeLockout.t.sol.
• Low. Any non-zero address can be crowned. The registry never checks that a challenger token has code or matches the symbol, so an EOA can become the "canonical token" with fees routed to the opener.

Coverage: all 26 listed entry points have rows. The hook's swap callbacks and the registry's openChallenge carry the findings. Everything else, including the delta accounting across all four swap shapes and partial fills, the rehearsal's gas-starvation resistance, and the manifest against the implementation, traced as holding. The frontend's side encoding and the shipped ABI arrays also match the compiled contracts.

Not reached in depth: the web application's transaction wiring beyond the side encoding, and the registry invariant suite's handler logic, which I relied on rather than re-derived.

I've written the review to .imd-findings.json: 6 findings (1 high, 2 medium, 3 low) and a coverage row for each of the 26 entry points. No repository files were changed. I deleted my scratch test after running it.

Findings kept

1. High: a challenge winner can block every swap on the pool (src/CrownHook.sol:344). All four specialists reported this. The hook pays the cut while the PoolManager is still open for the swap. A beneficiary contract can accept the ETH and, in the same call, leave a 1-wei debt on itself (for example poolManager.mint(self, 0, 1)). The whole swap then reverts with CurrencyNotSettled, for buys and sells alike. Anyone can become that beneficiary by winning an undefended challenge, and the 0.05 ETH it costs comes back to them in full. The brief says the hook must never block a swap. I ran a self-contained Foundry proof against the code: the honest-king buy succeeds, and after the flip the buy fails with [FAIL: CurrencyNotSettled()]. The proof is attached to the finding.
2. Medium: the king can keep every outside challenger locked out (src/CrownRegistry.sol:188). Merged from all four specialists. There is only one challenge slot per ticker, a failed challenge starts a cooldown, and a successful one restarts the 7-day minimum reign. So the king can repeatedly challenge itself with a throwaway token, for about 0.001 ETH a week or for nothing. Every rule is coded as the brief words it, so fixing this means changing a rule.
3. Medium: the owner decides who the pool pays (src/CrownHook.sol:131). After launch the pool pays no cut until the owner sets a registry and registers the pool by hand. setRegistry accepts any contract, so the owner, who is also the genesis beneficiary, can point it at one that always names themselves. Dethrones in the real registry would then change nothing. Also, afterInitialize records no ticker and DEFAULT_CUT_BPS is never used.
4. Low: large early buys pay no cut (src/CrownHook.sol:340). When the cut is more than the ETH the PoolManager holds, the whole cut is skipped rather than paying what's there. The README says this only affects the first buy, which is wrong.
5. Low: rounding dust is stranded (src/CrownRegistry.sol:169). Refunds are rounded down per staker and the slash on the side total, so a few wei per challenge belong to nobody and can never be withdrawn.
6. Low: registerPool doesn't check the ticker's king (src/CrownHook.sol:140). Someone can claim a ticker first by front-running the owner, and the pool then pays them permanently.

Dropped:

• Last-minute stake sniping: this is how the brief's fixed stake window works, not a defect.
• A wallet address with no code can be crowned: it causes no harm beyond crowning any junk token, and the suggested fix is easy to get around.

Deployability: both contracts the factory deploys fit the size limits; the hook's runtime is about 8.2 KB. The hook's constructor arguments and permissions match launch.json. Its afterInitialize callback can only be called by the PoolManager and returns the correct selector. So nothing blocks deployment, though the cut still depends on the manual setup in finding 3.

Work is complete and verified. Here is the recap.

Findings and what changed

• High, hostile beneficiary (fixed). The proof reproduced with CurrencyNotSettled(). The hook now pays through an external self-call, payout, that snapshots the PoolManager's nonzero-delta count, the hook's own ETH delta, the manager's ETH balance and its sync slots, takes the cut, and reverts unless the only trace is the hook's -cut delta. The catch rolls back the payment and everything the beneficiary did, and the swap proceeds without the cut. The proof passes; a permanent test covers mint, take and sync re-entries on all four swap shapes.
• Medium, sham-challenge lock (fixed by rule decision). A live challenge in its staking window can be displaced by bonding exactly twice its bond. The displaced challenge ends with full refunds on both sides, no slash, no cooldown, no crown change. The site reads requiredBond and offers "Displace this challenge" under the live challenge.
• Medium, owner-chosen registry (fixed within the proof's API). setRegistry accepts only a bytecode-identical CrownRegistry or ThroneRegistry (code-hash immutables). registerPool requires the registry and that the ticker's king is the pool's token. afterInitialize records the default 100 bps cut, and an unbound pool emits POOL_NOT_REGISTERED. The constructor and setter signatures stay as the proof harness requires, which the response explains.
• Low, short-manager cut (fixed). The hook pays min(cut, balance) and skips only when the manager holds no ETH.
• Low, squatted tickers (fixed). Covered by the king-owns-pool check above.
• Low, rounding dust (disputed). The suggested fix would let refunds exceed what the slash split leaves, so the last claimer could fail. The dust is documented and bounded by the invariant suite.

Validation

Documents updated: README (registry rules, hook payout, owner functions, after-launch list, assumptions), DESIGN.md (new disclosure component), validation/README.md (revision section), and .imd-responses.json with all six answers. WebKit and a real wallet on Robinhood Chain were not exercised and are recorded as limitations.

Revised launch.json. Only its notes changed. Everything else in the manifest already matched the accepted code.

What I checked against the current tree

• The constructor is (IPoolManager poolManager_, address owner_), so the arguments stay $poolManager and $owner.
• getHookPermissions enables afterInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta. The manifest lists exactly those five.
• Token contract CrownToken, "Crown Demo", CRWN, 18 decimals, no constructor arguments. Pool values are the launch's own: native ETH, fee 12500, tickSpacing 60, the given initialPrice.
• The first key is "kind": "univ4_hook", the address is lowercase, and the notes are 3731 characters.

Why the notes needed revising

Another contributor's accepted commit changed CrownHook and CrownRegistry after my previous manifest. The old notes described behaviour that no longer holds, so I corrected them to the current code:

• setRegistry accepts only a contract whose runtime code hash matches the compiled CrownRegistry or ThroneRegistry.
• registerPool requires the registry to be set and the ticker's king to be the pool's own token.
• A PoolManager holding no ETH skips the cut. One holding less than the cut now pays what it holds, where the old notes said it skipped.
• The payout runs in a self-call that is rolled back if the beneficiary leaves any trace in the PoolManager.
• A live challenge inside its window can be displaced by a new challenger bonding twice its bond, with full refunds and no slash, cooldown or crown change.

Verification

forge build succeeded and forge test with the verifier's fuzz seed passed all 82 tests across 7 suites, including both invariant suites. git status shows launch.json as the only modified file.

The review is complete and .imd-findings.json holds one finding plus a 30-row coverage record.

Settled from round 1

• Hostile beneficiary blocking swaps (high): not fixed. The earlier proof now passes, because delta-opening re-entries are rolled back. But the new payout trace checks miss a trade the beneficiary settles entirely in ERC-6909 claims. With ETH parked in the manager as claims, its receive can swap on the launch pool, close the deltas with burn and mint, and leave the delta count, ETH balance and sync slots exactly as the checks expect. The nested swap costs 96k gas, inside the 150k budget. On the beforeSwap path it buys ahead of the swapper, and any slippage bound then reverts the whole transaction, including the beneficiary's trade, so blocking is free and selective. Proof at test/scratch/ClaimsSandwich.t.sol fails on this tree with the swapper's slippage revert. Suggested fix is to pay beneficiaries with code by poolManager.mint claims so no code runs while the manager is unlocked.
• Challenge-slot lockout (medium): fixed by displacement at double the bond with full refunds. I verified the sham tie, the doubling ladder, and that the registry balance covers every claim.
• Owner-chosen registry (medium): fixed by the codehash check and the king-equals-pool-token check. A fake registry is refused and ThroneRegistry accepted. The documented two-call setup gap remains and matches the brief.
• Partial cut (low): fixed. The hook pays min(cut, balance).
• Rounding dust (low): dropped. The author's objection is correct: per-staker ceiling refunds could exceed what finalize reserved, so the dust is a documented assumption.
• Unchecked ticker binding (low): fixed in registerPool.

Also checked: hook creation code is 20,976 bytes despite embedding both registries' runtime code, the manifest matches the constructor and permissions, and all 82 repository tests pass.

The work is complete. Here is the recap.

Finding reproduced. A scratch test built from the reviewer's recipe failed on the starting tree exactly as described. The beneficiary contract traded on the pool from ERC-6909 claims inside its own payout. The bounded buy reverted with a slippage error, the unbounded buy received about 4% less than quoted, and the cut was still counted as paid.

Fix in src/CrownHook.sol. No beneficiary code runs during a payment any more.

• A code-less address is paid ETH by take, which executes nothing.
• An address with code is credited the cut as a native-ETH ERC-6909 claim in the PoolManager by mint. That runs no callback and needs no manager balance, so a contract's cut is never clamped or skipped.
• The payment self-call keeps its accounting checks as a defensive invariant and refuses a transfer to an address with code.
• A new redeem function lets a claim holder such as a multisig convert its own claims to ETH in its own transaction, after approving the hook as operator. The hook never holds funds or claims.

Verification.

Other changes. New permanent tests cover the claims-trading beneficiary with a slippage-bound router, a re-entering beneficiary on all four swap shapes, the claim path on a short manager, and redemption. The README, the site's how-it-works copy, the regenerated hook ABI, the rebuilt dist/ export, and the validation notes are updated. The reviewer response is in .imd-responses.json with verdict fixed.

Limitation. The page offers no control for redeem, since connected browser wallets are code-less accounts paid in ETH directly. That is documented in the validation notes and the README.

Done. I revised only launch.json, and only its notes.

What was stale. Since the manifest was last written, the accepted hook in src/CrownHook.sol changed how it pays beneficiaries that have code. A wallet is still paid ETH by transfer inside the swap. A contract beneficiary is now credited an ERC-6909 claim on native ETH in the PoolManager and redeems it later through the hook's redeem function. The old notes said no fee is ever deferred as a claim and that a rejecting beneficiary skips the cut, which no longer describes the accepted code.

What I changed. The notes now describe the wallet-versus-contract payout split, the claim redemption path, and that a contract beneficiary's claim is minted in full regardless of the manager's ETH balance. I shortened other sentences to stay under the 4000-character cap without dropping facts.

What I verified against the source.

• Constructor is still (IPoolManager, address owner), written as $poolManager and $owner.
• getHookPermissions still enables afterInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta, exactly as listed.
• Token contract CrownToken is still named "Crown Demo" / CRWN with 18 decimals and no constructor arguments.
• Pool fields are unchanged: native ETH pair, fee 12500, tickSpacing 60, the given initialPrice.
• The file parses as JSON, kind is the first key, and notes are 3962 characters.

Checks. forge build succeeded, and forge test with the verifier's fuzz seed passed all 85 tests across 7 suites. git status shows launch.json as the only modified tracked file. I did not commit, since the earlier rounds show the harness making the commits.

The findings file is valid and nothing in the tree outside my scratch tests and the findings file was touched.

Outcome: my round-2 finding is fixed, and I found no new defect. The findings file holds an empty list and a full coverage record.

What I verified on the revised hook

• The claims-trading beneficiary no longer gets execution. I re-ran the exact round-2 scenario through the real registry flow, not a mock: a contract holding 50 ETH of ERC-6909 claims wins the crown via openChallenge, stake and finalize, with a receive() that trades the pool in claims. The hook now routes any address with code to a claim mint, so its code never runs. A 1 ETH exact-input buy with a 1% slippage bound fills at exactly the quoted output, the beneficiary's call counter stays at zero, it buys no tokens ahead, and its claim grows by exactly the cut. The exact-input sell path behaves the same.
• The dirty-delta variants the specialists raised (a 1 wei mint or take inside receive) also never run and block nothing.
• Redemption works and is scoped. After setting the hook as operator, the beneficiary redeems its claim to a named recipient, and the hook ends with no claim and no ETH. Only the caller's own claims can be burned, and the callback is reachable only through the hook's own unlock.
• Factory deployability holds. Embedding both registry runtime codes for the codehash check leaves the hook at 22,965 bytes of initcode and 12,681 bytes of runtime, inside the limits. The manifest's constructor arguments and permissions match the source.

Changed code I read as new

• The registry's new challenge displacement (double the live bond inside the window) refunds both sides in full, refuses stake and finalize on the displaced challenge, blocks displacement after the window, and leaves the contract balance equal to what it owes. I did not find a funds defect in it. It turns the lockout the specialists reported into a capital contest with an exponentially growing bond, which the author documents as the design.

Results

The scratch tests live under test/scratch and are not part of the submission.