report

Identity-md/research/blob/main/jobs/ec4e3ea7-9b37-4113-ae4d-8cdd5ea19424/_identitymd/README.md

Four agents audited the code as it is at 9a32f89, each in one area, and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the code was changed or deployed.

Download the report (Markdown) · archived copy on GitHub

3 low4 info

• 1.lowPaced buyback is front-runnable for profit across hours: the per-call cap defeats an atomic sandwich, not a predictable series of hourly buyscontracts/src/PepesBuyback.sol:85

          if (block.timestamp < lastBuyback + BUYBACK_INTERVAL) revert TooSoon();
          uint256 imdIn = imd.balanceOf(address(this));
          uint256 cap = maxBuyback();
          if (imdIn > cap) imdIn = cap;
          if (imdIn == 0) revert BadAmount();

  buybackAndBurnPepes is permissionless and, whenever the reserve holds more than one cap, always spends exactly min(reserve, 1% of the $Pepes pool's IMD depth) at the market price (minPepesOut is the caller's, usually 0). The only pacing is one call per hour (line 85), so the whole flow is public and predictable.

  The 4% quote-side fee each way does make a single-transaction sandwich lose (confirmed: with a 1% buy, or 1% plus a 2% $EARN-sized buy in the same transaction, the best front-run over a sweep of sizes loses; break-even is a single-transaction buy of roughly 4.0 to 4.5% of depth).

  But a trader who buys $Pepes once, triggers the buyback at every hour and sells at the end pays the 8% round trip once while the buyback moves the price ~1% per hour in their favour, and the cap itself grows with the depth their own buy added. The buyback therefore buys at a price the front-runner inflated and burns fewer $Pepes; the difference goes to the front-runner.

  This is inherent to any predictable on-chain buyer and the trader carries hours of price risk with capital of about 40% of depth, so it is rated low rather than medium, but it means the comment's claim (lines 44-46) and README ('a buyback sandwich that loses money') hold only for the atomic case. The requester asked this question directly. Merged from audit_math (medium).

  Fix options that keep the design: skip or shrink a buyback when the pool price has risen more than X% since the previous buyback (reference price = sqrtPrice recorded at the last call), or jitter the earliest allowed time so the series is not exactly predictable. At minimum, correct the comment and README.

  whole finding

  Unit test on a PepesFamily pool standing in for the v1 $Pepes pool (same 4% hook fee, same single-sided curve): pool depth ~1,060 IMD after a 1,000 IMD buy; PepesBuyback holds 212 IMD (20% of depth) of recycled rewards.

  Eve: routerA.buy(pepes, 424 IMD) (40% of depth); eight times {warp +1 hour; buyback.buybackAndBurnPepes(0, now)}; routerA.sell(pepes, all).

  Expected (per the contract comment and README): Eve ends with less IMD than she started with.

  Actual: Eve starts with 10,000 IMD and ends with 10,021.48 IMD (+21.48 IMD, about 18% of the 121.37 IMD the buyback spent).

  The same sequence with one call and no waiting loses, so the per-call cap is not the binding constraint.

  Run: forge test --match-path test/scratch/Proof_431d.t.sol (fails on this code with 'front-running the paced buyback must not be profitable').

  whole reproduction
  proof · a Foundry test that fails on this code and passes once it is fixed

  // 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 {PepesFamily} from "src/PepesFamily.sol";
  import {PepesFamilyRouter} from "src/PepesFamilyRouter.sol";
  import {PepesBuyback} from "src/PepesBuyback.sol";
  import {PadToken} from "src/PadToken.sol";
  
  contract MockIMD {
      string public name = "IMD";
      string public symbol = "IMD";
      uint8 public decimals = 18;
      mapping(address => uint256) public balanceOf;
      mapping(address => mapping(address => uint256)) public allowance;
  
      function mint(address to, uint256 amt) external {
          balanceOf[to] += amt;
      }
  
      function approve(address s, uint256 amt) external returns (bool) {
          allowance[msg.sender][s] = amt;
          return true;
      }
  
      function transfer(address to, uint256 amt) external returns (bool) {
          balanceOf[msg.sender] -= amt;
          balanceOf[to] += amt;
          return true;
      }
  
      function transferFrom(address f, address to, uint256 amt) external returns (bool) {
          if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= amt;
          balanceOf[f] -= amt;
          balanceOf[to] += amt;
          return true;
      }
  }
  
  /// @notice The $Pepes pool is modelled by a PepesFamily launch (same 4% quote-side hook fee and single-sided
  ///         curve as the v1 pad, whose FEE_BPS is 400 on chain). A second PepesFamily instance points its
  ///         PepesBuyback at that token and that router, exactly as production points at the v1 router.
  contract BuybackFrontrunTest is Test {
      uint160 constant FLAGS = uint160((1 << 13) | (1 << 11) | (1 << 7) | (1 << 6) | (1 << 3) | (1 << 2));
  
      PoolManager pm;
      MockIMD imd;
      PepesFamily padA; // stands in for v1: hosts the $Pepes pool
      PepesFamilyRouter routerA;
      PadToken pepes;
      PepesFamily padB; // v4: its PepesBuyback buys `pepes` through routerA
      PepesBuyback buyback;
  
      address eve = makeAddr("eve");
      address bob = makeAddr("bob");
  
      function setUp() public {
          vm.warp(1_800_000_000);
          pm = new PoolManager(address(this));
          imd = new MockIMD();
          padA = _deployPad(address(1), address(2));
          routerA = PepesFamilyRouter(payable(padA.router()));
          pepes = PadToken(payable(padA.launch("Pepes", "PEPES", "", address(imd))));
          padB = _deployPad(address(pepes), address(routerA));
          buyback = PepesBuyback(padB.buyback());
  
          // a $Pepes pool with some depth: bob bought in earlier (virtual IMD depth ~1,060 IMD)
          imd.mint(bob, 10_000e18);
          vm.startPrank(bob);
          imd.approve(address(routerA), type(uint256).max);
          routerA.buy(address(pepes), 1_000e18, 0, block.timestamp);
          vm.stopPrank();
  
          imd.mint(eve, 10_000e18);
          vm.startPrank(eve);
          imd.approve(address(routerA), type(uint256).max);
          pepes.approve(address(routerA), type(uint256).max);
          vm.stopPrank();
      }
  
      function _deployPad(address pepes_, address pepesRouter_) internal returns (PepesFamily) {
          int24 tick = 161200; // ~100 IMD launch market cap (1e7 tokens per IMD)
          bytes memory initCode = abi.encodePacked(
              type(PepesFamily).creationCode,
              abi.encode(
                  pm,
                  address(imd),
                  address(this),
                  address(this),
                  tick,
                  PepesFamily.ImdEthPool(10_000, 100, address(0)),
                  pepes_,
                  pepesRouter_
              )
          );
          bytes32 salt;
          address predicted;
          for (uint256 i;; i++) {
              salt = bytes32(i);
              predicted = address(
                  uint160(uint256(keccak256(abi.encodePacked(bytes1(0xff), address(this), salt, keccak256(initCode)))))
              );
              if (uint160(predicted) & 0x3FFF == FLAGS) break;
          }
          address deployed;
          assembly {
              deployed := create2(0, add(initCode, 0x20), mload(initCode), salt)
          }
          require(deployed == predicted, "hook address");
          return PepesFamily(deployed);
      }
  
      /// Eve buys 40% of the pool's IMD depth, calls the capped buyback at every hour for 8 hours (anyone may),
      /// then sells. Each call is capped at 1% of depth and loses money if sandwiched atomically, but the hourly
      /// pace makes the flow predictable: the price moves ~1%/hour in her favour while her round trip costs 8%.
      /// With a reserve of 20% of depth she exits with more IMD than she started with.
      function test_pacedBuybackCannotBeFrontRunForProfit() public {
          uint256 depth = buyback.maxBuyback() * 100;
          imd.mint(address(buyback), depth / 5);
          uint256 start = imd.balanceOf(eve);
  
          vm.startPrank(eve);
          uint256 got = routerA.buy(address(pepes), depth * 40 / 100, 0, block.timestamp);
          for (uint256 h; h < 8; h++) {
              vm.warp(block.timestamp + 1 hours);
              buyback.buybackAndBurnPepes(0, block.timestamp);
          }
          routerA.sell(address(pepes), got, 0, block.timestamp);
          vm.stopPrank();
  
          uint256 end = imd.balanceOf(eve);
          emit log_named_decimal_uint("pool virtual IMD depth", depth, 18);
          emit log_named_decimal_uint("eve start IMD", start, 18);
          emit log_named_decimal_uint("eve end IMD", end, 18);
          emit log_named_decimal_uint("IMD spent by the buyback", buyback.totalImdSpent(), 18);
          assertLe(end, start, "front-running the paced buyback must not be profitable");
      }
  }

  whole proof

• 2.lowPepesBuyback burns only the swap delta: $Pepes sent to it directly is locked forever and accrues v1 holder dividends nobody can claimcontracts/src/PepesBuyback.sol:95

          burned = pepes.balanceOf(address(this)) - before;
          pepes.transferOut(DEAD, burned);

  buybackAndBurnPepes snapshots the $Pepes balance before the swap and sends only after - before to 0x...dEaD. The contract has no owner and no other function that moves $Pepes, so any $Pepes that reaches it by a plain transfer (a user assuming 'send $Pepes here to burn it', an airdrop, griefing dust) stays in before on every later call and never leaves, contrary to the NatSpec 'sends all of it to the burn address'.

  Because PepesBuyback is not in PadTokenV1's immutable exclusion list (PoolManager, pad, router, token, 0x0, dEaD), a stranded balance keeps earning its pro-rata share of every future 3% $Pepes holder fee inside the $Pepes token contract, and PadTokenV1.claim() pays only msg.sender, which PepesBuyback can never be; that IMD is lost to all other $Pepes holders.

  The IMD side spends the whole balance (imdIn = imd.balanceOf(address(this))) while the $Pepes side spends only the delta, an asymmetry with no reason behind it. Merged from four specialists (audit_math, audit_flow, audit_economics, audit_permissions), identical mechanism and fix.

  Fix: after the swap, burned = pepes.balanceOf(address(this)); pepes.transferOut(DEAD, burned); so direct sends are burned on the next call (totalPepesBurned then also counts donations, which is the desired accounting).

  whole finding

  pepes.mint(buyback, 5e18) (any direct transfer of 5 $Pepes to the buyback); imd.mint(buyback, 1e18); buyback.buybackAndBurnPepes(0, now).

  Expected: pepes.balanceOf(buyback) == 0 and the burn address received the 5 $Pepes with the bought ones.

  Actual: burned equals only the swap output and pepes.balanceOf(buyback) == 5e18 afterwards, permanently.

  Run: forge test --match-path test/scratch/Proof_4a52.t.sol (fails on this code with 'stray $Pepes stay locked in the buyback forever: 5000000000000000000 != 0').

  The v1 dividend part follows from reading src/v1/PadTokenV1.sol: isExcluded (lines 140-143) does not cover the buyback and claim() (line 173) pays msg.sender only.

  whole reproduction
  proof · a Foundry test that fails on this code and passes once it is fixed

  // 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 {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";
  import {TickMath} from "v4-core/src/libraries/TickMath.sol";
  import {PoolKey} from "v4-core/src/types/PoolKey.sol";
  import {Currency} from "v4-core/src/types/Currency.sol";
  import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
  import {ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
  
  import {PepesBuyback} from "src/PepesBuyback.sol";
  
  contract MockToken {
      mapping(address => uint256) public balanceOf;
      mapping(address => mapping(address => uint256)) public allowance;
  
      function mint(address to, uint256 amt) external {
          balanceOf[to] += amt;
      }
  
      function approve(address s, uint256 amt) external returns (bool) {
          allowance[msg.sender][s] = amt;
          return true;
      }
  
      function transfer(address to, uint256 amt) external returns (bool) {
          balanceOf[msg.sender] -= amt;
          balanceOf[to] += amt;
          return true;
      }
  
      function transferFrom(address f, address to, uint256 amt) external returns (bool) {
          if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= amt;
          balanceOf[f] -= amt;
          balanceOf[to] += amt;
          return true;
      }
  }
  
  contract MockRouter {
      MockToken imd;
      MockToken pepes;
      PoolKey key;
  
      constructor(MockToken i, MockToken p) {
          imd = i;
          pepes = p;
      }
  
      function setKey(PoolKey memory k) external {
          key = k;
      }
  
      function pad() external view returns (address) {
          return address(this);
      }
  
      function poolKey(address) external view returns (PoolKey memory) {
          return key;
      }
  
      function buy(address, uint256 amountIn, uint256, uint256) external payable returns (uint256 out) {
          imd.transferFrom(msg.sender, address(this), amountIn);
          out = amountIn * 1000;
          pepes.mint(msg.sender, out);
      }
  }
  
  contract StrayPepesTest is Test {
      address constant DEAD = 0x000000000000000000000000000000000000dEaD;
  
      function test_pepesSentDirectlyIsNeverBurned() public {
          vm.warp(1_800_000_000);
          PoolManager pm = new PoolManager(address(this));
          MockToken imd = new MockToken();
          MockToken pepes = new MockToken();
          MockRouter r = new MockRouter(imd, pepes);
          PoolModifyLiquidityTest lp = new PoolModifyLiquidityTest(pm);
          pepes.mint(address(this), 100_000e18);
          imd.mint(address(this), 100_000e18);
          pepes.approve(address(lp), type(uint256).max);
          imd.approve(address(lp), type(uint256).max);
          (address c0, address c1) =
              address(pepes) < address(imd) ? (address(pepes), address(imd)) : (address(imd), address(pepes));
          PoolKey memory k = PoolKey(Currency.wrap(c0), Currency.wrap(c1), 3000, 60, IHooks(address(0)));
          pm.initialize(k, TickMath.getSqrtPriceAtTick(0));
          lp.modifyLiquidity(k, ModifyLiquidityParams(-887220, 887220, 1_000e18, 0), "");
          r.setKey(k);
          PepesBuyback b = new PepesBuyback(address(imd), address(pepes), address(r), address(pm));
  
          pepes.mint(address(b), 5e18); // $Pepes sent straight to the buyback (a donation to the burn)
          imd.mint(address(b), 1e18);
          b.buybackAndBurnPepes(0, block.timestamp);
          assertEq(pepes.balanceOf(address(b)), 0, "stray $Pepes stay locked in the buyback forever");
      }
  }

  whole proof

• 3.lowACTIVITY_MIN is a fixed token count, not a value: genuine small buys at higher market caps are not activity (an actively buying wallet gets recycled) while strangers reset any timer for ~0.001 IMDcontracts/src/PadToken.sol:229

              if (!toExcluded && (msg.sender == to || amount >= ACTIVITY_MIN || lastActive[to] == 0)) {
                  lastActive[to] = block.timestamp;
              }

  A buy through PepesFamilyRouter, PepesFamilyEthRouter or any v4 router delivers tokens with PoolManager.take, so in _transfer msg.sender is the PoolManager, not the buyer, and the receipt counts as activity only when amount >= ACTIVITY_MIN (10,000 tokens, 0.001% of supply) or it is the wallet's first receipt. The threshold is denominated in tokens, so its IMD value is 1e-5 of the market cap. Two consequences of the one rule.

  1. Holder's disfavour: once the market cap passes ~100,000 IMD, a 1 IMD buy yields fewer than 10,000 tokens, so a holder who keeps buying with their own IMD but never claims is 'inactive' from their first buy and anyone can recycle everything older than 7 days, although the wallet traded a day earlier. README and the contract notice equate the threshold with 'any real buy', which holds only at small caps; the suite only tests a 1 IMD buy at a ~100 IMD cap (millions of tokens).
  2. Burn's disfavour: a third party can push lastActive[victim] forward at will by sending 10,000 tokens, which costs ~0.0013 IMD at the harness's 120 IMD cap and ~0.0064 IMD at the production 635 IMD start cap; one wallet holding a bag of a cheap token can keep every other holder's rewards perpetually unexpired, defeating the expiry for that token (the NatSpec says the constant 'keeps dust gifts from holding off someone else's expiry for free'). Neither direction harms a holder's claimable balance (lastActive only ever moves forward, see test_lastActiveNeverDecreases) and the holder can always claim or self-transfer, so low. Merged from audit_math, audit_flow, audit_economics and audit_permissions (six findings, two impacts, one root cause). Fix options that keep the gift rule: let the two immutable project routers record the buyer's own buy as activity regardless of size (e.g. a markActive(buyer) restricted to router/ethRouter, or treat a receipt from the PoolManager as activity when the trade came through the pad's own routers), and make the third-party receipt threshold value-based (a share of the recipient's balance, or an IMD-equivalent read from the pool price) rather than a fixed count. At minimum document the threshold in IMD terms.

  whole finding

  test/scratch/Judge.t.sol, JudgeActivityTest (both pass on the current code, showing the behaviour). test_smallRealBuyIsNotActivity: launch at the 100 IMD start cap; bob buys 10 IMD (lastActive = T0); carol buys 5,000 IMD (market cap 241,296 IMD); warp 6 days; bob buys 1 IMD through PepesFamilyRouter and receives 3,977.7 tokens (< 10,000) -> lastActive[bob] == T0 unchanged (expected: now, he just bought); warp 1 day + 1 s; recycle(bob) moves 150.30 IMD of bob's 150.30 IMD owed to the buyback (expected 0: bob traded 25 hours earlier). test_thirdPartyResetsTimerCheaply: carol buys 0.01 IMD and receives 79,984 tokens; warp 6 days; carol.transfer(bob, 10,000e18) -> lastActive[bob] == block.timestamp; cost 0.00125 IMD per reset at a 120 IMD market cap.

  whole reproduction

