The review is complete. .imd-findings.json holds three findings, each with a concrete failing input, and all snippets match the tree. Nothing outside test/scratch/ and the findings file was created.

Outcome: no critical or high defect found. The hook's delta accounting, pot and prize accounting, flip lifecycle, charge clocks and reign tracking held up against every counterexample I tried, and the project's 250 unit tests pass on this commit. The three findings are a trust-boundary gap, an ownership footgun, and a deployment-gas note.

Findings written

• Medium, src/SherwoodV2.sol:1112. Both burn pools are set by the owner after deployment, and the check only requires ETH as currency0, the right token as currency1, and a hook other than this one. The brief's "existing ETH/$IMD 1% pool" and "holder pool" are not enforced. A scratch test (test/scratch/BuybackDiversion.t.sol) initializes a pool whose hook takes the ETH in beforeSwap, has the owner set it as the buyback pool, and runs buybackAndBurn: the beneficiary receives the whole reserve minus 1 wei, zero tokens reach the dead address, and the reserve is marked spent. Fix suggested: fix the two pool keys (at least their hook fields) in the constructor; 6 extra arguments still fit under the 16-argument limit and need no external call.
• Low, src/SherwoodV2.sol:1101. setOwner is single-step with no zero check. Since the game pool and burn pools can only be created by the owner, a mistaken setOwner before setup leaves a hook no pool can ever carry.
• Info, src/SherwoodV2Launcher.sol:17. Salt mining is open-ended: tries are a geometric draw fixed by the launcher's address, about 125 gas each. A 10M gas ceiling fails for roughly 1 in 9 launcher addresses; about 18M covers all but 1 in 500.

Coverage

• Read in full: src/SherwoodV2.sol, src/SherwoodV2Launcher.sol, the setup script, launch.json (schema-valid: three keys, 8 string arguments, notes 2,814 characters), and the relevant v4-core hook and PoolManager paths.
• Read for context only: src/Sherwood.sol (v1, not launched here), the test suite and fixtures.
• Not reached: the live Dice contract's refundRequest. The hook's receive() writes storage, so a refund pushed with a 2300-gas stipend would revert. The live bytecode has no transfer/send stipend pattern, which suggests a full-gas call, but my fork rehearsal of the refund did not complete against the public RPC in the time available, so this stays unverified rather than a finding. The holder-pool hook's behavior under the host buyback was also not independently verified beyond the project's own fork test.

Done. The build passes, all 254 local tests pass (the twelfth suite is the scratch harness copy, which is not submitted), and the 10 fork tests pass against the live Robinhood Chain RPC.

What the audit found and what changed

• Medium, burn pools chosen by the owner after deployment. Confirmed by reading the arrived code: the setter accepted any fee, tick spacing and hook other than the game hook, so a capture-hook pool could take the 17% burn share. Fixed in src/SherwoodV2.sol by fixing both keys in the hook. The game-token burn pool is the ETH/token 1% pool with no hook, and the host burn pool is the ETH/$PFWA holder pool with Hookr's holder hook. The currencies come from the constructor's token and host arguments, so the launcher keeps its eight arguments as the brief and the committed launch.json state. The two setters, their check and stored keys are gone. In $PFWA's own game the single burn goes through the holder pool, which the fork test previously set by hand.
• Low, single-step owner handover. Confirmed by reading. The owner now names a next owner who must call acceptOwner, and naming zero cancels. A mistaken handover can no longer strand the hook before the game pool exists.
• Info, open-ended salt mining. No code change. The launcher is untouched, and the gas-ceiling note stays as an open item for the deployer. A scratch factory rehearsal on an empty chain cost about 6.9M gas.

Tests and docs

