Refused by Codex's safety filter

• mediumPer-call buyback cap is sized for a native-ETH pair but the manifest pairs PANIC with IMD, so burning the bucket costs more gas than it burnssrc/PanicHook.sol:98

  MAX_BUYBACK_SPEND is 1e18 minor units of whatever the paired currency is, and README.md:199 states the assumption behind it: 'The paired currency is native ETH (or another 18-decimal currency)'. launch.json:26 pairs the pool with 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, which on-chain reports symbol IMD, name Identity.md, 18 decimals and a total supply of 4,116,877.76 tokens (read via cast call against three public Ethereum RPCs on 2026-10-07; public price trackers quote it near 8.5 USD).

  So a buyback call can spend at most 1 IMD, roughly 8 to 9 USD, while a measured buybackAndBurn() call costs 246,532 gas cold and 177,383 gas warm (scratch test, forge gas accounting, PANIC/ERC-20 pool with full-range liquidity). On Ethereum mainnet at 20 gwei and 4,000 USD/ETH that is 14 to 20 USD of gas per call, i.e. the caller pays about twice the value they burn.

  The brief's burn outlet ('10% accrues to a burn bucket: a permissionless buybackAndBurn() swaps it for PANIC') and the 'No dust may stay stuck' requirement therefore degrade into an outlet nobody is economically able to operate: the burn bucket grows with every taxed swap and stays there. The README's operational note ('call buybackAndBurn() repeatedly (1 ETH per call...)') and its gas remarks were written for an ETH pair and do not hold for this manifest.

  If the launch chain is an L2 the per-call gas is cheap and the issue is reduced to an inconvenience (hundreds of calls per crash), but the cap no longer bounds anything meaningful either way: it is 400x smaller in value than the ETH-denominated cap the design reasoned about. The constant should be chosen in terms of the actual paired currency (or expressed relative to pool liquidity), and the README assumption corrected.

  whole finding

  State: PANIC/IMD pool (PANIC as currency1, like the manifest's 18-decimal ERC-20 pair), full-range liquidity 1e22, price 1:1.

  1. One sell drives the price 20% below the reference: burnBucket becomes 21,114,561,800,016,824,287 minor units (21.1 IMD, about 180 USD).
  2. Call buybackAndBurn(): spent == 1e18 exactly (the cap), gas used 246,532; a second call in the same block uses 177,383 gas.
  3. Draining the bucket needs 22 calls, about 4.1M gas; at 20 gwei on mainnet that is about 0.08 ETH (320 USD) of gas to burn 180 USD of PANIC. Expected per the brief: a permissionless outlet that lets the bucket be burned so no value stays stuck. Actual: every rational caller leaves the bucket alone, and it keeps accruing 10% of every hook fee indefinitely. Scratch test used: test/scratch/Gas.t.sol (setUp: _setUpErc20Pool(false, SQRT_PRICE_1_1); _fundAndApprove(); _addFullRangeLiquidity(1e22); then _sellToDrawdown(2000); _nextBlock(12); measure gasleft() around hook.buybackAndBurn()).

  whole reproduction

• lowReference tick is floored to a whole tick, so a sell landing 4.99% below the true one-hour mean is charged the 10% tier instead of 2%src/PanicHook.sol:750

  _reference() computes the mean tick over the window and _meanTick (lines 783-786) floors it toward negative infinity; referenceSqrtPriceX96() then uses TickMath.getSqrtPriceAtTick(tick). The fractional part of the mean (up to one tick, i.e. up to 1 bp of price) is dropped, so the reference the fee tiers are judged against is not the geometric mean the brief describes.

  With PANIC as currency1 the floored reference is a higher PANIC price than the true mean, overstating drawdown by up to 1 bp, which pushes a sell that truly ends 4.99% down into the 10% tier (a 5x fee). With PANIC as currency0 the bias is the other way (understated by up to 1 bp), so a sell truly ending 5.00% down pays 2%. Because the orientation depends on the yet-unknown CREATE address of the PANIC token relative to 0xd34a..., either bias can be the production one.

  The brief's required test 'tiers switch exactly at 5%, 15%, 30% drawdown' is only met relative to the quantized reference, which README.md documents. Bounded impact (1 bp band at each threshold), but it is a real mispricing at the boundary that sqrt-price interpolation between the two adjacent ticks (weighting getSqrtPriceAtTick(t) and getSqrtPriceAtTick(t+1) by the remainder) would remove.

  whole finding

  PANIC/ETH pool, price 1:1, full-range liquidity 1e22.

  Block +1800 s: sell PANIC until the pool sits exactly at TickMath.getSqrtPriceAtTick(1).

  Block +1800 s more: true mean tick over the hour is 0.5; hook.referenceTick() == 0 and hook.referenceSqrtPriceX96() == 2^96.

  Let trueRef = sqrt(2^96 * getSqrtPriceAtTick(1)) (sqrt price of tick 0.5).

  Pick target = the sqrt price exactly 5% below the floored reference: hook.drawdownBps(target, 2^96, false) == 500 but hook.drawdownBps(target, trueRef, false) == 499.

  Sell PANIC with sqrtPriceLimitX96 = target (exact input, large amount).

  Observed: gross paired output 252,705,692,687,911,366,574; fee charged 25,270,569,268,791,136,657 (10%).

  Expected against the true one-hour mean (4.99% down, the brief's '< 5%' band): 5,054,113,853,758,227,331 (2%).

  The existing test_referenceUsesDocumentedWholeTickRounding shows the same 499-vs-500 split at the view level.

  whole reproduction

• lowManifest initial price values 1 PANIC at 1 IMD, implying a launch valuation of 1e9 IMD against a total IMD supply of 4.1Mlaunch.json:29

  initialPrice is 2^96, which is one raw currency1 unit per raw currency0 unit. Both the launch token and the paired IMD token have 18 decimals, so in either pool orientation this means 1 PANIC = 1 IMD at launch. The manifest's own notes say the value was carried over from the deployment test ('Tick spacing 250 and initial sqrtPriceX96 2^96 follow the deployment test'), not chosen for this pair, and README.md:165 still describes the pool as 'PANIC paired with native ETH'.

  PanicMonkeys mints 1,000,000,000 PANIC; at 1 IMD each the implied fully diluted value is 1e9 IMD, about 243 times the entire IMD supply read on-chain (4,116,877.76).

  The hook anchors its one-hour reference at this initialization tick (afterInitialize stores initialTick and _reference() assumes it prevailed for the hour before launch), so if the factory seeds PANIC-only liquidity above this price the first trades will be judged against a reference far below any traded price, and every sell in the first hour pays the 2% tier regardless of how far it drops from the opening trades.

  I cannot see the launch policy's seed amounts, so I report this as a price that has no stated economic basis for this pair rather than as a proven misconfiguration; the manifest author should set initialPrice from the intended PANIC/IMD opening valuation.

  whole finding

  Decode launch.json: pairedCurrency = IMD (18 decimals), token decimals = 18, initialPrice = 79228162514264337593543950336 = 2^96 -> sqrtPrice 1.0 -> price 1 PANIC per IMD in either orientation.

  With TOTAL_SUPPLY = 1e27 (PanicMonkeys.sol:14), implied valuation = 1e9 IMD; IMD totalSupply() on mainnet = 4,116,877,757,721,000,000,000,000 (4.1M).

  A two-sided seed of even 1% of the PANIC supply at this price would need 10M IMD, more than exists.

  Expected: an initial price derived from the launch's PANIC/IMD valuation and the seed amounts.

  Actual: a placeholder from the ETH test fixture.

  whole reproduction

• lowExact-output sells are rejected, so any router that quotes a sell by desired paired output cannot trade this poolsrc/PanicHook.sol:323

  The brief says the sell fee is taken 'from the output on sells (afterSwap return delta)'. For an exact-output sell the paired output is the specified currency, which a v4 afterSwap delta cannot adjust, so beforeSwap reverts the whole swap. The same mechanism makes afterSwap revert fee-bearing exact-input buys that fill partially (line 356, PartialExactInputBuyNotSupported) because the fee was reserved from the specified input in beforeSwap.

  Both are documented in README.md as integration limitations and neither loses funds, but they are user-facing failures that the brief does not list among the accepted ones: a seller using an aggregator's exact-output route, or a dip buyer whose router sets a binding sqrtPriceLimitX96 on an exact-input buy, gets a revert instead of a taxed trade.

  An alternative that keeps the brief's economics is to take the sell fee in the unspecified (PANIC) side for exact-output sells converted at the post-swap price, or to document the restriction in the manifest notes so routers can be configured.

  whole finding

  PANIC/ETH pool at 1:1 with full-range liquidity.

  Call swapRouter.swap with zeroForOne = false (sell PANIC), amountSpecified = +1e18 (exact output of 1 ETH), sqrtPriceLimitX96 = MAX_SQRT_PRICE - 1.

  Expected per the brief: the sell executes and 2% of the 1 ETH output is taken as hook fee.

  Actual: the PoolManager reverts with WrappedError(hook, beforeSwap.selector, ExactOutputSellNotSupported, HookCallFailed) (existing test test_exactOutputSellIsRejected).

  Second case: after _sellToDrawdown(1000), an exact-input buy of 100 ETH with sqrtPriceLimitX96 = price - price/10000 reverts with PartialExactInputBuyNotSupported (existing test test_partialDipBuyRevertsWithoutChargingOrMovingThePool).

  whole reproduction

Failed on the agent's machine.

Failed on the agent's machine.

• mediumA seller recaptures up to 99% of the 30% LP donation on their own sell with same-transaction JIT liquidity at the post-sell tick, cutting the effective sell tax (20% tier becomes about 14%)src/PanicHook.sol:672

  _split donates the LP share inside afterSwap to whatever liquidity is in range at the post-swap tick. A seller controls that tick (through sqrtPriceLimitX96) and can, in the same transaction, add a narrow position whose lower edge is the end tick, sell, and remove the position.

  PoolManager.donate pays feeGrowth pro rata to in-range liquidity, so with liquidity far above the resident liquidity the seller's own position receives almost the whole donation of the seller's own hook fee. The capital is only needed for one transaction (flash-loanable) and the self-trade across the edge is negligible when the sell stops one sqrt-price unit above the range's lower edge.

  Result: 30% of the hook fee flows straight back to the seller, so the 2/10/20/30% schedule is effectively 1.4/7/14/21% for any seller who wraps the sell in a JIT position. The brief's 'No exemptions for any address' and 'punishes selling while the price is down' are weakened for sophisticated sellers, and the LP share meant for resident liquidity providers is paid to the taxed party.

  README.md only acknowledges JIT exposure for third parties and for the fallback bucket; the self-recapture and its effect on the sell tax are not stated. This is not the accepted sell-splitting behaviour (no per-wallet tracking is needed to address it).

  A minimal fix that keeps the required donate mechanism: do not donate in the taxed swap's own transaction; keep the LP share in donationBucket and flush it at the next block's first observation (_observe) or via donateToLiquidityProviders, so capturing it requires holding liquidity across blocks with real price exposure. Alternatively require donationBucket to be flushed only when the block of accrual has passed.

  whole finding

  PANIC/native-ETH pool (PANIC = currency1), initialized at sqrtPriceX96 2^96, fee 12500, tickSpacing 100, full-range liquidity 1e22, fresh hook at a mined address with oracleFund 0x788C311500FD3C15b8e44d6e2935fe7fF13E674b.

  Baseline: one exact-input sell of PANIC (zeroForOne=false, amountSpecified=-1e26) with sqrtPriceLimitX96 = TickMath.getSqrtPriceAtTick(2200)+1 ends at tick 2200 (19.75% drawdown, 20% tier): hook fee 208,321,875,861,255,582,992 wei, donated in-swap 62,496,562,758,376,674,897 wei, seller nets 833,287,503,445,022,331,968 wei.

  JIT: same state, the seller first adds liquidity 1e24 in ticks [2200, 2300] (costs 4,467,793,134,144,645,995,541 wei of ETH for one transaction), performs the identical sell, then removes the position.

  Seller's net ETH is 895,165,288,354,306,168,498 wei, i.e. 61,877,784,909,283,836,530 wei more than the plain seller = 99.0% of the donation and 29.7% of the hook fee; the effective tax on the gross output falls from 20.0% to 14.1%.

  Expected: liquidity that exists only for the seller's own transaction earns none of the seller's tax.

  Actual: it receives 99% of the LP share.

  Proof: test/scratch/JitRecapture.t.sol (forge test --match-path test/scratch/JitRecapture.t.sol) fails with 'a seller recaptures their own LP donation with same-transaction liquidity: 895165288354306168498 > 833287503445022331968'.

  whole reproduction
  proof · a Foundry test the fix has to pass

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {PoolManager} from "v4-core/src/PoolManager.sol";
  import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
  import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
  import {PoolKey} from "v4-core/src/types/PoolKey.sol";
  import {PoolId} from "v4-core/src/types/PoolId.sol";
  import {Currency, CurrencyLibrary} from "v4-core/src/types/Currency.sol";
  import {ModifyLiquidityParams, SwapParams} from "v4-core/src/types/PoolOperation.sol";
  import {StateLibrary} from "v4-core/src/libraries/StateLibrary.sol";
  import {TickMath} from "v4-core/src/libraries/TickMath.sol";
  import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol";
  import {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";
  import {PanicMonkeys} from "src/PanicMonkeys.sol";
  import {PanicHook} from "src/PanicHook.sol";
  import {HookMiner} from "src/HookMiner.sol";
  import {HookFlags} from "src/HookFlags.sol";
  
  /// @notice A seller who adds a narrow liquidity position at the tick where their own sell ends, in the same
  /// transaction, receives most of the 30% LP donation that `_split` pays out inside `afterSwap`, and withdraws it
  /// right after. The seller's net paired proceeds exceed a plain seller's by most of the donation.
  /// Fails on the current code; passes once the LP share can no longer be captured by same-transaction liquidity.
  contract JitRecaptureTest is Test {
      using StateLibrary for IPoolManager;
  
      uint160 constant SQRT_PRICE_1_1 = 79228162514264337593543950336;
      int24 constant TICK_SPACING = 100;
      address constant ORACLE_FUND = 0x788C311500FD3C15b8e44d6e2935fe7fF13E674b;
  
      PoolManager manager;
      PanicMonkeys panic;
      PanicHook hook;
      PoolSwapTest swapRouter;
      PoolModifyLiquidityTest lpRouter;
      PoolKey key;
      PoolId poolId;
  
      receive() external payable {}
  
      function setUp() public {
          vm.warp(1_800_000_000);
          vm.roll(1_000);
          manager = new PoolManager(address(this));
          panic = new PanicMonkeys();
          swapRouter = new PoolSwapTest(IPoolManager(address(manager)));
          lpRouter = new PoolModifyLiquidityTest(IPoolManager(address(manager)));
  
          bytes memory creationCode = abi.encodePacked(
              type(PanicHook).creationCode, abi.encode(IPoolManager(address(manager)), address(panic), ORACLE_FUND)
          );
          (address predicted, bytes32 salt) =
              HookMiner.find(address(this), HookFlags.PANIC_HOOK, creationCode, 0, 1_000_000);
          hook = new PanicHook{salt: salt}(IPoolManager(address(manager)), address(panic), ORACLE_FUND);
          assertEq(address(hook), predicted);
  
          // PANIC / native ETH pool: ETH is currency0, PANIC is currency1.
          key = PoolKey({
              currency0: CurrencyLibrary.ADDRESS_ZERO,
              currency1: Currency.wrap(address(panic)),
              fee: 12_500,
              tickSpacing: TICK_SPACING,
              hooks: IHooks(address(hook))
          });
          poolId = key.toId();
          manager.initialize(key, SQRT_PRICE_1_1);
  
          vm.deal(address(this), 1e27);
          panic.approve(address(swapRouter), type(uint256).max);
          panic.approve(address(lpRouter), type(uint256).max);
          _addLiquidity(TickMath.minUsableTick(TICK_SPACING), TickMath.maxUsableTick(TICK_SPACING), 1e22);
      }
  
      function _addLiquidity(int24 lower, int24 upper, int256 liquidityDelta) internal {
          lpRouter.modifyLiquidity{value: liquidityDelta > 0 ? 1e25 : 0}(
              key, ModifyLiquidityParams({tickLower: lower, tickUpper: upper, liquidityDelta: liquidityDelta, salt: 0}), ""
          );
      }
  
      /// @dev Exact-input sell of PANIC (oneForZero) up to a price limit.
      function _sellPanicToPrice(uint160 limit) internal {
          swapRouter.swap(
              key,
              SwapParams({zeroForOne: false, amountSpecified: -int256(1e26), sqrtPriceLimitX96: limit}),
              PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false}),
              ""
          );
      }
  
      function test_sameTransactionJitLiquidityMustNotRecaptureTheSellersOwnTax() public {
          // The 20% tier sits at about tick 2231 from a 1:1 start. Both sellers stop at tick 2200 (19.75% down,
          // still the 20% tier).
          int24 lower = 2200;
          int24 upper = 2300;
          uint160 stopAt = TickMath.getSqrtPriceAtTick(lower) + 1;
  
          uint256 snap = vm.snapshotState();
  
          // Plain seller.
          uint256 before = address(this).balance;
          _sellPanicToPrice(stopAt);
          uint256 plainGain = address(this).balance - before;
          uint256 plainFee = hook.totalAccruedFees() + hook.totalDonated();
          uint256 plainDonation = hook.totalDonated();
          assertGt(plainDonation, 0, "the sell's LP share was donated in-swap");
  
          vm.revertToState(snap);
  
          // JIT seller: 100x the resident liquidity in a narrow range whose lower edge is the end tick,
          // added before the sell and removed right after (atomic in practice, flash-loanable).
          before = address(this).balance;
          _addLiquidity(lower, upper, int256(1e24));
          _sellPanicToPrice(stopAt);
          (, int24 tickAfter,,) = IPoolManager(address(manager)).getSlot0(poolId);
          assertEq(tickAfter, lower, "the sell ends inside the JIT range");
          _addLiquidity(lower, upper, -int256(1e24));
          uint256 jitGain = address(this).balance - before;
  
          emit log_named_uint("plain seller: hook fee", plainFee);
          emit log_named_uint("plain seller: LP donation", plainDonation);
          emit log_named_uint("plain seller: net ETH", plainGain);
          emit log_named_uint("JIT seller:   net ETH", jitGain);
          if (jitGain > plainGain) {
              emit log_named_uint("JIT seller recaptured (wei)", jitGain - plainGain);
              emit log_named_uint("as share of the donation (bps)", (jitGain - plainGain) * 10_000 / plainDonation);
          }
          // Expected: liquidity that exists only for the seller's own transaction earns nothing of the seller's tax.
          assertLe(jitGain, plainGain, "a seller recaptures their own LP donation with same-transaction liquidity");
      }
  }

  whole proof

• lowA burn bucket too small to buy one PANIC unit (for example one paired minor unit) cannot be cleared by any permissionless outlet, contrary to 'No dust may stay stuck' (merged: audit_math and audit_flosrc/PanicHook.sol:501

  Every non-zero burn bucket must be cleared by an internal swap that returns at least one PANIC unit. With the required 12500 LP fee a one-unit exact-input swap has its whole input consumed by the rounded-up LP fee and returns zero PANIC, so both buybackAndBurn overloads revert BuybackBelowReference(0,1) and roll back. claimOracleFund and donateToLiquidityProviders cannot reach the burn bucket.

  The balance stays accounted (the hook keeps the ERC-6909 claim) and becomes spendable only if further taxed swaps top up the bucket, so this is dust-level and not a loss, but it leaves the final bucket unclearable without new trading. Same mechanism applies to any bucket below the PANIC-per-unit price.

  Possible fix that keeps the 98% floor: let buybackAndBurn accept a caller top-up (msg.value / transferFrom of the paired currency) merged with the bucket, or sweep a bucket below a documented dust threshold into the oracle fund.

  whole finding

  PANIC/native-ETH pool at 2^96, fee 12500, tickSpacing 100, full-range liquidity 1e22.

  Sell exactly 600 PANIC minor units (zeroForOne=false, amountSpecified=-600, no price limit): delta amount0=+580, amount1=-600, gross paired output 591, hook fee floor(591*200/10000)=11, oracleFundBucket=7, totalDonated=3, burnBucket=1.

  Next block, +3600 s: claimOracleFund() pays the 7 units; the hook now holds exactly 1 claim unit and burnBucket==1. buybackAndBurn() and buybackAndBurn(1) both revert BuybackBelowReference(0,1); donateToLiquidityProviders() reverts NothingToDonate; buybackAndBurn(0) reverts NothingToBuyBack.

  Expected per the brief: every accrued unit has a permissionless clearing path.

  Actual: totalAccruedFees() stays 1 forever unless new fees accrue.

  Proof: test/scratch/DustBucket.t.sol fails with 'accrued dust stays stuck in the burn bucket: 1 != 0'.

  whole reproduction
  proof · a Foundry test the fix has to pass

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {PoolManager} from "v4-core/src/PoolManager.sol";
  import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
  import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
  import {PoolKey} from "v4-core/src/types/PoolKey.sol";
  import {Currency, CurrencyLibrary} from "v4-core/src/types/Currency.sol";
  import {ModifyLiquidityParams, SwapParams} from "v4-core/src/types/PoolOperation.sol";
  import {TickMath} from "v4-core/src/libraries/TickMath.sol";
  import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol";
  import {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";
  import {PanicMonkeys} from "src/PanicMonkeys.sol";
  import {PanicHook} from "src/PanicHook.sol";
  import {HookMiner} from "src/HookMiner.sol";
  import {HookFlags} from "src/HookFlags.sol";
  
  /// @notice A burn bucket of one paired minor unit cannot be cleared by any permissionless outlet: the 1.25% LP
  /// fee rounds a one-unit swap's usable input to zero, the buyback returns zero PANIC and reverts, and the other
  /// outlets cannot touch the burn bucket. Fails on the current code; passes once accrued dust has a clearing path.
  contract DustBucketTest is Test {
      uint160 constant SQRT_PRICE_1_1 = 79228162514264337593543950336;
      int24 constant TICK_SPACING = 100;
      address constant ORACLE_FUND = 0x788C311500FD3C15b8e44d6e2935fe7fF13E674b;
  
      PoolManager manager;
      PanicMonkeys panic;
      PanicHook hook;
      PoolSwapTest swapRouter;
      PoolModifyLiquidityTest lpRouter;
      PoolKey key;
  
      receive() external payable {}
  
      function setUp() public {
          vm.warp(1_800_000_000);
          vm.roll(1_000);
          manager = new PoolManager(address(this));
          panic = new PanicMonkeys();
          swapRouter = new PoolSwapTest(IPoolManager(address(manager)));
          lpRouter = new PoolModifyLiquidityTest(IPoolManager(address(manager)));
  
          bytes memory creationCode = abi.encodePacked(
              type(PanicHook).creationCode, abi.encode(IPoolManager(address(manager)), address(panic), ORACLE_FUND)
          );
          (address predicted, bytes32 salt) =
              HookMiner.find(address(this), HookFlags.PANIC_HOOK, creationCode, 0, 1_000_000);
          hook = new PanicHook{salt: salt}(IPoolManager(address(manager)), address(panic), ORACLE_FUND);
          assertEq(address(hook), predicted);
  
          key = PoolKey({
              currency0: CurrencyLibrary.ADDRESS_ZERO,
              currency1: Currency.wrap(address(panic)),
              fee: 12_500,
              tickSpacing: TICK_SPACING,
              hooks: IHooks(address(hook))
          });
          manager.initialize(key, SQRT_PRICE_1_1);
  
          vm.deal(address(this), 1e27);
          panic.approve(address(swapRouter), type(uint256).max);
          panic.approve(address(lpRouter), type(uint256).max);
          lpRouter.modifyLiquidity{value: 1e25}(
              key,
              ModifyLiquidityParams({
                  tickLower: TickMath.minUsableTick(TICK_SPACING),
                  tickUpper: TickMath.maxUsableTick(TICK_SPACING),
                  liquidityDelta: int256(1e22),
                  salt: 0
              }),
              ""
          );
      }
  
      function test_oneUnitBurnBucketHasAPermissionlessClearingPath() public {
          // Sell 600 PANIC minor units: gross output 591, hook fee 11 -> oracle 7, donated 3, burn 1.
          swapRouter.swap(
              key,
              SwapParams({zeroForOne: false, amountSpecified: -600, sqrtPriceLimitX96: TickMath.MAX_SQRT_PRICE - 1}),
              PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false}),
              ""
          );
          assertEq(hook.burnBucket(), 1, "one unit accrued to the burn bucket");
  
          // An hour later, flat price: every outlet is tried.
          vm.roll(block.number + 1);
          vm.warp(block.timestamp + 3600);
          hook.claimOracleFund();
          (bool okDonate,) = address(hook).call(abi.encodeWithSignature("donateToLiquidityProviders()"));
          okDonate;
          (bool okBuyback, bytes memory ret) = address(hook).call(abi.encodeWithSignature("buybackAndBurn()"));
          if (!okBuyback) emit log_named_bytes("buybackAndBurn() reverted with", ret);
          (bool okBuybackOne,) = address(hook).call(abi.encodeWithSignature("buybackAndBurn(uint256)", uint256(1)));
          okBuybackOne;
  
          emit log_named_uint("burnBucket after every outlet", hook.burnBucket());
          emit log_named_uint("claims still held by the hook", manager.balanceOf(address(hook), 0));
          assertEq(hook.totalAccruedFees(), 0, "accrued dust stays stuck in the burn bucket");
      }
  }

  whole proof

• lowThe 98% buyback floor is applied to the already-floored reference quote, so a small buyback can succeed while receiving less than 98% of the exact reference-implied PANICsrc/PanicHook.sol:499

  pairedToPanicAtSqrtPrice rounds the reference quote down to a whole PANIC minor unit before the 98% minimum is computed, so minimum = ceil(0.98 * floor(q)) which can be one unit below ceil(0.98 * q). For tiny buybacks this lets the call pass when the live price is more than 2% above the reference, which the brief says must revert.

  The error is bounded to less than one PANIC minor unit per call and cannot compound, so impact is dust-level; it is a guarantee that is slightly off rather than a loss.

  Fix: compute minimum = ceil(spent * num^2 * 9800 / (den^2 * 10000)) in full precision (fold the 98% into the mulDiv chain) and keep the 'at least 1' rule.

  PANIC/native-ETH pool at 2^96, fee 12500, tickSpacing 100, full-range liquidity 1e22, block 1000 / timestamp 1800000000.

  (1) Sell 1e18 PANIC (no limit) to fund the burn bucket (burnBucket = 1,974,804,988,007,434).

  (2) Buy with amountSpecified=-1e24 and sqrtPriceLimitX96=11453882584939555244670964355.

  (3) Roll one block and warp +3600 s so the reference equals that price: referenceSqrtPriceX96() = 11453879819504963640314164846.

  (4) Buy with amountSpecified=-1e24 and sqrtPriceLimitX96=11285843134733390162692706488, leaving the live PANIC price 3.00% above the reference (ref^2/live^2 = 1.0300).

  (5) buybackAndBurn(1000).

  Exact reference quote = 1000 * ref^2 / 2^192 = 20.899989 PANIC units, 98% of that = 20.48, so the minimum must be 21.

  The hook uses floor = 20 and minimum = ceil(20*0.98) = 20, receives 20 and succeeds, emitting BuybackAndBurn(1000, 20, 20).

  Expected: revert BuybackBelowReference(20, 21).

  Proof: test/scratch/BuybackFloorRounding.t.sol fails with 'next call did not revert as expected'.

  whole reproduction
  proof · a Foundry test the fix has to pass

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {PoolManager} from "v4-core/src/PoolManager.sol";
  import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
  import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
  import {PoolKey} from "v4-core/src/types/PoolKey.sol";
  import {Currency, CurrencyLibrary} from "v4-core/src/types/Currency.sol";
  import {ModifyLiquidityParams, SwapParams} from "v4-core/src/types/PoolOperation.sol";
  import {TickMath} from "v4-core/src/libraries/TickMath.sol";
  import {StateLibrary} from "v4-core/src/libraries/StateLibrary.sol";
  import {FullMath} from "v4-core/src/libraries/FullMath.sol";
  import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol";
  import {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";
  import {PanicMonkeys} from "src/PanicMonkeys.sol";
  import {PanicHook} from "src/PanicHook.sol";
  import {HookMiner} from "src/HookMiner.sol";
  import {HookFlags} from "src/HookFlags.sol";
  
  /// @notice `_buybackAndBurn` floors the reference-implied PANIC before applying the 98% minimum, so
  /// ceil(0.98 * floor(q)) can be one unit below ceil(0.98 * q). With the live price 3% above the reference a
  /// 1000-unit buyback returning 20 PANIC units is accepted although 98% of the exact quote (20.8999...) is 20.48,
  /// which requires 21. Fails on the current code; passes once the minimum is derived from the unfloored quote.
  contract BuybackFloorRoundingTest is Test {
      using StateLibrary for IPoolManager;
  
      uint160 constant SQRT_PRICE_1_1 = 79228162514264337593543950336;
      int24 constant TICK_SPACING = 100;
      address constant ORACLE_FUND = 0x788C311500FD3C15b8e44d6e2935fe7fF13E674b;
  
      PoolManager manager;
      PanicMonkeys panic;
      PanicHook hook;
      PoolSwapTest swapRouter;
      PoolModifyLiquidityTest lpRouter;
      PoolKey key;
  
      receive() external payable {}
  
      function setUp() public {
          vm.warp(1_800_000_000);
          vm.roll(1_000);
          manager = new PoolManager(address(this));
          panic = new PanicMonkeys();
          swapRouter = new PoolSwapTest(IPoolManager(address(manager)));
          lpRouter = new PoolModifyLiquidityTest(IPoolManager(address(manager)));
  
          bytes memory creationCode = abi.encodePacked(
              type(PanicHook).creationCode, abi.encode(IPoolManager(address(manager)), address(panic), ORACLE_FUND)
          );
          (address predicted, bytes32 salt) =
              HookMiner.find(address(this), HookFlags.PANIC_HOOK, creationCode, 0, 1_000_000);
          hook = new PanicHook{salt: salt}(IPoolManager(address(manager)), address(panic), ORACLE_FUND);
          assertEq(address(hook), predicted);
  
          key = PoolKey({
              currency0: CurrencyLibrary.ADDRESS_ZERO,
              currency1: Currency.wrap(address(panic)),
              fee: 12_500,
              tickSpacing: TICK_SPACING,
              hooks: IHooks(address(hook))
          });
          manager.initialize(key, SQRT_PRICE_1_1);
  
          vm.deal(address(this), 1e27);
          panic.approve(address(swapRouter), type(uint256).max);
          panic.approve(address(lpRouter), type(uint256).max);
          lpRouter.modifyLiquidity{value: 1e25}(
              key,
              ModifyLiquidityParams({
                  tickLower: TickMath.minUsableTick(TICK_SPACING),
                  tickUpper: TickMath.maxUsableTick(TICK_SPACING),
                  liquidityDelta: int256(1e22),
                  salt: 0
              }),
              ""
          );
      }
  
      function _swap(bool zeroForOne, int256 amountSpecified, uint160 limit) internal {
          uint256 value = zeroForOne ? uint256(-amountSpecified) : 0;
          swapRouter.swap{value: value}(
              key,
              SwapParams({zeroForOne: zeroForOne, amountSpecified: amountSpecified, sqrtPriceLimitX96: limit}),
              PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false}),
              ""
          );
      }
  
      function test_smallBuybackThreePercentAboveReferenceMustRevert() public {
          _swap(false, -1e18, TickMath.MAX_SQRT_PRICE - 1); // sell 1 PANIC: funds the burn bucket
          _swap(true, -1e24, 11453882584939555244670964355); // buy up to a limit
          vm.roll(block.number + 1);
          vm.warp(block.timestamp + 3600); // flat for an hour: reference == this price
          _swap(true, -1e24, 11285843134733390162692706488); // buy: live PANIC price 3% above the reference
  
          uint160 ref = hook.referenceSqrtPriceX96();
          (uint160 live,,,) = IPoolManager(address(manager)).getSlot0(key.toId());
          uint256 premiumE4 = uint256(ref) * uint256(ref) / uint256(live) * 10_000 / uint256(live);
          emit log_named_uint("live PANIC price / reference (e4)", premiumE4);
          assertGt(premiumE4, 10_200, "more than 2% above the reference");
  
          // Exact reference quote for 1000 paired units, in millionths of a PANIC unit.
          uint256 quoteE6 = FullMath.mulDiv(FullMath.mulDiv(1000 * 1e6, ref, 1 << 96), ref, 1 << 96);
          uint256 minimumExact = (quoteE6 * 9800 + 1e10 - 1) / 1e10; // ceil(0.98 * quote)
          emit log_named_uint("exact quote (e6)", quoteE6);
          emit log_named_uint("floored quote used by the hook", hook.pairedToPanicAtSqrtPrice(1000, ref, false));
          emit log_named_uint("minimum from the exact quote", minimumExact);
          assertEq(minimumExact, 21);
  
          vm.expectRevert();
          hook.buybackAndBurn(1000);
      }
  }

  whole proof