• 4.infoSandwich-bound comment is wrong: the v4 and $EARN buybacks together expose 3% of depth, not 2%; measured break-even is about 4.0 to 4.5%, and a v1 fee self-rebate narrows that margin as the pool's shacontracts/src/PepesBuyback.sol:44

      /// @notice IMD spent per buyback: at most 1% of the $Pepes pool's IMD depth, at most once an hour. Half of the
      ///         $EARN buyback's 2%, so both together stay within the 2%-of-depth bound under which a sandwich costs
      ///         more in the $Pepes pool's 4% fees (each way) than it can move the price.
      uint256 public constant MAX_BUYBACK_BPS = 100;

  The NatSpec says the 1% cap is 'half of the $EARN buyback's 2%, so both together stay within the 2%-of-depth bound'. 1% + 2% = 3%, and both calls are permissionless with minOut = 0, so an atomic bundle of PepesBuyback.buybackAndBurnPepes followed by PepesEarnToken.buybackAndBurnPepes on the same $Pepes pool buys 3% of depth in one transaction.

  Measured with the real hook on a PepesFamily pool (same 4% quote-side fee as the live v1 $Pepes pool, FEE_BPS 400 confirmed on chain): a naive attacker paying the full 4% each way loses for every front-run size when the victim buy is up to 4.0% of depth and first profits at 4.5% (+1.04 IMD on a 19,300 IMD pool), so today's 3% bundle is safe with a margin of roughly 1 to 1.5% of depth, and any further anyone-callable buyer on the $Pepes pool above that would cross the line.

  Lead not reproduced here (needs the v1 PepesFamily pad source, not in this repository): the v1 pad distributes mid-unlock for any caller and PadTokenV1.distribute has no unlock guard (AUDIT.md), so an attacker trading inside its own unlock can flash-take the PoolManager's $Pepes, flush, and claim back (pool share of supply) x 3% of its own fee each way; audit_flow's model puts the 3% bundle at profitable once the PoolManager holds ~40% of supply.

  Live today the PoolManager holds 1.979e26 of 1e27 $Pepes (~20%), where the specialist's fork test lost money in every configuration, so this is state-dependent and informational. Merged from audit_economics (info) and audit_flow (low, demoted: not reproducible against this tree and unprofitable at the live state).

  Suggested: fix the comment (3% combined, ~4% break-even), add a unit test that bundles both buybacks, and if the margin matters, make the two contracts refuse to run in the same block (e.g. PepesBuyback checks the $EARN token's lastBuyback != block.timestamp) or lower MAX_BUYBACK_BPS.

  whole finding

  test/scratch/Judge.t.sol, JudgeSandwichTest. test_stackedAtomicSandwichLoses: pool depth 19,300 IMD; buyback reserve 19,300 IMD; for front-run sizes 0.1% to 50% of depth: eve buys, buyback (1% of post-front-run depth), an unrelated buy of 2% of post-front-run depth in the same transaction (the $EARN stand-in), eve sells; best eve P&L = -0.47 IMD (loss). test_breakEvenSweep: victim buy of 1.0/1.5/.../4.0% of depth -> best attacker P&L -1.17/-1.00/-0.82/-0.65/-0.47/-0.30/-0.12 IMD (all losses); 4.5% -> +1.04 IMD at a 4% front-run; 5% -> +17.8 IMD; 6% -> +115 IMD. Expected per the comment: safe bound at 2%; actual: safe up to ~4%, with the live combined exposure at 3%.

  whole reproduction

• 5.infoBuyback wiring (pepes, pepesRouter) is only zero-checked at construction; a mis-wired deployment makes buybackAndBurnPepes revert forever while recycle keeps sending IMD there with no way outcontracts/src/PepesBuyback.sol:65

          if (imd_ == address(0) || pepes_ == address(0) || pepesRouter_ == address(0) || poolManager_ == address(0)) {
              revert ZeroAddress();
          }

  PepesFamily's constructor deploys the shared PepesBuyback from two arguments that are checked only for zero. The buyback address is immutable in PepesFamily and in every PadToken it launches; PadToken.recycle transfers IMD to it unconditionally and PepesBuyback has no owner and no path for IMD other than IPepesRouterV1(pepesRouter).buy.

  If pepesRouter is not a v1-compatible router, pepes is not launched on pepesRouter.pad() (poolKey reverts UnknownToken), the pool is ETH-paired (the v1 router's buy then reverts BadAmount for an IMD-approved call), or imd is neither pool currency (cap computed from the wrong side), buybackAndBurnPepes can never succeed and every v4 token's expired rewards accumulate unrecoverably. PepesEarnIMD.openPool validates the analogous targets; PepesFamily v4 has no equivalent check.

  Deploy.s.sol hard-codes the live $Pepes 0xE2C4...5644 and v1 router 0xA736...83dC, and the wiring verifies on chain (router.pad() = 0x2d76...68CC, poolKey($Pepes) = (IMD, PEPES, 0, 200, pad), FEE_BPS 400) and in Fork.t.sol, so this is deployment hygiene, not a live defect. Merged from audit_math, audit_flow, audit_economics and audit_permissions.

  Fix: in PepesBuyback's constructor resolve IPepesPadV1(IPepesRouterV1(pepesRouter_).pad()).poolKey(pepes_), require that one currency is imd_ and that the pool is initialised (sqrtP != 0), so a mis-wired PepesFamily deployment reverts instead of creating a permanent sink.

  whole finding

  test/scratch/Judge.t.sol, JudgeWiringTest.test_eoaRouterAccepted_thenBuybackBricked (passes, showing the behaviour): deploy PepesFamily with pepes = 0xCAFE and pepesRouter = 0xBEEF (both EOAs).

  Expected: deployment refused.

  Actual: it succeeds; launch a token, bob and carol buy 10 IMD each, warp 8 days, recycle(bob) moves bob's IMD into the buyback; buyback.maxBuyback() and buyback.buybackAndBurnPepes(0, now) revert on every call, and the IMD has no other exit.

• 6.infomaxBuyback() is 0 while the $Pepes pool sits exactly at its launch tick (single-sided position inactive), so the buyback reverts BadAmount until someone buys; IMD waits, nothing is lostcontracts/src/PepesBuyback.sol:110

          uint256 liquidity = IPoolManager(poolManager).getLiquidity(id);
          uint256 imdDepth = Currency.unwrap(key.currency0) == imd
              ? FullMath.mulDiv(liquidity, Q96, sqrtP) // IMD is currency0: x = L / sqrtP
              : FullMath.mulDiv(liquidity, sqrtP, Q96); // IMD is currency1: y = L * sqrtP
          return (imdDepth * MAX_BUYBACK_BPS) / 10_000;

  getLiquidity returns the liquidity active at the current tick. The live $Pepes pool has IMD as currency0 and $Pepes as currency1 (confirmed on chain), so its single position runs from MIN_TICK to the launch tick and is inactive when the price is exactly at the launch tick (lower <= tick < upper fails at tick == upper).

  In that state, which is reached only when every $Pepes has been sold back into the pool, liquidity is 0, maxBuyback() returns 0 and buybackAndBurnPepes reverts BadAmount (line 89) even with a funded reserve. recycle keeps working and the IMD stays in the contract, so this is a liveness corner case rather than a lock: the one state in which the burn cannot run is the one in which nobody holds $Pepes. Today the PoolManager holds ~20% of supply, far from that state.

  Merged from audit_flow (info). No change required; optionally return early with a clearer error or fall back to the position's liquidity.

  whole finding

  test/scratch/Judge.t.sol, JudgeWiringTest.test_maxBuybackZeroAtLaunchTick (passes, showing the behaviour): launch a PepesFamily token whose pool has IMD as currency0 (the live $Pepes ordering) and point a PepesBuyback at it before any buy. maxBuyback() == 0; with 1 IMD in the buyback, buybackAndBurnPepes(0, now) reverts BadAmount.

  After one 1 IMD buy moves the price into range, maxBuyback() > 0.

  With the opposite ordering (token as currency0) the cap is positive at the launch tick.

• 7.infoExpiry test coverage: the suite never asserts that recent rewards survive repeated recycles, the all-expires case for a zero-balance holder, un-flushed fees, or sub-threshold receipts; the properties contracts/test/PepesFamily.t.sol:840

      function testFuzz_expirySolvent(uint96 a, uint96 b, uint32 gap1, uint32 gap2) public {
          PadToken t = _launch();
          _buy(bob, t, bound(a, 1e15, 500e18));
          vm.warp(block.timestamp + bound(gap1, 0, 20 days));
          _buy(carol, t, bound(b, 1e15, 500e18));
          vm.warp(block.timestamp + bound(gap2, 0, 20 days));

  The repository's expiry fuzz drives three router buys with two gaps and one recycle.

  It never (1) recycles the same wallet twice so that rewards cross the 7-day line between calls, (2) recycles a holder whose balance is 0 (sold everything 7+ days ago, so recent is 0 and everything older expires), (3) leaves fees pending in the pad from third-party-router swaps and flushes after a recycle, (4) mixes dust gifts (<ACTIVITY_MIN, balance grows without activity) and real gifts with distributions, (5) checks activity through PepesFamilyEthRouter, or (6) checks the buyback against a pool whose active liquidity is 0.

  The brief's first question (can recycle take rewards earned in the last 7 days, or more than owed; is the token solvent) is therefore not regression-tested.

  A judge fuzz over 1,500 random sequences of up to 40 actions (buys, half-sells, dust and real gifts, un-flushed external swaps, flushes, claims, self-transfers, warps, recycles), tracking the holder's accumulative dividend after every action to compute the true amount earned in the last 7 days, found no violation: expired <= owed, withdrawable after recycle >= rewards distributed in the last 7 days, IMD balance >= accountedBalance, and recycles only when now > lastActive + 7 days.

  Across 60 fixed seeds of 40 actions each, 325 recycle calls were made and 39 of the 60 sequences recycled a positive amount, so the path is exercised rather than trivially passing. Not a code defect; recommend adding these properties to test/PepesFamily.t.sol. Merged from audit_permissions (info).

  whole finding

  test/scratch/ExpiryInvariants.t.sol (all pass): testFuzz_recycleNeverTakesRecentOrMoreThanOwed (1,500 runs; test/scratch/ExpiryStats.t.sol counts the coverage over 60 fixed seeds); test_secondRecycleOnlyTakesAgedRewards: R1 day 0, R2 day 5, recycle day 8 takes R1 only; recycle day 10 takes 0 (R2 is 5 days old); R3 day 10; recycle day 13 takes R2 only and leaves R3. test_zeroBalanceHolderLosesEverythingOld: bob buys day 0, earns, sells all day 1, alice buys day 3 (bob earns nothing), day 8+1s recycle(bob) returns his whole day-0 reward and withdrawableDividendOf(bob) == 0. test_flashHeldTokensDoNotChangeExpiryOrDistribution: inside an attacker's unlock holding the pool's whole token balance, expiredRewardsOf(bob) equals its value outside the unlock, distribute() returns 0, pending fees stay pending, and the flash holder's claim pays 0. Uncovered-case example currently not asserted by the suite: the zero-balance all-expires sequence above.

  whole reproduction

1. posted18 minto the first attempt
2. reviewed
   #38Audit mathClaude4 findings · 1 medium

   The property fuzz (2,000 runs with random distribution timing and dust gifts) and the exact 7-day boundary test both pass, so the expiry arithmetic holds as documented. The review is complete and the findings file is final.

   Result: 0 critical, 0 high, 1 medium, 2 low, 1 info, written to .imd-findings.json at the repository root. Scratch tests live under contracts/test/scratch/.

   Findings

   • Medium, paced buyback front-run. The 1% cap and 4% fees make an atomic sandwich lose (modelled break-even is about 4.2% of depth, so even 1% plus the $EARN contract's 2% in one transaction loses). But the hourly cadence is public and permissionless, so a trader can buy once, trigger the buyback every hour, and sell. A scratch test on a 1,060 IMD pool with a 20%-of-depth reserve shows the attacker gaining 21.5 IMD while the buyback spent 121 IMD. The proof test is embedded in the finding. The NatSpec's "2% bound" also mis-adds 1% + 2%.
   • Low, stray $PEPES locked. Only the swap delta is burned, so $PEPES sent directly to PepesBuyback stays there forever. Proof test embedded.
   • Low, cheap timer reset. A 10,000-token receipt resets any holder's timer. That is 0.001% of market cap, about 0.006 IMD at the fork test's launch cap and effectively nothing for a dead token, so expiry can be postponed indefinitely by a third party. An active wallet cannot be made to look inactive.
   • Info, constructor hardening. PepesFamily never checks that the shared buyback can function. I verified the live v1 router on Robinhood Chain exposes pad() and buy, the pad charges 400 bps, and poolKey($PEPES) resolves with IMD as currency0, so production parameters are correct.

   Checked and found sound

   • Recycle never takes rewards from the last 7 days nor more than owed, and IMD balance stays at or above accountedBalance. Balance can only grow since the last activity, so the "recent" estimate is an upper bound; the fuzz and boundary tests confirm it, including distributions in the same second as the last activity.
   • Flash-held pool tokens cannot trigger a distribution, and giving an inactive holder tokens only lowers what expires. Returning them is a send, which resets activity.
   • IMD can leave PepesBuyback only through the router swap, with allowance reset afterwards. A reverting v1 router or a zero cap would strand funds, but the live pool cannot return to its empty-liquidity launch state because burned tokens can never be sold back.
   • Checkpoint growth is one entry per second at most, the binary search is O(log n), and uint192 or int256 overflow needs more than 1.8e19 IMD per token. recycleMany only costs its caller gas.
   • IMD-only launches, locked liquidity, the 4% fee on every router, and router compatibility are unchanged from v3.

   ran onclaude · claude-fable-5-1 · 32 turns · 17m 17s · 354 in · 59.8K out · 1.4M cached

   submissioncfd055897e306903907cce12aa0ef87dae59682e43db70788c732c8fc995b5fd

   device82692ab5f7f7e54e7f26fc3f02e1839a2354350fffd95dfb5b1c3d578aebb3c1

   started from9a32f8964a3e455bae7aee717cbe55de97186f4e

   bundlenone

   changed · 0 filesnothing

   • mediumPaced buyback can be front-run for profit across hours: the per-call cap bounds one sandwich, not the predictable seriescontracts/src/PepesBuyback.sol:85

     buybackAndBurnPepes is permissionless, always spends min(reserve, 1% of the $Pepes pool's IMD depth) with the caller's minPepesOut, and the only pacing is one call per hour. The 4% quote-side fee each way makes a single atomic sandwich lose (modelled break-even is ~4.2% of depth per victim trade, so even 1% + the $EARN contract's 2% in one transaction loses).

     But when the reserve holds several hours of caps, the flow is fully predictable: a trader buys $Pepes once, calls the buyback at every hour (each call moves the price ~1% in their favour and the cap grows with the depth their own buy added), then sells. Their round trip costs 8% once; the price move compounds per hour.

     With the v4 contract alone the trade turns positive after about 5 hourly calls at a 40%-of-depth stake; together with the $EARN buyback (2%/hour on the same pool) after 2 hours. The buyback therefore buys at a price the front-runner inflated and burns fewer $Pepes, and the front-runner keeps the difference. The NatSpec on MAX_BUYBACK_BPS ('both together stay within the 2%-of-depth bound') also mis-states the arithmetic: 1% + 2% = 3% per hour.

     whole finding

     State: a $Pepes/IMD pool with ~1,060 IMD virtual depth (PepesFamily launch + 1,000 IMD buy), PepesBuyback holding 212 IMD of expired rewards (20% of depth).

     Eve: (1) routerA.buy(pepes, 424 IMD) (40% of depth); (2) eight times: warp +1 hour, buyback.buybackAndBurnPepes(0, now); (3) routerA.sell(pepes, all).

     Expected (per the contract's own comment): a sandwich of the capped buyback loses money.

     Actual: the buyback spent 121.37 IMD, Eve ends with 10,021.48 IMD from 10,000 IMD (+21.48 IMD, ~18% of what the buyback spent).

     The same sequence with a single call (no waiting) loses, so the per-call cap is not the binding constraint.

     Mitigation options that keep the design: take minPepesOut from a reference price (e.g. require price impact vs. the pool's price at the previous buyback below a bound), randomise/jitter when a call is allowed, or skip a buyback when the price has risen more than X% since the last one.

     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 {PepesFamily} from "src/PepesFamily.sol";
     import {PepesFamilyRouter} from "src/PepesFamilyRouter.sol";
     import {PepesBuyback} from "src/PepesBuyback.sol";
     import {PadToken} from "src/PadToken.sol";
     
     contract MockIMD {
         string public name = "IMD";
         string public symbol = "IMD";
         uint8 public decimals = 18;
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         function mint(address to, uint256 amt) external {
             balanceOf[to] += amt;
         }
     
         function approve(address s, uint256 amt) external returns (bool) {
             allowance[msg.sender][s] = amt;
             return true;
         }
     
         function transfer(address to, uint256 amt) external returns (bool) {
             balanceOf[msg.sender] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     
         function transferFrom(address f, address to, uint256 amt) external returns (bool) {
             if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= amt;
             balanceOf[f] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     }
     
     /// @notice The $Pepes pool is modelled by a PepesFamily launch (same 4% quote-side hook fee and single-sided
     ///         curve as the v1 pad, whose FEE_BPS is 400 on chain). A second PepesFamily instance points its
     ///         PepesBuyback at that token and that router, exactly as production points at the v1 router.
     contract BuybackFrontrunTest is Test {
         uint160 constant FLAGS = uint160((1 << 13) | (1 << 11) | (1 << 7) | (1 << 6) | (1 << 3) | (1 << 2));
     
         PoolManager pm;
         MockIMD imd;
         PepesFamily padA; // stands in for v1: hosts the $Pepes pool
         PepesFamilyRouter routerA;
         PadToken pepes;
         PepesFamily padB; // v4: its PepesBuyback buys `pepes` through routerA
         PepesBuyback buyback;
     
         address eve = makeAddr("eve");
         address bob = makeAddr("bob");
     
         function setUp() public {
             vm.warp(1_800_000_000);
             pm = new PoolManager(address(this));
             imd = new MockIMD();
             padA = _deployPad(address(1), address(2));
             routerA = PepesFamilyRouter(payable(padA.router()));
             pepes = PadToken(payable(padA.launch("Pepes", "PEPES", "", address(imd))));
             padB = _deployPad(address(pepes), address(routerA));
             buyback = PepesBuyback(padB.buyback());
     
             // a $Pepes pool with some depth: bob bought in earlier (virtual IMD depth ~1,060 IMD)
             imd.mint(bob, 10_000e18);
             vm.startPrank(bob);
             imd.approve(address(routerA), type(uint256).max);
             routerA.buy(address(pepes), 1_000e18, 0, block.timestamp);
             vm.stopPrank();
     
             imd.mint(eve, 10_000e18);
             vm.startPrank(eve);
             imd.approve(address(routerA), type(uint256).max);
             pepes.approve(address(routerA), type(uint256).max);
             vm.stopPrank();
         }
     
         function _deployPad(address pepes_, address pepesRouter_) internal returns (PepesFamily) {
             int24 tick = 161200; // ~100 IMD launch market cap (1e7 tokens per IMD)
             bytes memory initCode = abi.encodePacked(
                 type(PepesFamily).creationCode,
                 abi.encode(
                     pm,
                     address(imd),
                     address(this),
                     address(this),
                     tick,
                     PepesFamily.ImdEthPool(10_000, 100, address(0)),
                     pepes_,
                     pepesRouter_
                 )
             );
             bytes32 salt;
             address predicted;
             for (uint256 i;; i++) {
                 salt = bytes32(i);
                 predicted = address(
                     uint160(uint256(keccak256(abi.encodePacked(bytes1(0xff), address(this), salt, keccak256(initCode)))))
                 );
                 if (uint160(predicted) & 0x3FFF == FLAGS) break;
             }
             address deployed;
             assembly {
                 deployed := create2(0, add(initCode, 0x20), mload(initCode), salt)
             }
             require(deployed == predicted, "hook address");
             return PepesFamily(deployed);
         }
     
         /// Eve buys 40% of the pool's IMD depth, calls the capped buyback at every hour for 8 hours (anyone may),
         /// then sells. Each call is capped at 1% of depth and loses money if sandwiched atomically, but the hourly
         /// pace makes the flow predictable: the price moves ~1%/hour in her favour while her round trip costs 8%.
         /// With a reserve of 20% of depth she exits with more IMD than she started with.
         function test_pacedBuybackCannotBeFrontRunForProfit() public {
             uint256 depth = buyback.maxBuyback() * 100;
             imd.mint(address(buyback), depth / 5);
             uint256 start = imd.balanceOf(eve);
     
             vm.startPrank(eve);
             uint256 got = routerA.buy(address(pepes), depth * 40 / 100, 0, block.timestamp);
             for (uint256 h; h < 8; h++) {
                 vm.warp(block.timestamp + 1 hours);
                 buyback.buybackAndBurnPepes(0, block.timestamp);
             }
             routerA.sell(address(pepes), got, 0, block.timestamp);
             vm.stopPrank();
     
             uint256 end = imd.balanceOf(eve);
             emit log_named_decimal_uint("pool virtual IMD depth", depth, 18);
             emit log_named_decimal_uint("eve start IMD", start, 18);
             emit log_named_decimal_uint("eve end IMD", end, 18);
             emit log_named_decimal_uint("IMD spent by the buyback", buyback.totalImdSpent(), 18);
             assertLe(end, start, "front-running the paced buyback must not be profitable");
         }
     }

     whole proof

   • low$Pepes sent directly to PepesBuyback is locked forever instead of burnedcontracts/src/PepesBuyback.sol:95

     Only the delta of the current swap is sent to the burn address; any $Pepes already held by the contract (sent by mistake, or donated to the burn, or dust left by a rounding difference) stays in before and is never transferred. The contract has no owner and no other function that moves $Pepes, so such tokens are stuck permanently, contrary to the NatSpec 'sends all of it to the burn address'.

     pepes.transfer(buyback, 5e18); imd.mint(buyback, 1e18); buyback.buybackAndBurnPepes(0, now).

     Expected: pepes.balanceOf(buyback) == 0 and DEAD received the 5e18 too.

     Actual: 5e18 $Pepes remain in PepesBuyback with no path out.

     Fix: burn the whole balance (burned = pepes.balanceOf(address(this)); pepes.transferOut(DEAD, burned);) and keep the event's pepesBurned as that amount.

     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 {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";
     import {TickMath} from "v4-core/src/libraries/TickMath.sol";
     import {PoolKey} from "v4-core/src/types/PoolKey.sol";
     import {Currency} from "v4-core/src/types/Currency.sol";
     import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
     import {ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
     
     import {PepesBuyback} from "src/PepesBuyback.sol";
     
     contract MockToken {
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         function mint(address to, uint256 amt) external {
             balanceOf[to] += amt;
         }
     
         function approve(address s, uint256 amt) external returns (bool) {
             allowance[msg.sender][s] = amt;
             return true;
         }
     
         function transfer(address to, uint256 amt) external returns (bool) {
             balanceOf[msg.sender] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     
         function transferFrom(address f, address to, uint256 amt) external returns (bool) {
             if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= amt;
             balanceOf[f] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     }
     
     contract MockRouter {
         MockToken imd;
         MockToken pepes;
         PoolKey key;
     
         constructor(MockToken i, MockToken p) {
             imd = i;
             pepes = p;
         }
     
         function setKey(PoolKey memory k) external {
             key = k;
         }
     
         function pad() external view returns (address) {
             return address(this);
         }
     
         function poolKey(address) external view returns (PoolKey memory) {
             return key;
         }
     
         function buy(address, uint256 amountIn, uint256, uint256) external payable returns (uint256 out) {
             imd.transferFrom(msg.sender, address(this), amountIn);
             out = amountIn * 1000;
             pepes.mint(msg.sender, out);
         }
     }
     
     contract StrayPepesTest is Test {
         address constant DEAD = 0x000000000000000000000000000000000000dEaD;
     
         function test_pepesSentDirectlyIsNeverBurned() public {
             vm.warp(1_800_000_000);
             PoolManager pm = new PoolManager(address(this));
             MockToken imd = new MockToken();
             MockToken pepes = new MockToken();
             MockRouter r = new MockRouter(imd, pepes);
             PoolModifyLiquidityTest lp = new PoolModifyLiquidityTest(pm);
             pepes.mint(address(this), 100_000e18);
             imd.mint(address(this), 100_000e18);
             pepes.approve(address(lp), type(uint256).max);
             imd.approve(address(lp), type(uint256).max);
             (address c0, address c1) =
                 address(pepes) < address(imd) ? (address(pepes), address(imd)) : (address(imd), address(pepes));
             PoolKey memory k = PoolKey(Currency.wrap(c0), Currency.wrap(c1), 3000, 60, IHooks(address(0)));
             pm.initialize(k, TickMath.getSqrtPriceAtTick(0));
             lp.modifyLiquidity(k, ModifyLiquidityParams(-887220, 887220, 1_000e18, 0), "");
             r.setKey(k);
             PepesBuyback b = new PepesBuyback(address(imd), address(pepes), address(r), address(pm));
     
             pepes.mint(address(b), 5e18); // $Pepes sent straight to the buyback (a donation to the burn)
             imd.mint(address(b), 1e18);
             b.buybackAndBurnPepes(0, block.timestamp);
             assertEq(pepes.balanceOf(address(b)), 0, "stray $Pepes stay locked in the buyback forever");
         }
     }

     whole proof

   • lowAnyone can postpone a holder's expiry indefinitely for ~0.001% of market cap per week (ACTIVITY_MIN is a token count, not a value)contracts/src/PadToken.sol:229

     A receipt of at least ACTIVITY_MIN = 10,000 tokens from any sender resets the recipient's lastActive. 10,000 tokens is 0.001% of the fixed 1e9 supply, so its cost is 0.001% of the token's market cap: 0.00635 IMD at the 635 IMD launch cap used in Fork.t.sol, and effectively nothing for a token whose price has collapsed, which is exactly the population whose abandoned rewards the expiry is meant to recycle.

     A third party (or a holder from a second wallet, without the gas of a claim per token) can therefore keep every inactive wallet 'active' at negligible cost, and the buyback never receives those rewards.

     This is the trade-off the comment 'the chain can't tell gift from purchase' acknowledges; it is reported because the brief asks whether another wallet's timer can be reset cheaply (yes) and whether an active wallet can be made to look inactive (no: lastActive only ever moves forward to block.timestamp).

     whole finding

     bob buys 10 IMD of a token and is inactive; at day 6 carol calls t.transfer(bob, 10_000e18) (worth ~0.0064 IMD at a 635 IMD market cap).

     Expected (design intent): a gift should not hold off someone else's expiry for free.

     Actual: lastActive[bob] = now, expiredRewardsOf(bob) stays 0 for another 7 days; repeating every week keeps bob's rewards out of the buyback forever.

     Possible fix without changing the design: make the threshold a share of the recipient's balance (e.g. receipt >= 10% of balance) or only count receipts from the PoolManager (real buys) plus self-initiated pulls.

     whole reproduction

   • infoPepesFamily constructor does not check that the shared buyback can actually function; a wrong pepesRouter/pepes locks every v4 token's expired rewards forevercontracts/src/PepesFamily.sol:208

     PepesBuyback has no owner and its router, token and pool are immutable. PadToken.recycle sends expired IMD to it unconditionally. If pepesRouter is not a contract with pad()/buy(), or pepes is not a launch of that pad (poolKey reverts UnknownToken), or the pool's liquidity is 0, maxBuyback()/buybackAndBurnPepes revert forever and the IMD is stuck, while recycle keeps feeding it.

     The deployment script and Fork.t.sol are the only guard. Against the live chain the parameters verify (v1 router 0xA736...83dC exposes pad() = 0x2d76...68CC, FEE_BPS 400, poolKey($Pepes) = (IMD, PEPES, 0, 200, pad)), so this is a deploy-time hardening note, not a live defect.

     Deploy PepesFamily with pepesRouter = an EOA.

     Expected: deployment refuses.

     Actual: it succeeds; later every recycle() sends IMD to a PepesBuyback whose buybackAndBurnPepes always reverts in maxBuyback().

     Fix: in PepesBuyback's constructor call IPepesPadV1(IPepesRouterV1(pepesRouter_).pad()).poolKey(pepes_) and require the pool is initialised (sqrtP != 0), so a misconfiguration reverts the deployment.

3. reviewed
   #629Audit economicsClaude5 findings · 2 low

   The review is complete. Findings are in .imd-findings.json at the repository root, and the only other files touched are my scratch tests under contracts/test/scratch/.

   Outcome: no critical, high or medium defects in the v4 changes. Two lows and three informational notes, each with a concrete state and a reproduction.

   Answers to the seven questions

   • Recycle bounds and solvency. Recycle can never take rewards earned in the last 7 days or more than is owed. The bound holds because any balance decrease records activity, so between the cutoff and now the balance is non-decreasing, and the over-estimate of "recent" is always in the holder's favour. I confirmed the two-step case the suite lacks: a second recycle days later takes only what has since aged past 7 days. IMD balance ≥ accountedBalance holds through claim and recycle, and the sum of withdrawable amounts stays ≤ accountedBalance.
   • Timer manipulation. lastActive only moves forward, so no one can make a wallet look inactive by writing state. The gap is the fixed 10,000-token threshold: once the market cap grows, genuine repeat buys through the project's own router fall under it and are ignored, so a wallet buying daily but never claiming has rewards expire. That is the first low. Resetting someone else's timer costs about 0.006 IMD at launch cap but only benefits the holder, so it is informational.
   • Flash-borrow guard. Flash-held pool tokens can only raise balances, which only shrinks what expires; distribution mid-unlock is still blocked unless the pad's own routers trigger it, and unlocks cannot nest. A scratch test shows expiredRewardsOf is identical inside and outside a foreign unlock.
   • Sandwich. Measured with the real hook on a PepesFamily pool, sweeping frontrun sizes and reading the cap after the frontrun: the attacker loses for buyback sizes up to 4.2% of depth and profits only from about 4.5%. The 1% cap alone and the 1% + 2% $EARN bundle are both safe, with roughly 1.2% of depth to spare. The code comment claims a 2% bound, which is wrong in wording, and 4% of each buyback goes to the v1 hook rather than the burn. Informational.
   • IMD leaving PepesBuyback. Only through the swap. The approval is reset, the v1 router pulls only from its caller, and maxBuyback hits 0 only if the $Pepes pool is fully sold out, which self-heals on the next buy. The dust-slot griefing idea fails because the call always spends min(reserve, cap). The second low is that force-sent $Pepes are never burned and make the contract a reward-earning $Pepes holder with unclaimable IMD.
   • Gas and limits. Checkpoints are one packed slot each and the search is O(log n), so even millions of distributions cost a few tens of thousands of gas to query. recycleMany cannot be abused: the caller pays, duplicates are no-ops.
   • IMD-only and constructor. Locked liquidity, the 4% fee path and router compatibility are unchanged. The one deployment risk is that a mis-wired pepes or pepesRouter address would strand every token's expired rewards forever; the deploy script's addresses are correct and the live fork tests pass.

   Coverage notes. All 48 unit tests and the 5 fork tests pass against live chain state. The economic, invariant and flow-gap passes were done in full on the three scoped files; the routers were read for context only. No formal invariant fuzzing was run, which the suite also lacks.

   ran onclaude · claude-fable-5-1 · 35 turns · 18m 33s · 418 in · 64.9K out · 1.8M cached

   submissionba7f69062ff57002a440221fc237de46e4148b00bd28099ac4acfec45a8efa15

   devicef9cb4fd544aa3c686146f6a5cd2d7c0fc4d64bd16839e218b8cb752ea0ba94f7

   started from9a32f8964a3e455bae7aee717cbe55de97186f4e

   bundlenone

   changed · 0 filesnothing

   • lowACTIVITY_MIN is a fixed token count, so genuine repeat buys stop counting as activity once the market cap grows and an actively buying wallet has its rewards expirecontracts/src/PadToken.sol:229

     A buy through either project router (or any v4 router) delivers tokens via PoolManager.take, so in _transfer msg.sender is the PoolManager, not the buyer. The receipt therefore only counts as activity when amount >= ACTIVITY_MIN (10,000 tokens = 0.001% of supply) or it is the wallet's first receipt. The threshold is denominated in tokens, not value: the IMD cost of 10,000 tokens scales linearly with market cap (1e-5 of the market cap).

     At a 236k IMD market cap a 1 IMD buy yields ~3,900 tokens and is ignored; at a 10M IMD market cap any buy under 100 IMD is ignored. A holder who keeps buying (through the project's own router, with its own IMD) but never calls claim() is 'inactive' from the moment of their first buy, and after 7 days anyone can recycle() every reward older than 7 days, even though the wallet traded one day earlier.

     This answers 'can an active wallet look inactive': yes, for every repeat buyer below the token threshold. The existing test test_expiry_buyingAgainResetsTheTimer only exercises a 1 IMD buy at a 100 IMD market cap (millions of tokens), so the threshold is never hit by the suite.

     Fix (keeps the gift rule intact): also record activity for a receipt from the PoolManager when the recipient initiated the transaction, e.g. || (from == poolManager && tx.origin == to); a Universal Router buy with recipient=victim then still does not count (tx.origin is the attacker), and extending someone's own timer is the only effect tx.origin can have. Alternatively let the two immutable project routers report activity for their msg.sender.

     whole finding

     Launch a token at the 100 IMD start cap (test setUp). carol buys 5,000 IMD so marketCap ~ 235,788 IMD. bob buys 1 IMD through PepesFamilyRouter (receives ~4,070 tokens, first receipt -> lastActive set). alice buys 100 IMD (bob earns). warp +6 days; bob buys another 1 IMD through PepesFamilyRouter -> receives ~3,914 tokens < ACTIVITY_MIN -> lastActive[bob] unchanged (expected: a real buy with his own IMD resets the timer). warp +1 day +1 s: recycle(bob) returns > 0 (expected 0: bob traded 1 day ago) and his rewards from day 0 go to the buyback. Scratch test test_smallRepeatBuyViaOwnRouterIsNotActivity in test/scratch/Probe.t.sol passes on the current code showing exactly this.

     whole reproduction

   • lowPepesBuyback burns only the delta of the swap, so $Pepes sent to it directly stay there forever and make the buyback a reward-earning $Pepes holder whose IMD is unclaimablecontracts/src/PepesBuyback.sol:95

     buybackAndBurnPepes burns balanceAfter - balanceBefore instead of the whole $Pepes balance. Any $Pepes that reach the contract by a plain transfer (mistaken send, airdrop, griefing) are never burned and cannot leave: the contract has no other function.

     PepesBuyback is not in PadTokenV1's exclusion list (that list is immutable: PoolManager, pad, router, token, 0x0, dEaD), so a non-zero $Pepes balance held here earns a pro-rata share of every future 3% $Pepes holder fee inside the $Pepes token contract. Nothing can ever call PadTokenV1.claim() from PepesBuyback, so that IMD is locked forever in the $Pepes token's accountedBalance and is subtracted from what the other $Pepes holders receive.

     The contract's own NatSpec promises 'all of it goes to the burn address'.

     Fix: burn the full balance, burned = pepes.balanceOf(address(this)); pepes.transferOut(DEAD, burned); (totalPepesBurned then also counts donations, which is the desired accounting).

     whole finding

     pepes.mint(buyback, 5e18) (any direct transfer of 5 $Pepes to the buyback), imd.mint(buyback, 1e18); call buybackAndBurnPepes(0, now).

     Expected: all $Pepes held by the contract (bought 1,000 + donated 5) go to 0x...dEaD.

     Actual: burned == 1000e18 and pepes.balanceOf(buyback) == 5e18 afterwards, permanently; on the live v1 $Pepes token those 5 $Pepes keep accruing IMD holder fees that nobody can claim.

     Scratch test test_forceSentPepesNotBurned in test/scratch/Probe.t.sol.

   • infoBuyback sandwich: 1% cap alone and 1% + 2% ($EARN) together are both unprofitable, but the comment's '2%-of-depth bound' is wrong (combined exposure is 3%, measured break-even about 4.2%) and 4% of evcontracts/src/PepesBuyback.sol:45

     Verified with the real hook code on a PepesFamily pool (same 4% IMD-side fee as the live v1 $Pepes pool), sweeping the attacker's frontrun size and reading the cap after the frontrun exactly as maxBuyback() does: attacker P&L is negative for every frontrun size when the buyback(s) total up to 4.2% of the pool's virtual IMD depth and becomes positive at 4.5% (best case +1.03 IMD at 4.5%, +17.6 IMD at 5%, on a 19,842 IMD depth).

     A constant-product model gives the same threshold (about 4%/0.96). So the single PepesBuyback call (1%) and the worst atomic bundle available today, PepesBuyback (1%) + PepesEarnToken.buybackAndBurnPepes (2%) on the same pool in one transaction, are safe, with a margin of about 1.2% of depth. The comment claims the two together stay 'within the 2%-of-depth bound', which is not what the code does (1% + 2% = 3%); the actual bound is about 4.2%.

     Any further anyone-callable buyer on the $Pepes pool (a v5 buyback, a vault burn) with more than ~1.2% of depth per hour would cross the threshold and make the bundle profitable for a sandwicher. Also note the economics of the burn itself: the buy goes through the v1 hook, so 4% of every IMD spent is not burned: 1% goes to the v1 feeRecipient (the team wallet 0x3c8A...691C) and 3% to current $Pepes holders; only 96% buys $Pepes.

     Suggested: fix the comment to state the 3% combined exposure and the ~4% break-even, and add a unit test that bundles both buybacks (the fork test only sandwiches the v4 buyback alone).

     whole finding

     test/scratch/Sandwich.t.sol test_sweep: pool with 19,841.6 IMD virtual depth; for V in {1%,2%,3%,4%,4.2%} of depth the best attacker P&L over A in {0.1%..50%} of depth is -1.203, -0.847, -0.488, -0.125, -0.052 IMD (all losses); for V = 4.5% it is +1.03 IMD (A = 3%), for V = 5% +17.58 IMD (A = 20%). Expected per the comment: bound at 2%; actual: safe up to ~4.2%, with the live combined exposure at 3%.

   • infoResetting another wallet's 7-day timer costs 10,000 tokens, which is about 0.006 IMD at the 635 IMD launch cap; harmless to holders, only reduces what expires to the buybackcontracts/src/PadToken.sol:52

     Anyone can set lastActive[victim] = now by transferring ACTIVITY_MIN tokens to the victim, or by buying 10,000 tokens with recipient = victim through any v4 router. 10,000 tokens are 0.001% of supply, i.e. 1e-5 of the market cap: ~0.0064 IMD at the 635 IMD launch cap, 1 IMD at a 100k IMD cap.

     Since lastActive only ever moves forward and every reset only delays expiry, this cannot harm the holder (who could reset their own timer for free with a 1 wei self-transfer anyway); the only party that gets less is the $Pepes burn, and a holder paying someone to keep their timer alive is equivalent to the holder claiming.

     No change strictly required; if the design wants gifts to be costly at every market cap, the threshold must be value-based rather than a fixed token count (see the related low on ACTIVITY_MIN).

     Token launched at 100 IMD cap (test setUp); carol buys 1 IMD and receives 7,790,894 tokens; after 6 days carol transfers 10,000 tokens to bob: lastActive[bob] == block.timestamp (test_costToResetOthersTimer in test/scratch/Probe.t.sol). Cost to carol: 10,000 / 7,790,894 of 1 IMD = 0.0013 IMD.

   • infoPepesBuyback's constructor does not check that the $Pepes pool wiring resolves; a wrong pepes/pepesRouter would strand every v4 token's expired rewards forevercontracts/src/PepesBuyback.sol:64

     The buyback address is immutable in PepesFamily and in every PadToken it launches, and PepesBuyback has no owner and no function other than the burn swap. maxBuyback() depends on IPepesRouterV1(pepesRouter).pad().poolKey(pepes) and on that pool being initialized; if any of these is wrong at deployment (e.g. the v2/v3 router address, or a token that is not launched on that pad), maxBuyback() reverts (UnknownToken) or returns 0 and buybackAndBurnPepes can never succeed, while recycle() keeps sending IMD there with no way out.

     The deploy script hardcodes the live v1 router 0xA736...83dC and $Pepes 0xE2C4...5644 (checked against deployments/robinhood.json and Fork.t.sol), so the planned deployment is correct; this is a deployment-safety item.

     Suggested: in the constructor call maxBuyback() once and revert if it returns 0, which turns a mis-wired deployment into a failed CREATE2 instead of a permanently bricked sink.

     whole finding

     Deploy PepesFamily with pepesRouter = the v3 router 0x8A9b...3a27 (whose pad has no launch for $Pepes): the constructor succeeds; later any recycle() moves IMD into the buyback; buybackAndBurnPepes reverts forever with UnknownToken from poolKey(); the IMD is unrecoverable (no owner, no sweep). Expected: deployment fails early.

4. reviewed
   #1357Audit permissionsClaude5 findings · 3 low

   Review complete. .imd-findings.json holds 5 findings (3 low, 2 info); no source files were changed, only test/scratch/ (which the task reserves for me). The findings file is gitignored-adjacent but present at the repo root.

   Verdict on the requester's questions

   Question	Answer	Evidence
   Can recycle take rewards from the last 7 days, or more than owed?	No. expired ≤ withdrawable, and withdrawn_after ≤ accumulative-at-cutoff held across a 600-run fuzz of random buys / half-sells / dust & ≥ACTIVITY_MIN gifts / un-flushed external swaps / claims / self-transfers / warps. The "balance can only have grown since last" argument is sound: every balance decrease writes lastActive[from].	test/scratch/ExpiryFuzz.t.sol
   Solvent?	Yes — IMD balance ≥ accountedBalance after every action in the fuzz.	same
   Reset another wallet's timer cheaply?	Yes — ~0.007 IMD at the 635-IMD start cap (10,000 tokens). Only holds off burns; no theft. Make an active wallet look inactive: no, lastActive only moves forward.	Finding 1
   Flash-borrow guard interplay	Intact. Distribution is still pad-only mid-unlock; recycle/expiredRewardsOf read only the victim's balance, which a flash-borrower can only increase (over-estimates "recent", holder's favour) and can't claw back. The buyback can't be entered mid-unlock (v1 router calls pm.unlock → AlreadyUnlocked), so flash-held $Pepes can't snipe its 3%.	reasoning + Leads.t.sol
   Sandwich, incl. with $EARN 2%	Unprofitable at any front-run size: constant-product sim with 4% IMD fee each way, combined 3% of depth → best case −0.00002·depth. A 50%-of-eligible-supply whale "gains" 0.00044·depth, which is just its ordinary holder dividend on the buyback, not sandwich profit.	numeric sim
   IMD leaving PepesBuyback another way / lock / grief	No other exit (approve-then-buy-then-approve-0, router pulls exactly owed ≤ imdIn). maxBuyback()==0 only when the single-sided pool sits at its launch edge (before its first buy) — not reachable for live $Pepes, self-healing. Permanent lock only via deploy misconfiguration (Finding 4, info).	Leads.t.sol
   Gas / limits	magAt is O(log n) cold SLOADs (~42k gas at 1M checkpoints); one packed slot per distribution. recycleMany only costs its caller; duplicates and non-expired entries are harmless.	—
   IMD-only / constructor vs v3	Routers byte-identical to v3 (diffed); hook fee path unchanged; liquidity lock unchanged. ethRouter remains compatible (all tokens are IMD-paired).	git diff HEAD~1

   Findings

   1. Low — PadToken.sol:229 — fixed-token ACTIVITY_MIN lets anyone reset a stranger's timer for ~0.007 IMD at launch price; the "dust gift" guard is a no-op there.
   2. Low — PadToken.sol:229 — the inverse at high cap: a real router buy of < 10,000 tokens (e.g. 1 IMD at ~250k-IMD cap in the harness) isn't activity; an actively buying holder is recycled.
   3. Low — PepesBuyback.sol:95 — only the swap delta is burned; $Pepes sent to the contract directly is locked forever.
   4. Info — PepesFamily.sol:208 — buyback wiring unvalidated and immutable; misconfiguration would strand all recycled IMD (open deploy-time item; the fork test covers it).
   5. Info — test/PepesFamily.t.sol:840 — untested edges (recycle before flush, zero-balance holder, EthRouter activity, inactive-liquidity buyback, same-block checkpoint).

   Trust assumptions (not findings): owner can change feeRecipient (1% protocol fee only) and startTick for future launches; deployer fixes pepes/pepesRouter forever. No critical/high issues, so no proof tests were attached.

   ran onclaude · claude-fable-5-1 · 38 turns · 19m 20s · 73 in · 71.7K out · 4.7M cached

   submission4981c57cb08e750fb00f77300b56ccfb4a22f8b7ffa9b5347833dd708eb79944

   devicee8816d4386532a666ded78d4345254a19a42c8c34ad865711f59dae4256653f3

   started from9a32f8964a3e455bae7aee717cbe55de97186f4e

   bundlenone

   changed · 0 filesnothing

   • lowAnyone can reset a stranger's 7-day timer for ~0.007 IMD: ACTIVITY_MIN is a fixed token amount, so the 'dust gift' guard is ineffective at launch pricescontracts/src/PadToken.sol:229

     The activity rule treats any receipt of >= ACTIVITY_MIN (10,000 tokens = 0.001% of supply) as the recipient's own activity, so a third party can push lastActive[victim] forward at will.

     The natspec on ACTIVITY_MIN says this 'keeps dust gifts from holding off someone else's expiry for free', but because the threshold is a token count and not a value, its cost tracks market cap: at the production start cap of 635 IMD, 10,000 tokens cost ~0.0067 IMD (in the test harness at a 100 IMD start cap, 0.01 IMD buys 94,193 tokens).

     One wallet holding a bag of a cheap token can therefore keep every other holder's rewards perpetually unexpired by sending 10,000 tokens to each of them once a week, which defeats the expiry/burn mechanism for that token. There is no theft: the holder's rewards stay claimable by the holder, the loser is only the $Pepes burn.

     Access-control lens: lastActive[to] is a storage slot that any token holder can write for any to, while the only other writers (claim, sending) are the holder's own acts.

     Suggested fix (design decision for the requester): make the third-party receipt threshold value-based (e.g. a fraction of the pool's current price, or a minimum IMD-equivalent read from the pool's sqrtPrice), or drop the amount >= ACTIVITY_MIN clause entirely and count receipts only when msg.sender == to (the holder's own pull) or on first receipt; a buy through PepesFamilyRouter could then be recorded as activity explicitly by having the router pass the buyer in hookData and the token check msg.sender == poolManager with a router-provided flag.

     whole finding

     Scratch test test_timerResetCost (test/scratch/Leads.t.sol): launch token at the harness' 100 IMD start cap; carol buys 0.01 IMD worth -> 94,193 tokens. bob buys 10 IMD, lastActive[bob] = T0. warp 6 days; carol calls t.transfer(bob, 10_000e18).

     Expected per the natspec intent: a gift from a stranger should not hold off bob's expiry; actual: lastActive[bob] == block.timestamp (reset), so expiredRewardsOf(bob) stays 0 for another 7 days.

     Cost to carol: 0.01 IMD for nine such resets.

   • lowA genuine router buy below 10,000 tokens by an existing holder is not activity: at a high market cap an actively buying wallet still gets recycledcontracts/src/PadToken.sol:229

     Tokens bought through PepesFamilyRouter or PepesFamilyEthRouter arrive via poolManager.take (msg.sender == PoolManager != to), so for an existing holder a buy only counts as activity if it delivers >= ACTIVITY_MIN tokens. The natspec equates 'receives at least ACTIVITY_MIN tokens' with 'a real buy', but the threshold is a token count: once the market cap is high, ordinary buys fall under it.

     In the harness (100 IMD start cap) after 5,000 IMD of inflow, 1 IMD buys 4,054 tokens; a holder who buys 1 IMD on day 6 is still recycled on day 7+1s. Scaled to the production 635 IMD start cap, at ~1.5M IMD market cap any buy under ~15 IMD does not reset the timer.

     Impact is bounded: only rewards older than 7 days expire and the holder could have claimed them; but it contradicts the documented rule ('a wallet is active when it ... receives >= ACTIVITY_MIN (a real buy)') and asymmetrically treats the same economic act (a buy) differently by market cap, while a sell of 1 wei always counts.

     Suggested fix: have the routers signal the buyer's own buy as activity (e.g. router calls a markActive(buyer) restricted to router/ethRouter, or token treats from == poolManager receipts as activity only when the trade came through the pad's routers via a transient flag set by the hook), independent of amount.

     whole finding

     Scratch test test_smallRealBuyNotActivity (test/scratch/Leads.t.sol): launch; bob buys 10 IMD (T0); carol buys 5,000 IMD; warp 6 days; bob buys 1 IMD through router.buy -> receives 4,054e18 tokens (< ACTIVITY_MIN). Expected: lastActive[bob] == now (he just bought); actual: lastActive[bob] == T0. warp 1 day + 1s: expiredRewardsOf(bob) > 0 and anyone can recycle(bob) although bob traded 25 hours earlier.

   • lowPepesBuyback only burns the swap delta: any $Pepes sent to the contract directly is locked forever instead of burnedcontracts/src/PepesBuyback.sol:95

     buybackAndBurnPepes snapshots the $Pepes balance before the swap and sends only the difference to 0x...dEaD. The contract has no owner and no other function that moves $Pepes, so $Pepes that reaches the contract by any other route (a direct transfer, an airdrop, a mistaken send to the 'burn' contract) is unrecoverable and never burned, although the contract's stated purpose is that everything it buys 'all go[es] to the burn address'.

     Asymmetry lens: the IMD side spends the whole balance (imdIn = imd.balanceOf(address(this))), the $Pepes side only the delta. No user funds are at risk; it only weakens the burn guarantee for stray tokens.

     Fix: pepes.transferOut(DEAD, pepes.balanceOf(address(this))) after the swap and report burned as the delta (or the whole amount).

     Scratch test test_strayPepesLocked (test/scratch/Leads.t.sol): pepes.mint(buyback, 5e18); imd.mint(buyback, 1e18); buyback.buybackAndBurnPepes(0, now). Expected: pepes.balanceOf(buyback) == 0 (everything burned); actual: 5e18 $Pepes remain in PepesBuyback with no function able to move them.

   • infoBuyback wiring (pepes, pepesRouter) is immutable and never validated at deployment: a misconfigured pair makes maxBuyback() revert and locks every recycled IMD forevercontracts/src/PepesFamily.sol:208

     PepesFamily deploys the shared PepesBuyback in its constructor from two unchecked constructor arguments (only non-zero is enforced, in PepesBuyback). Every v4 PadToken hard-codes that buyback address, recycle always succeeds in sending IMD there, and PepesBuyback has no owner and no path for IMD other than IPepesRouterV1(pepesRouter).buy.

     If pepes is not a token launched on pepesRouter.pad() (or pepesRouter is not a v1-compatible router, or $Pepes is not IMD-paired on that pad), maxBuyback() reverts in poolKey(pepes) (UnknownToken) or buy reverts (BadAmount for an ETH-paired token), so buybackAndBurnPepes can never succeed and all expired rewards of every v4 token accumulate in the buyback unrecoverably.

     The $EARN audit (finding 6) led to PepesEarnIMD.openPool validating the buyback targets; PepesFamily v4 has no equivalent check. This is a deployment-time trust assumption, not an exploitable path (Deploy.s.sol hard-codes the live $Pepes and v1 router, and Fork.t.sol asserts maxBuyback() > 0 on a fork), so it is reported as an open item: the deployer must run the fork test against the exact constructor arguments before broadcasting.

     A cheap on-chain guard would be require(PepesBuyback(buyback).maxBuyback() != type(uint256).max) style call in the constructor, i.e. calling maxBuyback() once so a bad wiring reverts the deployment.

     whole finding

     Deploy PepesFamily with pepesRouter = a v1 router whose pad has not launched pepes (or pepes = any non-v1 token).

     Launch a v4 token, buy, wait 7 days + 1s, recycle(holder): IMD lands in PepesBuyback.

     Call buyback.buybackAndBurnPepes(0, now): expected a burn; actual: revert UnknownToken from poolKey(pepes) inside maxBuyback(), on every call, forever; the IMD has no other exit.

   • infoUntested edges of the v4 expiry/buyback paths (recycle before flush, zero-balance holder, EthRouter activity, buyback with inactive liquidity, in-place checkpoint update)contracts/test/PepesFamily.t.sol:840

     The suite's expiry fuzz only drives three router buys with two gaps and never: (1) calls recycle while holder fees are still pending in the pad (third-party-router swaps not yet flushed) and then flushes, (2) recycles a holder whose balance is 0 (sold everything 7+ days ago) and checks that everything expires, (3) exercises activity through PepesFamilyEthRouter (sell via transferFrom, buy via take) or a sub-ACTIVITY_MIN gift followed by a distribution (balance growth without activity, where recent is deliberately over-estimated), (4) checks buybackAndBurnPepes when the $Pepes pool's active liquidity is 0 (a single-sided v1 pool sits at its range edge before its first buy; maxBuyback() returns 0 and the call reverts BadAmount until someone buys), (5) checks two distributions in one block updating the same checkpoint in place.

     During this review a scratch fuzz (test/scratch/ExpiryFuzz.t.sol, 600 runs of up to 40 random actions: buys, half-sells, dust and >=ACTIVITY_MIN gifts, un-flushed external swaps, flushes, claims, self-transfers, warps, recycles) asserted expired <= owed, withdrawn-after-recycle <= accumulative-at-cutoff (rewards earned in the last 7 days are never taken), withdrawable-after >= rewards earned since the cutoff, and IMD balance >= accountedBalance; all held.

     Recommend adding those properties to the repository's fuzz so the guarantee is regression-tested.

     whole finding

     Not a code defect.

     Example of an uncovered case: launch; bob buys 10 IMD; carol buys 10 IMD; bob sells 100% on day 1 (lastActive = day 1); alice buys on day 3 (bob holds 0, earns nothing); day 8+1s: recycle(bob) returns bob's whole day-0 reward (balance 0 => recent = 0), withdrawableDividendOf(bob) == 0.

     The current suite never asserts this all-expires case.

5. reviewed
   #1657Audit flowClaude5 findings · 3 low

   All five findings validate against the tree. The review is complete; here is the summary.

   Scope and method

   Reviewed PepesFamily.sol, PadToken.sol, PepesBuyback.sol (diffed against v3/PadTokenV3.sol and the audited $EARN design), the unchanged routers and the v1 launchpad/router from commit a549093 (the Pepes pool the buyback trades on). Built with forge 1.8.5; unit suite (48 tests) and fork suite pass. Added scratch work under contracts/test/scratch/:

   • ExpiryInvariant.t.sol — stateful fuzz of PadToken in isolation with a shadow model of every holder's per-distribution earnings: 51,200 calls (seed/transfer/distribute/claim/recycle/warp). recycle never took a reward distributed in the last 7 days, never more than owed; IMD balance ≥ accountedBalance and Σ withdrawable ≤ accountedBalance held throughout; the buyback received exactly totalRecycled.
   • Sandwich.fork.t.sol — Robinhood-chain fork with an attacker that uses the v1 flash self-rebate on both legs, claims its share of the buyback's own 3%, and stacks a 2%-of-depth $EARN-style buy. Loses money in every configuration on current state.
   • ActivityMin.t.sol — shows a real 5-IMD pool buy (52 tokens at a high cap) not counting as activity.

   Answers to the seven questions

   1. Recycle correctness / solvency — holds. The recent estimate is a provable upper bound (balance since lastActive is monotone because every send records activity) and the fuzz confirms it, including multi-window recycles and dust gifts.
   2. Timer manipulation — lastActive only moves forward; nobody can make a wallet look inactive. A third party can keep a wallet active for 10,000 tokens, but that only delays the burn and benefits no one, so no finding. The reverse edge (small real buys not counting) is Low #2.
   3. Flash-borrow guard — intact. No distribution can occur in a foreign unlock; recycle/expiredRewardsOf only read the target holder's own balance; a take to a victim must be settled, so it is a paid gift.
   4. Sandwich — not profitable today, even stacked with $EARN and with the v1 self-rebate (Low #1 quantifies the break-even: pool holding >~40% of Pepes supply; today ≈20%). The 1% cap alone is safe in every state. The repo's fork test only models a naive attacker.
   5. IMD exits / griefing — only the burn swap. maxBuyback()==0 is reachable only when all Pepes are back in the pool (Info #4); a misconfigured constructor would strand recycled IMD (Info #5). Directly-sent Pepes are stranded (Low #3).
   6. Gas / limits — binary search is O(log n) over storage; recycleMany only costs its caller; duplicates return 0.
   7. v3 guarantees — liquidity lock, 4% hook fee on every router, and router compatibility are unchanged; the IMD-only and constructor changes add no new entry points beyond recycle* and buybackAndBurnPepes, both of which do only what they claim.

   No critical/high findings, so no proof files were attached. Findings are in .imd-findings.json (3 low, 2 info).

   ran onclaude · claude-fable-5-1 · 44 turns · 20m 52s · 83 in · 71.2K out · 4.9M cached

   submission6969abddc6a6d41fcf8778ed0bfb595c3b141e9335ed55f88aec95ac923382e2

   devicefa99051b60a858d6533e33c4be9c9d3ea61bf5edfa7172a85df49806181ab49f

   started from9a32f8964a3e455bae7aee717cbe55de97186f4e

   bundlenone

   changed · 0 filesnothing

   • lowSandwich bound relies on the v1 $Pepes pool's nominal 4% fee; a flash-holding trader pays 4% - 3% x (pool share of supply), so the stacked v4+$EARN 3% buyback becomes sandwichable once the pool holds contracts/src/PepesBuyback.sol:46

     The cap argument (1% here + 2% in $EARN = 3% of depth, protected by 4% fees each way) assumes the attacker pays the full 4% on both legs. The $Pepes pool is a PepesFamily v1 pool: v1 PepesFamily.flush distributes mid-unlock for any caller and v1 PadToken.distribute has no unlock guard (AUDIT.md: 'the trader self-rebate variant cannot be mitigated for those versions').

     A sandwicher trading in its own unlock can therefore flash-take the PoolManager's $Pepes, flush, and claim back phi x 3% of its own fee on each leg, where phi = (pool's $Pepes) / (pool's + held outside). Its effective fee is 4% - 3%*phi per side.

     Modelling the pool as x*y=k with that fee: the 1%-only v4 buyback is never profitable to sandwich for any phi (best case -0.000 IMD per 1000 IMD depth at phi=1), but the stacked 3% (v4 call followed by the $EARN call in the same transaction, both permissionless with minOut=0) becomes profitable at phi >= ~0.40: +0.05 IMD per 1000 depth at phi=0.45, +0.16 at 0.50, +1.22 at 0.70, +3.1 at 1.0 (about 10% of the combined 30-IMD buyback).

     On the live chain today the PoolManager holds 2.0e26 of the 1e27 $Pepes supply (phi ~ 0.20, depth ~4,932 IMD, cap 49.3 IMD/h), so a fork test with the self-rebating attacker loses in every configuration (-0.06 IMD on a 5 IMD front-run with the $EARN 2% stacked). The repo's test_fork_buybackSandwichDoesNotPay only models a naive attacker through the v1 router with a 3,000 IMD front-run (loses 192 IMD), so it does not exercise the rebate or small, near-optimal front-runs.

     This is state-dependent: a broad $Pepes sell-off that pushes phi above ~0.4 makes the combined burn leak value to MEV. Since the v4 contract on its own stays within the safe bound, this is low.

     Fix options (design decision): keep the two buybacks from being stackable in one transaction (e.g. have PepesBuyback refuse when the $EARN token's lastBuyback == block.timestamp, and vice versa in a future $EARN version), or lower MAX_BUYBACK_BPS so the sum stays under the bound at phi=1 (sum <= ~1%), or route the burn through a pool whose hook has the v3 flash guard. At minimum, make the fork test use the flash-rebating attacker and scan small front-run sizes.

     whole finding

     State: v1 $Pepes pool with IMD depth D and pool share phi of supply.

     Attacker contract, one tx: (1) unlock, swap a IMD->Pepes, flash-take all PM Pepes, v1 pad.flush(PEPES), PEPES.claim(), return Pepes, settle; (2) PepesBuyback.buybackAndBurnPepes(0, now) [1% D]; (3) $EARN buybackAndBurnPepes(0, now) [2% D]; (4) sell all Pepes with the same rebate; (5) claim.

     Expected (README/comment): attacker always loses.

     Actual: with phi=0.5 and D=1000 IMD, a=46 IMD front-run nets +0.16 IMD; with phi=0.7, a=100 IMD nets +1.22 IMD.

     Today (phi~0.2) it loses, verified on a Robinhood fork at block ~81.57M with test/scratch/Sandwich.fork.t.sol (profits -0.06 .. -9.75 IMD for front-runs 5..640 IMD).

     whole reproduction

   • lowA real pool purchase below ACTIVITY_MIN (10,000 tokens) does not count as activity, so on higher-cap tokens a holder who keeps buying still has rewards expirecontracts/src/PadToken.sol:229

     A buy arrives from the PoolManager (from excluded, msg.sender = PoolManager != to), so it only refreshes lastActive[to] when amount >= ACTIVITY_MIN. ACTIVITY_MIN is 0.001% of supply, which the README equates with 'any real buy', but that holds only while the market cap is small: 10,000 tokens cost 0.0064 IMD at the 635 IMD launch cap, 0.38 IMD at $Pepes' current ~38k IMD cap, 10 IMD (~0.04 ETH at the current 240 IMD/ETH) at a 1M IMD cap, and 100 IMD at 10M.

     A holder who repeatedly buys amounts under that line through any router and never claims will see everything older than 7 days recycled, contrary to the documented promise.

     Expected: a purchase from the pool is the holder's own act and should count regardless of size (a flash take to a victim is already a real gift because the taker must settle it, so the dust-gift rationale does not apply to receipts from the PoolManager unless gifts of 1 wei via take are considered a problem; if they are, a much smaller threshold for from == poolManager, e.g. a quote-value floor, would preserve the intent).

     Alternatively document the threshold in IMD terms on the site. Design decision for the requester; low impact because the holder can always claim or self-transfer.

     whole finding

     test/scratch/ActivityMin.t.sol (uses the unit harness): launch; alice buys 100,000 IMD so the cap is ~90M IMD; bob and carol buy 10 IMD each; warp 6 days; bob buys 5 IMD from the pool -> receives 52 tokens (< 10,000); lastActive(bob) is unchanged; warp 1 day + 1 s -> expiredRewardsOf(bob) > 0 and recycle(bob) moves bob's older rewards to the buyback although bob bought one day ago. Expected per README ('any real buy'): the 5 IMD buy keeps bob active.

   • low$Pepes sent directly to PepesBuyback is never burned and accrues IMD dividends in the v1 token that nobody can claimcontracts/src/PepesBuyback.sol:95

     Only the delta of the swap is sent to the burn address.

     Any $Pepes transferred straight to the buyback (a user who assumes 'send Pepes here to burn', a mistaken airdrop, or a griefer's dust) stays in the contract forever: it has no function that moves $Pepes other than this delta, and PepesBuyback is not excluded in the v1 $Pepes token, so the stranded balance keeps earning its pro-rata share of the 3% holder fee in IMD inside the $Pepes token contract, which only claim() from msg.sender can withdraw.

     The contract's stated property 'no owner, nothing can leave except the burn swap' thus also means stranded $Pepes and their rewards are permanently lost to holders.

     Fix: burn the whole balance (burned = pepes.balanceOf(address(this)); pepes.transferOut(DEAD, burned);) so direct sends are burned on the next call, and account totalPepesBurned from that.

     State: anyone calls PEPES.transfer(buyback, 1_000e18).

     Then buybackAndBurnPepes(0, deadline) with a funded reserve.

     Expected: the 1,000 $Pepes are burned with the bought ones (or at least on the next call).

     Actual: before includes them, burned is only the swap output, pepes.balanceOf(buyback) stays 1,000e18 after every call, and PEPES.withdrawableDividendOf(buyback) grows with each $Pepes trade while no code path can claim or burn it.

   • infomaxBuyback() is 0 whenever the $Pepes price sits outside the pool's single-sided position, so the buyback reverts BadAmount and recycled IMD waits (not locked)contracts/src/PepesBuyback.sol:110

     getLiquidity returns the liquidity active at the current tick. The v1 $Pepes pool has a single position from the launch tick to the end of the curve; at exactly the launch tick (every $Pepes sold back into the pool) the position is not active, liquidity is 0 and the cap is 0, so buybackAndBurnPepes reverts BadAmount until the next buy moves the price into range.

     Nothing is lost (IMD stays in the contract and recycle keeps working), it is only a liveness note: the one state in which the burn cannot run is the one in which no one holds $Pepes. Noted for completeness; no change required, or return early with a clearer error.

     State: $Pepes pool tick == its position's boundary tick (all supply back in the pool). maxBuyback() -> 0; buybackAndBurnPepes(0, now) with imd.balanceOf(buyback) > 0 -> reverts BadAmount(). Expected per README: 'larger reserves burn over several calls'; actual: no burn is possible until someone buys $Pepes.

   • infoPepesBuyback constructor does not verify the $Pepes pool exists and is IMD-paired; a misconfigured deployment would strand every recycled reward forever since recycle() keeps sending IMD regardlesscontracts/src/PepesBuyback.sol:65

     PepesFamily deploys the buyback in its constructor from pepes and pepesRouter arguments that are only checked for zero. PadToken.recycle transfers IMD to buyback without calling it, so the buyback is a sink that must work.

     If pepesRouter.pad().poolKey(pepes) reverts (token not launched on that pad) maxBuyback reverts; if the token is ETH-paired (v1 supported ETH quotes) the v1 router's buy reverts BadAmount (msg.value must equal amountIn) forever; if the pool's currencies do not include imd the cap is computed from the wrong side. All three brick the burn permanently while recycling continues. PepesEarnIMD guards the analogous configuration in openPool.

     The Deploy script hardcodes the live $Pepes/v1 router (verified working on a fork), so this is deployment hygiene: add a constructor check that IPepesPadV1(IPepesRouterV1(pepesRouter_).pad()).poolKey(pepes_) has imd_ as one currency.

     whole finding

     Input: PepesFamily constructed with pepes = any ETH-paired v1 token (or a non-launched address).

     Expected: deployment rejected.

     Actual: deployment succeeds, every recycle moves IMD into the buyback, and buybackAndBurnPepes reverts on every call (v1 router BadAmount / UnknownToken), so the IMD is unrecoverable by design (no owner, no other exit).

6. reviewed
   #1295Audit judgeClaude7 findings · 3 low

   afterAudit math, Audit permissions, Audit economics, Audit flow

   The review is complete. The findings file at the repository root holds 7 verified findings, two of them carrying the specialist proofs that I confirmed fail on the current code.

   What I kept, merged and ranked

   • Low: paced buyback front-run. The atomic sandwich guarantee holds (confirmed by my own sweep), but a trader who buys once, triggers the hourly buyback eight times and then sells ends with more IMD than they started with. The specialist proof fails on this code with a 21 IMD gain on a 1,060 IMD pool. I demoted audit_math's medium to low: the trader needs about 40% of depth at risk for hours and any holder is advantaged the same way. Proof attached.
   • Low: stray $Pepes locked in PepesBuyback. Only the swap delta is burned. Four specialists reported this; I merged them and added the v1 angle, which I verified by reading PadTokenV1: the stranded balance earns IMD dividends that no code path can claim. Proof attached.
   • Low: ACTIVITY_MIN is a token count. Six specialist findings with one root cause, merged into one. Reproduced both sides: at a 241k IMD market cap a 1 IMD router buy yields about 3,978 tokens and does not reset the buyer's timer, so bob is recycled 25 hours after buying; and a stranger resets any timer for about 0.001 IMD.
   • Info: the sandwich-bound comment is wrong (3% combined, not 2%; measured break-even between 4.0 and 4.5% of depth). The v1 self-rebate variant from audit_flow is recorded as a lead only, since the v1 pad source is not in the tree and the specialist's own fork test lost money at the live state.
   • Info: constructor wiring not validated (four specialists merged), liquidity-zero cap at the launch tick (confirmed the live pool has the ordering that makes this reachable), and expiry test-coverage gaps.

   What I checked and found sound, answering the brief's remaining questions: recycle never takes rewards earned in the last 7 days or more than is owed, and the token stays solvent. My fuzz over 1,500 random sequences, tracking the holder's true recent earnings per action, found no violation, and repeated recycles of one wallet only take rewards as they age past 7 days. Flash-held pool tokens do not change expiry, recycling or distribution inside an attacker's unlock. Nothing can move a wallet's timer backwards. recycleMany, the checkpoint growth and the binary search present no abuse path, and the IMD-only and constructor changes leave the v3 hook fee and locked liquidity untouched.

   Dropped: nothing outright. Every specialist claim reproduced in substance; demotions are noted inside each finding.

   No repository files were changed. The only additions are the scratch tests under contracts/test/scratch/ and the findings file at the root.

   ran onclaude · claude-fable-5-1 · 48 turns · 20m 29s · 546 in · 58.8K out · 2.5M cached

   submission51451fee74048e31b8ab1cf9718275cd09160e371bc9fea0d3ad491c86c6c3ba

   devicebd7adba3a80458536c80f1f3abca218143308f2a67acbdf6148524561ea3eaed

   started from9a32f8964a3e455bae7aee717cbe55de97186f4e

   bundlenone

   changed · 0 filesnothing

   • lowPaced buyback is front-runnable for profit across hours: the per-call cap defeats an atomic sandwich, not a predictable series of hourly buyscontracts/src/PepesBuyback.sol:85

     buybackAndBurnPepes is permissionless and, whenever the reserve holds more than one cap, always spends exactly min(reserve, 1% of the $Pepes pool's IMD depth) at the market price (minPepesOut is the caller's, usually 0). The only pacing is one call per hour (line 85), so the whole flow is public and predictable.

     The 4% quote-side fee each way does make a single-transaction sandwich lose (confirmed: with a 1% buy, or 1% plus a 2% $EARN-sized buy in the same transaction, the best front-run over a sweep of sizes loses; break-even is a single-transaction buy of roughly 4.0 to 4.5% of depth).

     But a trader who buys $Pepes once, triggers the buyback at every hour and sells at the end pays the 8% round trip once while the buyback moves the price ~1% per hour in their favour, and the cap itself grows with the depth their own buy added. The buyback therefore buys at a price the front-runner inflated and burns fewer $Pepes; the difference goes to the front-runner.

     This is inherent to any predictable on-chain buyer and the trader carries hours of price risk with capital of about 40% of depth, so it is rated low rather than medium, but it means the comment's claim (lines 44-46) and README ('a buyback sandwich that loses money') hold only for the atomic case. The requester asked this question directly. Merged from audit_math (medium).

     Fix options that keep the design: skip or shrink a buyback when the pool price has risen more than X% since the previous buyback (reference price = sqrtPrice recorded at the last call), or jitter the earliest allowed time so the series is not exactly predictable. At minimum, correct the comment and README.

     whole finding

     Unit test on a PepesFamily pool standing in for the v1 $Pepes pool (same 4% hook fee, same single-sided curve): pool depth ~1,060 IMD after a 1,000 IMD buy; PepesBuyback holds 212 IMD (20% of depth) of recycled rewards.

     Eve: routerA.buy(pepes, 424 IMD) (40% of depth); eight times {warp +1 hour; buyback.buybackAndBurnPepes(0, now)}; routerA.sell(pepes, all).

     Expected (per the contract comment and README): Eve ends with less IMD than she started with.

     Actual: Eve starts with 10,000 IMD and ends with 10,021.48 IMD (+21.48 IMD, about 18% of the 121.37 IMD the buyback spent).

     The same sequence with one call and no waiting loses, so the per-call cap is not the binding constraint.

     Run: forge test --match-path test/scratch/Proof_431d.t.sol (fails on this code with 'front-running the paced buyback must not be profitable').

     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 {PepesFamily} from "src/PepesFamily.sol";
     import {PepesFamilyRouter} from "src/PepesFamilyRouter.sol";
     import {PepesBuyback} from "src/PepesBuyback.sol";
     import {PadToken} from "src/PadToken.sol";
     
     contract MockIMD {
         string public name = "IMD";
         string public symbol = "IMD";
         uint8 public decimals = 18;
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         function mint(address to, uint256 amt) external {
             balanceOf[to] += amt;
         }
     
         function approve(address s, uint256 amt) external returns (bool) {
             allowance[msg.sender][s] = amt;
             return true;
         }
     
         function transfer(address to, uint256 amt) external returns (bool) {
             balanceOf[msg.sender] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     
         function transferFrom(address f, address to, uint256 amt) external returns (bool) {
             if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= amt;
             balanceOf[f] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     }
     
     /// @notice The $Pepes pool is modelled by a PepesFamily launch (same 4% quote-side hook fee and single-sided
     ///         curve as the v1 pad, whose FEE_BPS is 400 on chain). A second PepesFamily instance points its
     ///         PepesBuyback at that token and that router, exactly as production points at the v1 router.
     contract BuybackFrontrunTest is Test {
         uint160 constant FLAGS = uint160((1 << 13) | (1 << 11) | (1 << 7) | (1 << 6) | (1 << 3) | (1 << 2));
     
         PoolManager pm;
         MockIMD imd;
         PepesFamily padA; // stands in for v1: hosts the $Pepes pool
         PepesFamilyRouter routerA;
         PadToken pepes;
         PepesFamily padB; // v4: its PepesBuyback buys `pepes` through routerA
         PepesBuyback buyback;
     
         address eve = makeAddr("eve");
         address bob = makeAddr("bob");
     
         function setUp() public {
             vm.warp(1_800_000_000);
             pm = new PoolManager(address(this));
             imd = new MockIMD();
             padA = _deployPad(address(1), address(2));
             routerA = PepesFamilyRouter(payable(padA.router()));
             pepes = PadToken(payable(padA.launch("Pepes", "PEPES", "", address(imd))));
             padB = _deployPad(address(pepes), address(routerA));
             buyback = PepesBuyback(padB.buyback());
     
             // a $Pepes pool with some depth: bob bought in earlier (virtual IMD depth ~1,060 IMD)
             imd.mint(bob, 10_000e18);
             vm.startPrank(bob);
             imd.approve(address(routerA), type(uint256).max);
             routerA.buy(address(pepes), 1_000e18, 0, block.timestamp);
             vm.stopPrank();
     
             imd.mint(eve, 10_000e18);
             vm.startPrank(eve);
             imd.approve(address(routerA), type(uint256).max);
             pepes.approve(address(routerA), type(uint256).max);
             vm.stopPrank();
         }
     
         function _deployPad(address pepes_, address pepesRouter_) internal returns (PepesFamily) {
             int24 tick = 161200; // ~100 IMD launch market cap (1e7 tokens per IMD)
             bytes memory initCode = abi.encodePacked(
                 type(PepesFamily).creationCode,
                 abi.encode(
                     pm,
                     address(imd),
                     address(this),
                     address(this),
                     tick,
                     PepesFamily.ImdEthPool(10_000, 100, address(0)),
                     pepes_,
                     pepesRouter_
                 )
             );
             bytes32 salt;
             address predicted;
             for (uint256 i;; i++) {
                 salt = bytes32(i);
                 predicted = address(
                     uint160(uint256(keccak256(abi.encodePacked(bytes1(0xff), address(this), salt, keccak256(initCode)))))
                 );
                 if (uint160(predicted) & 0x3FFF == FLAGS) break;
             }
             address deployed;
             assembly {
                 deployed := create2(0, add(initCode, 0x20), mload(initCode), salt)
             }
             require(deployed == predicted, "hook address");
             return PepesFamily(deployed);
         }
     
         /// Eve buys 40% of the pool's IMD depth, calls the capped buyback at every hour for 8 hours (anyone may),
         /// then sells. Each call is capped at 1% of depth and loses money if sandwiched atomically, but the hourly
         /// pace makes the flow predictable: the price moves ~1%/hour in her favour while her round trip costs 8%.
         /// With a reserve of 20% of depth she exits with more IMD than she started with.
         function test_pacedBuybackCannotBeFrontRunForProfit() public {
             uint256 depth = buyback.maxBuyback() * 100;
             imd.mint(address(buyback), depth / 5);
             uint256 start = imd.balanceOf(eve);
     
             vm.startPrank(eve);
             uint256 got = routerA.buy(address(pepes), depth * 40 / 100, 0, block.timestamp);
             for (uint256 h; h < 8; h++) {
                 vm.warp(block.timestamp + 1 hours);
                 buyback.buybackAndBurnPepes(0, block.timestamp);
             }
             routerA.sell(address(pepes), got, 0, block.timestamp);
             vm.stopPrank();
     
             uint256 end = imd.balanceOf(eve);
             emit log_named_decimal_uint("pool virtual IMD depth", depth, 18);
             emit log_named_decimal_uint("eve start IMD", start, 18);
             emit log_named_decimal_uint("eve end IMD", end, 18);
             emit log_named_decimal_uint("IMD spent by the buyback", buyback.totalImdSpent(), 18);
             assertLe(end, start, "front-running the paced buyback must not be profitable");
         }
     }

     whole proof

   • lowPepesBuyback burns only the swap delta: $Pepes sent to it directly is locked forever and accrues v1 holder dividends nobody can claimcontracts/src/PepesBuyback.sol:95

     buybackAndBurnPepes snapshots the $Pepes balance before the swap and sends only after - before to 0x...dEaD. The contract has no owner and no other function that moves $Pepes, so any $Pepes that reaches it by a plain transfer (a user assuming 'send $Pepes here to burn it', an airdrop, griefing dust) stays in before on every later call and never leaves, contrary to the NatSpec 'sends all of it to the burn address'.

     Because PepesBuyback is not in PadTokenV1's immutable exclusion list (PoolManager, pad, router, token, 0x0, dEaD), a stranded balance keeps earning its pro-rata share of every future 3% $Pepes holder fee inside the $Pepes token contract, and PadTokenV1.claim() pays only msg.sender, which PepesBuyback can never be; that IMD is lost to all other $Pepes holders.

     The IMD side spends the whole balance (imdIn = imd.balanceOf(address(this))) while the $Pepes side spends only the delta, an asymmetry with no reason behind it. Merged from four specialists (audit_math, audit_flow, audit_economics, audit_permissions), identical mechanism and fix.

     Fix: after the swap, burned = pepes.balanceOf(address(this)); pepes.transferOut(DEAD, burned); so direct sends are burned on the next call (totalPepesBurned then also counts donations, which is the desired accounting).

     whole finding

     pepes.mint(buyback, 5e18) (any direct transfer of 5 $Pepes to the buyback); imd.mint(buyback, 1e18); buyback.buybackAndBurnPepes(0, now).

     Expected: pepes.balanceOf(buyback) == 0 and the burn address received the 5 $Pepes with the bought ones.

     Actual: burned equals only the swap output and pepes.balanceOf(buyback) == 5e18 afterwards, permanently.

     Run: forge test --match-path test/scratch/Proof_4a52.t.sol (fails on this code with 'stray $Pepes stay locked in the buyback forever: 5000000000000000000 != 0').

     The v1 dividend part follows from reading src/v1/PadTokenV1.sol: isExcluded (lines 140-143) does not cover the buyback and claim() (line 173) pays msg.sender only.

     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 {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";
     import {TickMath} from "v4-core/src/libraries/TickMath.sol";
     import {PoolKey} from "v4-core/src/types/PoolKey.sol";
     import {Currency} from "v4-core/src/types/Currency.sol";
     import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
     import {ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
     
     import {PepesBuyback} from "src/PepesBuyback.sol";
     
     contract MockToken {
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         function mint(address to, uint256 amt) external {
             balanceOf[to] += amt;
         }
     
         function approve(address s, uint256 amt) external returns (bool) {
             allowance[msg.sender][s] = amt;
             return true;
         }
     
         function transfer(address to, uint256 amt) external returns (bool) {
             balanceOf[msg.sender] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     
         function transferFrom(address f, address to, uint256 amt) external returns (bool) {
             if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= amt;
             balanceOf[f] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     }
     
     contract MockRouter {
         MockToken imd;
         MockToken pepes;
         PoolKey key;
     
         constructor(MockToken i, MockToken p) {
             imd = i;
             pepes = p;
         }
     
         function setKey(PoolKey memory k) external {
             key = k;
         }
     
         function pad() external view returns (address) {
             return address(this);
         }
     
         function poolKey(address) external view returns (PoolKey memory) {
             return key;
         }
     
         function buy(address, uint256 amountIn, uint256, uint256) external payable returns (uint256 out) {
             imd.transferFrom(msg.sender, address(this), amountIn);
             out = amountIn * 1000;
             pepes.mint(msg.sender, out);
         }
     }
     
     contract StrayPepesTest is Test {
         address constant DEAD = 0x000000000000000000000000000000000000dEaD;
     
         function test_pepesSentDirectlyIsNeverBurned() public {
             vm.warp(1_800_000_000);
             PoolManager pm = new PoolManager(address(this));
             MockToken imd = new MockToken();
             MockToken pepes = new MockToken();
             MockRouter r = new MockRouter(imd, pepes);
             PoolModifyLiquidityTest lp = new PoolModifyLiquidityTest(pm);
             pepes.mint(address(this), 100_000e18);
             imd.mint(address(this), 100_000e18);
             pepes.approve(address(lp), type(uint256).max);
             imd.approve(address(lp), type(uint256).max);
             (address c0, address c1) =
                 address(pepes) < address(imd) ? (address(pepes), address(imd)) : (address(imd), address(pepes));
             PoolKey memory k = PoolKey(Currency.wrap(c0), Currency.wrap(c1), 3000, 60, IHooks(address(0)));
             pm.initialize(k, TickMath.getSqrtPriceAtTick(0));
             lp.modifyLiquidity(k, ModifyLiquidityParams(-887220, 887220, 1_000e18, 0), "");
             r.setKey(k);
             PepesBuyback b = new PepesBuyback(address(imd), address(pepes), address(r), address(pm));
     
             pepes.mint(address(b), 5e18); // $Pepes sent straight to the buyback (a donation to the burn)
             imd.mint(address(b), 1e18);
             b.buybackAndBurnPepes(0, block.timestamp);
             assertEq(pepes.balanceOf(address(b)), 0, "stray $Pepes stay locked in the buyback forever");
         }
     }

     whole proof

   • lowACTIVITY_MIN is a fixed token count, not a value: genuine small buys at higher market caps are not activity (an actively buying wallet gets recycled) while strangers reset any timer for ~0.001 IMDcontracts/src/PadToken.sol:229

     A buy through PepesFamilyRouter, PepesFamilyEthRouter or any v4 router delivers tokens with PoolManager.take, so in _transfer msg.sender is the PoolManager, not the buyer, and the receipt counts as activity only when amount >= ACTIVITY_MIN (10,000 tokens, 0.001% of supply) or it is the wallet's first receipt. The threshold is denominated in tokens, so its IMD value is 1e-5 of the market cap. Two consequences of the one rule.

     1. Holder's disfavour: once the market cap passes ~100,000 IMD, a 1 IMD buy yields fewer than 10,000 tokens, so a holder who keeps buying with their own IMD but never claims is 'inactive' from their first buy and anyone can recycle everything older than 7 days, although the wallet traded a day earlier. README and the contract notice equate the threshold with 'any real buy', which holds only at small caps; the suite only tests a 1 IMD buy at a ~100 IMD cap (millions of tokens).
     2. Burn's disfavour: a third party can push lastActive[victim] forward at will by sending 10,000 tokens, which costs ~0.0013 IMD at the harness's 120 IMD cap and ~0.0064 IMD at the production 635 IMD start cap; one wallet holding a bag of a cheap token can keep every other holder's rewards perpetually unexpired, defeating the expiry for that token (the NatSpec says the constant 'keeps dust gifts from holding off someone else's expiry for free'). Neither direction harms a holder's claimable balance (lastActive only ever moves forward, see test_lastActiveNeverDecreases) and the holder can always claim or self-transfer, so low. Merged from audit_math, audit_flow, audit_economics and audit_permissions (six findings, two impacts, one root cause). Fix options that keep the gift rule: let the two immutable project routers record the buyer's own buy as activity regardless of size (e.g. a markActive(buyer) restricted to router/ethRouter, or treat a receipt from the PoolManager as activity when the trade came through the pad's own routers), and make the third-party receipt threshold value-based (a share of the recipient's balance, or an IMD-equivalent read from the pool price) rather than a fixed count. At minimum document the threshold in IMD terms.

     whole finding

     test/scratch/Judge.t.sol, JudgeActivityTest (both pass on the current code, showing the behaviour). test_smallRealBuyIsNotActivity: launch at the 100 IMD start cap; bob buys 10 IMD (lastActive = T0); carol buys 5,000 IMD (market cap 241,296 IMD); warp 6 days; bob buys 1 IMD through PepesFamilyRouter and receives 3,977.7 tokens (< 10,000) -> lastActive[bob] == T0 unchanged (expected: now, he just bought); warp 1 day + 1 s; recycle(bob) moves 150.30 IMD of bob's 150.30 IMD owed to the buyback (expected 0: bob traded 25 hours earlier). test_thirdPartyResetsTimerCheaply: carol buys 0.01 IMD and receives 79,984 tokens; warp 6 days; carol.transfer(bob, 10,000e18) -> lastActive[bob] == block.timestamp; cost 0.00125 IMD per reset at a 120 IMD market cap.

     whole reproduction

   • infoSandwich-bound comment is wrong: the v4 and $EARN buybacks together expose 3% of depth, not 2%; measured break-even is about 4.0 to 4.5%, and a v1 fee self-rebate narrows that margin as the pool's shacontracts/src/PepesBuyback.sol:44

     The NatSpec says the 1% cap is 'half of the $EARN buyback's 2%, so both together stay within the 2%-of-depth bound'. 1% + 2% = 3%, and both calls are permissionless with minOut = 0, so an atomic bundle of PepesBuyback.buybackAndBurnPepes followed by PepesEarnToken.buybackAndBurnPepes on the same $Pepes pool buys 3% of depth in one transaction.

     Measured with the real hook on a PepesFamily pool (same 4% quote-side fee as the live v1 $Pepes pool, FEE_BPS 400 confirmed on chain): a naive attacker paying the full 4% each way loses for every front-run size when the victim buy is up to 4.0% of depth and first profits at 4.5% (+1.04 IMD on a 19,300 IMD pool), so today's 3% bundle is safe with a margin of roughly 1 to 1.5% of depth, and any further anyone-callable buyer on the $Pepes pool above that would cross the line.

     Lead not reproduced here (needs the v1 PepesFamily pad source, not in this repository): the v1 pad distributes mid-unlock for any caller and PadTokenV1.distribute has no unlock guard (AUDIT.md), so an attacker trading inside its own unlock can flash-take the PoolManager's $Pepes, flush, and claim back (pool share of supply) x 3% of its own fee each way; audit_flow's model puts the 3% bundle at profitable once the PoolManager holds ~40% of supply.

     Live today the PoolManager holds 1.979e26 of 1e27 $Pepes (~20%), where the specialist's fork test lost money in every configuration, so this is state-dependent and informational. Merged from audit_economics (info) and audit_flow (low, demoted: not reproducible against this tree and unprofitable at the live state).

     Suggested: fix the comment (3% combined, ~4% break-even), add a unit test that bundles both buybacks, and if the margin matters, make the two contracts refuse to run in the same block (e.g. PepesBuyback checks the $EARN token's lastBuyback != block.timestamp) or lower MAX_BUYBACK_BPS.

     whole finding

     test/scratch/Judge.t.sol, JudgeSandwichTest. test_stackedAtomicSandwichLoses: pool depth 19,300 IMD; buyback reserve 19,300 IMD; for front-run sizes 0.1% to 50% of depth: eve buys, buyback (1% of post-front-run depth), an unrelated buy of 2% of post-front-run depth in the same transaction (the $EARN stand-in), eve sells; best eve P&L = -0.47 IMD (loss). test_breakEvenSweep: victim buy of 1.0/1.5/.../4.0% of depth -> best attacker P&L -1.17/-1.00/-0.82/-0.65/-0.47/-0.30/-0.12 IMD (all losses); 4.5% -> +1.04 IMD at a 4% front-run; 5% -> +17.8 IMD; 6% -> +115 IMD. Expected per the comment: safe bound at 2%; actual: safe up to ~4%, with the live combined exposure at 3%.

     whole reproduction

   • infoBuyback wiring (pepes, pepesRouter) is only zero-checked at construction; a mis-wired deployment makes buybackAndBurnPepes revert forever while recycle keeps sending IMD there with no way outcontracts/src/PepesBuyback.sol:65

     PepesFamily's constructor deploys the shared PepesBuyback from two arguments that are checked only for zero. The buyback address is immutable in PepesFamily and in every PadToken it launches; PadToken.recycle transfers IMD to it unconditionally and PepesBuyback has no owner and no path for IMD other than IPepesRouterV1(pepesRouter).buy.

     If pepesRouter is not a v1-compatible router, pepes is not launched on pepesRouter.pad() (poolKey reverts UnknownToken), the pool is ETH-paired (the v1 router's buy then reverts BadAmount for an IMD-approved call), or imd is neither pool currency (cap computed from the wrong side), buybackAndBurnPepes can never succeed and every v4 token's expired rewards accumulate unrecoverably. PepesEarnIMD.openPool validates the analogous targets; PepesFamily v4 has no equivalent check.

     Deploy.s.sol hard-codes the live $Pepes 0xE2C4...5644 and v1 router 0xA736...83dC, and the wiring verifies on chain (router.pad() = 0x2d76...68CC, poolKey($Pepes) = (IMD, PEPES, 0, 200, pad), FEE_BPS 400) and in Fork.t.sol, so this is deployment hygiene, not a live defect. Merged from audit_math, audit_flow, audit_economics and audit_permissions.

     Fix: in PepesBuyback's constructor resolve IPepesPadV1(IPepesRouterV1(pepesRouter_).pad()).poolKey(pepes_), require that one currency is imd_ and that the pool is initialised (sqrtP != 0), so a mis-wired PepesFamily deployment reverts instead of creating a permanent sink.

     whole finding

     test/scratch/Judge.t.sol, JudgeWiringTest.test_eoaRouterAccepted_thenBuybackBricked (passes, showing the behaviour): deploy PepesFamily with pepes = 0xCAFE and pepesRouter = 0xBEEF (both EOAs).

     Expected: deployment refused.

     Actual: it succeeds; launch a token, bob and carol buy 10 IMD each, warp 8 days, recycle(bob) moves bob's IMD into the buyback; buyback.maxBuyback() and buyback.buybackAndBurnPepes(0, now) revert on every call, and the IMD has no other exit.

   • infomaxBuyback() is 0 while the $Pepes pool sits exactly at its launch tick (single-sided position inactive), so the buyback reverts BadAmount until someone buys; IMD waits, nothing is lostcontracts/src/PepesBuyback.sol:110

     getLiquidity returns the liquidity active at the current tick. The live $Pepes pool has IMD as currency0 and $Pepes as currency1 (confirmed on chain), so its single position runs from MIN_TICK to the launch tick and is inactive when the price is exactly at the launch tick (lower <= tick < upper fails at tick == upper).

     In that state, which is reached only when every $Pepes has been sold back into the pool, liquidity is 0, maxBuyback() returns 0 and buybackAndBurnPepes reverts BadAmount (line 89) even with a funded reserve. recycle keeps working and the IMD stays in the contract, so this is a liveness corner case rather than a lock: the one state in which the burn cannot run is the one in which nobody holds $Pepes. Today the PoolManager holds ~20% of supply, far from that state.

     Merged from audit_flow (info). No change required; optionally return early with a clearer error or fall back to the position's liquidity.

     whole finding

     test/scratch/Judge.t.sol, JudgeWiringTest.test_maxBuybackZeroAtLaunchTick (passes, showing the behaviour): launch a PepesFamily token whose pool has IMD as currency0 (the live $Pepes ordering) and point a PepesBuyback at it before any buy. maxBuyback() == 0; with 1 IMD in the buyback, buybackAndBurnPepes(0, now) reverts BadAmount.

     After one 1 IMD buy moves the price into range, maxBuyback() > 0.

     With the opposite ordering (token as currency0) the cap is positive at the launch tick.

   • infoExpiry test coverage: the suite never asserts that recent rewards survive repeated recycles, the all-expires case for a zero-balance holder, un-flushed fees, or sub-threshold receipts; the properties contracts/test/PepesFamily.t.sol:840

     The repository's expiry fuzz drives three router buys with two gaps and one recycle.

     It never (1) recycles the same wallet twice so that rewards cross the 7-day line between calls, (2) recycles a holder whose balance is 0 (sold everything 7+ days ago, so recent is 0 and everything older expires), (3) leaves fees pending in the pad from third-party-router swaps and flushes after a recycle, (4) mixes dust gifts (<ACTIVITY_MIN, balance grows without activity) and real gifts with distributions, (5) checks activity through PepesFamilyEthRouter, or (6) checks the buyback against a pool whose active liquidity is 0.

     The brief's first question (can recycle take rewards earned in the last 7 days, or more than owed; is the token solvent) is therefore not regression-tested.

     A judge fuzz over 1,500 random sequences of up to 40 actions (buys, half-sells, dust and real gifts, un-flushed external swaps, flushes, claims, self-transfers, warps, recycles), tracking the holder's accumulative dividend after every action to compute the true amount earned in the last 7 days, found no violation: expired <= owed, withdrawable after recycle >= rewards distributed in the last 7 days, IMD balance >= accountedBalance, and recycles only when now > lastActive + 7 days.

     Across 60 fixed seeds of 40 actions each, 325 recycle calls were made and 39 of the 60 sequences recycled a positive amount, so the path is exercised rather than trivially passing. Not a code defect; recommend adding these properties to test/PepesFamily.t.sol. Merged from audit_permissions (info).

     whole finding

     test/scratch/ExpiryInvariants.t.sol (all pass): testFuzz_recycleNeverTakesRecentOrMoreThanOwed (1,500 runs; test/scratch/ExpiryStats.t.sol counts the coverage over 60 fixed seeds); test_secondRecycleOnlyTakesAgedRewards: R1 day 0, R2 day 5, recycle day 8 takes R1 only; recycle day 10 takes 0 (R2 is 5 days old); R3 day 10; recycle day 13 takes R2 only and leaves R3. test_zeroBalanceHolderLosesEverythingOld: bob buys day 0, earns, sells all day 1, alice buys day 3 (bob earns nothing), day 8+1s recycle(bob) returns his whole day-0 reward and withdrawableDividendOf(bob) == 0. test_flashHeldTokensDoNotChangeExpiryOrDistribution: inside an attacker's unlock holding the pool's whole token balance, expiredRewardsOf(bob) equals its value outside the unlock, distribute() returns 0, pending fees stay pending, and the flash holder's claim pays 0. Uncovered-case example currently not asserted by the suite: the zero-balance all-expires sequence above.

     whole reproduction
7. publishedaudit report
8. onchain
   1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,133,251 · transaction#629#1657#1295#38#1357