• New test/SherwoodV2LaunchConfig.t.sol covers the fixed keys, the audit's capture-pool scenario on the fixed code, and both owner-handover reproductions.
• A new test/helpers/MockHolderHook.sol is etched at the holder hook's fixed address so unit tests can create that pool. The fixture, main suite, accounting, invariant, buyback-hook fuzz and both fork suites were adapted to the fixed keys. The fork launcher rehearsal now asserts both live pools exist and burns through them without any setup call.
• The setup script drops the two setter steps and checks both pools exist. README and ADAPTATION.md describe revision 4, the reasons, and the checks run.

Side effects worth knowing

• The hook's runtime fell to 23,654 bytes, 922 under the EIP-170 limit, because the stored keys and setters were larger than the two-step owner and the key views.
• Protected paths, launch.json and the launcher source are unchanged.

I found no math defects in SherwoodV2. The review reports one low-severity finding, and it is in the deployment notes, not the code. All 253 unit tests pass (forge test --no-match-contract Fork); I did not run the fork tests. The tree is unchanged, and the results are in .imd-findings.json.

The finding (low): launch.json:18. The manifest notes tell the owner to "set the two buyback pools with setBuybackPool and setHostBuybackPool". Revision 4 removed both functions and fixed the two burn pools as constants in the hook. An owner, or a script, that follows the notes calls functions that don't exist, and the call reverts. No funds are at risk, but the signed manifest misdescribes the owner's setup and powers. The suggested fix is to rewrite that sentence: the owner creates the game pool and may name an operator, the burn pools need no setup, and a handover is setOwner(next) then acceptOwner().

What I checked and found sound:

• Swap deltas: the buy and sell fees net to zero in the hook's account. The partial-fill check uses the same rounding as the fee, so a fully filled buy passes exactly. Below 20 wei the fee rounds to zero, which is harmless.
• Buyback swaps in unlockCallback: on an exact-input swap the ETH paid can never exceed the amount, even with the holder pool's hook. A partial fill returns the rest to the right reserve. A shortfall below minOut reverts the whole burn.
• Settlement split:
  • Prizes are at most 78% of the pot, referral cuts at most 3.9%, and burns 17%, so the rollover is always at least about 1.1% and can't underflow.
  • A partial forfeit never pays more than the prize.
  • Once a round is settled its pot can't receive any more ETH, so nothing gets stranded.
• Claims, referrals and sweeps: each pays out only after its bookkeeping is updated. At the exact deadline a claim still works and a sweep doesn't, so the two can never both run.
• Flips: the Dice fee leaves the pot before the request, and a refund comes back into the buyback reserve. Any pending flip can be expired 5 minutes before settlement opens. A reveal that arrives after expiry is ignored.
• Charge clocks: a clock never passes the current time, and a new wallet's first spend leaves its bank one short of full (17 of 18 Steals, for example).
• King of the Hill: every reign timestamp is capped at the round's end, so no reign seconds are counted after the round ends. The revision 3 unknown-spell credit can't underflow.

Coverage: the file has a row for every listed entry point, plus four invariants.

• All 18 SherwoodV2 entry points hold, each with a one-line reason.
• The 17 entry points on the v1 contract (src/Sherwood.sol) are marked unreached. This launch doesn't deploy v1, so I spent the time on v2.

No finding is high enough to need a Foundry proof test. Two edges are not defects but not covered by a test either. When two players tie for #1, settlement and the running leader tracking may pick different ones. On boards over 1,500 players, how fast the rescan finishes depends on the gas each swap is sent with.

launch.json is done and verified. Only that file changed.

What I found: the tree already carried a manifest from the earlier accepted commit, and its structure and arguments were correct: kind evm_contracts, one contract, SherwoodV2Launcher, with the eight constructor arguments in declaration order (poolManager, $IMD token, $PFWA host, hostHolderMin, dice, diceProvider, $owner, genesis 1791835200), matching both the brief and the launcher's constructor. The notes, though, described two owner setters, setBuybackPool and setHostBuybackPool, that do not exist in the accepted source. In the implementation both buyback pool keys are constants exposed by the buybackPool and hostBuybackPool views, so nothing is set after deployment.

