Refused by Codex's safety filter

• mediumZero-liquidity waiver makes the hook a no-op for a JIT LP that is the only active liquidity, which is the approved launch geometrysrc/JITPenaltyHook.sol:132

  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.

  whole finding

  Fresh pool at sqrtPriceX96 = 2^96 (tick 0).

  Seed: passive router adds liquidity 1000e18 in [-600,-60] (delta amount0 == 0, getLiquidity == 0).

  Roll 50 blocks.

  Same block: JIT router adds 1000e18 in [-60,60] (pays ~2.995e18 of each currency), then PoolSwapTest buy zeroForOne exact input 0.1 ether (tick after buy = -2, seed never entered), then JIT removes -1000e18.

  Observed: PenaltyWaived emitted, feesAccrued.amount0 = 299999999999999 (the entire 0.3% of 0.1 ETH), callerDelta.amount0 = 3095354955910780936 = principal + all fees, totalDonated = (0,0), getLiquidity == 0 after removal; a subsequent poke of the seed position returns feesAccrued == 0.

  Expected per the hook's purpose: 100% of 2.99999e14 wei donated at elapsed 0.

  Spec rule (3) mandates the observed behaviour, hence medium and a scope decision rather than a redo.

  whole reproduction

• lowA non-sole JIT LP can induce the waiver by swapping the price out of every other LP's range before removingsrc/JITPenaltyHook.sol:132

  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).

  whole finding

  Pool at tick 0.

  Passive adds 1e18 in [-600,600]; roll 10.

  Attacker adds 100e18 in [-600,600] (same block as the rest).

  Victim buys zeroForOne exact input 1 ether (tick -197).

  Attacker sells oneForZero exact input 50 JITP with sqrtPriceLimitX96 = getSqrtPriceAtTick(660): tick becomes 660, getLiquidity == 0.

  Attacker removes -100e18: PenaltyWaived emitted, totalDonated == (0,0), feesAccrued = (2970297029702970, 12104649651115097).

  Attacker then buys zeroForOne 5 ether with limit getSqrtPriceAtTick(-197) to restore the price (tick -197).

  Net attacker balance change over the whole sequence, valued 1:1: 12379000173901552.

  Honest control run without the push (remove at elapsed 0 straight after the victim swap): PenaltyDonated 2970297029702970 of currency0, net 9648983075312734.

  Expected: with another LP in the pool a same-block exit should forfeit the full 2.97e15; actual: the LP keeps it and pays ~2.4e14 in swap round-trip.

  whole reproduction

• lowDonation recipient set includes the penalized LP's own liquidity, so a dominant LP recaptures most of the penalty through pokes or a second saltsrc/JITPenaltyHook.sol:142

  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.

  whole finding

  Case 1 (mature sibling): pool at tick 0; passive adds 1e18 in [-600,600]; attacker adds 9e18 with salt 1; roll 10 blocks; attacker adds 90e18 with salt 2 and a victim buys zeroForOne exact input 1 ether in that block (fee 3e15 wei ETH).

  Attacker removes salt 2 at elapsed 0: feesAccrued.amount0 = 2699999999999999, PenaltyDonated 2699999999999999.

  Attacker pokes salt 1 (elapsed 10, no penalty): callerDelta.amount0 = 2699999999999999.

  Passive poke collects 299999999999999.

  Actual: attacker keeps 90% of the victim's fee at elapsed 0.

  Expected by the stated rule: 0% at elapsed 0.

  Case 2 (pokes): passive 1e18, attacker 99e18 in [-600,600], victim buys 1 ether, roll 1 block, attacker pokes 80 times (liquidityDelta 0) then removes.

  Attacker receives 2724504234807766 of its 2970297029702970 fee share (91.7%); passive ends with 275466726786241.

  Expected at elapsed 1: attacker 10% (2.97e14), 90% to others.

  whole reproduction

• lowPositionManager slippage checks double-subtract fees under this hook, so tight amountMin/amountMax bounds revert on the recommended routersrc/JITPenaltyHook.sol:117

  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.

  whole finding

  From test_removeAtElapsed0 state (passive 1e18 and lp 1e18 in [-600,600], one buy of 0.001 ether and one sell of 0.0005 ether, passive poked): lp removes -1e18 at elapsed 0.

  Independent principal0 = 29802074517953757, feesAccrued0 = 1499999999999, callerDelta0 = 29802074517953757.

  PositionManager would compute liquidityDelta - feesAccrued = 29800574517953758 and validateMinOut(amount0Min = 29802074517953757) reverts.

  Increase path after 20 more blocks and another trade pair: callerDelta0 = -29968075565809217 (the true principal), feesAccrued0 = 999999999999, PositionManager basis = -29969075565809216, so validateMaxIn(amount0Max = 29968075565809217) reverts.

  Source: PositionManager.sol lines 297-300, 342-345, 433-435 at the pinned revision.

  whole reproduction

• infoShared-router window resets and fee withholding are keyed on the router address; PoolModifyLiquidityTest lets any caller reset and penalize another user's positionsrc/JITPenaltyHook.sol:72

  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.

  whole finding

  test_sharedRouterSameSaltResetsAnotherUsersWindow: passive and lp routers seeded; roll 9 blocks; 0xBEEF calls lp.modify{value: 0.1 ether}(key, ModifyLiquidityParams(-600, 600, 1e18, 0)) through the same LiquidityRouter used by the original LP. lastAddedBlock(key.toId(), calculatePositionKey(lp, -600, 600, 0)) becomes the new block, so the original LP's removal one block later at what should have been elapsed 10 is instead penalized at elapsed 1 (90%) on all fees, including those the griefer's add just withheld.

  whole reproduction

• infoChecked and found correct: return-delta signs, principal isolation, zero-liquidity guard equivalence, poke/partial/new-salt paths, manifest and ABI consistencysrc/JITPenaltyHook.sol:92

  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.

  whole finding

  Not a defect. Verification commands: forge test (70 passed); python3 -c "import json;print(len(json.load(open('launch.json'))['notes']))" -> 3309; forge inspect src/JITPenaltyHook.sol:JITPenaltyHook abi --json compared equal to docs/abi/JITPenaltyHook.json; the delta accounting in test_removeAtElapsed{0,5,9,10} and testFuzz_feeSplitAndPrincipal matches the independent principal oracle in test/helpers/HookFixture.sol.