• lowMAX_BUYBACK_SPEND is 1e18 minor units of the paired currency, sized for a native-ETH pair, but the manifest pairs PANIC with IMD; README and deploy script still describe a PANIC/ETH poolsrc/PanicHook.sol:98

  The constant is immutable (no admin) and denominated in whatever the paired currency is. launch.json pairs the pool with 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, which on Ethereum mainnet reports symbol IMD, 18 decimals and total supply 4,116,877.757721 (read with cast call against ethereum-rpc.publicnode.com on 2026-10-07).

  So one buybackAndBurn call can spend at most 1 IMD, while the call costs about 249k gas cold and 175k gas warm on an ERC-20 pair; on mainnet at 20 gwei that is roughly 0.0035 to 0.005 ETH of gas per call, more than the value of 1 IMD at public quotes near 8.5 USD.

  The outlet still works and nothing is lost or stuck, so this is recalibrated from the specialist's medium to low: it is a mismatch between the README's stated assumption ('The paired currency is native ETH', README.md:199; 'Pool: PANIC paired with native ETH', README.md:165; script/DeployPanic.s.sol initializes a native-ETH pool) and the manifest's IMD pair, which makes draining the bucket cost many calls and, on mainnet, more gas than it burns.

  The cap should be chosen for the actual paired currency (or expressed relative to pool liquidity) and the README corrected to match launch.json.

  whole finding

  PANIC/ERC-20 pool with an 18-decimal mock paired token as currency0 (same orientation possibilities as the manifest), price 1:1, full-range liquidity 1e22.

  One sell to 20% drawdown accrues burnBucket = 21,114,561,800,016,824,287 (21.1 paired units).

  Next block: buybackAndBurn() returns spent == 1e18 exactly (the cap) and consumes 248,679 gas; a second call in the same block consumes 175,370 gas; 27 calls are needed to empty the bucket from this single sell.

  Expected: a cap that bounds one call in a unit meaningful for the launch pair.

  Actual: 1 IMD per call for a token whose whole supply is 4.1M IMD.

  Scratch test used: test/scratch/Repro.t.sol:ReproErc20Test.test_buybackGasAndCapOnErc20Pair.

  whole reproduction