What I did: rewrote that final part of the notes to describe the accepted implementation. They now state that the buyback pools are fixed constants, that the only post-deployment step is the owner initializing the native-ETH/$IMD game pool with launcher.hook() as its hook (beforeInitialize accepts only the owner, only those currencies, and only once), and that ownership hands over in two steps via setOwner and acceptOwner, with setOperator naming the buyback operator. Everything else in the notes was left as written.

Checks:

• Manifest parses as JSON with exactly the keys kind, contracts and notes. Notes are 3,294 characters, under the 4,000 limit. One contract with 8 string arguments.
• forge build succeeds.
• forge test: 256 passed, 0 failed, 2 skipped (the fork rehearsals that need a live RPC).
• git status shows launch.json as the only modified file.

The review is complete. No tracked file was changed; only the findings file and two scratch probes under test/scratch/ were written.

Outcome: no fund-moving defect found in the economics. The swap delta accounting, pot/prize/referral/claim/sweep flows, the two buyback swaps, the flip lifecycle, the charge clocks and the reign tracking all hold under the Economic Security, Invariant and Flow Gap checks. Three findings are recorded in .imd-findings.json, none above low.

Findings

• Low. Late Dice reveal can be selectively pre-empted. After 10 minutes expireFlip is permissionless and scores the stake as a buy, and any later reveal is dropped. If the provider is late, a flipper expires a losing reveal and lets a winning one through, so their outcome becomes max(buy, flip) and the previous player never receives the lost stake. Points only, no ETH. Confirmed with a scratch test.
• Info. Views disagree with settle during an unknown spell. After #1 loses a flip on a board above 12 players, kingOfTheHill and reignOf show the old holder as King and zero seconds for the player settle will crown with the whole spell. Confirmed with a scratch test (view says alice, settle crowns carol with 68,399 s).
• Info. Flip economics. A flip's expectation is 1.0 to 1.5 times a plain buy, and a two-wallet pair whose second wallet is previous never loses points on a flip, while the pot pays the Dice fee. This is the rule as written, reported as economics rather than a defect.

What was verified

• Full local suite: 253 tests pass, including the 256x96 ETH-conservation invariant run.
• Launcher fork rehearsal against live Robinhood Chain passes: deploy, pool setup, a play, settlement, and both burns through the live 1% pool and the live Hookr holder hook.
• Live $IMD transfers in full on a fork, so bought equals what winners actually receive.
• Live Dice bytecode has no 2300-gas transfer pattern, so refunds into receive() cannot fail.
• Settlement cannot underflow: prizes, referral cuts and burns commit at most 98.9% of a pot.

Coverage answers all 35 listed entry points. Every SherwoodV2 entry point is holds except expireFlip (finding 1). The Sherwood v1 entry points are marked unreached, since v1 is not deployed by this launch and was not reviewed.

Both probes pass. The review is complete and .imd-findings.json holds the results.

Outcome: the control flow in src/SherwoodV2.sol holds in every focus area. I found one low defect with a failing proof test and one informational manifest note. No critical, high or medium finding.

Findings written to .imd-findings.json:

• Low, Robin Hood charge with no leader above zero (src/SherwoodV2.sol:559). When every scoring player is at or below zero, a credit while the leader cache is empty makes a below-zero player the cached #1. A Robin Hood then reaches the charge spend and moves nothing, although the README says a Robin Hood with no leader keeps its charge. The self-contained proof test/scratch/RobinHoodNoLeader.t.sol fails on this tree with robinsLeft 2 instead of 3.
• Info, stale manifest notes (launch.json:18). The notes tell the owner to call two setters that revision 4 removed from v2. Contracts and constructor arguments match the brief.

What I verified and recorded as holding:

• Swap deltas: a buy's fee take plus the positive specified delta makes the swapper pay exactly its declared amount, and the partial-fill check compares the pre-hook pool delta. A sell's fee flows through the unspecified delta and nets the take.
• Both buyback swaps settle exactly what the pool took, burn the net output, and return partial fills to their own reserve. Both fixed pool keys exist on the live chain. I confirmed slot0 for the 1%/100 key and the holder key by RPC, and the launcher fork rehearsal burns through both.
• Pot, prize, referral, claim and sweep accounting conserve ETH. Settlement has no revert path other than gas, and every pending flip is expirable five minutes before settlement opens.
• Flip lifecycle, charge clocks, and King of the Hill reign tracking, including a cold-storage callback on a 12-player board where the previous player takes #1 within the 200k limit, and a batched settlement that credits the final unknown spell to the right King.
• $IMD and $PFWA transfer without fee, so the holding rule and holder bonus work as written.

Coverage: all 19 SherwoodV2 entry points are answered (18 hold, one carries finding 1), plus rows for the three invariants, the manifest and the live dependencies. The 17 Sherwood v1 entry points are marked unreached, since v1 is deployed, unchanged and outside this area.

Files under test/scratch/ are probes only and are not part of the submission.

Done. forge test passes: 279 tests, 0 failures, 2 skipped (the fork suites, which skip with no RPC configured). Only files under test/ changed.

What I added

• test/SherwoodV2Edges.t.sol (21 tests through the real PoolManager). Failure paths and edges the existing 253 tests did not pin:
  • Settlement with a zero batch, an empty round (burns plus an 83% rollover, nothing to claim or sweep), rollover landing in the round live at settlement, settling the live round or an impossible round number, second claims, sweeps after a full claim, and claims or sweeps for rounds that never settled.
  • A buyback request ten times the reserve spends exactly the reserve and leaves the other one alone. An empty reserve cannot burn.
  • Hook data of 20, 33, 63 and 64 bytes with an unknown move: the move word decodes, the rest is ignored, the referrer and welcome bonus apply only on 64 bytes.
  • Robin Hood by the leader keeps its charge. A Steal from a player wiped to zero spends its charge and moves nothing. A shield raised near a round's end still reflects in the next round.
  • A flip in the last second of a round expires exactly at the ten-minute mark, before settlement opens, scores as a buy in its own round and starts no reign. Late reveals and double expiries change nothing.
  • The kingOfTheHill view agrees with the settled King.
  • Seven fuzz properties with inline run counts: every wei of a settled pot lands in exactly one of prizes, referral cut, reserves and rollover under fuzzed partial sales by all winners, through claims and the sweep; buy points and fees from one wei up; Steal and Robin Hood charge banks, spends and next-charge times; shield charges at every 0.025 ETH crossing; Steals, Robin Hoods and reflects are zero-sum; fundPot round bounds.
• test/SherwoodV2FreshBoardInvariant.t.sol. A second invariant campaign reusing the six-actor handler from a different start (fresh board, Dice fee at its cap, a reflected Robin Hood leaving a player below zero, a flip pending), 128 runs of depth 64 with reverts failing the run. Invariants: ETH held equals every obligation and never exceeds ETH in; the live round's reign holder is the cached #1 with the most points; settled rounds keep seven days to claim, hold no pending flips and award no prize above its share or to anyone at or below zero.
• test/SHERWOOD_V2_TESTING.md gains a revision 5 section describing the above.

Defects found: none. Every property held on the code as it stands, so no .imd-findings.json was written. The three failures I hit while writing were harness mistakes, not contract behaviour: a timestamp cached across a vm.warp under via-IR, a view call consumed by expectRevert, and a balance check that forgot the rollover. Each is noted in the testing notes so the next contributor avoids them.

Still owed: no fork run was made here. The live rehearsal in test/SherwoodV2LauncherFork.t.sol against Robinhood Chain remains to be run before deployment, as the earlier notes already state.

Review complete. The findings are in .imd-findings.json with a coverage row for every listed entry point.

What I found in the assigned area (Access Control, Trust Gap, Asymmetry)

