Implemented QUIVER and the ownerless hook with ETH fees, threshold buybacks, IMD burning, deferred fee claims, and failure retries.

Verified: forge build, forge fmt --check, and all 28 tests pass with the supplied fuzz seed.

Deployment and operational details are in README.md. Key caveat: Sherwood’s holding rules may forfeit prizes when purchased IMD is burned. Live-chain fork validation remains outstanding.

I found no defects I could back with a reproduction, so .imd-findings.json has an empty findings list. Its coverage record has a row for each of the 9 entry points, and every row is holds. No repository files were changed, and the existing suite passes (28/28).

What I checked, for the economics area:

• Fee on each swap direction: the hook takes 1% of the ETH side in all four cases.
  • Exact-input buys and exact-output sells: ETH is the amount the trader specifies. beforeSwap takes the fee from that amount, and afterSwap refuses a partial fill instead of charging fee on ETH that never traded.
  • Exact-input sells and exact-output buys: ETH is the other side. afterSwap takes the fee from the ETH that actually changed hands.
  • Balances: every path settles to zero.
• Fresh pool manager with no ETH: when the manager can't cover the fee, the hook records an ERC-6909 claim instead of transferring. _redeem and redeemFees later turn the claim into ETH, never more than the manager holds. Nobody can use this to pick the Sherwood player.
• Buyback: it fires once the hook holds at least 0.005 ETH, and only through a call the hook makes to itself. It pays the ETH in first, then does an exact-input swap with no price limit on the pool from the brief (fee 9000, tick spacing 180, hook 0xc33c…). All the $IMD goes to 0x…dEaD. A failed buyback is rolled back and its gas is capped, so the trader's swap still succeeds and the next swap retries.
• Strict balance equality (flagged by both slither and aderyn): not exploitable. The hook reads its balance immediately before the check, and ETH sent to it with receive() just adds to the jar.

The scanner flags on reentrancy and "locks Ether" didn't hold up: the busy flag guards re-entry, and having no withdrawal is what the brief asks for.

There is one real exposure, but it is by design. With no price limit, the buyback can be sandwiched. Someone can buy $IMD on the Sherwood pool, make the trade that tips the jar, then sell, and the jar takes the loss. The brief requires no price limit, and README line 65 and SECURITY.md already say so, so I didn't file it as a defect.

Two things I couldn't check without a fork of Robinhood Chain:

• whether Sherwood's swap fits in the 2,000,000 gas budget. If it doesn't, every buyback fails and the ETH collects in the hook with no way out.
• whether Sherwood really credits the move to tx.origin. If it does, a relayer or bundler that submits someone else's trade becomes the player, not the trader.

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

forge build succeeded with existing lint warnings. All 28 tests passed using the required fuzz seed. Only launch.json changed for submission.

The review is complete. The findings and coverage record are in .imd-findings.json at the repository root. No source file was changed; only test/scratch/ holds my scratch and proof tests.

Outcome. The fee and delta arithmetic in SherwoodPlayerHook holds up under the Math Precision, Boundary and Numerical Gap checks. I found no critical or high defect. Four findings are recorded, two low and two informational, each with a concrete input or state.

Findings

1. Low, line 154. The buyback's poolManager.sync(address(0)) clears the transient sync slot of whoever synced last. A router that follows the sequence sync, transfer, swap, settle for its ERC-20 input has its settlement credited as zero and the whole swap reverts with CurrencyNotSettled, but only on the swap whose jar is at or above the threshold. The same swap succeeds with the jar below the threshold or with a sync-after-swap router. A self-contained Foundry proof fails on the current code and is attached.
2. Low, line 97. The fee base differs by swap mode. Exact-input sells and buys pay a full 1% of the gross ETH side, while exact-output sells and buys pay 1/101 of it, about 0.990%. For the same net ETH to a seller the jar receives 1% less fee on the exact-output path. Numbers from the fixture are in the reproduction.
3. Info, line 126. The fee floors, so swaps under 100 wei of ETH pay nothing. Gas dwarfs the loss, so it is a rounding-direction note only.
4. Info, line 38. From the published Sherwood v2 source, the leader rescan loop runs at least 200 entries and keeps going until 1,000,000 gas remains. With a stale leader and a few hundred players it can exceed the fixed 2,000,000 gas budget, so the tipping swapper pays for a failed attempt until an external buy refreshes the leader. Not reproducible locally. It is a lead for the fork rehearsal.

Coverage. All nine listed entry points have a row. Both token transfers, receive, redeemFees and unlockCallback hold. beforeSwap, afterSwap and executeBuyback carry findings. Three invariant rows cover zero hook deltas, the int128 fee bound, and every static-analysis lead, each of which I traced and rejected.

