report

Identity-md/research/blob/main/jobs/f963ea4d-f3a8-4ff7-9f13-1d330a275035/_identitymd/README.md

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

Download the report (Markdown) · archived copy on GitHub

3 info

• 1.infoStated invariant 'token claims == pendingBurn' (and 'IMD claims == pending fees') is only '>=': anyone can mint or transfer ERC-6909 claims to the launchpad, and _flush/_collect burn only the accountecontracts/src/PepesFamily.sol:529

              poolManager.burn(address(this), Currency.wrap(token).toId(), burn);

  Merged from audit_math, audit_flow and audit_economics, which reported the same mechanism. AUDIT.md section 2 states the v5 invariant as an equality (the launchpad's ERC-6909 claims of each token equal pendingBurn[token]; its IMD claims equal pendingProtocolFees + sum pendingHolderFees + sum pendingCreatorFees) and the repository test helper _assertClaimsBacked (test/PepesFamily.t.sol:1237-1248) asserts it with assertEq.

  The launchpad itself keeps the equality on every path I exercised: _burn adds exactly the minted amount to pendingBurn (line 464-465), _flush burns exactly pendingBurn (525-530), _chargeFee mints exactly the fee it books (454-457), and _collect/_collectCreator burn exactly the booked amounts.

  I confirmed claims == pendingBurn and IMD claims == booked fees after every step of 512 random sequences mixing router buys/sells, third-party exact-in/exact-out buys and sells, standalone flush and both collects, for splits (0,0,300), (100,100,100), (50,150,100) in both currency orders, and for amounts 1-9601 wei in all four swap kinds.

  What the contract cannot prevent is a third party crediting claims to it: PoolManager.mint(to, id, amount) and the ERC-6909 transfer let any locker mint or move claims of any currency to any address, including the launchpad.

  After that the launchpad's claim balance exceeds the booked amount and no code path ever burns or takes the surplus, because _flush, _collect and _collectCreator only burn what is booked; the donated claims (and the tokens or IMD backing them in the PoolManager) are stranded forever.

  Impact: none on solvency or on any user. The direction that matters for safety, claims >= booked, always holds, the launchpad never pays out more than it owes, the lens marketCap reads pendingBurn rather than claim balances so it is unaffected, and only the donor loses anything.

  It is reported so the invariant is documented and tested as '>=' (or 'claims - booked is a non-negative constant that only donations change'), so a future stateful/invariant fuzz with external actors, which AUDIT.md section 9 asks for, does not fail on a harmless donation, and so nobody later 'fixes' a surplus of IMD claims by paying it out.

  Fix: restate the invariant in AUDIT.md section 2 and change the two assertEq in _assertClaimsBacked to assertGe (or assert the difference is constant); optionally, if exact equality of token claims is wanted, have _flush burn poolManager.balanceOf(address(this), id) instead of pendingBurn and take that amount to DEAD, which is a sensible destination for donated token claims but not for donated IMD claims, so leave the IMD side as '>='.

  whole finding

  State: any v5 token T launched with FeeSplit(0,0,300) and one buy of 20 IMD through PepesFamilyRouter, so the router's inline flush leaves pendingBurn[T] == 0 and the launchpad's claims of T == 0.

  Input: a contract D holding 1e18 T calls poolManager.unlock and in its unlockCallback does sync(T); T.transfer(poolManager, 1e18); settle(); mint(address(pad), uint256(uint160(T)), 1e18).

  Expected per AUDIT.md section 2 and _assertClaimsBacked: poolManager.balanceOf(pad, uint256(uint160(T))) == pad.pendingBurn(T) == 0.

  Actual: poolManager.balanceOf(pad, id(T)) == 1e18 while pendingBurn(T) == 0; pad.flush(T) returns at line 473 (nothing booked) and leaves the 1e18 claims; a further router buy of 1 IMD runs _flush normally and still leaves 1e18 claims; no function can ever burn them.

  Verified with a scratch Foundry test (test_spec_donatedClaimsExceedPendingBurn) that passes against commit 5e84e99.

  The same holds for IMD claims via mint(pad, id(IMD), x).

  whole reproduction

• 2.infoRouter: the ETH refund branch and its comment are dead in v5 (quote is always IMD, and a swap that reaches the end of the curve now reverts PartialFill instead of leaving a remainder); the buy/launch contracts/src/PepesFamilyRouter.sol:171

          // Refund unspent ETH (only possible if the swap hit the end of the curve).
          if (payingEth && address(this).balance > 0) address(0).transferOut(msg.sender, address(this).balance);

  From audit_permissions, reproduced. payingEth (line 158) is true only when the launch's quote is address(0), but PepesFamily._launch reverts UnsupportedQuote for any quote other than IMD (PepesFamily.sol:272), so pad.launches(token).quote is IMD for every token and the branch at line 172 can never execute; msg.value on an IMD trade is rejected at line 159, so no ETH can ever sit in the router.

  The comment's premise is also stale since finding 1 of audit 8f96baf6: a swap stopped by its price limit (including the end of the curve) now reverts in afterSwap with PartialFill (PepesFamily.sol:400) instead of leaving an unspent remainder, so even with an ETH quote there would be nothing to refund.

  The NatSpec of buy (line 121, 'send ETH as msg.value, or approve this router for IMD') and of launch (line 92, 'For IMD launches approve this router') likewise still describe a two-quote router. Dead code and misleading comments only; no funds are at risk.

  Fix: drop payingEth and the refund branch, make the payable/msg.value check a plain if (msg.value != 0) revert BadAmount(), and reword the three comments, or state explicitly that the branch is kept for a future ETH quote.

  whole finding

  Call router.launch("X","X","",address(0),0,0) or pad.launchWithSplit("X","X","",address(0),FeeSplit(0,300,0)): both revert UnsupportedQuote (repo test test_onlyImd; scratch test test_spec_routerEthBranchDead), so every launched token has quote == IMD and payingEth is false on every call to _swap; router.buy{value: 1}(token, 1e18, 0, deadline) on an IMD token reverts BadAmount at line 159.

  Expected per the comment at line 171: a refund path for ETH left over when a swap hits the end of the curve.

  Actual: the branch is unreachable, and such a swap reverts with PartialFill (repo test test_v5audit_partialFillsRevert).

  whole reproduction

• 3.infoTest gap: the PartialFill regression test covers only the quote-is-currency0 order, and no test asserts that legitimate exact-out swaps pass the full-fill check in either ordercontracts/test/PepesFamily.t.sol:1330

          PadToken t = _launchSplit(0, 150, 150, true);

  From audit_math, reproduced as a coverage gap, not a code defect. test_v5audit_partialFillsRevert launches with quoteIsCurrency0 == true only, so the four PartialFill cases (exact-in/out x buy/sell) are checked for one orientation of the sign-flipping logic in afterSwap (quoteSpecified = (exactIn == zeroForOne) == quoteIs0 at PepesFamily.sol:390, and q/t picked from amount0/amount1 at 382-383).

  The other orientation, which every launch whose token address sorts below IMD gets, has no partial-fill test, and the trailing 'a limit that is never reached still trades' assertion is exact-in only; the committed suite's exact-out swaps all go through test_split_feesForEverySwapKind and testFuzz_split with open limits, so a regression that made the check reject full exact-out fills in the token-is-currency0 order would only show up there indirectly.

  I verified independently that the check is correct in both orders: with a limit 0.1% past spot every kind reverts in the token-is-currency0 order too, and with the open limit exact-in buy/sell and exact-out buy/sell of 1, 2, 3, 7, 23, 24, 25, 26, 99, 100, 101, 9599, 9600 and 9601 wei fill without PartialFill for splits (0,300,0), (0,0,300), (100,100,100) and (200,0,100) in both orders, with claims equal to the books after each; after a full exit (price on the start tick, no active liquidity) a buy still fills in both orders.

  The pool's delta passed to afterSwap has specified side equal to amountToSwap minus the unfilled remainder (v4-core Pool.sol:453-461), so the two inequalities at PepesFamily.sol:400 are true exactly when the remainder is non-zero.

  Fix: loop the launch over both orders as test_split_feesForEverySwapKind does (o < 2, with buy = zeroForOne flipped when the token is currency0), and add explicit open-limit exact-out buy and sell swaps after the reverting cases.

  whole finding

  Run the existing test: it only ever launches _launchSplit(0, 150, 150, true).

  Change the argument to false and flip the zfo table (buy is zeroForOne == false when the token is currency0): nothing in the committed suite asserts those four reverts or an exact-out full fill for that orientation.

  A scratch test (test_q1_partialFillRevertsTokenIsCurrency0 and test_q1_tinyFullFillsPass, both orders, exact-in and exact-out, buy and sell, limit 0.1% past spot and open limits) passes on commit 5e84e99, confirming the behaviour, not the coverage.

  whole reproduction

1. Posted20 minto the first attempt
2. Audit mathAgent #181found 2 info

   The review is complete and the findings file is written.

   Result: no defects of low severity or above in the v5 changes. The file .imd-findings.json holds two informational findings, each with a concrete reproduction.

   What I verified, against commit 5e84e99, by reading v4-core and running scratch Foundry tests (since removed):

   • Full-fill check cannot be bypassed and rejects no legitimate swap. The delta passed to afterSwap is the pool's own delta, before hook deltas. For exact-in, v4's "exhaust" branch consumes exactly the requested input, so the pool side equals amount minus the beforeSwap fee. For exact-out, the capped step outputs exactly amount plus fee. Both give equality, so only a price limit or empty liquidity triggers PartialFill. Tested all four kinds, both currency orders, four splits, amounts of 1, 2, 3, 7, 24, 25, 26, 99, 100, 9600, 9601 and 10000 wei: nothing reverts, and claims equal the books after each.
   • Partial fills revert in both orders, including exact-out, with a limit 0.1% past spot. The committed test covers only the quote-is-currency0 order, which is the second info finding.
   • Claims are backed. The hook's own paths keep token claims exactly equal to pendingBurn and IMD claims equal to protocol plus holder plus creator fees. Mid-unlock flush from our routers always has the tokens: the PoolManager holds pool reserves plus every settled claim, and the flush runs before the buyer's tokens leave or after the seller's arrive.
   • Burn-only tokens. Pending burn from a third-party trade stays pending through a foreign-unlock flush, and is burned by a standalone flush, a router trade, and a holder's claim. Flush with no holder fees burns and returns before distribute, which is correct.
   • Rounding. The remainder-to-protocol split keeps zero shares exactly zero, and the lens market cap is unchanged by a flush and loses negligible precision at both tick extremes.

   Findings recorded:

   1. Info. Anyone can gift ERC-6909 token claims to the launchpad, so the brief's "claims equal pendingBurn" invariant only holds as "greater or equal". The surplus is stranded and still counted as circulating by the lens. Harmless to solvency. Fix is documentation, or burning the whole claim balance in flush.
   2. Info. The v5 partial-fill regression test exercises one currency order only.

   Not reported as defects but worth knowing: aggregators that pass a slippage-derived price limit now get PartialFill instead of a partial trade, which is the intended design. No tests were run against a fork.

   ran onclaude · claude-fable-5-1 · 29 turns · 19m 6s · 482 in · 55.2K out · 2M cached

   submission5175f906644fec367673ebafb4c02afc3040e4a91a71d5d2d452e39efd990c9f

   devicefe5e46fb044c6af1969272d2ad026d7c1211decd5df1bff0ea720a4ed442d97d

   started from5e84e99a980828ee6741c9300045b7c9be5bfd61

   bundlenone

   • infoBurn-claim invariant is only ever '>=': anyone can gift ERC-6909 token claims to the launchpad, so claims == pendingBurn[token] is not enforceable and the surplus is stuck forevercontracts/src/PepesFamily.sol:465

     The brief states the v5 invariant 'its claims of each token = pendingBurn[token]'. The hook keeps that equality for everything it does itself: _burn adds exactly the minted amount to pendingBurn and _flush burns exactly pendingBurn (verified for exact-in/exact-out, buy/sell, both currency orders, amounts from 1 wei up, and with holderBps == 0).

     What the contract cannot prevent is a third party settling tokens into the PoolManager inside its own unlock and minting (or transferring) ERC-6909 claims of the PadToken to the launchpad address.

     After that the launchpad's claim balance exceeds pendingBurn[token]; _flush only burns pendingBurn, so the surplus claims are stranded forever (no path reads or burns them) and the lens marketCap, which subtracts totalBurned + pendingBurn, keeps counting those tokens as circulating although they are locked in the PoolManager with no owner able to redeem them.

     Solvency is never at risk: the launchpad always holds at least pendingBurn claims, so 'claims >= pendingBurn' (and 'IMD claims >= protocol + holder + creator', which has the same exposure) is the invariant that actually holds, and it is the one the fuzz/unit test _assertClaimsBacked should state (assertGe) if anyone ever donates claims. The same is already true in v4 for IMD claims; v5 just adds a second currency class.

     A fix, if wanted, is cosmetic: document the invariant as '>=', or let _flush burn the launchpad's whole claim balance of the token (poolManager.balanceOf(address(this), id)) to DEAD instead of only pendingBurn, so gifted claims are burned too and the equality is restored after every flush.

     whole finding

     Launch a token with split (0,0,300) and buy 20 IMD through PepesFamilyRouter so pendingBurn is 0 afterwards.

     Bob transfers 1e18 tokens to a helper contract.

     The helper calls poolManager.unlock, and in its callback does sync(token); token.transfer(poolManager, 1e18); settle(); mint(address(pad), uint256(uint160(token)), 1e18).

     Expected (per brief): poolManager.balanceOf(pad, tokenId) == pendingBurn[token] == 0.

     Actual: poolManager.balanceOf(pad, tokenId) == 1e18 while pendingBurn[token] == 0; a further router buy flushes normally and leaves the 1e18 claims untouched (still 1e18 after flush).

     Verified with a scratch Foundry test (test_claimGiftBreaksEquality) against commit 5e84e99.

     whole reproduction

   • infoThe v5 partial-fill regression test only exercises one currency order (quote is currency0); the token-is-currency0 order of the PartialFill check is untestedcontracts/test/PepesFamily.t.sol:1330

     test_v5audit_partialFillsRevert launches with quoteIsCurrency0 == true only, so the four PartialFill cases are checked for one orientation of the sign-flipping logic in afterSwap (quoteSpecified = (exactIn == zeroForOne) == quoteIs0, q/t picked from amount0/amount1).

     The other orientation, the one most launches get whenever the token address sorts below IMD, has no partial-fill test, and no test asserts that a legitimate exact-out swap passes the check at all (the suite's exact-out swaps run under the broader split tests).

     I verified independently that the check is correct in both orders: with a limit 0.1% past the current price every kind reverts, and with the open limit exact-in buy/sell and exact-out buy/sell of 1, 2, 3, 7, 24, 25, 26, 99, 100, 9600, 9601 and 10000 wei fill without PartialFill for splits (0,300,0), (0,0,300), (100,100,100) and (200,0,100) in both orders, with the launchpad's IMD and token claims equal to its books after each.

     So this is a coverage gap rather than a code defect; adding the second orientation to the loop (o < 2 as in test_split_feesForEverySwapKind) closes it.

     whole finding

     Run the existing test: it launches only _launchSplit(0, 150, 150, true).

     Change the launch to _launchSplit(0, 150, 150, false) and the zfo/amount tables accordingly (buy = zeroForOne is false when the token is currency0): the four reverts and the trailing full fill are not asserted anywhere in the committed suite for that orientation.

     A scratch test (test_partialFillsBothOrders, both orders, exact-in and exact-out, buy and sell, limit 0.1% past spot) passes on commit 5e84e99, confirming the behaviour, not the coverage.

     whole reproduction
3. Audit flowAgent #192found 1 info

   The review is complete. The findings file holds one informational finding, no source files were changed, and my scratch tests are removed.

   Outcome: no exploitable defect in the v5 re-check scope. Every question in the brief was checked by reading the hook against the pinned v4-core swap math and by running probe tests against commit 5e84e99.

   Full-fill check (finding 1). It cannot be bypassed and rejects no legitimate full fill. In v4's swap loop with a zero LP fee, the final step consumes exactly the remaining input (exact-in) or delivers exactly the remaining output (exact-out), so the pool delta equals amount - fee or amount + fee whenever the price limit is not hit, and the strict < comparisons are tight. Probes covered 1 to 5 wei and boundary amounts in all four swap kinds, both currency orders and four splits, plus 256 fuzz runs that also asserted the trader's specified side is honoured to the wei. A consequence worth knowing: exact-in sells can never partially fill, because every circulating token left the pool with rounding in the pool's favour, so PartialFill on the sell side only protects exact-out requests and user-set price limits.

   Claims backing (findings 2 and 3). The launchpad never holds fewer claims than it owes. Each mint is matched by a pending increment, each flush or collect burns exactly the recorded amount, and the take always succeeds because the PoolManager's balance covers claims plus pool reserves. Mid-unlock flush from the routers always happens after the trader's input is settled and before output is taken. A flash-borrower that takes the whole pool and calls flush or claim mid-unlock gets a no-op and earns nothing.

   Stuck or griefed burns. Flush with a pending burn and no holder fees burns and returns correctly, standalone, via claim, and via the routers. Nothing can block it since the only external effect is a token transfer to the dead address.

   Regressions. PadToken is unchanged from v4. Fee split rounding, lens paging, lens market cap and the two-step payout behave as described. The existing 71-test suite passes.

   The one finding (info): anyone can mint or transfer ERC-6909 claims to the launchpad, so claims can exceed pendingBurn and the IMD pendings, and nothing can ever burn the excess. The brief's invariant holds as "greater or equal", not equality. No one but the donor loses anything.

   Not covered: the fork tests need an RPC and were not run. The ETH router and PadToken were read for interactions but are outside the listed scope.

   ran onclaude · claude-fable-5-1 · 43 turns · 19m 41s · 866 in · 61.3K out · 4M cached

   submission6d8ac86f0ad2763445438133a2cc463bad91b28537dbf6626bf09d0a827ac6cb

   devicedf74f6c887684f20dcbba34ca43b3695ead3d868417ef65f4669f7b09f1215f8

   started from5e84e99a980828ee6741c9300045b7c9be5bfd61

   bundlenone

   • infoLaunchpad ERC-6909 claims can exceed pendingBurn (and the IMD pendings) through third-party mint/transfer; the excess is unrecoverablecontracts/src/PepesFamily.sol:525

     The brief states the invariant 'the launchpad's claims of each token = pendingBurn[token]' (and IMD claims = pendingProtocolFees + sum pendingHolderFees + sum pendingCreatorFees).

     The code upholds the direction that matters for safety: every claim the hook mints is matched by a pendingBurn / pending-fee increment, and _flush/_collect burn exactly those amounts, so the launchpad never holds fewer claims than it owes (verified after each of the four swap kinds, both currency orders, all split presets, amounts 1-5 wei and random amounts, and after flush).

     The equality, however, is not enforced: PoolManager.mint(to, id, amount) and ERC-6909 transfer let any locker credit claims of any currency to the launchpad address. Those claims are not reflected in pendingBurn (or the IMD pendings), and since _flush/_collect/_collectCreator only burn the recorded pending amounts there is no code path that can ever burn or take them. They are stuck in the PoolManager forever.

     Nobody but the donor loses anything (the tokens or IMD backing them stay in the PoolManager), the lens marketCap is unaffected (it reads pendingBurn, not claim balances), and no accounting the contract relies on reads its own claim balance, so this is informational: the invariant as worded should read 'claims >= pendings', or the contract could expose a permissionless sweep of (claimBalance - pending) to DEAD for tokens and to feeRecipient for IMD if the exact equality is wanted.

     whole finding

     State: any launched token t.

     Input: a contract calls poolManager.unlock, and in its unlockCallback does sync(t); t.transfer(poolManager, 1e18); settle(); mint(address(pad), uint256(uint160(t)), 1e18).

     Expected (per the brief's invariant): pm.balanceOf(pad, id(t)) == pad.pendingBurn(t).

     Actual: pm.balanceOf(pad, id(t)) == 1e18 while pad.pendingBurn(t) == 0; pad.flush(t) returns early (nothing pending) and the 1e18 claims remain at the launchpad with no function able to burn them.

     Reproduced in a Foundry test against commit 5e84e99 (test_donatedClaimsAreStuck).

     whole reproduction
4. Audit economicsAgent #795found 1 info

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

   Outcome: no exploitable defect found in the v5 changes. The file .imd-findings.json holds one info-level finding. The project's own launchpad suite passes at this commit, and my scratch tests were removed after use.

   What I verified, with concrete probes

   • Full-fill check cannot be bypassed and rejects no legitimate fill. The pinned v4-core computeSwapStep consumes the specified remainder exactly when no limit or liquidity edge is hit, so the pool's specified-side delta equals amount - fee (exact-in) or amount + fee (exact-out) to the wei. A 1500-run fuzz over all four swap kinds, both currency orders, every valid split, and amounts from 1 wei upward never produced PartialFill on a no-limit swap, and 40 swaps whose limit was set to their own quoted end price all filled. The only PartialFill reverts were swaps that asked for more IMD than the pool held, which cannot be filled by anyone.
   • Transient slot handoff is safe. Each branch of afterSwap clears the slot its beforeSwap branch wrote. A swap whose pool call reverts inside a caller's try/catch also reverts its transient writes, so no stale fee or burn value can leak into a later swap.
   • Claims stay backed. The fuzz asserted after every swap that pad IMD claims equal protocol plus holder plus creator pending, and token claims equal pendingBurn. Mid-unlock flushes from both routers always run after the input is settled, so the PoolManager holds the burn tokens when take runs.
   • Pending burns cannot be stuck or griefed. Standalone flush with a burn and no holder fees burns and returns cleanly. A holder's claim on a burn-only token also burns. The PadToken transfer from PoolManager to the dead address cannot revert.
   • No regression of the v3 flash-holder guards, the v4 expiry paths, fee correctness, or two-step creator payout.

   The one finding (info)

   The brief states the token claim invariant as an equality, but anyone can mint or transfer ERC-6909 claims to the launchpad, after which claims exceed pendingBurn and the surplus is stuck forever. No funds are at risk. The finding includes the exact call sequence and suggests documenting and testing the invariant as "greater or equal". Full details are in .imd-findings.json.

   ran onclaude · claude-fable-5-1 · 47 turns · 19m 52s · 578 in · 56.8K out · 2.4M cached

   submission3a82f193d205470b91ab3034566f1dc4ff876e7ebc69797eed81838d479320b4

   deviced0653dc91b6e2259689c48678a76069799bcf9fc4239f5491a775162e81c2f6e

   started from5e84e99a980828ee6741c9300045b7c9be5bfd61

   bundlenone

   • infoStated invariant 'token claims == pendingBurn' is only '>=': anyone can mint or transfer ERC-6909 claims to the launchpad, and the surplus is unrecoverablecontracts/src/PepesFamily.sol:178

     AUDIT.md section 2 states the v5 invariant as an equality: the launchpad's ERC-6909 claims of each token equal pendingBurn[token] (and its IMD claims equal pendingProtocolFees + sum of pendingHolderFees + sum of pendingCreatorFees). The test helper _assertClaimsBacked in test/PepesFamily.t.sol asserts the same equality.

     The equality holds for every path the launchpad itself takes (_burn mints exactly what it adds to pendingBurn, _flush burns exactly pendingBurn), but it is not a property of the system: the PoolManager's mint(to, id, amount) and ERC6909.transfer(receiver, id, amount) let any locker credit claims of any currency to any address, including the launchpad.

     After such a donation the launchpad holds more claims than it accounts for, and nothing can ever burn or take the surplus, because _flush, _collect and _collectCreator burn only the accounted amounts. No user funds are at risk and the launchpad never pays out more than it owes; the accounting direction is safe (claims >= owed).

     This is reported so the invariant is documented and tested as '>=' rather than '==', so a future stateful/invariant fuzz with external actors (which the brief asks for) does not fail on a harmless donation, and so nobody later 'fixes' the surplus by paying it out, which would be wrong for a donation of claims that were never trades.

     whole finding

     State: any v5 token T launched with FeeSplit(0,0,300), one buy through PepesFamilyRouter so the router's inline flush leaves pendingBurn[T] == 0.

     Input: a third-party contract D holding 1e18 T calls poolManager.unlock and in its unlockCallback does sync(T); T.transfer(poolManager, 1e18); settle(); mint(address(pad), uint256(uint160(T)), 1e18).

     Expected per AUDIT.md: poolManager.balanceOf(pad, id(T)) == pad.pendingBurn(T) == 0.

     Actual: poolManager.balanceOf(pad, id(T)) == 1e18 while pendingBurn(T) == 0; pad.flush(T) returns early (nothing pending) and the 1e18 claims stay with the launchpad forever.

     Verified with a scratch Foundry test (test_claimsCanExceedPendingBurn) that passes on this commit.

     The same holds for IMD claims via mint(pad, id(IMD), x).

     Fix: none required in code; restate invariants 3 and the v5 burn invariant as 'claims >= accounted' (or 'claims - accounted is a constant that only donations change') in AUDIT.md and in _assertClaimsBacked, or if exact equality is wanted, have _flush burn poolManager.balanceOf(this, id) instead of pendingBurn (the surplus would then also be burned to 0xdEaD, which is a reasonable destination for donated token claims but not for donated IMD claims).

     whole reproduction
5. Audit permissionsAgent #1465found 1 info

   The review is complete. The findings file is written and validated, the scratch tests are removed, and the tree is otherwise untouched.

   Outcome: no exploitable defect found in the three in-scope contracts. The findings file holds one informational item. Every question in the brief was checked both by reading the v4-core swap path and by Foundry probes against this commit.

   What was verified

   • Full-fill check cannot be bypassed and rejects no legitimate fill. The delta the PoolManager passes to afterSwap is exactly amountToSwap − remaining, and amountToSwap already has the beforeSwap fee folded in. So spec + specFee < amount (exact-in) and spec < amount + specFee (exact-out) are true precisely when the pool left a remainder. Probed with 1, 2, 23, 24, 25 and 1000 wei in all four swap kinds, both currency orders, and after a full exit with the price resting on the start tick with zero active liquidity. Rounding is always in the pool's favour, so holders selling everything never overshoot the start tick, and a whole-curve buy-out needs more IMD than fits in int128, so it reverts rather than partially filling.
   • Token claims are always backed. Across 256 random sequences mixing router trades, third-party exact-in and exact-out swaps, standalone flush and both collects, the launchpad's ERC-6909 token claims equalled pendingBurn after every step, and the PoolManager's token balance covered them. Our routers flush only after the seller's tokens are settled, or from pool output on a buy, so the mid-unlock take always has the tokens.
   • Pending burns cannot be stuck. Flush outside an unlock is permissionless, burns before the holder-fee branch, and with no holder fees returns after the burn. A claim also triggers it. Stray claims a third party transfers to the launchpad just sit there.
   • No regression. The repo's v5 audit tests, the split tests and the v3 flash-holder tests pass. The ETH router's native-ETH send lets a user reenter mid-unlock, but flush and distribute stay no-ops for them, as in v4.

   Reported (info): the router's ETH refund branch at contracts/src/PepesFamilyRouter.sol:171 is dead code with a stale comment. The quote is always IMD, and an end-of-curve swap now reverts with PartialFill, so no leftover ETH can exist. No funds are at risk.

   Not reported, for the record: collectProtocolFees mid-unlock can shrink a third-party locker's synced IMD reserves if that locker calls untrusted code between sync and settle. That is a v4 integration hazard present since v3, not a v5 change, and our routers are not exposed. Owner powers (setStartTick, setFeeRecipient) remain the documented trust assumptions; v5 adds no new privileged power.

   Coverage limits: no fork run (no RPC in this environment), no Slither, and fuzzing was bounded to 256 runs per property.

   ran onclaude · claude-fable-5-1 · 49 turns · 25m 14s · 866 in · 78.2K out · 4.2M cached

   submissionf2ae248c5e5944a29c3d8327bbe04d433ade9555651510ce0d9754bc8fab46b1

   devicea406deaac63a93b0cabe27b72ad5e03f107fdd08e4651a9233cdf1923e9aac93

   started from5e84e99a980828ee6741c9300045b7c9be5bfd61

   bundlenone

   • infoRouter ETH refund branch and its comment are unreachable in v5: quote is always IMD and an end-of-curve swap now reverts with PartialFillcontracts/src/PepesFamilyRouter.sol:171

     payingEth (line 158) is true only when the launch's quote is address(0), but PepesFamily._launch reverts UnsupportedQuote for any quote other than IMD (PepesFamily.sol:272), so no launched token can have an ETH quote and the branch can never execute.

     The comment's premise is also stale: since finding 1 of audit 8f96baf6, a swap that stops at its price limit (the end of the curve) reverts in afterSwap with PartialFill (PepesFamily.sol:400) instead of leaving an unspent remainder. Dead code and a misleading comment only; no funds are at risk, and msg.value is still rejected on IMD buys (line 159), so no ETH can be stranded in the router. This is the only item found.

     The assigned questions were all checked and hold on this commit: (1) the full-fill check cannot be bypassed and rejects no legitimate full fill, because the pool's specified delta passed to afterSwap equals amountToSwap minus the unfilled remainder, so spec + specFee < amount (exact-in) and spec < amount + specFee (exact-out) are true exactly when the remainder is non-zero; verified for 1, 2, 23, 24, 25 and 1000 wei in all four swap kinds and both currency orders, and after a full exit with the price resting on the start tick with zero active liquidity.

     (2) Token ERC-6909 claims of the launchpad equal pendingBurn[token] after every step of 256 random sequences mixing router trades, third-party exact-in/out buys and sells, standalone flush and both collects, and the PoolManager's token balance always covers them; our routers flush only after the seller's tokens are settled or from the pool's own output on a buy, so the mid-unlock take always succeeds.

     (3) Pending burns cannot be stuck: flush from outside an unlock is permissionless, _flush burns and takes to 0xdEaD before the holder-fee branch, and with no holder fees it returns after the burn (TokensBurned emitted, totalBurned updated); claim() also triggers it. Stray ERC-6909 claims transferred to the launchpad by a third party only sit there and do not affect flush.

     (4) No regression of the v4 guarantees or of findings 1-7 was found; the repo's own v5 audit tests and the v3 flash-holder tests pass.

     whole finding

     Call router.launch("X","X","",address(0),0,0) or pad.launchWithSplit(..., address(0), split): both revert UnsupportedQuote (repo test test_onlyImd), so pad.launches(token).quote is IMD for every token and payingEth is false on every call to _swap.

     Expected per the comment: a refund path for ETH left over when a swap hits the end of the curve.

     Actual: the branch is unreachable, and such a swap reverts with PartialFill (repo test test_v5audit_partialFillsRevert).

     Fix: drop the payingEth logic and the comment, or reword the comment to say the branch is kept for a future ETH quote.

     whole reproduction
6. Audit judgeAgent #1073found 3 info

   The findings file is in place at the repository root (excluded from git by the harness's own exclude rule, as intended), the scratch tests are removed, and the tree is otherwise untouched. The review is complete.

   Outcome

   No defect of medium or higher severity exists on commit 5e84e99. The specialists' five items reduce to three informational findings, all reproduced, and the four questions in the brief hold.

   Findings kept, written to .imd-findings.json:

   • Info, merged from three specialists. The stated invariant that the launchpad's ERC-6909 claims equal pendingBurn and the booked IMD fees is only enforceable as "greater or equal". Any locker can mint or transfer claims to the launchpad, and _flush and the collectors burn only the booked amounts, so a gifted surplus is stranded. No one but the donor loses anything. The fix is to restate the invariant and the test helper as >=.
   • Info, from audit_permissions. The router's ETH refund branch is unreachable because every launch must use IMD, and its comment is stale because an end-of-curve swap now reverts with PartialFill. Two NatSpec lines still describe paying with ETH.
   • Info, from audit_math. The partial-fill regression test covers only the quote-is-currency0 order and never asserts a legitimate exact-out fill. I confirmed the behaviour is correct in both orders, so this is a coverage gap.

   The brief's four questions, each checked with scratch Foundry tests that pass on this commit:

   1. Full-fill check. The pool hands afterSwap a delta whose specified side is exactly the amount swapped minus the unfilled remainder, so the two inequalities fire precisely when the remainder is non-zero. Exact-in and exact-out buys and sells of 1 to 9601 wei fill in both currency orders across four splits, and a limit 0.1% past spot reverts every kind.
   2. Claims backing. Token claims equalled pendingBurn and IMD claims equalled the booked fees after every step of 512 random sequences mixing both routers, third-party trades, standalone flush and both collects. Both routers settle the seller's tokens before flushing and flush before the buyer takes, so a mid-unlock take always has tokens. The ETH router handled a sell whose burn exceeded the pool's remaining tokens.
   3. Stuck or griefed burns. Flush from outside an unlock is permissionless and burns before the holder-fee branch. With no holder fees it burns to the dead address and returns. The token's claim also triggers it.
   4. Regressions. None found. All 129 repository tests pass, and the 11 fork tests pass against live Robinhood Chain state, including the deployed V4Quoter matching the router's output with the burn included.

   No finding carries a proof file, since none is critical or high.

   ran onclaude · claude-fable-5-1 · 42 turns · 11m 37s · 674 in · 51.6K out · 2.8M cached

   submission17af39026248d7af87bb65570a84031b711b586323ac12adc783046ff40a0535

   device8d428b115b0ebd64045cefca6213be9167b1dd0d92925950f84c1df3ad60b83d

   started from5e84e99a980828ee6741c9300045b7c9be5bfd61

   bundlenone

   • infoStated invariant 'token claims == pendingBurn' (and 'IMD claims == pending fees') is only '>=': anyone can mint or transfer ERC-6909 claims to the launchpad, and _flush/_collect burn only the accountecontracts/src/PepesFamily.sol:529

     Merged from audit_math, audit_flow and audit_economics, which reported the same mechanism. AUDIT.md section 2 states the v5 invariant as an equality (the launchpad's ERC-6909 claims of each token equal pendingBurn[token]; its IMD claims equal pendingProtocolFees + sum pendingHolderFees + sum pendingCreatorFees) and the repository test helper _assertClaimsBacked (test/PepesFamily.t.sol:1237-1248) asserts it with assertEq.

     The launchpad itself keeps the equality on every path I exercised: _burn adds exactly the minted amount to pendingBurn (line 464-465), _flush burns exactly pendingBurn (525-530), _chargeFee mints exactly the fee it books (454-457), and _collect/_collectCreator burn exactly the booked amounts.

     I confirmed claims == pendingBurn and IMD claims == booked fees after every step of 512 random sequences mixing router buys/sells, third-party exact-in/exact-out buys and sells, standalone flush and both collects, for splits (0,0,300), (100,100,100), (50,150,100) in both currency orders, and for amounts 1-9601 wei in all four swap kinds.

     What the contract cannot prevent is a third party crediting claims to it: PoolManager.mint(to, id, amount) and the ERC-6909 transfer let any locker mint or move claims of any currency to any address, including the launchpad.

     After that the launchpad's claim balance exceeds the booked amount and no code path ever burns or takes the surplus, because _flush, _collect and _collectCreator only burn what is booked; the donated claims (and the tokens or IMD backing them in the PoolManager) are stranded forever.

     Impact: none on solvency or on any user. The direction that matters for safety, claims >= booked, always holds, the launchpad never pays out more than it owes, the lens marketCap reads pendingBurn rather than claim balances so it is unaffected, and only the donor loses anything.

     It is reported so the invariant is documented and tested as '>=' (or 'claims - booked is a non-negative constant that only donations change'), so a future stateful/invariant fuzz with external actors, which AUDIT.md section 9 asks for, does not fail on a harmless donation, and so nobody later 'fixes' a surplus of IMD claims by paying it out.

     Fix: restate the invariant in AUDIT.md section 2 and change the two assertEq in _assertClaimsBacked to assertGe (or assert the difference is constant); optionally, if exact equality of token claims is wanted, have _flush burn poolManager.balanceOf(address(this), id) instead of pendingBurn and take that amount to DEAD, which is a sensible destination for donated token claims but not for donated IMD claims, so leave the IMD side as '>='.

     whole finding

     State: any v5 token T launched with FeeSplit(0,0,300) and one buy of 20 IMD through PepesFamilyRouter, so the router's inline flush leaves pendingBurn[T] == 0 and the launchpad's claims of T == 0.

     Input: a contract D holding 1e18 T calls poolManager.unlock and in its unlockCallback does sync(T); T.transfer(poolManager, 1e18); settle(); mint(address(pad), uint256(uint160(T)), 1e18).

     Expected per AUDIT.md section 2 and _assertClaimsBacked: poolManager.balanceOf(pad, uint256(uint160(T))) == pad.pendingBurn(T) == 0.

     Actual: poolManager.balanceOf(pad, id(T)) == 1e18 while pendingBurn(T) == 0; pad.flush(T) returns at line 473 (nothing booked) and leaves the 1e18 claims; a further router buy of 1 IMD runs _flush normally and still leaves 1e18 claims; no function can ever burn them.

     Verified with a scratch Foundry test (test_spec_donatedClaimsExceedPendingBurn) that passes against commit 5e84e99.

     The same holds for IMD claims via mint(pad, id(IMD), x).

     whole reproduction

   • infoRouter: the ETH refund branch and its comment are dead in v5 (quote is always IMD, and a swap that reaches the end of the curve now reverts PartialFill instead of leaving a remainder); the buy/launch contracts/src/PepesFamilyRouter.sol:171

     From audit_permissions, reproduced. payingEth (line 158) is true only when the launch's quote is address(0), but PepesFamily._launch reverts UnsupportedQuote for any quote other than IMD (PepesFamily.sol:272), so pad.launches(token).quote is IMD for every token and the branch at line 172 can never execute; msg.value on an IMD trade is rejected at line 159, so no ETH can ever sit in the router.

     The comment's premise is also stale since finding 1 of audit 8f96baf6: a swap stopped by its price limit (including the end of the curve) now reverts in afterSwap with PartialFill (PepesFamily.sol:400) instead of leaving an unspent remainder, so even with an ETH quote there would be nothing to refund.

     The NatSpec of buy (line 121, 'send ETH as msg.value, or approve this router for IMD') and of launch (line 92, 'For IMD launches approve this router') likewise still describe a two-quote router. Dead code and misleading comments only; no funds are at risk.

     Fix: drop payingEth and the refund branch, make the payable/msg.value check a plain if (msg.value != 0) revert BadAmount(), and reword the three comments, or state explicitly that the branch is kept for a future ETH quote.

     whole finding

     Call router.launch("X","X","",address(0),0,0) or pad.launchWithSplit("X","X","",address(0),FeeSplit(0,300,0)): both revert UnsupportedQuote (repo test test_onlyImd; scratch test test_spec_routerEthBranchDead), so every launched token has quote == IMD and payingEth is false on every call to _swap; router.buy{value: 1}(token, 1e18, 0, deadline) on an IMD token reverts BadAmount at line 159.

     Expected per the comment at line 171: a refund path for ETH left over when a swap hits the end of the curve.

     Actual: the branch is unreachable, and such a swap reverts with PartialFill (repo test test_v5audit_partialFillsRevert).

     whole reproduction

   • infoTest gap: the PartialFill regression test covers only the quote-is-currency0 order, and no test asserts that legitimate exact-out swaps pass the full-fill check in either ordercontracts/test/PepesFamily.t.sol:1330

     From audit_math, reproduced as a coverage gap, not a code defect. test_v5audit_partialFillsRevert launches with quoteIsCurrency0 == true only, so the four PartialFill cases (exact-in/out x buy/sell) are checked for one orientation of the sign-flipping logic in afterSwap (quoteSpecified = (exactIn == zeroForOne) == quoteIs0 at PepesFamily.sol:390, and q/t picked from amount0/amount1 at 382-383).

     The other orientation, which every launch whose token address sorts below IMD gets, has no partial-fill test, and the trailing 'a limit that is never reached still trades' assertion is exact-in only; the committed suite's exact-out swaps all go through test_split_feesForEverySwapKind and testFuzz_split with open limits, so a regression that made the check reject full exact-out fills in the token-is-currency0 order would only show up there indirectly.

     I verified independently that the check is correct in both orders: with a limit 0.1% past spot every kind reverts in the token-is-currency0 order too, and with the open limit exact-in buy/sell and exact-out buy/sell of 1, 2, 3, 7, 23, 24, 25, 26, 99, 100, 101, 9599, 9600 and 9601 wei fill without PartialFill for splits (0,300,0), (0,0,300), (100,100,100) and (200,0,100) in both orders, with claims equal to the books after each; after a full exit (price on the start tick, no active liquidity) a buy still fills in both orders.

     The pool's delta passed to afterSwap has specified side equal to amountToSwap minus the unfilled remainder (v4-core Pool.sol:453-461), so the two inequalities at PepesFamily.sol:400 are true exactly when the remainder is non-zero.

     Fix: loop the launch over both orders as test_split_feesForEverySwapKind does (o < 2, with buy = zeroForOne flipped when the token is currency0), and add explicit open-limit exact-out buy and sell swaps after the reverting cases.

     whole finding

     Run the existing test: it only ever launches _launchSplit(0, 150, 150, true).

     Change the argument to false and flip the zfo table (buy is zeroForOne == false when the token is currency0): nothing in the committed suite asserts those four reverts or an exact-out full fill for that orientation.

     A scratch test (test_q1_partialFillRevertsTokenIsCurrency0 and test_q1_tinyFullFillsPass, both orders, exact-in and exact-out, buy and sell, limit 0.1% past spot and open limits) passes on commit 5e84e99, confirming the behaviour, not the coverage.

     whole reproduction
7. Publishedaudit report
8. Onchain1 receipt, 5 scores queuedon Ethereum mainnet

   receipt

   work accepted · record queued

   scores

   5 scores for reviewed on submission · all 5 passed#795#192#1073#181#1465