Approved workflow

Rule (3) of the approved workflow says a penalty is waived when in-range liquidity is zero after the removal, and the implementation does exactly that (line 132 emits PenaltyWaived and returns -held). The consequence on the approved launch geometry is that the hook deters nothing for the launch's first buys: the factory seeds one-sided JITP liquidity strictly below the opening tick ([-600,-60] in the rehearsal), so active liquidity at tick 0 is zero.

A JIT LP that adds liquidity around tick 0 in the same block as the first buy becomes the only active liquidity; a buy that does not push the price down to the seed's upper tick trades entirely against the JIT liquidity, and the JIT LP's same-block removal leaves state.liquidity == 0, so the full 0.3% fee is paid out with elapsed == 0 and nothing is donated. The seed LP earns nothing.

The same holds later whenever a sell has pushed the price above the seed range (no liquidity above it, so price jumps to the swap limit): every JIT at that price is penalty-free until some passive LP adds liquidity there.

This is implemented to spec, so it is a design finding, not an implementation error, and the fix needs a scope decision: (a) keep the no-revert guarantee but escrow the penalty as hook claims and donate it on the next callback when active liquidity exists (changes rule 3: LP no longer receives the waived amount), or (b) have the deployment seed span the opening tick so active liquidity is never zero (a factory configuration change, still leaves the post-sell case), or (c) accept and document that the hook only bites while passive liquidity is in range.

The launch rehearsal test (test_launchRehearsalFirstBuyIntoEthlessPoolThenSell) does not include a JIT front-run of the first buy, so the suite never observes this.

Same root cause as the previous finding, with passive LPs present. Because the waiver condition is the pool's current active liquidity, not whether other LPs exist, an LP whose window is open can (1) swap the price past the range edge of all other positions (once liquidity hits zero the price jumps to the limit at no cost), (2) remove, hitting the zero-liquidity waiver and receiving 100% of fees, then (3) swap back through the passive liquidity.

The cost is the round-trip fee and impact on the other LPs' reserves between the current price and their range edge; the gain is the whole penalty. In the reproduction below the induced-waiver sequence nets 2.73e15 more than the honest penalized exit (the penalty was 2.97e15, the round trip cost ~2.4e14). Profitability scales with the ratio of the JIT's fee share to the depth of other liquidity near the range edge, which is exactly the situation in which JIT is attractive.

REVIEW-NOTES mentions moving the price into a self-controlled range as an economic limit but no test exercises it and the notes do not quantify it. Fix options are the same scope decision as above (escrow instead of waive).

The penalty is donated pro rata to all active liquidity, which includes any liquidity the penalized actor still has in range: the remainder of the same position after a poke or partial removal, or a second position under another salt that is already outside its window. Two concrete consequences.

1. Same-block JIT with a mature sibling position: a JIT salt removed at elapsed 0 is penalized 100%, but the actor's mature salt immediately collects its share of the donation without penalty, so the deterrence is proportional only to other LPs' share of active liquidity.
2. Repeated pokes at elapsed >= 1: each poke pays (1-r) of current fees to the LP and donates r, of which the LP's remaining liquidity re-earns share s; the LP retains (1-r)/(1-s*r) of the fees instead of (1-r). At elapsed 1 with a 99% share that is about 92% instead of 10%. Each poke costs roughly 110k gas, so this pays whenever the fee at stake exceeds ~80 pokes of gas, i.e. for exactly the swaps JIT targets. REVIEW-NOTES documents both limits qualitatively ("not Sybil resistant", "repeated pokes can recapture"); there is no test quantifying them and the launch.json notes do not mention the magnitude. This is inherent to the approved donate-to-pool design (OpenZeppelin's LiquidityPenaltyHook has the same property), so it is reported as a documented economic limit and not a blocking defect; resolving it would require a different penalty sink (for example an escrow that is only released to liquidity that was active before the window opened), which is a scope decision.

The workflow and docs recommend v4-periphery PositionManager as the LP router. At the pinned revision (444c526b) PositionManager._increase, _decrease and _burn validate slippage on (liquidityDelta - feesAccrued), where liquidityDelta is the caller delta already reduced by this hook's returned delta.

With the hook, the add callerDelta is P (fees withheld) and the removal callerDelta is P + F + W - Q, so PositionManager's principal estimate becomes P - F on increase and P + W - Q - F on decrease/burn; both are off by the fee amount the hook moved.

An increaseLiquidity whose amount0Max/amount1Max equals the actual principal reverts with MaximumAmountExceeded whenever the position has any uncollected fees, and a decreaseLiquidity/burn whose amountMin equals the actual principal reverts with MinimumAmountInsufficient whenever the penalty exceeds previously withheld fees (always true on a fresh JIT exit within the window).

No funds are at risk and users can widen the bounds, but it contradicts the requirement that a removal never reverts because of the hook when the recommended router is used with tight bounds, and it is not documented in README, ABI.md or REVIEW-NOTES. A documentation note ("set PositionManager bounds against principal minus the maximum fee movement") resolves it; changing the hook to return zero delta would break the withholding rule, so no code change is proposed.

Position keys are Position.calculatePositionKey(sender, tickLower, tickUpper, salt) where sender is the router.

On a shared, ownerless router such as PoolModifyLiquidityTest (deployed on Sepolia) any account can add 1 wei of liquidity to another user's (ticks, salt) tuple; that resets lastAddedBlock and withholds all fees the add auto-collects, so a griefer repeating this every 9 blocks keeps the victim's fees permanently inside the window and every collection loses at least 10%.

Under that router the griefer can also poke or remove the shared position outright, which is a router-custody problem rather than a hook problem. The workflow explicitly asks for this to be documented and for PositionManager (tokenId salt, onlyIfApproved) to be recommended; README, REVIEW-NOTES, DEPLOYMENT.md and launch.json notes all do so, and test_sharedRouterSameSaltResetsAnotherUsersWindow reproduces the reset. Reported as a confirmed trust assumption, not a defect.

The website only offers a swap form, so no shared LP router is promoted by this launch.

Delta signs: core computes callerDelta = principal + feesAccrued and subtracts the hook delta; PoolManager.mint debits the hook by F and the returned +F credits it, so the add leaves the hook at zero and the LP at exactly P. On removal burn credits W, donate debits Q, and the returned Q - W nets to zero; the LP receives P + F + W - Q with 0 <= Q <= F + W because Q = ceil(total * (10 - elapsed) / 10) with elapsed < 10.

Neither callback reads the principal delta, so the hook can neither take principal nor pay out more than fees; SafeCast rejects negative fee components and BalanceDelta add/sub are overflow-checked.

The waiver condition poolManager.getLiquidity(poolId) == 0 reads the same state.liquidity slot that Pool.donate checks (NoLiquidityToReceiveFees), and it is evaluated after core has removed the liquidity, so the donate path cannot revert on zero liquidity; zero total fees skip donate and both events.

Pokes and partial removals assess all fees at the unchanged lastAddedBlock; a new salt cannot release another salt's withholding; two pools are independent; BaseHook.onlyPoolManager guards both return-delta callbacks and the address bits are validated in the constructor. launch.json: notes are 3309 characters (limit 4000), permissions equal getHookPermissions, constructorArgs is the single Sepolia PoolManager address in declaration order, initialPrice is 2^96, token has no constructor arguments and name/symbol/decimals match JITP. docs/abi/JITP.json and docs/abi/JITPenaltyHook.json are byte-equal to forge inspect output.

All 70 committed tests pass; invariant campaign 64 x 64 with zero reverts.

Not covered here: a Sepolia fork rehearsal against the live PoolManager, which the protected suite defers to the admission gate.