Refused by Codex's safety filter

• mediumExact-input sells and exact-output buys deliver PVP instead of the required ETH feessrc/PvPadHook.sol:334

  The approved workflow requires fee delivery to EOAs as ETH and a pullable-ETH fallback for failed delivery. On the ETH/PVP pool, these two swap shapes select currency1, so _skim transfers PVP directly and never creates an ETH entitlement. A beneficiary contract that only accepts or withdraws ETH receives unusable token fees instead. test_exactInputSell_feeInPvp and test_exactOutputBuy_feeInPvp assert this conflicting behavior rather than the approved ETH delivery requirement.

  The documented mixed-currency limitation does not resolve that requirement conflict; the workflow recommends the three current permission flags but does not prohibit other swap-path permissions needed to implement ETH fees.

  Confirmed with a focused Foundry test using test/utils/Fixture.sol unchanged: use its seeded ETH/PVP pool at sqrtPriceX96 = 79228162514264337593543950336; Alice calls claimKing(alice) with 20000000000000000 wei; record Alice's ETH and PVP balances; Bob calls the fixture's sellExactIn(bob, 100000000000000000000), equivalent to SwapParams(false, -100000000000000000000, TickMath.MAX_SQRT_PRICE - 1).

  The swap succeeds.

  Actual: Alice receives exactly 1000000000000000000 PVP minor units, her ETH balance is unchanged, and pending(alice, address(0)) is zero.

  Expected under the workflow: the nonzero swap fee is delivered as ETH or credited as withdrawable ETH.

  Exact-output buys likewise select PVP; the existing test_exactOutputBuy_feeInPvp demonstrates that branch.

  whole reproduction

• lowLater Kings can collect fees documented as belonging to the first beneficiarysrc/PvPadHook.sol:387

  The contract's top-level NatSpec, README, and pre-King fee test promise that fees earned before the first King belong to the first beneficiary. claimKing does not reserve those fees or remember that beneficiary, and assignUnassigned reads the beneficiary at assignment time. Consequently, a later King can collect the entire accrued balance if assignment was delayed, including by preceding the first beneficiary's assignment transaction.

  The existing test assigns immediately after the first claim and misses this succession state. The function-level comment instead describes the current-beneficiary behavior, so the delivered ownership documentation is also inconsistent. Resolve the intended pre-King entitlement and make the implementation and tests agree with it.

  Confirmed with a focused Foundry test using test/utils/Fixture.sol unchanged: before any King exists, Bob buys with exactly 1000000000000000000 wei, creating unassigned(address(0)) = 10000000000000000.

  Alice calls claimKing(alice) with 20000000000000000 wei.

  Before assignUnassigned is called, Carol calls claimKing(carol) with 30000000000000000 wei.

  Anyone then calls assignUnassigned(address(0)); Carol calls withdraw(address(0), carol).

  Actual: Carol receives the full 10000000000000000 wei of pre-King fees and pending(alice, address(0)) remains zero.

  Expected under the first-beneficiary promise: those fees remain payable to Alice despite the later King change.

  whole reproduction

• lowBoth claim entry points specified by the workflow are absentsrc/PvPadHook.sol:444

  The approved interface specifies payable claim(address) for the King and claim(uint256,address,uint256,bytes32[]) for workers. The implementation exposes only claimKing and claimWorker, with no aliases or fallback. Calls using either specified selector therefore revert even when the bid or proof is valid.

  The exported ABI accurately reflects the implementation, but neither it nor the tests exercise the required selectors. README's unilateral renaming leaves clients following the approved interface incompatible; retaining the descriptive functions and adding the specified entry points would preserve existing behavior.

  Confirmed with a focused Foundry test.

  On a fresh fixture hook, Alice sends 20000000000000000 wei with abi.encodeWithSignature('claim(address)', alice): the low-level call returns false, king remains zero, and workerPot remains zero, although the bid exceeds the initial 10000000000000000 wei price.

  For the worker case, first fund the hook through claimKing(alice) with 20000000000000000 wei, then have the configured updater call setEpoch(hook.leaf(1, bob, 10000000000000000), 1760000000, 1760086400) at timestamp 1760000000.

  Call abi.encodeWithSignature('claim(uint256,address,uint256,bytes32[])', uint256(1), bob, uint256(10000000000000000), new bytes32).

  Actual: the call returns false and claimed(1, bob) stays false.

  Expected: the valid single-leaf claim pays Bob.

  Calling claimWorker with exactly those arguments succeeds, confirming the selector mismatch rather than an invalid proof or budget.

  whole reproduction