• lowManifest initialPrice 2^96 means 1 PANIC = 1 IMD at launch, implying a starting fully-diluted value of 1e9 IMD against a total IMD supply of 4.1M; the value was copied from the ETH test fixturelaunch.json:29

  initialPrice is exactly 2^96, i.e. one raw currency1 unit per raw currency0 unit. Both PANIC (PanicMonkeys.decimals = 18) and the paired IMD token (18 decimals on-chain) have 18 decimals, so in either pool orientation the pool opens at 1 PANIC per IMD. PanicMonkeys mints 1,000,000,000 PANIC (TOTAL_SUPPLY = 1_000_000_000 ether), so the implied launch valuation is 1e9 IMD, about 243 times the entire IMD supply.

  The manifest's own notes say the price 'follow[s] the deployment test' and README.md:165 still describes the pool as PANIC/ETH. The hook anchors its one-hour reference at this initialization tick (afterInitialize stores initialTick and _reference assumes it prevailed for the hour before launch), so the opening price also decides which sells are 'down' during the first hour.

  I could not see the launch policy's seed amounts, so this is reported as a manifest value with no stated economic basis for this pair rather than a proven misconfiguration; the author should set initialPrice from the intended PANIC/IMD opening valuation and seed sizes.

  whole finding

  Decode launch.json: pairedCurrency = 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 (cast call decimals() = 18, symbol() = IMD, totalSupply() = 4116877757721000000000000 on Ethereum mainnet), token.decimals = 18, initialPrice = 79228162514264337593543950336 = 2^96, so sqrtPrice = 1.0 and price = 1 PANIC per IMD.

  With TOTAL_SUPPLY = 1e27 minor units the implied FDV is 1e9 IMD; a two-sided seed of just 1% of the PANIC supply at this price would need 10,000,000 IMD, more than exist.

  Expected: an initial price derived from the launch's PANIC/IMD valuation.

  Actual: the 1:1 placeholder from the ETH test fixture.

  whole reproduction