Checked and found sound. The absolute-value expression for int256.min, the hook delta sign conventions against v4-core's Hooks.beforeSwap and afterSwap, the PartialFill equality against SwapMath full-consumption arithmetic in all four modes, the strict balance equality in the self-call, the claim mint and redeem accounting, and that the 0.005 ETH threshold clears Sherwood's 0.001 ETH minimum buy.

Not reached. Deployed Sherwood bytecode on Robinhood Chain, which the README also states was not verified, and the exact value of Sherwood's MAX_LEADER_SCAN constant.

The review is complete. No source files were changed; the findings are in .imd-findings.json and the one proof test is under test/scratch/.

Area covered: Access Control, Trust Gap, Asymmetry. I mapped every entry point's guard (manager-only callbacks, self-only executeBuyback, public redeemFees and receive), diffed the paired paths (take vs mint, burn vs take, specified vs unspecified fee branches, redeemFees vs _attemptBuyback busy handling), and traced the delta accounting against v4-core's Hooks.afterSwap credit. The permission model itself holds: no escalation path, no unguarded writer of busy, claims can only flow back into the hook's own jar, and the published Sherwood v2 source confirms tx.origin attribution with a 0.001 ETH minimum below the hook's 0.005 ETH threshold.

Findings, most severe first:

• Medium, gas cap (line 201). The hook forwards at most 2,000,000 gas to the buyback no matter what the trader supplies. Sherwood v2 rescans the whole board inside every play when its leader cache is stale, with no gas break for boards up to 1,500 players. At roughly 350 to 400 players the buyback always runs out of gas, the jar keeps growing, and nothing can raise the constant. The scratch test BuybackGasCap.t.sol fails on the current code and passes with the clamp removed.
• Low, sync reset (line 154). executeBuyback calls sync(native), which erases a router's pre-synced ERC-20 reserves. A router that syncs and transfers before swapping reverts with CurrencyNotSettled whenever the buyback succeeds.
• Low, burn vs holdings rule (line 163). Sherwood books the burned IMD to the player's bought, so a hook-made player forfeits the prize and an existing Sherwood leader who trades QUIVER cuts their own prize. The brief mandates burning, so this needs a scope decision rather than a silent fix.
• Info, unbounded buyback price (line 158). Sandwichable and seat-snipeable by design; recorded as a trust assumption since the brief asks for no price limit.

Coverage: all nine listed entry points have rows (two marked finding, seven holds), plus four invariant rows. None are unreached. Static-analysis leads were all checked and none promoted.

Not verified: the live Sherwood and IMD bytecode on Robinhood Chain. The explorer and every RPC I tried were blocked, so the game behaviour is taken from the published commit the README links.

The review is complete. .imd-findings.json holds five findings and a full coverage record, the working tree is unchanged, and the one proof test fails on the current code and passes under a candidate fix.

Findings written

1. Medium, executeBuyback line 154. The buyback calls poolManager.sync(address(0)) inside the caller's unlock. That resets the transient synced-currency slot, so a router that pays its ERC-20 input before calling swap gets nothing credited from its later settle and the whole trade reverts with CurrencyNotSettled. The brief says the swap must still succeed. The jar rolls back, so that router stays blocked until a differently ordered router spends it. Proof test included. A two-line fix (skip the attempt when a currency is synced) makes the proof pass and leaves the existing 28 tests green.

2. Medium, line 163. The published Sherwood v2 source records the burned IMD as bought by tx.origin and scales prizes by balance / owed at settlement and requires holding at claim. A trader with no IMD who tips the jar forfeits the entire prize. An existing Sherwood winner who trades QUIVER has their earned prize cut pro rata by tokens they never received. This is a design conflict between the burn and Sherwood's holding rule, reported for the requester to decide.

3. Low, line 38. Sherwood's full leader rescan costs about 4,200 gas per player and ignores its gas reserve for boards up to 1,500 players. Above roughly 450 players the 2,000,000 gas budget is exceeded, so every buyback attempt fails until another player's move finishes the rescan.

4. Low, line 195. Measured on the fixture, the tipping swap succeeds from a 123k gas limit while the buyback needs 503k. Estimators with a 50% buffer (185k, verified) still produce a failed buyback, so ordinary wallet trades rarely become the player.

5. Info, line 158. No price bound or minimum output, as the brief requested. Recorded because findings 3 and 4 let the jar grow, which raises the sandwich value.

Coverage

All nine entry points have rows. beforeSwap, receive, redeemFees, unlockCallback and the three token functions hold after tracing their delta accounting and guards. afterSwap and executeBuyback point to findings. Extra rows record the zero-delta invariant, the vendored v4-core matching upstream apart from formatting, the permission flags, and the Sherwood source checks. Live Robinhood Chain bytecode was not verified because no RPC was available.