• Low, settle tie-break asymmetry. The live notion of #1 keeps the incumbent on equal points, so the King clock, Robin Hood targeting and the site's leader view all stay with the incumbent. Settlement ranks ties by join order instead, so on the same tie the earlier joiner takes 40% and the live #1 drops to 20%. A player with a lower join index can engineer this by buying up to an exact tie. Reproduced with a scratch test on this tree. Anchored at the ranking loop in settle.
• Info, trust assumption. The operator alone sets minOut for both burn swaps, so the execution price of 17% of every pot is at the operator's discretion. The README accepts this. I recorded it with the concrete call sequence and noted that there is no unprivileged amplifier on a sequencer chain.
• Info, handover asymmetry. The constructor sets operator = owner, but acceptOwner does not, so the previous owner keeps buyback and Dice-refund powers until the new owner calls setOperator.
• Info, stale manifest notes. The notes in launch.json still tell the owner to call two burn-pool setters that revision 4 removed. The contract entry and constructor arguments are correct.

What held under my lenses

• The permission map has no weaker writer for any guarded variable and no escalation path. All hook callbacks and the unlock callback are reachable only from the PoolManager, and the unlock callback only from the hook's own two burn functions.
• ETH accounting conserves: every inflow lands in one bucket, settlement cannot underflow or revert, claims and sweeps are disjoint at the deadline.
• The thinnest margin in the flip lifecycle is the small-board Dice callback. I measured its worst case with the previous player at zero points, a first reign write and cold storage.

Scenario	Callback gas
Leader loses on 12 players, worst state	183,021
Dice limit	200,000

Not reached

• The 17 v1 Sherwood entry points are marked unreached. V1 is already live and is not deployed by this launch.
• A candidate about Robin Hood spending a charge on a negative cached leader did not reproduce, because the robber's own credit takes the lead first. It is not reported.

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

Review complete. The findings file at .imd-findings.json holds six findings and a 38-row coverage record (all 35 listed entry points answered, plus three invariants), and the project's full non-fork suite including the invariant tests passes on this tree.

What I kept, all reproduced with scratch tests against the real v4 core fixture

• Low: Robin Hood spends a charge against a sub-zero cached leader. _credit adopts any credited player into an empty cache even at or below zero, so a Robin Hood runs and burns its charge while nobody is above zero. Scratch test fails with "2 != 3".
• Low: tie at the top is resolved differently live and at settlement. The incumbent keeps #1 live (strict greater-than), but settlement walks join order, so on an exact tie the earlier joiner takes 40% while the live #1 and King takes 20%.
• Low: acceptOwner leaves the previous owner as operator. After a handover the old owner still runs both buybacks with any minOut and Dice refunds until the new owner calls setOperator.
• Low: kingOfTheHill and reignOf disagree with settle during an unknown spell. The views show the old holder and 0 seconds for the player settle crowns with 68,399 seconds.
• Low: a Dice reveal later than the 10-minute timeout can be selectively pre-empted. A losing reveal is turned into a plain buy by expireFlip; a winning one is left alone.
• Info: operator-chosen minOut is the only price bound on the burn swaps. Documented trust assumption, recorded as the contract's material privileged power.

What I dropped

• The three "stale launch.json notes" findings from audit_math, audit_flow and audit_permissions do not reproduce: the notes in the tree already say the burn pools are fixed and nothing is set after deployment.
• The "flip EV exceeds a buy" item is the rule as commissioned, not a defect.

My own pass found nothing above low. I verified the swap delta accounting against the vendored v4 Hooks.afterSwap (the hook sees the raw swap delta, so the partial-fill guard is correct and ethPaid can never exceed the burn amount), traced ETH conservation across pot, prizes, referral cuts, sweeps and reserves, the flip lifecycle, the charge clocks, and reign tracking including the revision 3 final-unknown branch. Nothing blocks swaps, settlement or claims. The launcher's init code and the hook's 23,654-byte runtime are within the factory's limits. Nothing in the tree was modified; the scratch tests live under test/scratch/ and are not kept.