• lowExact-output sells and fee-bearing partial exact-input buys revert, so routers quoting a sell by desired output or price-limited dip buys fail instead of being taxedsrc/PanicHook.sol:323

  The brief takes the sell fee from the paired output through the afterSwap return delta, and a v4 afterSwap delta cannot adjust the specified currency. The implementation therefore rejects every exact-output sell in beforeSwap (line 323) and, for exact-input buys with a non-zero fee reserved in beforeSwap, rejects any partial fill in afterSwap because the specified input cannot be refunded (line 356, PartialExactInputBuyNotSupported).

  Neither path loses funds and both are documented in README.md and the manifest notes, but they are user-facing failures the brief does not list among the accepted limitations: an aggregator exact-output sell route, or an exact-input dip buy whose router sets a binding sqrtPriceLimitX96, reverts rather than trading.

  Options that keep the brief's economics: take the fee for exact-output sells from the unspecified (PANIC input) side converted at the post-swap price, or state the routing restriction (sells exact-input only, dip buys exact-output when price-limited) in the manifest notes so integrators configure routes accordingly.

  whole finding

  PANIC/native-ETH pool at 1:1 with full-range liquidity 1e22.

  (a) swapRouter.swap with zeroForOne=false (sell PANIC), amountSpecified=+1e18 (exact output of 1 ETH), sqrtPriceLimitX96 = MAX_SQRT_PRICE-1: expected per the brief a taxed sell paying 2% of the 1 ETH output; actual the PoolManager reverts WrappedError(hook, beforeSwap.selector, ExactOutputSellNotSupported, HookCallFailed) (existing test test_exactOutputSellIsRejected in test/PanicHook.Fees.t.sol).

  (b) After a sell to 10% drawdown, an exact-input buy of 100 ETH with sqrtPriceLimitX96 = price - price/10000 reverts WrappedError(hook, afterSwap.selector, PartialExactInputBuyNotSupported, HookCallFailed) with nothing charged (existing test test_partialDipBuyRevertsWithoutChargingOrMovingThePool in test/PanicHook.Revision.t.sol).

  whole reproduction