Added failure-path, fuzz, and stateful invariant tests under test/.

Verified with the required seed: 58 tests passed, 0 failed, including 45,056 invariant calls. forge build also passes.

No confirmed implementation defects found. Sherwood is modeled locally; live-chain integration remains unverified.

The review kept two findings and dropped the rest. Both are in .imd-findings.json, along with a coverage row for each of the 9 entry points. I ran no Foundry test. The first finding is checked against the v4-core source; the second rests on numbers from the math specialist that I did not re-run. Neither finding carries a proof file, since proofs are only required for critical or high findings.

Kept:

1. Medium: the buyback can make a valid swap revert (src/SherwoodPlayerHook.sol:154). Three specialists reported this, so it is merged into one finding. executeBuyback calls poolManager.sync(address(0)), which in v4-core clears the record of which currency the trader's router has paid in (PoolManager.sol:280-282). Some routers pay their tokens in before calling swap() and settle afterwards. With the slot cleared, their settle() credits nothing and the whole transaction reverts with CurrencyNotSettled. This happens only when the jar is full and the buyback works, which breaks "the swap still succeeds". It keeps happening for that router until another router's swap spends the jar. Fix: if a currency is already synced, skip the buyback and retry on a later swap.
2. Low: the fee depends on how the swap is specified (src/SherwoodPlayerHook.sol:97). On exact-output swaps, the 1% is taken from the net amount, so the jar gets about 0.99% of the ETH side instead of 1%. Traders can pick the cheaper form.

Dropped:

• 2M gas cap and Sherwood's board rescan: whether the buyback runs out of gas depends on the live Sherwood contract and its board size, which I can't reproduce here.
• Burned IMD costing the player their prize: this follows from Sherwood's own holding rule combined with the burn the brief explicitly asks for.
• No price limit on the buyback (sandwich risk): the brief asks for an exact-input swap with no price limit, and the README documents it.
• Rounding, wallet gas estimates, and the static-analysis leads: none of them showed a reproducible defect.

Coverage: the three Quiver ERC-20 functions, receive(), redeemFees() and unlockCallback() hold. afterSwap and executeBuyback point to finding 1, and beforeSwap to finding 2.

Both findings reproduced and are fixed. Build, the full suite with the verifier's fuzz seed, and forge fmt --check all pass.

Finding 1 (medium, synced-currency reset): fixed. I reproduced it with a router that syncs and transfers its QUIVER input before the swap and settles afterwards. With the jar at the threshold the sell reverted CurrencyNotSettled; with an empty jar it passed. The manager cannot be re-synced to the router's pre-transfer reserves, so nothing inside executeBuyback can repair the slot. The hook now reads the synced currency through TransientStateLibrary before the self-call. When a currency is synced it emits BuybackDeferred and returns, leaving the jar intact for the next swap that arrives with the slot clear. The prepaying router now sells successfully on a full jar, and a following ordinary swap plays the whole jar.

Finding 2 (low, fee base by swap mode): fixed. Exact-output forms charged 1/101 of the gross ETH leg while exact-input forms charged 1/100. A single _fee helper now divides by 100 on exact input and by 99 on exact output, which equals 1% of the gross leg exactly under floor division. The afterSwap partial-fill check uses the same helper.

Files changed:

• src/SherwoodPlayerHook.sol: deferral check, new event, fee helper.
• test/helpers/PrepayRouter.sol: new pre-syncing router.
• test/SherwoodPlayerHook.t.sol: two prepaying-router tests, a cross-mode fee-equivalence test, and updated exact-output and fuzz assertions.
• README.md and SECURITY.md: fee table, deferral behaviour, monitoring, and the limitation that a venue whose router always pre-syncs cannot tip the jar itself.
• .imd-responses.json: both findings answered as fixed.

Test results:

Suite	Result
33 tests across 4 suites, seed 0xee01…42cd	all pass

Nothing was committed, per the task rules.

The existing launch.json already satisfies every criterion, so no change was needed and the working tree stays clean.

What I verified

• Contract names match the repository: hook SherwoodPlayerHook, token Quiver with name "Sherwood Player", symbol "QUIVER", 18 decimals.
• Constructor arguments match the hook's declaration order, pool manager then token, written as "$poolManager" and "$token". The hook has no owner, factory or launch-number parameter, so no other placeholder applies.
• Permissions match what getHookPermissions returns exactly: beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta.
• Pool fields are the launch's own: native ETH as the zero-address paired currency, fee 12500, tick spacing 60, and the one-to-one initial price. The hook's own constants accept that fee and spacing in beforeInitialize.
• Notes are one string of 2139 characters, under the 4000 cap, and every address in the manifest is lowercase. The first field is "kind": "univ4_hook".

