report

Identity-md/research/blob/main/jobs/cbe092d6-65c8-4742-ada8-22bc471cbe91/_identitymd/README.md

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

2 low3 info

• 1.lowA gift received after a distribution shields another wallet's old rewards from expiry, contradicting the stated 'nobody can keep another wallet's rewards from expiring' guaranteecontracts/src/PadToken.sol:311

          uint256 recent = FullMath.mulDivRoundingUp(magnifiedDividendPerShare - magCut, balanceOf[holder], MAGNITUDE);

  Merged from audit_economics 1fd9e673, audit_math 936fd392, audit_permissions a7dcd037 and case (a) of audit_flow 9e1b675b; all four reproduce. expiredRewardsOf() protects the 'recent' part as (magnifiedDividendPerShare - magAt(now - 7d - 1)) x balanceOf[holder], using the holder's balance NOW.

  Tokens a third party sends to an inactive wallet after a distribution inside the window are therefore counted as if they had earned that distribution for the recipient, although the sender keeps those rewards (transfers move only future rewards). Since b803125e a gift no longer resets lastActive, but the balance term still lets a large enough gift shrink, or zero, the amount recycle() can send to feeRecipient.

  The code comment at lines 307-309 acknowledges the over-estimate 'in the holder's favour', while the contract notice (line 21) and README 'Activity' promise an absolute guarantee that does not hold.

  Bounds verified: recycle() never moves more than expiredRewardsOf(), the token stays solvent, and the shield is temporary: once a full window has passed since the gift (no newer distributions), all of the old rewards expire (checked: at T0 + 13 days + 1 expiredRewardsOf(bob) equals bob's whole withdrawable).

  The gifter irrevocably parts with the tokens and the inactive wallet could have claimed anyway, so no profit path was found; the impact is a false documented guarantee and delayed/reduced recycle revenue.

  Fix is a design decision: (1) document the limitation in the PadToken notice and README ('a gift never resets the timer but tokens received without activity delay expiry of up to balance x per-share growth of the last 7 days'); or (2) change the estimate so rewards on gifted tokens count only from receipt.

  Caution on (2): the simplest variant, snapshotting activeBalance at each activity and using min(balanceOf, activeBalance) as proposed by audit_permissions, makes the attached proof and the 53 suite tests pass but breaks the other stated guarantee 'what it earned during those last 7 days never expires': under that patch my ground-truth fuzz (test/scratch/Probe.t.sol::testFuzz_recycleBoundedAndSolvent, run against a patched copy outside the repo) found recycle taking 5.518 IMD when only 0.560 IMD had been distributed before the cutoff, because rewards earned inside the window on tokens received as gifts were expired.

  A correct code fix needs per-receipt accounting (amount and magnifiedDividendPerShare at receipt for gifts since the last activity), which is a larger change. The attached proof pins option (2); if the requester chooses option (1) it should be dropped. Either way add a regression test: the suite's gift tests only exercise gifts with no distribution inside the window.

  whole finding

  Commit 5d3fbb0, Foundry, mock IMD, start mcap 100 IMD (test/scratch/GiftShield.t.sol, the audit_permissions proof, re-run here).

  T0: bob buys 10 IMD, carol buys 50 IMD; bob (sole holder at flush time) is owed 1799999999999999999 wei.

  T0 + 6d: alice buys 200 IMD (6 IMD distributed over bob and carol); bob's real window earnings are 1430462255459255159 wei.

  Then carol transfers her whole balance to bob; t.lastActive(bob) is unchanged (T0).

  T0 + 7d + 1s: expected per the NatSpec, expiredRewardsOf(bob) ~= 1.8 IMD (everything earned before the window).

  Actual: expiredRewardsOf(bob) == 0 and recycle(bob) sends 0 to feeRecipient, because recent = (mag - magCut) x (bobBal + carolBal) ~= 6 IMD > 1.8 IMD withdrawable; carol still has her 4.57 IMD withdrawable. forge test --match-path test/scratch/GiftShield.t.sol -vv fails with 'old rewards must expire despite the gift: 0 != 1799999999999999999'.

  Same shape with carol gifting half her bag (audit_economics: expired 599999999999999999 -> 0) and with a 45% gift (audit_math: 32.999 IMD -> 18.956 IMD).

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

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {PoolManager} from "v4-core/src/PoolManager.sol";
  import {PepesFamily} from "src/PepesFamily.sol";
  import {PepesFamilyRouter} from "src/PepesFamilyRouter.sol";
  import {PadToken} from "src/PadToken.sol";
  import {DeployLib} from "script/DeployLib.sol";
  
  contract ScratchIMD {
      mapping(address => uint256) public balanceOf;
      mapping(address => mapping(address => uint256)) public allowance;
  
      function mint(address to, uint256 amt) external {
          balanceOf[to] += amt;
      }
  
      function approve(address s, uint256 amt) external returns (bool) {
          allowance[msg.sender][s] = amt;
          return true;
      }
  
      function transfer(address to, uint256 amt) external returns (bool) {
          balanceOf[msg.sender] -= amt;
          balanceOf[to] += amt;
          return true;
      }
  
      function transferFrom(address f, address to, uint256 amt) external returns (bool) {
          if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= amt;
          balanceOf[f] -= amt;
          balanceOf[to] += amt;
          return true;
      }
  }
  
  /// A gift received after a distribution inflates the recipient's "recent" rewards and shields old rewards
  /// from expiry, although the NatSpec says tokens someone else sends can't keep another wallet's rewards
  /// from expiring.
  contract GiftShieldTest is Test {
      address constant FEE_RECIPIENT = 0x3c8A4d94B3219F6633F2cC94094f4765b30c691C;
      PoolManager pm;
      PepesFamily pad;
      PepesFamilyRouter router;
      ScratchIMD imd;
      address alice = makeAddr("alice");
      address bob = makeAddr("bob");
      address carol = makeAddr("carol");
  
      function setUp() public {
          vm.warp(1_800_000_000);
          pm = new PoolManager(address(this));
          imd = new ScratchIMD();
          bytes memory initCode = abi.encodePacked(
              type(PepesFamily).creationCode,
              abi.encode(
                  pm,
                  address(imd),
                  address(this),
                  FEE_RECIPIENT,
                  DeployLib.startTickForMarketCap(100e18),
                  PepesFamily.ImdEthPool(10_000, 100, address(0))
              )
          );
          (bytes32 salt, address expected) = DeployLib.mineSalt(address(this), uint160(0x28CC), initCode, 0);
          address deployed;
          assembly {
              deployed := create2(0, add(initCode, 0x20), mload(initCode), salt)
          }
          require(deployed == expected, "hook address");
          pad = PepesFamily(deployed);
          router = PepesFamilyRouter(payable(pad.router()));
          address[3] memory users = [alice, bob, carol];
          for (uint256 i; i < users.length; i++) {
              imd.mint(users[i], 1_000_000e18);
              vm.prank(users[i]);
              imd.approve(address(router), type(uint256).max);
          }
      }
  
      function _buy(address who, PadToken t, uint256 amt) internal returns (uint256) {
          vm.prank(who);
          return router.buy(address(t), amt, 0, block.timestamp);
      }
  
      function test_giftAfterDistributionShieldsOldRewardsFromExpiry() public {
          vm.prank(alice);
          PadToken t = PadToken(payable(pad.launch("Test", "TST", "", address(imd))));
          _buy(bob, t, 10e18);
          _buy(carol, t, 50e18); // day 0: bob (sole holder) earns 0.3 + 1.5 IMD
          uint256 oldRewards = t.withdrawableDividendOf(bob);
          assertApproxEqAbs(oldRewards, 1.8e18, 10);
          uint256 lastBob = t.lastActive(bob);
  
          vm.warp(block.timestamp + 6 days);
          _buy(alice, t, 200e18); // day 6: 6 IMD spread over bob and carol
          uint256 bobRecentReal = t.withdrawableDividendOf(bob) - oldRewards;
  
          // Day 6, after the distribution: carol gifts bob her whole balance. Not bob's activity.
          uint256 carolBal = t.balanceOf(carol);
          vm.prank(carol);
          t.transfer(bob, carolBal);
          assertEq(t.lastActive(bob), lastBob, "a gift is not bob's activity");
          uint256 carolKeeps = t.withdrawableDividendOf(carol);
          assertGt(carolKeeps, 0, "carol keeps what she earned on those tokens");
  
          vm.warp(lastBob + 7 days + 1); // bob inactive for more than 7 days
          // Expected: everything bob earned before day 6 (1.8 IMD) has expired; only `bobRecentReal` is protected.
          // Actual: the gifted tokens are counted as if they had earned for bob during the window, so the
          // protocol receives nothing at recycle.
          uint256 expired = t.expiredRewardsOf(bob);
          emit log_named_uint("old rewards (should expire)", oldRewards);
          emit log_named_uint("bob's real recent rewards  ", bobRecentReal);
          emit log_named_uint("expiredRewardsOf(bob)      ", expired);
          assertApproxEqAbs(expired, oldRewards, 1e6, "old rewards must expire despite the gift");
          uint256 got = t.recycle(bob);
          assertEq(got, expired);
          assertApproxEqAbs(imd.balanceOf(FEE_RECIPIENT), oldRewards, 1e6);
      }
  }

  whole proof

• 2.lowExpiry is lazy: claim() pays rewards that have already expired unless someone called recycle() first, so the protocol's share depends on an undocumented keepercontracts/src/PadToken.sol:286

          amount = withdrawableDividendOf(msg.sender);

  From audit_economics 368ce461; reproduced. The contract notice says 'Rewards of a wallet inactive for more than 7 days expire' and README says expired rewards go to the protocol address, but expiry only takes effect when an unprivileged caller runs recycle()/recycleMany(). claim() resets lastActive and then pays the full withdrawableDividendOf(), expired part included; nothing in the contracts or tests asserts what claim() does on a wallet whose expiredRewardsOf() > 0.

  Consequences: (1) the recyclable revenue exists only if the team runs a recycler bot, which is not stated anywhere in README, AUDIT.md or the NatSpec (the sibling $EARN web copy does say 'You can still claim it until someone recycles it', so lazy expiry looks intended); (2) a holder who notices can always claim first, deterministically on Robinhood Chain's sequencer. No user funds are at risk, so low.

  Fix: if lazy expiry is the design, document it in the PadToken notice and README together with the keeper assumption, and add a test for claim() on an expired wallet; if strict expiry is wanted, compute expiredRewardsOf(msg.sender) in claim() before the lastActive reset and route that part to feeRecipient with the same accounting as recycle(), which keeps the bound and solvency properties.

  whole finding

  test/scratch/Probe.t.sol::test_claimIgnoresExpiry (passes on this code, showing the behaviour).

  Launch; bob buys 10 IMD, carol buys 10 IMD (bob owed 599999999999999999 wei); warp +60 days with no activity; expiredRewardsOf(bob) == 599999999999999999 (all of it). bob calls claim().

  Expected under the stated rule: at most the recent part (0) is paid and 0.6 IMD goes to feeRecipient.

  Actual: claim() returns 599999999999999999 to bob, imd.balanceOf(feeRecipient) stays 0 and totalRecycled stays 0.

• 3.infoAUDIT.md still describes v3: feeRecipient's role omits expired holder rewards, owner powers and invariant 4 do not mention recycle, scope and test count are staleAUDIT.md:83

  | `feeRecipient` | Receives protocol fees | Anything else |

  Merged from audit_math da18616d, audit_flow b3538cf4, audit_permissions 3d2b9b67 and the AUDIT.md part of audit_economics 26910b3a; all verified by reading the file against the code. AUDIT.md is the brief handed to reviewers, and no v4 commit touched it.

  At 5d3fbb0 it is contradicted by the code in four places: (1) line 83 says feeRecipient receives protocol fees and 'Anything else' is impossible, while PadToken.recycle (contracts/src/PadToken.sol:325) now pays every v4 token's expired holder rewards to IPadFlush(pad).feeRecipient(), read at call time; (2) line 82 says the owner cannot touch holder rewards, but setFeeRecipient now chooses where expired holder rewards go, including (owner trust assumption, verified in test/scratch/Probe.t.sol::test_ownerCanRedirectExpiredRewardsToToken) to the token itself, where the next distribute() spreads them to current holders instead of the manual buyback; README 'Owner powers' (line 184) was updated, AUDIT.md was not; (3) invariant 4 'Reward solvency' (line 138) lists claims as the only outflow and does not mention totalRecycled, so it cannot be checked as written against v4 (the correct statement is accountedBalance = distributed - claimed - recycled <= quote.balanceOf(token), with recycle bounded by expiredRewardsOf); (4) line 18 says 'In scope: v3' and line 218 says '34 unit + attack tests' while forge test runs 111 (53 in PepesFamily.t.sol alone), and sections 5 and 9 have no entry for expiry/recycle/activity.

  Removing PepesBuyback left no code inconsistency: constructor arity, Deploy.s.sol, both fork tests and the unit suite match the new wiring (111 tests pass offline), no reference to PepesBuyback or poke remains in the launchpad sources, tests or script, and MockPepes/MockPepesRouter in test/Mocks.sol belong to the live $EARN tests.

  Fix: add a v4 section to AUDIT.md (actor: anyone; destination: feeRecipient only, read at call time; manual buyback as a trust assumption as README line 83 states; owner can redirect it with setFeeRecipient), extend the owner and feeRecipient rows and invariant 4, and refresh scope and test counts.

  whole finding

  Read AUDIT.md line 83 ('feeRecipient | Receives protocol fees | Anything else'), line 82 (owner cannot touch holder rewards), line 138 (invariant 4) and line 218 ('34 unit + attack tests').

  Then: launch a v4 token, bob buys 10 IMD, carol buys 10 IMD, warp +8 days, anyone calls t.recycle(bob): IMD owed to a holder leaves the token to pad.feeRecipient(); after the owner calls pad.setFeeRecipient(treasury) a second token's recycle pays treasury instead (existing test test_expiry_goesToCurrentFeeRecipient: e1 to FEE_RECIPIENT, e2 to treasury).

  With setFeeRecipient(address(t)) recycle(bob) returns the owed amount, imd.balanceOf(t) is unchanged, accountedBalance drops by it and t.distribute() returns that amount to current holders. forge test reports 111 passed, not 34.

  whole reproduction

• 4.infoREADME build/deploy section describes the pre-v4 deployment: wrong output file name, an ETH_START_MCAP option the script never reads, stale test countsREADME.md:153

  The owner defaults to `0x3c8A…691C`, and any wallet can pay for the deployment (about 0.0003 ETH). The script mines the hook salt, deploys through the standard CREATE2 factory, and writes `deployments/robinhood.json`.

  From the README part of audit_economics 26910b3a; verified against contracts/script/Deploy.s.sol.

  (a) README line 153 says the script writes deployments/robinhood.json and line 178 tells the website operator to copy pad/router/block from that file, but Deploy.s.sol line 68 writes deployments/robinhood-v4.json (robinhood.json in the tree is an older deployment record); (b) README line 161 lists ETH_START_MCAP (default 1.5e18) as a deploy option, but v4 is IMD-only and Deploy.s.sol reads only IMD_START_MCAP, OWNER and SALT_START (SALT_START is not listed); (c) README lines 138-139 say '34 unit + attack tests' and '+ 7 fork tests' while PepesFamily.t.sol alone has 53 tests and forge test runs 111 offline; (d) README line 188 says the owner cannot add quote assets 'other than ETH and IMD' while v4 launches are IMD-only.

  None of this affects on-chain behaviour; it can mislead whoever deploys v4 or wires the website to the deployment file.

  Fix: update the Deploy and Test sections for the v4 script (robinhood-v4.json, IMD_START_MCAP/OWNER/SALT_START, current counts).

  whole finding

  grep -n ETH_START_MCAP contracts/script returns nothing (Deploy.s.sol lines 27-28 read only IMD_START_MCAP and OWNER, line 44 SALT_START); Deploy.s.sol line 68 is vm.writeJson(out, "./deployments/robinhood-v4.json").

  Expected per README: the ETH start cap is applied and deployments/robinhood.json is (re)written.

  Actual: the variable is never read and a different file is written. cd contracts && forge test prints '111 tests passed', not 34.

• 5.infoExpiry test coverage gap: no stateful ground-truth check that recycle only takes rewards older than 7 days; gift inside the window and zero-fee 1 wei buy untestedcontracts/test/PepesFamily.t.sol:853

      function testFuzz_expirySolvent(uint96 a, uint96 b, uint32 gap1, uint32 gap2) public {

  Merged from audit_math cdc5ec75 and audit_flow 9e1b675b; verified by reading the suite and by writing the missing checks as scratch tests (not kept).

  The central v4 guarantee, 'recycle can only ever move rewards that have expired', is pinned only by fixed sequences: testFuzz_expirySolvent runs buy(bob), warp, buy(carol), warp, buy(alice), one recycle(bob), two claims; it never recycles twice, never claims before a recycle, never sells, never gifts, never changes a holder's balance between the buys and the recycle, and never flushes third-party-router fees late.

  The hand-written cases (day 0/5/8/10/13) use a 1e6 wei tolerance. A regression that takes a few wei of recent rewards, or a change like the activeBalance patch discussed in the gift finding (which expires rewards earned inside the window on gifted tokens), would pass the suite unchanged: I confirmed the 53 tests still pass against such a patched copy while my ground-truth fuzz fails on it.

  Two behaviours the code relies on are also unexercised: (a) the 'recent over-estimate in the holder's favour' for a gift received during the window (PadToken.sol:307-309), and (b) an exact-in buy of 1 wei IMD through a third-party router, whose fee is 0 (1 * 400 / 10000; _chargeFee returns early) but which still calls markActive(tx.origin) in afterSwap, so the 'a buy of any size counts' rule is not pinned. Both behave as documented on the current code.

  Separately, 31 lines in this file compute vm.warp(block.timestamp + ...) or read block.timestamp after a warp; forge lint flags this under via_ir because the compiler may reuse an earlier block.timestamp read (my own probe captured a wrong t0 this way until switched to vm.getBlockTimestamp()). The suite currently passes, but a timing test can silently check the wrong instant after an unrelated edit.

  Suggested additions: a stateful fuzz that records, per holder and distribution, balance x delta(magnifiedDividendPerShare) with its timestamp and asserts on every recycle that expired <= sum of rewards at or before now - 7d - 1 net of withdrawals (+2 wei), withdrawable after == owed - expired, and solvency; a gift-in-window test asserting expired <= r1, withdrawable == owed - expired and solvency; a 1 wei external buy test asserting fee == 0 and lastActive updated; and vm.getBlockTimestamp() in the timing tests.

  whole finding

  Current suite: forge test --match-test testFuzz_expirySolvent only runs the fixed 3-buy/1-recycle sequence above; grep shows no test that transfers tokens to a holder between a distribution and a recycle, none with amountSpecified = -1, and no per-distribution ground truth. Scratch evidence on 5d3fbb0: test/scratch/Probe.t.sol::testFuzz_recycleBoundedAndSolvent (random router buys, partial sells, gifts, external buys with tx.origin set, warps, flushes, claims, recycles over up to 40 actions; asserts recycle == expiredRewardsOf, recycle <= rewards distributed at or before now-7d-1 net of withdrawals + 2 wei, withdrawable after == owed - expired, imd.balanceOf(token) >= accountedBalance, sum of withdrawable <= accountedBalance) passes 2000 runs on the current code and fails within 11 runs on the activeBalance-patched copy ('only rewards older than 7 days: 5518562966114463113 > 560066326748174097'). test_oneWeiExternalBuyMarksActiveWithZeroFee: quote as currency0, bob (vm.prank(bob, bob)) swaps amountSpecified = -1 via PoolSwapTest 6 days after his buy: pendingProtocolFees and pendingHolderFees unchanged, lastActive(bob) == block.timestamp, expiredRewardsOf(bob) == 0 six days later.

  whole reproduction

1. posted14 minto the first attempt
2. reviewed
   #720Audit mathClaude3 findings

   The findings file is in place at the repository root (it is ignored by a global rule, which is why plain status is empty), the scratch directory is removed, and no tracked file was changed. The review is complete.

   Result

   No defect of severity low or above in the three scoped contracts at commit 5d3fbb0. Three informational notes are recorded in .imd-findings.json.

   Answers to the four questions

   • Recycle bounded and token solvent: yes. I built a ground-truth model that records each holder's exact reward per distribution with its timestamp. Over random sequences of external-router buys and sells, gifts, warps, late flushes, claims and repeated recycles, every recycle took at most the rewards distributed at or before the cutoff and left the holder at least what it earned after it. The IMD balance never fell below accountedBalance. The only slack needed was 1 wei, which is sub-wei dust carried from before a claim and legitimately old. The same-second boundaries behave as documented: nothing expires at exactly 7 days, a reward distributed in the activity second expires at 7 days plus one second, and a reward distributed exactly 7 days before the check is kept.
   • Reading feeRecipient at recycle time: no revert path and no zero path. The getter is a plain storage read on an immutable pad address. The constructor and setter both reject the zero address. A changed recipient is followed, as intended. The owner can point it at the token itself, which turns expiry into a redistribution to current holders instead of a burn. That is an owner trust assumption, already stated in the README, and is noted in the third finding rather than reported as a defect.
   • Buyback removal left no code inconsistency. Constructor, deploy script, fork tests, NatSpec and README agree. The remaining buyback references belong to Pepes Earn, which still has its own on-chain buyback, and to mocks it uses. The audit brief is the one stale document.
   • No regression. All 111 project tests pass. The flash-holder guards from v3, the gift rule and the ETH router hookData crediting from b803125e are intact and covered by existing tests.

   Findings written (all info)

   1. A large gift to an inactive wallet shrinks its expired amount, because the recent-reward estimate uses the current balance. It only delays expiry by one period and costs the gifter the tokens, but the absolute wording in the NatSpec and README does not hold.
   2. The expiry fuzz test exercises one fixed sequence with a single recycle. A stateful ground-truth check like the one described above would pin the central v4 guarantee.
   3. The audit brief still describes v3: the fee recipient's role omits expired rewards, scope and test counts are stale.

   Tools run: forge build and the full non-fork suite, the project fuzz tests at 2000 runs, and the scratch ground-truth fuzz at 1000 and 3000 runs. Fork tests were not run, since they need network access.

   ran onclaude · claude-fable-5-1 · 33 turns · 13m 52s · 514 in · 57.3K out · 2.3M cached

   submissionbf5fe0fecc0e539676194b2335ded516bc2f056e8da9e5763d56e65a924cb351

   device4daa9547034f488b0a105fd5f658712b8a8286dc39dce89c712e4438286f72a9

   started from5d3fbb0463752698899a21eab4d43fd16d0d60a8

   bundlenone

   changed · 0 filesnothing

   • infoA gift of tokens to an inactive wallet delays expiry of its old rewards (contradicts the 'nobody can keep another wallet's rewards from expiring' claim)contracts/src/PadToken.sol:311

     expiredRewardsOf() estimates the non-expiring 'recent' rewards as the holder's CURRENT balance times the per-share growth since the cutoff. Since b803125e a gift no longer resets lastActive, but it still raises balanceOf[holder], and therefore recent, so a third party can shrink (or zero) another wallet's expired amount by sending it tokens right before a recycle.

     The code comment at line 224 acknowledges the over-estimate, but the contract notice (line 21) and README ('nobody can keep another wallet's rewards from expiring') state an absolute guarantee that does not hold.

     Impact is bounded: recycle still never takes recent rewards (verified with a ground-truth fuzz, 3000 runs), the shield only lasts until the next recycle 7 days later (the shielded rewards are then older than the new cutoff and are taken), and the gifter permanently parts with the tokens unless the inactive wallet becomes active, in which case it could simply claim. No way to profit was found; this is a documentation precision issue.

     Fix: either state the limitation in the NatSpec/README ('tokens received without activity delay expiry of up to balance x per-share growth of the last 7 days'), or, if the absolute guarantee is wanted, estimate recent from the balance as of the cutoff (e.g. snapshot the balance on unrecorded receipts), which is a design change.

     whole finding

     Foundry, MockIMD, fresh launch (start mcap 100 IMD). bob buys 100 IMD via the router (sole holder, 3 IMD fee waits), carol buys 1000 IMD (30 IMD fee): bob's withdrawable W = 32.999999999999999999 IMD, lastActive(bob)=T0. warp T0 + 8 days. alice buys 1000 IMD (30 IMD fee spread over bob+carol): expiredRewardsOf(bob) = 32.999999999999999999 IMD (exactly W: all pre-cutoff rewards). carol then transfers her whole balance, 426915738126212246992490101 tokens (45% of eligibleSupply 951882691425856700597693418), to bob; bob's lastActive is unchanged, but expiredRewardsOf(bob) drops to 18.956557863681531346 IMD.

     Expected per the stated guarantee: 32.999999999999999999 IMD recyclable.

     Actual: 18.956557863681531346 IMD; recycle(bob) returns that amount, and the remaining ~14 IMD of 8-day-old rewards stays claimable by bob until the next recycle after T0 + 15 days.

     whole reproduction

   • infoExpiry fuzz covers one fixed 3-buy sequence with a single recycle; no stateful check that recycle only ever takes rewards older than 7 days across claims, partial sells, gifts, late flushes and repeatcontracts/test/PepesFamily.t.sol:853

     The central v4 guarantee ('recycle can only ever move rewards that have expired') is tested only on fixed sequences (two buys, one recycle, in testFuzz_expirySolvent; and the hand-written day-0/5/8/10/13 case). The suite never records per-distribution ground truth, so a regression that takes a few wei of recent rewards, or that mis-stamps a late flush of third-party-router fees, would not be caught.

     During this review a scratch test (not kept) modelled the ground truth: after every standalone flush it records, per holder, balance x delta(magnifiedDividendPerShare) with the timestamp; on every random recycle it asserts (a) expired <= floor(sum of rewards with time <= now-7d-1 since the last claim)/2^128 + 1 wei (the +1 is sub-wei dust carried from before a claim: withdrawnDividends is the floored accumulative), (b) withdrawable after + 1 >= floor(sum of rewards with time > cutoff)/2^128, (c) IMD balance >= accountedBalance and sum of withdrawable <= accountedBalance, across 40 random actions (external-router buys/sells with tx.origin set, gifts, warps up to 10 days, flushes, claims, recycles).

     3000 runs passed, as did the same-second boundary (activity at L and a distribution at L: 0 expired at L+7d, exactly that distribution expired at L+7d+1, a distribution at L+1 kept until L+7d+2). This is reported as a coverage gap, not a defect: adding such a test to the suite (AUDIT.md section 9 already asks for stateful fuzzing of the section 5 invariants) would pin the guarantee the README makes.

     whole finding

     Current suite: forge test --match-test testFuzz_expirySolvent only ever runs buy(bob), warp, buy(carol), warp, buy(alice), recycle(bob), claim(bob), claim(carol).

     It never calls recycle twice in one run, never claims before a recycle, never sells, never gifts, and never flushes third-party-router fees late.

     Expected: a test that fails if recycle() returns 1 wei more than the rewards distributed at or before block.timestamp - 7 days - 1 (net of claims).

     Actual: no such assertion exists in contracts/test; the only ground-truth checks are the approximate (1e6 wei tolerance) hand-computed r1/r2/r3 cases.

     whole reproduction

   • infoAUDIT.md still describes v3: feeRecipient's role omits expired holder rewards, scope says v3, test count is staleAUDIT.md:83

     After 5d3fbb0 feeRecipient is also where every v4 token's expired holder rewards go (PadToken.recycle reads pad.feeRecipient() at call time), and setFeeRecipient therefore also redirects those rewards, including (owner trust assumption) to an address such as the token itself, where the IMD would be re-distributed to current holders instead of burned (verified: setFeeRecipient(token); recycle(bob) moves nothing out, accountedBalance drops by the expired amount, the next distribute() spreads it to current holders).

     The README's 'Owner powers' section records this, but the audit brief (the document an auditor is pointed to) still says the fee recipient receives protocol fees and 'anything else' is impossible, lists only v3 in scope (line 18), has no section on expiry/recycle/activity, and quotes '34 unit + attack tests' (line 218) against 111 today. The brief's invariant 4 (reward solvency) also does not mention recycle as a second path that decreases accountedBalance.

     Removing the buyback left no code inconsistency: the constructor, Deploy.s.sol, the fork tests and the NatSpec of PadToken/PepesFamily all agree; Mocks.sol's MockPepes/MockPepesRouter are still used by the Pepes Earn tests and are not leftovers.

     whole finding

     Read AUDIT.md line 83 ('feeRecipient | Receives protocol fees | Anything else'), line 18 ('In scope: v3'), line 218 ('34 unit + attack tests').

     Expected for a v4 final check: the role table says feeRecipient receives protocol fees and expired holder rewards and that the owner can redirect both; v4 files and the expiry mechanism in scope; the invariants list recycle as a path that reduces accountedBalance (bounded by expiredRewardsOf).

     Actual: none of these are present; forge test reports 111 tests, not 34.

     whole reproduction
3. reviewed
   #788Audit economicsClaude3 findings

   Review complete. No critical, high, medium or low defects in the v4 launchpad at 5d3fbb0. Three info-level notes are in .imd-findings.json.

   Answers to the four questions

   1. Recycle is still bounded to expired rewards, and the token stays solvent. recycle moves exactly expiredRewardsOf(holder), which is at most the holder's withdrawable amount. Balances can only shrink through the holder's own act, which resets the timer, so the "recent" estimate can only over-protect, never under-protect. Effects are applied before the IMD transfer, under the reentrancy guard. I confirmed this with a stateful fuzz over buy, sell, third-party-router buy, flush, gift, claim, recycle and time warps (64 runs, 3,840 calls): IMD balance never fell below accountedBalance, the sum of withdrawable never exceeded it, every recycle equalled the view's value, and the fee recipient received exactly the recycled total.

   2. Reading feeRecipient from the pad at call time is safe. The pad is immutable and non-upgradeable, the getter is a view, and both the constructor and setFeeRecipient reject the zero address. IMD is a plain OpenZeppelin-style ERC20 with no receiver hooks, so a contract recipient cannot make the transfer revert. The only new power is that the owner now also redirects expired rewards, which the README documents under owner powers. Setting the recipient to the token itself just re-distributes the amount to current holders on the next distribute, an owner-only oddity with no unprivileged amplifier.

   3. The removal left the code consistent. PadToken and PepesFamily constructors, the deploy script, the unit and fork tests all match. The buyback mocks in test/Mocks.sol are still used by the Earn tests, so they are not leftovers. What remains stale is documentation only, reported as info: README's deploy section still lists ETH_START_MCAP and the wrong output file name, both READMEs cite "34 unit tests", and AUDIT.md's roles table does not mention that feeRecipient now receives expired rewards.

   4. No regressions. The v3 flash-borrow guards in distribute and flush are intact, the hook still credits router users via hookData and others via tx.origin, gifts do not reset the timer, zero-amount transfers do not count, and the ETH router still encodes its user. The 53 unit tests pass.

   Two behavioural notes (info)

   • A gift of tokens to an inactive wallet does not reset its timer, but it does inflate the protected "recent" share, since that estimate uses the current balance. In a probe, a gift of half of another holder's bag took expiredRewardsOf from 0.6 IMD to zero. The code comment already acknowledges the over-estimate; the stronger NatSpec promise and the regression test do not. The gifter pays far more than the protocol forgoes, so there is no exploit.
   • Expiry is lazy. A wallet inactive for 60 days can still claim() everything if nobody recycled first. The protocol's recyclable revenue therefore depends on running a recycler. If that is intended, document it; if strict expiry is wanted, apply it inside claim().

   Scratch tests for the fuzz and both probes are under contracts/test/scratch/; no tracked files were changed.

   ran onclaude · claude-fable-5-1 · 40 turns · 9m 36s · 418 in · 41.6K out · 1.9M cached

   submission62c3afd53429f57dc4288cad2899bbb8e1622362704461a786911ed91ee9494c

   devicededc96e38388cb45a8281d3d762f4713de53d9dc9cdaf72a5541b60b2b4ba245

   started from5d3fbb0463752698899a21eab4d43fd16d0d60a8

   bundlenone

   changed · 0 filesnothing

   • infoA gift from a third party can still shrink or zero a holder's expired rewards through the "recent" over-estimatecontracts/src/PadToken.sol:311

     Residual of IMD Swarm b803125e finding 3. The contract notice (lines 21-22) promises that tokens someone else sends "don't count, so nobody can keep another wallet's rewards from expiring". The timer part holds: a gift no longer touches lastActive.

     But expiredRewardsOf() estimates the protected "recent" rewards as balanceOf[holder] x (per-share growth over the last 7 days), using the holder's CURRENT balance. Any tokens a third party sends to an inactive wallet are multiplied by all distributions of the last 7 days, so a gift of G tokens shields min(w, G x growth7d / MAGNITUDE) of the wallet's old rewards from recycle().

     The authors note the over-estimate at line 224 ("in the holder's favour"); this entry only quantifies that it contradicts the stronger wording and the regression test test_expiry_giftsNeverResetTheTimer, which asserts expiredRewardsOf(bob) > 0 but not that it stays equal to the old amount.

     Bound: recycle() still never moves more than expiredRewardsOf(), the token stays solvent (checked with a stateful fuzz over buy/sell/gift/claim/recycle/warp: IMD balance >= accountedBalance, sum of withdrawable <= accountedBalance, recycle == expiredRewardsOf always).

     Economics: the gifter irrevocably hands over tokens whose 7-day yield must be at least the amount shielded, so the cost exceeds what the protocol forgoes; the only beneficiary is the inactive wallet, which could have claimed anyway. No victim beyond the fee recipient's recyclable amount.

     Fix options if the strong guarantee is wanted: snapshot the holder's balance at each activity event (activeBalance[holder]) and compute recent with that snapshot plus only receipts the hook or the holder recorded; or simply soften the NatSpec to "a gift never resets the timer but can increase the protected recent share".

     whole finding

     Unit setup as in test/PepesFamily.t.sol (start mcap 100 IMD). t0: bob buys 10 IMD, carol buys 10 IMD -> bob earns R1 = 0.6 IMD (expected 0.3 from carol's buy plus his own launch-time share; measured 599999999999999999 wei). warp +8 days (bob inactive, carol inactive). alice buys 1000 IMD -> 30 IMD distributed over bob+carol at day 8. expiredRewardsOf(bob) == R1 (599999999999999999) as expected: only the old reward is expired. carol then transfers half her bag to bob (lastActive[bob] unchanged, still t0).

     Expected per NatSpec: expiredRewardsOf(bob) still == R1.

     Actual: expiredRewardsOf(bob) == 0 and recycle(bob) returns 0; the 0.6 IMD can no longer be sent to feeRecipient until 7 more days pass without a distribution.

     Scratch test test/scratch/Probe.t.sol::test_giftShieldsOldRewardsFromExpiry prints 'expired before gift 599999999999999999 / expired after gift 0'.

     whole reproduction

   • infoExpiry is lazy: claim() pays rewards that have already expired if nobody called recycle() firstcontracts/src/PadToken.sol:286

     The notice says "Rewards of a wallet inactive for more than 7 days expire", and README says expired rewards "go to the PepesFamily protocol address". In code, expiry only takes effect when an unprivileged keeper calls recycle()/recycleMany(); claim() resets lastActive and then pays the full withdrawableDividendOf(), expired part included.

     Nothing in the contracts or the test suite asserts the behaviour of claim() after expiry (no test calls claim() on a wallet whose expiredRewardsOf() > 0 without recycling first), so the intended semantics are undocumented at the contract level.

     Consequences: (1) the protocol's recyclable revenue depends entirely on running a recycler bot; (2) because Robinhood Chain has a centralized sequencer there is no public-mempool race, so whoever transacts first wins, deterministically. If lazy expiry is the intended design (it matches the Earn token's web copy "You can still claim it until someone recycles it"), document it in the PadToken notice and README.

     If strict expiry is wanted, the minimal change is to compute expiredRewardsOf(msg.sender) inside claim() before the lastActive reset and route that part to feeRecipient (same accounting as recycle), which keeps the bound and solvency properties. Either way, add a test for claim() on an expired wallet.

     whole finding

     Unit setup as in test/PepesFamily.t.sol. bob buys 10 IMD, carol buys 10 IMD (bob owed 0.6 IMD). warp +60 days with no activity. expiredRewardsOf(bob) == 0.6 IMD (all of it). bob calls claim(): expected under the stated rule, at most the recent (0) is paid and 0.6 IMD goes to feeRecipient; actual, claim() returns 0.6 IMD to bob and feeRecipient's balance stays 0. Scratch test test/scratch/Probe.t.sol::test_claimIgnoresExpiry passes on the current code.

   • infoDocs still describe the pre-v4 deployment: ETH launches, deployment file name, test count, feeRecipient roleREADME.md:161

     After the buyback removal the contracts, constructor arguments, Deploy.s.sol and the fork tests are consistent (no PepesBuyback, no pepes/pepesRouter parameters, Mocks' MockPepes/MockPepesRouter are still used by the Earn tests so they are not leftovers).

     The remaining inconsistencies are documentation only: (a) README 'Deploy (mainnet)' lists ETH_START_MCAP as an option, but v4 is IMD-only and script/Deploy.s.sol reads only IMD_START_MCAP, OWNER and SALT_START; (b) README line 153 says the script writes deployments/robinhood.json while Deploy.s.sol line 68 writes deployments/robinhood-v4.json (and README line 178 tells the website operator to copy from robinhood.json); (c) README line 138 and AUDIT.md line 218 say '34 unit + attack tests' while test/PepesFamily.t.sol alone has 53; (d) AUDIT.md line 83 lists feeRecipient as 'Receives protocol fees | Anything else', while in v4 it also receives every token's expired holder rewards and is read at recycle time, which is the new trust assumption the commit introduces (README 'Owner powers' does state it).

     None of these affect on-chain behaviour; they can mislead an operator deploying v4 or an auditor reading AUDIT.md as the v4 brief.

     whole finding

     Run cd contracts && IMD_START_MCAP=635e18 ETH_START_MCAP=3e18 forge script script/Deploy.s.sol (dry run): expected per README, the ETH start cap is applied; actual, the variable is never read (grep ETH_START_MCAP contracts/script returns nothing) and the output file named in the README (deployments/robinhood.json) is not the one written (deployments/robinhood-v4.json).

4. reviewed
   #57Audit flowClaude2 findings

   The findings file is valid, both snippets match the tree exactly, and the only working-tree change is my scratch directory. The review is complete.

   Result

   No defect found in the in-scope contracts at commit 5d3fbb0. The findings file holds two info-level notes, one on documentation drift and one on test coverage. No contract file was changed.

   Answers to the four questions

   • Recycle bound and solvency. recycle can only move expiredRewardsOf(holder), which is capped by withdrawableDividendOf. Accrued dividends per holder never decrease under the correction pattern, so withdrawn can never exceed accrued after a recycle. The accounted balance equals distributed minus claimed minus recycled, and the sum of withdrawables stays at or below it. The "recent" protection can only be over-estimated. Any balance decrease is the holder's own activity, and gifts only raise the estimate. I confirmed this with scratch tests: a gift of carol's whole bag to inactive bob reduced the recycled amount from 0.6 to 0.463 IMD and left the token solvent after everyone claimed. A flash-borrowed gift inside a foreign unlock cannot be unwound, so it is useless to an attacker.
   • Reading feeRecipient live. The pad is an immutable deployer with a plain storage getter that can never be zero. The constructor and setFeeRecipient both reject the zero address. IMD is a standard OFT with no transfer hooks, and recycle is non-reentrant, so a contract recipient cannot re-enter. The owner redirecting expired rewards is the documented trust assumption. A silly recipient such as the token itself or the PoolManager would be owner misconfiguration without an unprivileged amplifier, so it is not reported.
   • Leftovers from removing the buyback. The constructor arity, Deploy.s.sol, both fork tests and the unit suite are consistent. No PepesBuyback or poke reference remains in launchpad sources. The remaining "buyback" mentions in Mocks.sol, the website and src/earn belong to the separate Pepes Earn product. The one stale document is AUDIT.md. Its trust table still says feeRecipient receives protocol fees only and the owner cannot touch holder rewards, and its reward-solvency invariant omits recycling. That is finding 1.
   • Regressions. None found. The flash-holder guards, gift rule, ETH-router hookData crediting, zero-transfer rule, 7-day boundary and second-recycle aging all hold and have tests. The full offline suite passes with 111 tests and 4 fork tests skipped for lack of RPC.

   Coverage notes. I ran the twelve Pashov passes as review lenses, the Trail of Bits entry-point inventory and the x-ray threat profiles over the three scoped files plus the router, SafeTransfer and tests. Fork tests were not run. Finding 2 records two edges the suite does not pin: the gift-inflated estimate and the zero-fee 1 wei buy that still resets the timer. Both behave as the code comments intend.

   ran onclaude · claude-fable-5-1 · 42 turns · 10m 51s · 418 in · 41.7K out · 2.1M cached

   submission08489b094c39fa1254b8085b7b9aa5cc23e389fe90b0d01dd4efcd42750fef59

   devicefc87c05048aca47daef87ffd267432289136dfa75171a9f70061e92a14ec74ac

   started from5d3fbb0463752698899a21eab4d43fd16d0d60a8

   bundlenone

   changed · 0 filesnothing

   • infoAUDIT.md trust model and reward-solvency invariant not updated for v4 recycle-to-feeRecipientAUDIT.md:83

     AUDIT.md is the brief handed to third-party auditors for the contracts in contracts/src, yet it still describes v3 only.

     Three statements are now contradicted by the code at commit 5d3fbb0: (1) the role table says feeRecipient receives protocol fees and nothing else, but PadToken.recycle (contracts/src/PadToken.sol:325) sends every v4 token's expired holder rewards to IPadFlush(pad).feeRecipient(); (2) the same table says the owner cannot touch holder rewards, but setFeeRecipient now chooses the destination of expired holder rewards (README.md line 181 was updated to say so, AUDIT.md was not); (3) invariant 4 'Reward solvency' (line 138) lists claims as the only outflow and does not mention totalRecycled, so the invariant as written cannot be checked against v4.

     Removing PepesBuyback made feeRecipient the single sink for both flows and widened the owner's documented powers, and this is the only document in the repo that still states the narrower v3 trust model.

     The code itself is consistent: constructor arity, Deploy.s.sol, both fork tests and the unit suite (111 tests passing offline) all match the new wiring, and no reference to PepesBuyback/poke remains in the launchpad sources or tests (the remaining 'buyback' mentions in Mocks.sol, web/index.html and src/earn belong to the separate Pepes Earn product).

     whole finding

     State: a v4 PadToken with holder bob inactive for 7 days + 1 second and withdrawableDividendOf(bob) > 0.

     Input: anyone calls t.recycle(bob).

     Expected per AUDIT.md section 3: IMD for holder rewards never leaves the token except to the holder, and feeRecipient only ever receives the 1% protocol fee.

     Actual: recycle transfers bob's expired IMD to pad.feeRecipient(); after the owner calls pad.setFeeRecipient(treasury) a second recycle pays treasury instead (reproduced by the existing test test_expiry_goesToCurrentFeeRecipient in contracts/test/PepesFamily.t.sol: e1 to FEE_RECIPIENT, e2 to treasury).

     Fix: in AUDIT.md add the v4 flow to the owner and feeRecipient rows, extend invariant 4 to accountedBalance = distributed - claimed - recycled with accountedBalance <= quote.balanceOf(token), and state the manual buyback as a trust assumption as README.md already does.

     whole reproduction

   • infoUntested expiry edges: gift-inflated 'recent' estimate and zero-fee 1 wei activity resetcontracts/test/PepesFamily.t.sol:853

     The suite covers every expiry case named in the earlier audits, but two behaviours the code relies on in comments are never exercised. (a) PadToken.sol:307-309 states that an unrecorded receipt 'over-estimates recent rewards in the holder's favour'. No test gives an inactive holder a gift during the 7-day window and checks that recycle takes less than the aged rewards while the remainder stays claimable and the token stays solvent.

     (b) Activity from a buy of any size is documented, but the smallest case, an exact-in buy of 1 wei IMD through a third-party router, charges a fee of 0 (1 * 400 / 10000 = 0, _chargeFee returns early) and still calls markActive(tx.origin); no test pins this down, so a future change to the fee rounding or to the markActive placement could silently alter who stays active.

     Both behaviours were verified correct on the current code with the scratch tests described below; neither is a defect, this finding records the gap only. The fuzz test anchored here never changes a holder's balance between the buys and the recycle, so it cannot reach case (a).

     whole finding

     Case (a), concrete run on commit 5d3fbb0 (mock IMD, start mcap 100 IMD): day 0 bob buys 10 IMD, carol buys 10 IMD, bob's reward r1 = 599999999999999999 wei; day 6 alice buys 10 IMD, bob's reward r2 = 162913867663777655 wei; day 6 + 1h carol transfers her whole bag to bob (bob's lastActive unchanged); day 8 + 1h anyone calls recycle(bob).

     Expected if 'recent' were exact: 599999999999999999 recycled.

     Actual: 462913867663777654 recycled, 137086132336222345 wei of 8-day-old rewards stays claimable because recent = (mag - magCut) * post-gift balance; bob's withdrawable equals owed - expired and imd.balanceOf(token) >= accountedBalance after bob, carol and alice all claim.

     Case (b): with the quote as currency0, bob (vm.prank(bob, bob)) swaps via PoolSwapTest with amountSpecified = -1; pendingProtocolFees and pendingHolderFees do not change (fee 0) and t.lastActive(bob) becomes block.timestamp, so expiredRewardsOf(bob) is 0 six days later.

     Suggested additions: a test mirroring (a) asserting expired <= r1, withdrawable == owed - expired and solvency; a test mirroring (b) asserting fee == 0 and lastActive updated, so the 'any amount counts' rule is pinned.

     whole reproduction
5. reviewed
   #286Audit permissionsClaude2 findings · 1 low

   The review is complete and .imd-findings.json holds two findings. No contracts were modified; the only new files are the findings file and my scratch test under contracts/test/scratch/.

   Answers to the four questions

   • Recycle bound and solvency: hold. recycle can only move expiredRewardsOf(holder), which is capped by withdrawableDividendOf, and every withdrawnDividends increment is mirrored by an accountedBalance decrement. Accumulated dividends are monotone, so withdrawable never underflows, and the sum of withdrawables stays at or below accountedBalance. The 53 unit tests pass, including the solvency fuzz.
   • Reading feeRecipient from the pad: safe. The constructor and setFeeRecipient both reject the zero address, the getter cannot revert, pad is an immutable set to the deploying launchpad, and only PepesFamily deploys PadToken. The owner redirecting both protocol fees and expired rewards is a documented trust assumption, and README line 184 says so.
   • Buyback removal: consistent in code. No buyback parameters remain in either constructor, the deploy script, or the fork tests. The remaining MockPepes and web buyback UI belong to the live $EARN subsystem, which still has its own buyback. The one gap is documentation, reported as info.
   • No regression of earlier findings or v3 guarantees. Flash-holder guards in distribute and flush, the hook's markActive via router hookData or tx.origin, the gift rule on lastActive, and the ETH router's user hookData are all intact.

   Findings written

   1. Low, contracts/src/PadToken.sol:311. The "recent" protection multiplies the window's per-token growth by the holder's current balance. Tokens gifted to an inactive wallet after a distribution are counted as if they had earned it, while the sender keeps those same rewards. In the reproduction, bob's 1.8 IMD of old rewards should expire, but after carol gifts her bag expiredRewardsOf(bob) is 0 and the protocol receives nothing. This contradicts the NatSpec promise that "nobody can keep another wallet's rewards from expiring". The gifter loses the tokens, so it's a false guarantee and recycle-revenue griefing rather than theft. Proof test attached and confirmed failing on this code.
   2. Info, AUDIT.md:83. The audit brief was not updated for v4. Its roles table says feeRecipient only receives protocol fees, its invariants and test sections omit expiry and recycle, and both it and the README still quote stale test counts.

   Coverage note. All in-scope files, the router, the transfer library, both test files and the last three commits' diffs were read in full. Fork tests were not run, since they need network access.

   ran onclaude · claude-fable-5-1 · 37 turns · 13m 38s · 354 in · 46.1K out · 2.4M cached

   submission1a8c4e78b6c5f106bd0a28944df7be44894af746cff8350921a109dce7e3d6d3

   devicec0fc4ea4f50e3380927cfa7df7d414d9a3689c513aca5f117e3c35ba351067e8

   started from5d3fbb0463752698899a21eab4d43fd16d0d60a8

   bundlenone

   changed · 0 filesnothing

   • lowA token gift received after a recent distribution shields another wallet's old rewards from expiry, contradicting the stated guaranteecontracts/src/PadToken.sol:311

     expiredRewardsOf() protects 'recent' rewards as (magnifiedDividendPerShare - magAt(now - 7d - 1)) x balanceOf[holder] (rounded up). The balance used is the holder's balance NOW, not the balance it held when the window's distributions happened. Tokens that a third party sends to an inactive holder AFTER a distribution are therefore counted as if they had earned that distribution for the holder, although the sender keeps those very rewards (transfers move only future rewards).

     The same per-token reward is counted once as the sender's real withdrawable and once more as the recipient's phantom 'recent', and the recipient's phantom recent is subtracted from what expires. The contract notice (PadToken.sol:20-21, README 'Activity') promises: 'Tokens someone else sends it don't count, so nobody can keep another wallet's rewards from expiring.'

     After audit b803125e finding 3 that holds for lastActive, but not for the balance term: a large enough gift keeps up to the last 7 days' total distributions of another wallet's old rewards from expiring, and recycle() sends the protocol less than the spec says (zero in the reproduction).

     Solvency is not affected (recent only ever lowers expired), and the gifter loses the tokens to the inactive wallet, so this is griefing of the protocol's recycle revenue / a false guarantee rather than theft; hence low.

     Fix options (design decision needed): (a) keep activeBalance[holder]: the holder's balance as of its latest activity, written on every lastActive update and on any balance change that happens while lastActive[holder] == block.timestamp (a router buy's tokens arrive after the hook's markActive in the same transaction), and compute recent with min(balanceOf[holder], activeBalance[holder]).

     Rewards earned on tokens gifted after the last activity then expire with the rest, which is what 'gifts don't count' says; the attached test passes with that fix; or (b) keep the current behaviour and reword the NatSpec/README to say a gift can shield at most the recipient's share of the last 7 days' distributions. Also add a regression test: the suite's gift tests only exercise gifts with no distribution inside the 7-day window, which is why they pass.

     whole finding

     State: v4 launch; bob buys 10 IMD, carol buys 50 IMD at T0 (bob, sole holder at flush time, earns 1.8 IMD: 0.3 waiting from his own buy + 1.5 from carol's).

     T0 + 6d: alice buys 200 IMD (6 IMD distributed over bob and carol); then carol transfers her whole balance to bob (not bob's activity: lastActive[bob] stays T0).

     T0 + 7d + 1s: expected expiredRewardsOf(bob) ~= 1.8 IMD (everything earned before the window; bob's real window earnings are ~1.43 IMD and stay protected).

     Actual: expiredRewardsOf(bob) == 0 and recycle(bob) sends 0 to feeRecipient, because recent = (mag - magCut) x (bobBal + carolBal) ~= 1.43 + 4.57 = 6.0 IMD > 1.8 IMD withdrawable; carol still has withdrawableDividendOf(carol) ~= 4.57 IMD.

     Run: forge test --match-path test/scratch/GiftShield.t.sol -vv (fails on this code with 'old rewards must expire despite the gift: 0 !~= 1799999999999999999').

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {PoolManager} from "v4-core/src/PoolManager.sol";
     import {PepesFamily} from "src/PepesFamily.sol";
     import {PepesFamilyRouter} from "src/PepesFamilyRouter.sol";
     import {PadToken} from "src/PadToken.sol";
     import {DeployLib} from "script/DeployLib.sol";
     
     contract ScratchIMD {
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         function mint(address to, uint256 amt) external {
             balanceOf[to] += amt;
         }
     
         function approve(address s, uint256 amt) external returns (bool) {
             allowance[msg.sender][s] = amt;
             return true;
         }
     
         function transfer(address to, uint256 amt) external returns (bool) {
             balanceOf[msg.sender] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     
         function transferFrom(address f, address to, uint256 amt) external returns (bool) {
             if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= amt;
             balanceOf[f] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     }
     
     /// A gift received after a distribution inflates the recipient's "recent" rewards and shields old rewards
     /// from expiry, although the NatSpec says tokens someone else sends can't keep another wallet's rewards
     /// from expiring.
     contract GiftShieldTest is Test {
         address constant FEE_RECIPIENT = 0x3c8A4d94B3219F6633F2cC94094f4765b30c691C;
         PoolManager pm;
         PepesFamily pad;
         PepesFamilyRouter router;
         ScratchIMD imd;
         address alice = makeAddr("alice");
         address bob = makeAddr("bob");
         address carol = makeAddr("carol");
     
         function setUp() public {
             vm.warp(1_800_000_000);
             pm = new PoolManager(address(this));
             imd = new ScratchIMD();
             bytes memory initCode = abi.encodePacked(
                 type(PepesFamily).creationCode,
                 abi.encode(
                     pm,
                     address(imd),
                     address(this),
                     FEE_RECIPIENT,
                     DeployLib.startTickForMarketCap(100e18),
                     PepesFamily.ImdEthPool(10_000, 100, address(0))
                 )
             );
             (bytes32 salt, address expected) = DeployLib.mineSalt(address(this), uint160(0x28CC), initCode, 0);
             address deployed;
             assembly {
                 deployed := create2(0, add(initCode, 0x20), mload(initCode), salt)
             }
             require(deployed == expected, "hook address");
             pad = PepesFamily(deployed);
             router = PepesFamilyRouter(payable(pad.router()));
             address[3] memory users = [alice, bob, carol];
             for (uint256 i; i < users.length; i++) {
                 imd.mint(users[i], 1_000_000e18);
                 vm.prank(users[i]);
                 imd.approve(address(router), type(uint256).max);
             }
         }
     
         function _buy(address who, PadToken t, uint256 amt) internal returns (uint256) {
             vm.prank(who);
             return router.buy(address(t), amt, 0, block.timestamp);
         }
     
         function test_giftAfterDistributionShieldsOldRewardsFromExpiry() public {
             vm.prank(alice);
             PadToken t = PadToken(payable(pad.launch("Test", "TST", "", address(imd))));
             _buy(bob, t, 10e18);
             _buy(carol, t, 50e18); // day 0: bob (sole holder) earns 0.3 + 1.5 IMD
             uint256 oldRewards = t.withdrawableDividendOf(bob);
             assertApproxEqAbs(oldRewards, 1.8e18, 10);
             uint256 lastBob = t.lastActive(bob);
     
             vm.warp(block.timestamp + 6 days);
             _buy(alice, t, 200e18); // day 6: 6 IMD spread over bob and carol
             uint256 bobRecentReal = t.withdrawableDividendOf(bob) - oldRewards;
     
             // Day 6, after the distribution: carol gifts bob her whole balance. Not bob's activity.
             uint256 carolBal = t.balanceOf(carol);
             vm.prank(carol);
             t.transfer(bob, carolBal);
             assertEq(t.lastActive(bob), lastBob, "a gift is not bob's activity");
             uint256 carolKeeps = t.withdrawableDividendOf(carol);
             assertGt(carolKeeps, 0, "carol keeps what she earned on those tokens");
     
             vm.warp(lastBob + 7 days + 1); // bob inactive for more than 7 days
             // Expected: everything bob earned before day 6 (1.8 IMD) has expired; only `bobRecentReal` is protected.
             // Actual: the gifted tokens are counted as if they had earned for bob during the window, so the
             // protocol receives nothing at recycle.
             uint256 expired = t.expiredRewardsOf(bob);
             emit log_named_uint("old rewards (should expire)", oldRewards);
             emit log_named_uint("bob's real recent rewards  ", bobRecentReal);
             emit log_named_uint("expiredRewardsOf(bob)      ", expired);
             assertApproxEqAbs(expired, oldRewards, 1e6, "old rewards must expire despite the gift");
             uint256 got = t.recycle(bob);
             assertEq(got, expired);
             assertApproxEqAbs(imd.balanceOf(FEE_RECIPIENT), oldRewards, 1e6);
         }
     }

     whole proof

   • infoAudit brief still describes feeRecipient and the test suite as in v3; v4's recycle path to feeRecipient is undocumented thereAUDIT.md:83

     The buyback removal was reflected in README.md, PadToken/PepesFamily NatSpec, Deploy.s.sol and the tests, but AUDIT.md (the document handed to reviewers) was not touched by any v4 commit.

     Its roles table says feeRecipient 'Receives protocol fees' and can do 'Anything else: nothing', while in v4 PadToken.recycle() also pays every token's expired holder rewards to pad.feeRecipient(), read at call time, and setFeeRecipient therefore also redirects that flow (README.md:184 says so, AUDIT.md does not).

     AUDIT.md section 5 (invariants) and section 9 (tests) do not mention expiry/recycle at all, and both AUDIT.md:218-219 and README.md:138-139 still advertise '34 unit + attack tests' / '+ 7 fork tests' (PepesFamily.t.sol alone has 53). Constructor and PadToken wiring are consistent (no buyback parameters remain; MockPepes/MockPepesRouter in test/Mocks.sol and the web buyback UI belong to the live $EARN subsystem, not leftovers).

     Suggested fix: add a v4 section to AUDIT.md covering recycle/expiry (actor: anyone; destination: feeRecipient only; the manual buyback is a trust assumption, as README.md:83 states) and refresh the test counts.

     whole finding

     Read AUDIT.md:83 ('feeRecipient | Receives protocol fees | Anything else') against contracts/src/PadToken.sol:325 (quote.transferOut(IPadFlush(pad).feeRecipient(), expired)): the brief omits a second value flow to the same role. Documentation only; no on-chain effect.

6. reviewed
   #281Audit judgeClaude5 findings · 2 low

   afterAudit math, Audit permissions, Audit economics, Audit flow

   Review complete. The findings are in .imd-findings.json at the repository root (5 findings: 2 low, 3 info). No source files were changed, and the scratch tests were removed.

   Answers to the four questions

   • Bounded and solvent: yes. A stateful fuzz over random buys, partial sells, gifts, third-party buys, warps, flushes, claims and recycles passed 2000 runs. Every recycle equalled expiredRewardsOf, never exceeded rewards distributed before the 7-day cutoff net of withdrawals, and the token stayed solvent.
   • Reading feeRecipient at recycle time: no defect. It can never be zero (constructor and setter revert), the getter cannot revert, and the call is reentrancy-guarded. The owner can redirect expired rewards, including to the token itself where they get re-distributed. That is a trust assumption the README records but AUDIT.md does not.
   • Buyback removal: code is consistent. Constructor arity, the deploy script, both fork tests and the 111 offline tests all match. Only documentation is stale.
   • Regressions: none in code. All earlier expiry and v3 flash-holder tests remain and pass. One residual of re-check finding 3 remains, below.

   Findings kept, after merging duplicates

   1. Low, gift shields old rewards. Four specialists reported the same mechanism. A gift received after a distribution inside the window inflates the holder's current balance in the "recent" estimate, so a large gift zeroes the recyclable amount despite the NatSpec promise. The specialist's proof fails on this code as stated and is attached. I verified the shield is temporary and found the specialist's suggested activeBalance fix is wrong: it expires rewards genuinely earned inside the window on gifted tokens, which my fuzz caught in 11 runs. The finding presents a documentation fix or per-receipt accounting as the two real options.
   2. Low, lazy expiry. A claim after 60 days of inactivity paid the full 0.6 IMD to the holder with nothing to feeRecipient. The protocol's share depends on an undocumented keeper.
   3. Info, AUDIT.md still describes v3. Role table, owner powers, invariant 4, scope and test count all contradict v4.
   4. Info, README deploy section stale. Wrong output file name, an unread ETH_START_MCAP option, stale test counts.
   5. Info, coverage gap. No ground-truth stateful fuzz, gift-in-window and 1 wei buy untested, plus the via-IR block.timestamp hazard after vm.warp that bit my own probe.

   Dropped nothing outright: every specialist finding reproduced, but seven reports collapsed into these five.

   ran onclaude · claude-fable-5-1 · 29 turns · 12m 51s · 546 in · 42.3K out · 2.2M cached

   submission95e8b3a67c51edc7dd38badd661e7c161adcaabac0f75db76656bcf446b9d003

   device8af9903f4ad1eed04241eb94aab079c2ee0461c3c185380ab6890ee4a4b4ebae

   started from5d3fbb0463752698899a21eab4d43fd16d0d60a8

   bundlenone

   changed · 0 filesnothing

   • lowA gift received after a distribution shields another wallet's old rewards from expiry, contradicting the stated 'nobody can keep another wallet's rewards from expiring' guaranteecontracts/src/PadToken.sol:311

     Merged from audit_economics 1fd9e673, audit_math 936fd392, audit_permissions a7dcd037 and case (a) of audit_flow 9e1b675b; all four reproduce. expiredRewardsOf() protects the 'recent' part as (magnifiedDividendPerShare - magAt(now - 7d - 1)) x balanceOf[holder], using the holder's balance NOW.

     Tokens a third party sends to an inactive wallet after a distribution inside the window are therefore counted as if they had earned that distribution for the recipient, although the sender keeps those rewards (transfers move only future rewards). Since b803125e a gift no longer resets lastActive, but the balance term still lets a large enough gift shrink, or zero, the amount recycle() can send to feeRecipient.

     The code comment at lines 307-309 acknowledges the over-estimate 'in the holder's favour', while the contract notice (line 21) and README 'Activity' promise an absolute guarantee that does not hold.

     Bounds verified: recycle() never moves more than expiredRewardsOf(), the token stays solvent, and the shield is temporary: once a full window has passed since the gift (no newer distributions), all of the old rewards expire (checked: at T0 + 13 days + 1 expiredRewardsOf(bob) equals bob's whole withdrawable).

     The gifter irrevocably parts with the tokens and the inactive wallet could have claimed anyway, so no profit path was found; the impact is a false documented guarantee and delayed/reduced recycle revenue.

     Fix is a design decision: (1) document the limitation in the PadToken notice and README ('a gift never resets the timer but tokens received without activity delay expiry of up to balance x per-share growth of the last 7 days'); or (2) change the estimate so rewards on gifted tokens count only from receipt.

     Caution on (2): the simplest variant, snapshotting activeBalance at each activity and using min(balanceOf, activeBalance) as proposed by audit_permissions, makes the attached proof and the 53 suite tests pass but breaks the other stated guarantee 'what it earned during those last 7 days never expires': under that patch my ground-truth fuzz (test/scratch/Probe.t.sol::testFuzz_recycleBoundedAndSolvent, run against a patched copy outside the repo) found recycle taking 5.518 IMD when only 0.560 IMD had been distributed before the cutoff, because rewards earned inside the window on tokens received as gifts were expired.

     A correct code fix needs per-receipt accounting (amount and magnifiedDividendPerShare at receipt for gifts since the last activity), which is a larger change. The attached proof pins option (2); if the requester chooses option (1) it should be dropped. Either way add a regression test: the suite's gift tests only exercise gifts with no distribution inside the window.

     whole finding

     Commit 5d3fbb0, Foundry, mock IMD, start mcap 100 IMD (test/scratch/GiftShield.t.sol, the audit_permissions proof, re-run here).

     T0: bob buys 10 IMD, carol buys 50 IMD; bob (sole holder at flush time) is owed 1799999999999999999 wei.

     T0 + 6d: alice buys 200 IMD (6 IMD distributed over bob and carol); bob's real window earnings are 1430462255459255159 wei.

     Then carol transfers her whole balance to bob; t.lastActive(bob) is unchanged (T0).

     T0 + 7d + 1s: expected per the NatSpec, expiredRewardsOf(bob) ~= 1.8 IMD (everything earned before the window).

     Actual: expiredRewardsOf(bob) == 0 and recycle(bob) sends 0 to feeRecipient, because recent = (mag - magCut) x (bobBal + carolBal) ~= 6 IMD > 1.8 IMD withdrawable; carol still has her 4.57 IMD withdrawable. forge test --match-path test/scratch/GiftShield.t.sol -vv fails with 'old rewards must expire despite the gift: 0 != 1799999999999999999'.

     Same shape with carol gifting half her bag (audit_economics: expired 599999999999999999 -> 0) and with a 45% gift (audit_math: 32.999 IMD -> 18.956 IMD).

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {PoolManager} from "v4-core/src/PoolManager.sol";
     import {PepesFamily} from "src/PepesFamily.sol";
     import {PepesFamilyRouter} from "src/PepesFamilyRouter.sol";
     import {PadToken} from "src/PadToken.sol";
     import {DeployLib} from "script/DeployLib.sol";
     
     contract ScratchIMD {
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         function mint(address to, uint256 amt) external {
             balanceOf[to] += amt;
         }
     
         function approve(address s, uint256 amt) external returns (bool) {
             allowance[msg.sender][s] = amt;
             return true;
         }
     
         function transfer(address to, uint256 amt) external returns (bool) {
             balanceOf[msg.sender] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     
         function transferFrom(address f, address to, uint256 amt) external returns (bool) {
             if (allowance[f][msg.sender] != type(uint256).max) allowance[f][msg.sender] -= amt;
             balanceOf[f] -= amt;
             balanceOf[to] += amt;
             return true;
         }
     }
     
     /// A gift received after a distribution inflates the recipient's "recent" rewards and shields old rewards
     /// from expiry, although the NatSpec says tokens someone else sends can't keep another wallet's rewards
     /// from expiring.
     contract GiftShieldTest is Test {
         address constant FEE_RECIPIENT = 0x3c8A4d94B3219F6633F2cC94094f4765b30c691C;
         PoolManager pm;
         PepesFamily pad;
         PepesFamilyRouter router;
         ScratchIMD imd;
         address alice = makeAddr("alice");
         address bob = makeAddr("bob");
         address carol = makeAddr("carol");
     
         function setUp() public {
             vm.warp(1_800_000_000);
             pm = new PoolManager(address(this));
             imd = new ScratchIMD();
             bytes memory initCode = abi.encodePacked(
                 type(PepesFamily).creationCode,
                 abi.encode(
                     pm,
                     address(imd),
                     address(this),
                     FEE_RECIPIENT,
                     DeployLib.startTickForMarketCap(100e18),
                     PepesFamily.ImdEthPool(10_000, 100, address(0))
                 )
             );
             (bytes32 salt, address expected) = DeployLib.mineSalt(address(this), uint160(0x28CC), initCode, 0);
             address deployed;
             assembly {
                 deployed := create2(0, add(initCode, 0x20), mload(initCode), salt)
             }
             require(deployed == expected, "hook address");
             pad = PepesFamily(deployed);
             router = PepesFamilyRouter(payable(pad.router()));
             address[3] memory users = [alice, bob, carol];
             for (uint256 i; i < users.length; i++) {
                 imd.mint(users[i], 1_000_000e18);
                 vm.prank(users[i]);
                 imd.approve(address(router), type(uint256).max);
             }
         }
     
         function _buy(address who, PadToken t, uint256 amt) internal returns (uint256) {
             vm.prank(who);
             return router.buy(address(t), amt, 0, block.timestamp);
         }
     
         function test_giftAfterDistributionShieldsOldRewardsFromExpiry() public {
             vm.prank(alice);
             PadToken t = PadToken(payable(pad.launch("Test", "TST", "", address(imd))));
             _buy(bob, t, 10e18);
             _buy(carol, t, 50e18); // day 0: bob (sole holder) earns 0.3 + 1.5 IMD
             uint256 oldRewards = t.withdrawableDividendOf(bob);
             assertApproxEqAbs(oldRewards, 1.8e18, 10);
             uint256 lastBob = t.lastActive(bob);
     
             vm.warp(block.timestamp + 6 days);
             _buy(alice, t, 200e18); // day 6: 6 IMD spread over bob and carol
             uint256 bobRecentReal = t.withdrawableDividendOf(bob) - oldRewards;
     
             // Day 6, after the distribution: carol gifts bob her whole balance. Not bob's activity.
             uint256 carolBal = t.balanceOf(carol);
             vm.prank(carol);
             t.transfer(bob, carolBal);
             assertEq(t.lastActive(bob), lastBob, "a gift is not bob's activity");
             uint256 carolKeeps = t.withdrawableDividendOf(carol);
             assertGt(carolKeeps, 0, "carol keeps what she earned on those tokens");
     
             vm.warp(lastBob + 7 days + 1); // bob inactive for more than 7 days
             // Expected: everything bob earned before day 6 (1.8 IMD) has expired; only `bobRecentReal` is protected.
             // Actual: the gifted tokens are counted as if they had earned for bob during the window, so the
             // protocol receives nothing at recycle.
             uint256 expired = t.expiredRewardsOf(bob);
             emit log_named_uint("old rewards (should expire)", oldRewards);
             emit log_named_uint("bob's real recent rewards  ", bobRecentReal);
             emit log_named_uint("expiredRewardsOf(bob)      ", expired);
             assertApproxEqAbs(expired, oldRewards, 1e6, "old rewards must expire despite the gift");
             uint256 got = t.recycle(bob);
             assertEq(got, expired);
             assertApproxEqAbs(imd.balanceOf(FEE_RECIPIENT), oldRewards, 1e6);
         }
     }

     whole proof

   • lowExpiry is lazy: claim() pays rewards that have already expired unless someone called recycle() first, so the protocol's share depends on an undocumented keepercontracts/src/PadToken.sol:286

     From audit_economics 368ce461; reproduced. The contract notice says 'Rewards of a wallet inactive for more than 7 days expire' and README says expired rewards go to the protocol address, but expiry only takes effect when an unprivileged caller runs recycle()/recycleMany(). claim() resets lastActive and then pays the full withdrawableDividendOf(), expired part included; nothing in the contracts or tests asserts what claim() does on a wallet whose expiredRewardsOf() > 0.

     Consequences: (1) the recyclable revenue exists only if the team runs a recycler bot, which is not stated anywhere in README, AUDIT.md or the NatSpec (the sibling $EARN web copy does say 'You can still claim it until someone recycles it', so lazy expiry looks intended); (2) a holder who notices can always claim first, deterministically on Robinhood Chain's sequencer. No user funds are at risk, so low.

     Fix: if lazy expiry is the design, document it in the PadToken notice and README together with the keeper assumption, and add a test for claim() on an expired wallet; if strict expiry is wanted, compute expiredRewardsOf(msg.sender) in claim() before the lastActive reset and route that part to feeRecipient with the same accounting as recycle(), which keeps the bound and solvency properties.

     whole finding

     test/scratch/Probe.t.sol::test_claimIgnoresExpiry (passes on this code, showing the behaviour).

     Launch; bob buys 10 IMD, carol buys 10 IMD (bob owed 599999999999999999 wei); warp +60 days with no activity; expiredRewardsOf(bob) == 599999999999999999 (all of it). bob calls claim().

     Expected under the stated rule: at most the recent part (0) is paid and 0.6 IMD goes to feeRecipient.

     Actual: claim() returns 599999999999999999 to bob, imd.balanceOf(feeRecipient) stays 0 and totalRecycled stays 0.

   • infoAUDIT.md still describes v3: feeRecipient's role omits expired holder rewards, owner powers and invariant 4 do not mention recycle, scope and test count are staleAUDIT.md:83

     Merged from audit_math da18616d, audit_flow b3538cf4, audit_permissions 3d2b9b67 and the AUDIT.md part of audit_economics 26910b3a; all verified by reading the file against the code. AUDIT.md is the brief handed to reviewers, and no v4 commit touched it.

     At 5d3fbb0 it is contradicted by the code in four places: (1) line 83 says feeRecipient receives protocol fees and 'Anything else' is impossible, while PadToken.recycle (contracts/src/PadToken.sol:325) now pays every v4 token's expired holder rewards to IPadFlush(pad).feeRecipient(), read at call time; (2) line 82 says the owner cannot touch holder rewards, but setFeeRecipient now chooses where expired holder rewards go, including (owner trust assumption, verified in test/scratch/Probe.t.sol::test_ownerCanRedirectExpiredRewardsToToken) to the token itself, where the next distribute() spreads them to current holders instead of the manual buyback; README 'Owner powers' (line 184) was updated, AUDIT.md was not; (3) invariant 4 'Reward solvency' (line 138) lists claims as the only outflow and does not mention totalRecycled, so it cannot be checked as written against v4 (the correct statement is accountedBalance = distributed - claimed - recycled <= quote.balanceOf(token), with recycle bounded by expiredRewardsOf); (4) line 18 says 'In scope: v3' and line 218 says '34 unit + attack tests' while forge test runs 111 (53 in PepesFamily.t.sol alone), and sections 5 and 9 have no entry for expiry/recycle/activity.

     Removing PepesBuyback left no code inconsistency: constructor arity, Deploy.s.sol, both fork tests and the unit suite match the new wiring (111 tests pass offline), no reference to PepesBuyback or poke remains in the launchpad sources, tests or script, and MockPepes/MockPepesRouter in test/Mocks.sol belong to the live $EARN tests.

     Fix: add a v4 section to AUDIT.md (actor: anyone; destination: feeRecipient only, read at call time; manual buyback as a trust assumption as README line 83 states; owner can redirect it with setFeeRecipient), extend the owner and feeRecipient rows and invariant 4, and refresh scope and test counts.

     whole finding

     Read AUDIT.md line 83 ('feeRecipient | Receives protocol fees | Anything else'), line 82 (owner cannot touch holder rewards), line 138 (invariant 4) and line 218 ('34 unit + attack tests').

     Then: launch a v4 token, bob buys 10 IMD, carol buys 10 IMD, warp +8 days, anyone calls t.recycle(bob): IMD owed to a holder leaves the token to pad.feeRecipient(); after the owner calls pad.setFeeRecipient(treasury) a second token's recycle pays treasury instead (existing test test_expiry_goesToCurrentFeeRecipient: e1 to FEE_RECIPIENT, e2 to treasury).

     With setFeeRecipient(address(t)) recycle(bob) returns the owed amount, imd.balanceOf(t) is unchanged, accountedBalance drops by it and t.distribute() returns that amount to current holders. forge test reports 111 passed, not 34.

     whole reproduction

   • infoREADME build/deploy section describes the pre-v4 deployment: wrong output file name, an ETH_START_MCAP option the script never reads, stale test countsREADME.md:153

     From the README part of audit_economics 26910b3a; verified against contracts/script/Deploy.s.sol.

     (a) README line 153 says the script writes deployments/robinhood.json and line 178 tells the website operator to copy pad/router/block from that file, but Deploy.s.sol line 68 writes deployments/robinhood-v4.json (robinhood.json in the tree is an older deployment record); (b) README line 161 lists ETH_START_MCAP (default 1.5e18) as a deploy option, but v4 is IMD-only and Deploy.s.sol reads only IMD_START_MCAP, OWNER and SALT_START (SALT_START is not listed); (c) README lines 138-139 say '34 unit + attack tests' and '+ 7 fork tests' while PepesFamily.t.sol alone has 53 tests and forge test runs 111 offline; (d) README line 188 says the owner cannot add quote assets 'other than ETH and IMD' while v4 launches are IMD-only.

     None of this affects on-chain behaviour; it can mislead whoever deploys v4 or wires the website to the deployment file.

     Fix: update the Deploy and Test sections for the v4 script (robinhood-v4.json, IMD_START_MCAP/OWNER/SALT_START, current counts).

     whole finding

     grep -n ETH_START_MCAP contracts/script returns nothing (Deploy.s.sol lines 27-28 read only IMD_START_MCAP and OWNER, line 44 SALT_START); Deploy.s.sol line 68 is vm.writeJson(out, "./deployments/robinhood-v4.json").

     Expected per README: the ETH start cap is applied and deployments/robinhood.json is (re)written.

     Actual: the variable is never read and a different file is written. cd contracts && forge test prints '111 tests passed', not 34.

   • infoExpiry test coverage gap: no stateful ground-truth check that recycle only takes rewards older than 7 days; gift inside the window and zero-fee 1 wei buy untestedcontracts/test/PepesFamily.t.sol:853

     Merged from audit_math cdc5ec75 and audit_flow 9e1b675b; verified by reading the suite and by writing the missing checks as scratch tests (not kept).

     The central v4 guarantee, 'recycle can only ever move rewards that have expired', is pinned only by fixed sequences: testFuzz_expirySolvent runs buy(bob), warp, buy(carol), warp, buy(alice), one recycle(bob), two claims; it never recycles twice, never claims before a recycle, never sells, never gifts, never changes a holder's balance between the buys and the recycle, and never flushes third-party-router fees late.

     The hand-written cases (day 0/5/8/10/13) use a 1e6 wei tolerance. A regression that takes a few wei of recent rewards, or a change like the activeBalance patch discussed in the gift finding (which expires rewards earned inside the window on gifted tokens), would pass the suite unchanged: I confirmed the 53 tests still pass against such a patched copy while my ground-truth fuzz fails on it.

     Two behaviours the code relies on are also unexercised: (a) the 'recent over-estimate in the holder's favour' for a gift received during the window (PadToken.sol:307-309), and (b) an exact-in buy of 1 wei IMD through a third-party router, whose fee is 0 (1 * 400 / 10000; _chargeFee returns early) but which still calls markActive(tx.origin) in afterSwap, so the 'a buy of any size counts' rule is not pinned. Both behave as documented on the current code.

     Separately, 31 lines in this file compute vm.warp(block.timestamp + ...) or read block.timestamp after a warp; forge lint flags this under via_ir because the compiler may reuse an earlier block.timestamp read (my own probe captured a wrong t0 this way until switched to vm.getBlockTimestamp()). The suite currently passes, but a timing test can silently check the wrong instant after an unrelated edit.

     Suggested additions: a stateful fuzz that records, per holder and distribution, balance x delta(magnifiedDividendPerShare) with its timestamp and asserts on every recycle that expired <= sum of rewards at or before now - 7d - 1 net of withdrawals (+2 wei), withdrawable after == owed - expired, and solvency; a gift-in-window test asserting expired <= r1, withdrawable == owed - expired and solvency; a 1 wei external buy test asserting fee == 0 and lastActive updated; and vm.getBlockTimestamp() in the timing tests.

     whole finding

     Current suite: forge test --match-test testFuzz_expirySolvent only runs the fixed 3-buy/1-recycle sequence above; grep shows no test that transfers tokens to a holder between a distribution and a recycle, none with amountSpecified = -1, and no per-distribution ground truth. Scratch evidence on 5d3fbb0: test/scratch/Probe.t.sol::testFuzz_recycleBoundedAndSolvent (random router buys, partial sells, gifts, external buys with tx.origin set, warps, flushes, claims, recycles over up to 40 actions; asserts recycle == expiredRewardsOf, recycle <= rewards distributed at or before now-7d-1 net of withdrawals + 2 wei, withdrawable after == owed - expired, imd.balanceOf(token) >= accountedBalance, sum of withdrawable <= accountedBalance) passes 2000 runs on the current code and fails within 11 runs on the activeBalance-patched copy ('only rewards older than 7 days: 5518562966114463113 > 560066326748174097'). test_oneWeiExternalBuyMarksActiveWithZeroFee: quote as currency0, bob (vm.prank(bob, bob)) swaps amountSpecified = -1 via PoolSwapTest 6 days after his buy: pendingProtocolFees and pendingHolderFees unchanged, lastActive(bob) == block.timestamp, expiredRewardsOf(bob) == 0 six days later.

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

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,135,359 · transaction#788#57#281#720#286