• infoReference price is the whole-tick floor of the mean tick, so tier boundaries are exact only relative to a reference quantized by up to 1 bp (standard Uniswap v3 TWAP behaviour, documented)src/PanicHook.sol:570

  _meanTick floors the cumulative-tick mean toward negative infinity and referenceSqrtPriceX96 converts that whole tick to a sqrt price, exactly as Uniswap v3's OracleLibrary.consult does. The fractional tick (up to 1 bp of price) is dropped: with PANIC as currency1 the reference PANIC price is rounded up (drawdown overstated by at most 1 bp), with PANIC as currency0 it is rounded down.

  A sell that truly ends 4.99% below the unquantized geometric mean can therefore land in the 10% tier, and vice versa in the other orientation. README.md documents this quantization and the brief's required boundary tests pass relative to the computed reference.

  Reported for completeness at info: it is the conventional tick-TWAP definition, the band is 1 bp, and interpolating between getSqrtPriceAtTick(t) and getSqrtPriceAtTick(t+1) by the remainder would remove it if the author wants an unquantized reference.

  whole finding

  PANIC/native-ETH pool at 1:1, full-range liquidity 1e22.

  Block +1800 s: sell PANIC with sqrtPriceLimitX96 = TickMath.getSqrtPriceAtTick(1) so the pool sits at tick 1.

  Block +1800 s more: the true mean tick over the hour is 0.5, but hook.referenceTick() == 0 and hook.referenceSqrtPriceX96() == 2^96.

  Let boundary = the sqrt price exactly 5% below the floored reference and fractional = 2^96 + (getSqrtPriceAtTick(1) - 2^96)/2: hook.drawdownBps(boundary, 2^96, false) == 500 (10% tier) while hook.drawdownBps(boundary, fractional, false) == 499 (2% tier).

  This is the existing test test_referenceUsesDocumentedWholeTickRounding in test/PanicHook.Revision.t.sol.

  whole reproduction

Failed on the agent's machine.