Checks run

forge build: ok (one lint note only)
FOUNDRY_FUZZ_SEED=0xee01…42cd forge test: 31 passed, 0 failed

No file was modified, and no findings were attached to this revision that called for a manifest change.

I updated my earlier tests to match the revised implementation, and all 63 tests now pass with forge build and forge test under the verifier's fuzz seed (0 failed, 0 skipped).

Why five tests were failing. The implementer changed two things since my last round, and my tests still expected the old behaviour:

• Fee: exact-output swaps now charge amount / 99 instead of / 100, so the fee is 1% of the total ETH leg (the ETH a buyer pays including the fee, or what the pool pays out before the fee comes off a sell).
• Deferral: if the trader's router has already called sync on a currency during the swap, the hook now skips the buyback and emits BuybackDeferred. The jar is kept and a later swap spends it.

What I changed, all under test/:

• Fee checks (SherwoodAdversarial.t.sol, SherwoodDeferred.t.sol, helpers/JarHandler.sol): the expected fee is now 1% of that total, rounded down. The tests work out that total from the PoolManager's Swap event and the trader's balance change, without copying the hook's /100 and /99 formulas. One new check confirms the fee is added on top of buys and taken out of sells.
• Pre-sync router tests (SherwoodAdversarial.t.sol): I split my old two-buybacks test in two.
  • One test keeps the plain router and checks that two buybacks can happen inside one transaction.
  • The new test uses a router that syncs before each swap. It checks that the router still settles, each full-jar swap emits BuybackDeferred with the right amount, the Sherwood pool is untouched and the whole jar is kept. The next ordinary trader then plays the entire jar.
  • A third test checks that nothing is deferred below 0.005 ETH.
• Invariant tests: the handler's trade now randomly picks routers with or without the pre-swap sync. When the jar is full, a pre-synced swap must defer and keep every wei. The fixed scenario test now walks through a deferral too. I split trade into helpers to get past a "stack too deep" compiler error.
• test/README.md: updated for the new fee rule and the deferral tests.

One info-level finding, in .imd-findings.json. The brief says whoever's trade tips the jar becomes the player. A trader whose router syncs before swapping never does: their swap is deferred and the next trader through an ordinary router plays the whole jar instead. The implementer documents this as deliberate, because without the deferral those routers' transactions would revert. My tests check that documented behaviour, and the new pre-sync test shows it happening. The consequence for the requester: trading venues whose routers always sync first can never put their traders on the Sherwood board.

I didn't change anything outside test/ except that findings file, and I didn't commit.

The findings file exists and is valid. It is hidden from git status by the repository's own exclude rule, and no other file was created or changed.

Both prior findings are fixed and confirmed.

• Sync clobber (medium, bd9fb3ea): _attemptBuyback now reads the manager's transient synced-currency slot, the same slot _settle consults, and defers with BuybackDeferred when a currency is synced. My original reproduction, a router doing sync, transfer, swap, settle, take with the jar at the threshold, now completes with all deltas settled. The author's test covers it exactly, and the full suite of 63 tests passes.
• Fee base (low, 063c5bea): exact-output legs now charge amount/99, which equals floor((amount+fee)/100) exactly under floor division, so every mode pays 1% of the gross ETH leg. The partial-fill check uses the same helper, and the fuzz conservation test asserts it.

One new reproducible defect, rated low, with a proof. Between the early return at the gasleft() <= GAS_RESERVE check and the checked subtraction gasleft() - GAS_RESERVE, the function now spends gas on the exttload call and the cold busy store. For a band of transaction gas limits about 23k wide, roughly 250,500 to 273,500 on the fixture, the subtraction underflows and the trader's swap reverts with a wrapped Panic(0x11) instead of skipping the attempt. Below that band the swap succeeds with the attempt skipped. Above it the swap succeeds with the attempt running. No funds are lost, but it breaks "the swap still succeeds" in exactly the region a wallet's buffer over an estimateGas result can land. The embedded proof sweeps gas limits, fails on this code at the first limit in the band, and passes on a copy patched to re-read gasleft() right before the subtraction. The band also existed last round with the busy store alone, which I missed then; the new call widened it.

One info note records the tester's observation that a trader whose swap tips the jar through a router that pre-syncs its ERC-20 input is never the player, since the deferral hands the jar to the next clear-slot trader. That is the documented trade-off of the fix I asked for, and no change is requested.

Coverage answers all nine entry points, plus rows for the two settled findings and the hook-delta invariant. The specialists' other leads from last round, the Sherwood gas cap and the burn-forfeit interaction, depend on live Sherwood code not in the tree and remain dropped as before.