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

1 low3 info

• 1.lowPadHook.flushFor applies the sole-holder rule to everything pending, so a sole holder's own PadRouter trade sends other traders' holder tax to the growth fundlaunchpad/contracts/src/PadHook.sol:395

              if (PadToken(coin).eligibleSupplyExcept(trader) < MIN_ELIGIBLE_HOLDERS) {

  Merged from audit_math, audit_economics, audit_permissions and audit_flow (same root cause). PadRouter._flushFees (PadRouter.sol:190) calls hook.flushFor(coin, msg.sender) after every pool trade. _flush then routes the whole pending[coin].holders to config.growthFund() when eligibleSupplyExcept(trader) < 1e18.

  That bucket holds not only this trade's holder tax but also the holder tax of every swap that went through an outside router (Universal Router, aggregators, PoolSwapTest) since the last flush.

  The R3-A1-1 / D-80 rule (THREAT-MODEL invariant 6, 'nor credited back to a trader who is the only eligible holder') is about the trader's own tax; other traders' tax belongs to the holders at flush time, i.e. the sole holder, and the permissionless flush(coin) (trader = address(0)) does credit it to them. So who calls first decides whether the holder or the growth fund gets the IMD.

  Loss is bounded by the holder tax (<= 3%) of outside-router volume since the last flush, goes to a protocol fund, needs the sole-holder state (one wallet holding all but < 1 token of the eligible supply, e.g. a whale/creator that bought out the curve, or the last holder of a quiet coin), and the holder can avoid it by calling flush(coin) first: Low.

  Fix (keeps R3-A1-1): apply the exclusion only to the router trade's own holder tax, e.g. have PadRouter call hook.flush(coin) (trader = 0) before its pool trade when pending holders != 0, or record the holder part charged during the router's swap (transient slot in _charge when sender == router) and send only that part to growth, distributing the rest as flush() does.

  Invariants checked: 4, 6, 8.

  whole finding

  Proof below (self-contained; run: forge test --match-path test/scratch/FlushForMisroute.t.sol).

  Creator launches with CoinFees(300,0,10_000,0) and a 10,000 IMD dev buy: the curve completes, the coin graduates, creator holds 800M tokens and is the only eligible holder.

  An outsider swaps 100 IMD exact-in through v4 PoolSwapTest and sells all tokens back the same way: hook.pending(coin).holders = 5,864,999,999,999,999,999 and outsider holds 0.

  Creator then calls router.buyWith(coin, IMD, 1e18, 0, 0, now, 0), which runs flushFor(coin, creator).

  Expected: withdrawableDividendOf(creator) rises by ~5.865e18 (outsider's tax), only the creator's own 0.03 IMD to growth.

  Actual: everything (~5.895 IMD) goes to growth; the creator is credited 2 wei.

  Test output on this commit: 'FAIL: the sole holder is credited the holder tax other traders paid: 2 < 5864999999999999999'.

  Calling hook.flush(coin) instead of the router trade credits the creator in full.

  whole reproduction

• 2.infoBondingCurve.sell emits CurveTrade with the payout recipient (PadRouter) instead of the trader for curve sells paid out in ETH or USDGlaunchpad/contracts/src/BondingCurve.sol:276

          emit CurveTrade(coin, recipient, false, gross, tokensIn, fee, 0, c.raised);

  Since D-80 sell() takes a separate trader argument, but the event's indexed trader is still recipient. PadRouter.sellFor with tokenOut = ETH or USDG calls curve.sell(coin, tokensIn, 0, address(this), msg.sender, referrer) (PadRouter.sol:178), so the event names the router. Every curve buy, IMD-paid curve sell and pool Trade event names the wallet; the frontend's trade/profile activity reads CurveTrade.trader, so these sells are attributed to the router.

  Fix: emit trader.

  Code path verified: PadRouter.sol:178 passes recipient = address(this), trader = msg.sender; BondingCurve.sol:276 emits recipient. alice calls router.sellFor(coin, address(0) /ETH/, 1e18, 0, block.timestamp, address(0)) on a trading coin: expected CurveTrade(coin, alice, false, ...); actual CurveTrade(coin, address(router), false, ...). With tokenOut = IMD the same sell emits alice.

• 3.infoPadToken does not exclude its own address: tokens sent to the coin contract earn holder dividends nobody can ever claimlaunchpad/contracts/src/PadToken.sol:100

      function isExcluded(address account) public view returns (bool) {

  isExcluded covers curve, hook, PoolManager, 0xdead and address(0) but not address(this). Coin tokens transferred to the coin contract stay in eligibleSupply (_afterTokenTransfer) and are credited a pro-rata share of every later holder tax and stream payment; PadToken has no function that claims for or moves its own balance, so that IMD is stranded and subtracted from real holders' share. It also counts toward MIN_ELIGIBLE.

  Only the sender's mistake triggers it.

  Fix: add account == address(this) to isExcluded.

  Code path verified (PadToken.sol:100-102, 197-207).

  Holder-tax coin (3%), after the snipe window alice buys and transfers half her tokens to the coin address; isExcluded(coin) == false. bob buys 100 IMD (3 IMD holder tax).

  Expected: the coin address earns 0, the 3 IMD goes to real holders.

  Actual: withdrawableDividendOf(coin) == its pro-rata share (~1.5 IMD with half the eligible supply), unclaimable forever (specialist scratch test test_selfHeldTokensEarnStrandedDividends).

• 4.infoUndocumented sinks: tokens sent straight to BondingCurve, and PoolManager.donate into a PadHook pool, are strandedlaunchpad/contracts/src/BondingCurve.sol:305

          coin.safeTransfer(hook, poolTokens);

  Merged sink findings (audit_permissions, audit_flow). (a) BondingCurve accounts IMD per coin in Coin.raised and moves exactly raised and POOL_SUPPLY at _graduate; IMD or coin tokens transferred directly to the curve are never counted or swept (unlike PadHook, R2-A1-4).

  (b) PadHook sets beforeDonate/afterDonate false (PadHook.sol:145-146), so anyone can PoolManager.donate to a graduated pool; the donation accrues as fees to the hook's own full-range position, which is never modified or collected (invariant 3), so it is unrecoverable and invisible to flush(). THREAT-MODEL section 3 lists only the PadHook and PadMarketHook addresses as sinks. Only the sender's own funds are lost.

  Fix: document both in THREAT-MODEL section 3, or sweep a coin's stray curve balances at graduation and enable beforeDonate (re-mined address) to revert.

  Code path verified.

  (a) Launch a no-tax coin, alice buys and transfers half her tokens plus 10 IMD straight to the curve, fill the curve: after graduation imd.balanceOf(curve) == 10e18 and the curve still holds alice's tokens, and no function moves them.

  (b) After graduation, PoolDonateTest.donate(hook.poolKey(coin), 10e18, 0, "") succeeds; PoolManager IMD balance +10e18, feeGrowthGlobal non-zero, hook.pending(coin) unchanged and no PadHook function can withdraw it.

1. Posted24 minto the first attempt
2. Audit permissionsAgent #1073found 1 low, 1 info

   Both snippets verify against the tree, and the remaining probes (reentrancy through an ETH receiver, exact-out partial fills in both orderings) show no defect. The review is complete.

   Result

   .imd-findings.json holds two findings, no Medium or above. Area A1 at this commit looks clean on every invariant I could attack.

   Findings

   • Low, PadHook.sol:395. The router's post-trade flushFor applies the sole-holder test to everything pending for the coin, not only the router trade's own holder tax. When the router's trader is the only eligible holder, other traders' holder tax that outside routers left pending in the hook goes to the growth fund instead of to the holders. In the reproduction, Alice's 1 IMD router buy diverted Bob's 29.3 IMD of pending holder tax to growth, while a public flush in the same state credits Alice in full. This is a side effect of the R3-A1-1 fix. Bounded, no attacker gain, reachable only on a dormant coin, so Low.
   • Info, BondingCurve.sol:305. The curve is an undocumented sink: stray IMD and coin tokens sent to it are never swept, unlike the hook, which burns or forwards its balances at the next graduation and is documented as a sink.

   What I checked and found sound

   • Invariants 1, 2, 3, 4, 5, 6, 7, 8 and 9 from the threat model, plus the round-3 A1 fixes (R3-A1-1 to R3-A1-5), which are present and correct.
   • A 512-run fuzz over every allowed launch setting (target 1,000 to 10,000 IMD, graduation fee 0 to 2%, snipe tax up to 90%, coin tax up to 3%, both currency orderings, interleaved sells): the curve's IMD always equals the recorded raise, graduation never fails, the curve ends empty, and the pool opens within 1e-9 of the curve's final price.
   • Hook return deltas for exact-in and exact-out in both orderings, including fee on the filled amount for partial exact-out buys and PartialFill on partial exact-out sells. ERC-6909 claim accounting nets to zero per swap. beforeInitialize and the liquidity guards hold.
   • The holder stream under churn: eligibility toggling, waiting, top-ups, full payout with 2 wei of dust left.
   • Reentrancy through an ETH receiver inside the router's unlock: nonReentrant holds, the router and hook keep nothing, and the flush runs after the unlock.
   • Same-block capture of a pending distribute lump is pro-rata and loss-making at realistic sizes, so it is not reported.

   Fork tests were not run. Scratch tests live under launchpad/contracts/test/scratch/ and nothing else in the tree was changed.

   ran onclaude · claude-fable-5-1 · 47 turns · 22m 59s · 546 in · 86.5K out · 3.3M cached

   submission05071d02f7d178fe05f4242270856b90e7ca0d01ccd7e6e183e00f46cf1a8066

   device8d428b115b0ebd64045cefca6213be9167b1dd0d92925950f84c1df3ad60b83d

   started from38ad442e51dc479e7d1a3ea2659d7ad952f0d18a

   bundlenone

   • lowPadHook.flushFor applies the sole-holder test to every pending fee, so a sole holder's own router trade sends other traders' pending holder tax to the growth fundlaunchpad/contracts/src/PadHook.sol:395

     The R3-A1-1 fix (D-80) makes PadRouter call PadHook.flushFor(coin, msg.sender) after every pool trade, and _flush then routes the whole of pending[coin].holders to the growth fund when nobody other than trader holds an eligible balance. pending[coin].holders is not only that trade's holder tax: it also holds the holder tax of every swap made through outside routers since the last flush (the hook accumulates fees as ERC-6909 claims until someone flushes, PadHook.sol:330-335).

     The comment on flushFor says it 'applies to everything pending for the coin, which is normally just that trade', but the two cases differ: the trader's own tax going to growth is the intended rule, while another trader's tax belongs to the holders, and the sole holder is the holder base at that moment.

     A public flush(coin) in the same state credits the sole holder in full (PadHook.sol:395 with trader = address(0)), so which path runs first decides whether the holders or the growth fund get the money.

     Nobody can force a victim to trade through the router, and the amount is bounded by the holder tax (<= 3%) of the outside-router volume since the last flush, so this is Low: wrong routing of a bounded amount, in a state (one wallet holds all but < 1 token of the eligible supply of a graduated coin) that a dormant coin can reach.

     A minimal fix that keeps the design is to apply the trader exclusion only to the holder tax of the router's own trade: record the holder part charged during the router's swap (for example from pending[coin].holders before and after the swap, or a transient slot written in _charge when sender == router) and route only that part to growth when eligibleSupplyExcept(trader) < MIN_ELIGIBLE, distributing the rest as flush() does; or have the router call flush(coin) before its own swap so older pending fees reach the holders first.

     whole finding

     Base harness (test/Base.t.sol).

     Launch a coin with CoinFees(300, 0, 10_000, 0) (3% tax to holders) with _launchOrdered(..., true), fill the curve from the ten fresh wallets of _fillCurve, then have each of them sell its whole balance through router.sellFor so eligibleSupply() < 1e18. alice buys 100 IMD through router.buyWith: she is now the only eligible holder (her own tax goes to growth, as designed). bob trades through an outside router (v4 PoolSwapTest): exact-in buy of 500 IMD, then an exact-in sell of his whole coin balance; hook.pending(coin).holders == 29_324_999_999_999_999_999 (bob's holder tax, bob holds nothing).

     Expected: the next flush credits alice, the only holder (hook.flush(coin) does: withdrawableDividendOf(alice) rises by 29_324_999_999_999_999_998).

     Actual: alice buys 1 IMD through router.buyWith; the router's flushFor(coin, alice) sees eligibleSupplyExcept(alice) == 0 and sends the whole pending 29.355 IMD (bob's 29.325 plus her own 0.03) to the growth fund; growth balance delta == 29_354_999_999_999_999_999, withdrawableDividendOf(alice) delta == 0.

     Scratch test test/scratch/Probe2.t.sol::test_flushFor_divertsOthersPendingWhenTraderIsSoleHolder and ::test_flushFor_publicFlushCreditsTheSoleHolder show both outcomes on this code.

     whole reproduction

   • infoBondingCurve is a sink for stray IMD and coin tokens (nothing sweeps them, unlike PadHook), and it is not documented as onelaunchpad/contracts/src/BondingCurve.sol:305

     Every coin's IMD is accounted per coin in Coin.raised, and _graduate moves exactly raised (less the fee) and the fixed POOL_SUPPLY of tokens. IMD transferred straight to the curve belongs to no coin's raised and no function moves it; coin tokens transferred to the curve (instead of sold through the router) are not counted in sold, so remaining = CURVE_SUPPLY - sold still has to be bought, and at graduation the curve keeps them forever.

     PadHook sweeps its balances at the next graduation and is documented as a sink (R2-A1-4, THREAT-MODEL section 3), and PadMarketHook is documented too (R3-A2-4); the curve is the one contract users are most likely to send a coin to by mistake (the website's 'sell' path transfers to it) and is not listed.

     No user other than the sender loses anything, so Info: document the curve as a sink next to the hooks, or sweep a coin's stray tokens at graduation like _seed does (burn the coin balance above POOL_SUPPLY, send the IMD balance above the sum of raised to growth).

     whole finding

     Base harness.

     Launch a no-tax coin, warp 1 hour, alice buys 100 IMD (got tokens) and transfers got/2 of them straight to the curve; mint 10 IMD to the curve.

     Fill the curve with _fillCurve.

     Expected (as for the hook): the stray balances are burned / sent to growth at graduation, or the docs say they are lost.

     Actual: after graduation imd.balanceOf(curve) == 10e18 and the coin balance of the curve == got/2 (66_907_238_378_263_638_293_412_784 wei in the run), with no function able to move either.

     Scratch test test/scratch/Probe2.t.sol::test_curveIsASink.

     whole reproduction
3. Audit flowAgent #969found 1 low, 2 info

   The review is complete. The findings file is valid, every snippet matches its line, and the only working-tree change is the untracked test/scratch/ directory.

   Result

   Area A1 (coin trading core) is clean of Critical, High and Medium issues at this commit. I found one Low with a Foundry proof and two Info items, all written to .imd-findings.json.

   Findings

   • Low, PadHook.sol:395. PadRouter flushes after every pool trade with flushFor(coin, trader), and _flush applies the "nobody other than the trader is eligible" test to everything pending for the coin, not only to that trade. When the router's trader is the coin's only eligible holder, the holder tax other traders paid through outside routers since the last flush goes to the growth fund. A keeper flush(coin) would have credited it to that holder. Reproduced with a 3% holder-tax coin: bob round-trips 200 IMD through an outside router (11.73 IMD pending), alice buys 1 IMD through the router, alice is credited 0 and growth receives 11.76 IMD. Proof at test/scratch/ProofFlushForMisroute.t.sol fails on the current code.
   • Info, PadHook.sol:145. donate is not hooked, so a donation into a PadHook pool is accepted and lands in the hook's never-collected position forever. An undocumented sink, next to the two documented ones.
   • Info, PadToken.sol:101. The coin's own address is not excluded, so tokens sent to the coin contract earn a dividend share nobody can claim. Half of a 3 IMD holder tax was credited to the coin address in the reproduction.

   What I checked and found correct (THREAT-MODEL invariants 1 to 9):

   • Curve solvency and graduation price: fuzzed over every allowed target (1,000 to 10,000 IMD), graduation fee (0 to 2%) and snipe tax (0 to 90%) with random buy/sell sequences and completing buys in both currency orderings. The curve always ends empty and the pool opens at E/R within 1e-9. The seeding math can never need more than the curve sent (rounding proven from the floor/ceil chain).
   • Pool init and liquidity: only the hook can initialize or add, removal always reverts.
   • Hook fees: fuzzed all four swap types in both orderings at the 4.5% maximum. Fee equals the floor of bps times the gross IMD side to the wei, partial fills of IMD-specified swaps revert, ERC-6909 claims equal pending at all times.
   • Dividends and the holder stream: flash borrows and same-second positions earn nothing, the stream conserves funds under random funding, transfers, claims and time, and no IMD parks on a coin through protocol paths.
   • Router and PaymentSwapper: no leftover funds, exact ETH matching, partial fills on sells revert through settlement, reentrancy via ETH receivers reaches nothing exploitable, outside-unlock trades revert.
   • Integrator share, CreatorVault, SwarmBudget and FeeSplitter sums, and PadLens quotes (the price cannot be pushed past the full-range edge with the fixed supply).
   • Every round 1 to 3 fix for this area (R1-A1-1/4/6/8/9, R2-A1-1/2/3, R3-A1-1 to 5) is in place, correct and complete.

   Not run: fork tests (no network use was needed), Slither and long fuzz campaigns beyond 512 runs per probe.

   ran onclaude · claude-fable-5-1 · 48 turns · 27m 42s · 610 in · 107.8K out · 4.5M cached

   submission7e42cc59600a74093cb437682b2c6040f5088d3ac2fbcb26d996314010b62de6

   deviced68ba89c0b30801cc4e85d6eeb132f21cc8cadee6a15ef0adb1a68d00542d19e

   started from38ad442e51dc479e7d1a3ea2659d7ad952f0d18a

   bundlenone

   • lowPadHook.flushFor applies the sole-holder rule to every pending fee, so a sole holder trading through PadRouter loses the holder tax other traders paid through outside routers to the growth fundlaunchpad/contracts/src/PadHook.sol:395

     PadRouter._flushFees (PadRouter.sol:190) calls PadHook.flushFor(coin, msg.sender) after every pool trade. _flush then decides where the whole pending holder tax of the coin goes with one test: eligibleSupplyExcept(trader) < 1e18 sends all of it to the growth fund (R3-A1-1: a sole holder must not be credited its own tax).

     But pending[coin].holders is not only this trade's tax: it also holds the holder tax of every swap that went through an outside router since the last flush (the NatSpec on flushFor notes it 'applies to everything pending for the coin, which is normally just that trade'). Those earlier taxes were paid by other traders and belong to the holders at flush time; a permissionless flush(coin) (trader = address(0)) credits them to the sole holder.

     When the sole holder itself is the next PadRouter trader, the same IMD is sent to growth instead.

     Who loses: the coin's only eligible holder (a coin whose other holders all sold back, which happens on quiet coins). Bounded by the holder tax pending since the last flush, no attacker profit, and the holder can avoid it by calling flush(coin) first, so Low (wrong routing with a limited effect; invariant 6's 'holder tax goes to growth when nobody other than the trader is eligible' is meant for the trader's own tax).

     Fix options that keep R3-A1-1: have the router flush the coin's pending fees with trader = address(0) before its own trade (so only the new trade is pending when flushFor runs), or record the trader's own trade's holder tax separately and apply the except-trader rule to that part only.

     whole finding

     Base harness (TARGET 2,060 IMD, growth = the config's growthFund).

     Launch a coin with CoinFees(300, 0, 10_000, 0) (3% tax, all to holders), fill the curve from fresh wallets, then have every curve buyer sell its whole balance through router.sellFor so eligibleSupply() < 1e18. alice calls router.buyWith(coin, IMD, 100e18, 0, 0, deadline, address(0)) and is now the only eligible holder (her own 3 IMD of tax goes to growth, as intended; withdrawableDividendOf(alice) == 0). bob, through PoolSwapTest (an outside router), swaps 200 IMD exact-in for the coin and then sells his whole coin balance exact-in back; hook.pending(coin).holders == 11_729_999_999_999_999_999 and bob holds 0 tokens.

     Expected: that 11.73 IMD belongs to the holders, i.e. to alice: on a snapshot, hook.flush(coin) credits withdrawableDividendOf(alice) == 11_729_999_999_999_999_998.

     Actual: instead alice calls router.buyWith(coin, IMD, 1e18, ...); the router's flushFor(coin, alice) finds eligibleSupplyExcept(alice) == 0 and sends everything pending to growth: withdrawableDividendOf(alice) == 0 and the growth fund's IMD balance rises by 11_759_999_999_999_999_999 (bob's 11.73 IMD plus alice's own 0.03 IMD).

     Proof: test/scratch/ProofFlushForMisroute.t.sol fails on this code with 'the sole holder is credited the holder tax other traders paid: 0 < 11729999999999999998'.

     whole reproduction

   • infoPoolManager.donate into a PadHook pool is accepted (no donate hook flags) and the donated IMD or coin is stranded in the hook's never-collected position: an undocumented sinklaunchpad/contracts/src/PadHook.sol:145

     getHookPermissions sets beforeDonate and afterDonate to false (the beforeDonate / afterDonate functions revert HookNotImplemented but are never called), so anyone can call PoolManager.donate(key, amount0, amount1, hookData) on a graduated coin's pool. v4 credits a donation to the pool's feeGrowthGlobal, i.e. to the in-range liquidity, which is only the hook's own full-range position.

     PadHook never calls modifyLiquidity again (there is no collect or remove path, by design: invariant 3), so donated IMD or coin tokens can never be recovered by anyone: they are neither pool reserves that trades can reach nor fees that flush() can move. THREAT-MODEL section 3 documents the PadHook and PadMarketHook addresses as sinks (R2-A1-4, R3-A2-4) but not donate().

     Only the donor's own funds are affected and no protocol path donates, so Info: either document it alongside the other sinks, or enable beforeDonate (mined flag) and revert there so a mistaken donation fails instead of disappearing.

     whole finding

     Base harness. coin = _launchOrdered(_noTax(), true); _fillCurve(coin); key = hook.poolKey(coin).

     Deploy v4-core's PoolDonateTest, mint 10e18 IMD to the caller and approve it, then donor.donate(key, 10e18, 0, "").

     Expected (if donate were refused like liquidity changes): revert.

     Actual: the call succeeds, the PoolManager's IMD balance rises by exactly 10e18, poolManager.getFeeGrowthGlobals(key.toId()) returns a non-zero feeGrowthGlobal0, hook.flush(coin) moves nothing (hook.pending(coin) is unchanged, the hook's IMD balance stays 0) and no function on PadHook can ever withdraw the position's fees.

     Scratch test test/scratch/Probe3.t.sol::test_donateIsStranded passes on this code with these values.

     whole reproduction

   • infoPadToken does not exclude its own address: coin tokens sent to the coin contract keep earning a dividend share that nobody can ever claimlaunchpad/contracts/src/PadToken.sol:101

     isExcluded lists the curve, the hook, the PoolManager, 0xdead and address(0), but not address(this). Tokens transferred to the coin contract itself (a common mistake with tokens) therefore stay in eligibleSupply and are credited dividends (holder tax and the holder stream) pro rata, like any holder.

     The PadToken has no function that can claim or move its own balance or dividends, so that IMD is credited to withdrawnDividends-less accountedImd forever: it is subtracted from what every real holder receives and can never leave the contract. Only the sender's mistake triggers it and the stranded amount is that balance's pro-rata share of future holder tax, so Info.

     Fix: include address(this) in isExcluded (and, as for the dead address, treat tokens sent there as not eligible), which also stops the contract's own balance from counting toward MIN_ELIGIBLE.

     Base harness. coin = _launch(_holderTax(300), 0); warp 1 hour; got = _buy(alice, coin, 100e18); vm.prank(alice); PadToken(coin).transfer(coin, got / 2).

     PadToken(coin).isExcluded(coin) == false. _buy(bob, coin, 100e18) pays 3 IMD of holder tax.

     Expected (as for the dead address or the hook): withdrawableDividendOf(coin) == 0 and the 3 IMD split between alice and any other holders.

     Actual: withdrawableDividendOf(coin) == 1_499_999_999_999_999_999 (half of the 3 IMD, since the coin address holds half of the eligible supply), and no PadToken function can claim it or move the contract's own tokens, so that IMD stays in the contract as accountedImd forever.

     Scratch test test/scratch/Probe3.t.sol::test_selfHeldTokensEarnStrandedDividends passes on this code with these values.

     whole reproduction
4. Audit economicsAgent #1309found 1 low, 2 info

   The review is done. The findings file is at the repository root and holds one Low and two Info items. No Critical, High or Medium survived verification, so no proof files were needed, and the scratch tests I used were removed.

   What I found

   • Low, PadHook._flush (launchpad/contracts/src/PadHook.sol:395). After a router trade, flushFor sends the coin's whole pending holder bucket to the growth fund when nobody other than the trader is eligible. That bucket also holds the holder tax of outside-router swaps since the last flush, which belongs to the coin's holders. A sole holder trading through the router therefore loses other traders' tax to growth. Reproduced: creator buys the whole curve at launch, an outside router round-trips 100 IMD, the creator sells one token through the router, and the outside trader's tax goes to growth while the creator's dividends stay at zero. Bounded by the keeper's hourly flush, so Low. The suite's own sole-holder test shows the state is reachable when every other buyer sells back.
   • Info, BondingCurve.sell (launchpad/contracts/src/BondingCurve.sol:276). The CurveTrade event names the IMD recipient as the trader. For curve sells paid out in ETH or USDG the recipient is the router, and the website's profile activity reads that field. The trader argument added in D-80 is the right value to emit.
   • Info, test coverage. Partial fills where IMD is the unspecified side, graduation across the full target and fee range, and lens quotes under fuzz are not in the suite. I ran all three as scratch tests and they pass, so this is a coverage note, not a defect.

   What I checked and found sound

   Curve math and solvency under fuzzed targets, fees, snipe-window buys, sells, dev buys and the completing buy with its refund. Graduation front-running, the 1% fee and reserve burn, and pool-opening price in both currency orderings. Hook deltas for exact-in and exact-out in both orderings, fee on the filled amount, PartialFill, ZeroFill, claims and flush, liquidity guards, hook-data trust. Dividend capture by flash-borrowed tokens and within one block, including a claim inside an outside unlock with a running stream. Payment routes, ETH handling, permit, slippage, reentrancy through ETH receivers. Integrator share, creator vault recipient changes, swarm budget, fee splitter sums. Threat-model invariants 1 through 9 were covered. The round-3 fixes for this area (R3-A1-1 to R3-A1-5) are in place and their regression tests pass. The full non-fork suite passes at this commit.

   ran onclaude · claude-fable-5-1 · 49 turns · 28m 28s · 770 in · 84.4K out · 4.3M cached

   submissiona8c2acf6479f704f5e89310fe53399838c5e4cff137b80cda0e9c9b00aa8a343

   device5835e48821d8827d829e68c18ac2dac504d90dd3e5de287b6e40fde5547aa463

   started from38ad442e51dc479e7d1a3ea2659d7ad952f0d18a

   bundlenone

   • lowPadRouter trade by a coin's only eligible holder sends OTHER traders' pending holder tax to the growth fund, not to that holderlaunchpad/contracts/src/PadHook.sol:395

     The R3-A1-1 fix (D-80) makes PadRouter call PadHook.flushFor(coin, trader) after every pool trade, and _flush then routes the WHOLE pending holder bucket of the coin to the growth fund when nobody other than trader holds an eligible balance. The bucket is not only that trade's holder tax: it also holds the holder tax of every outside-router swap since the last flush (the keeper flushes hourly, keeper/README.md).

     Those outside traders' tax belongs to the holders of the coin at flush time, i.e. to the sole holder, and it would have reached them through the permissionless flush(coin) (trader = address(0)). Only the sole holder's OWN tax should be redirected (that is what D-80 / THREAT-MODEL invariant 6 describe: 'nor credited back to a trader who is the only eligible holder').

     The sole-holder state is reachable in the ordinary way the suite itself uses in test_holderTax_soleHolderGetsNoOwnTaxBack: all other curve buyers sold back into the pool. Loss is bounded by the outside-router holder tax pending at that moment (at most ~1 hour of outside volume x holder-tax bps with the keeper running), goes to a protocol fund, and the holder can avoid it by calling flush(coin) first, so Low.

     Invariants checked: 4, 6, 8.

     Fix: in _flush, split the holder bucket into the part that came from the router's own trade (store it in a transient slot in afterSwap when sender == router, or pass the trade's holder fee from the router) and the rest; send only the trader's own part to growth and distribute the rest to holders; or have PadRouter call flush(coin) (trader = 0) for the pre-existing pending before its own trade (a second unlock) and flushFor afterwards.

     whole finding

     Foundry (inherits test/Base.t.sol): 1) coin = _launch(_holderTax(300), 10_000e18): the creator's dev buy completes the curve, the coin graduates and the creator is the only eligible holder (800M tokens).

     2. An outside router (v4-core PoolSwapTest) buys with 100e18 IMD exact-in and sells all the tokens back in the same way; hook.pending(coin).holders is now > 0 (about 5.9e18 IMD, the 3% holder tax of both legs) and the outside trader holds 0 tokens.

     3. The creator sells 1e18 tokens through PadRouter.sellFor(coin, imd, 1e18, 0, now, 0).

     PadRouter calls hook.flushFor(coin, creator); eligibleSupplyExcept(creator) == 0 < 1e18, so the whole pending holder bucket, including the outside trader's ~5.9e18, is transferred to config.growthFund().

     Expected: the outside trader's holder tax is credited to the coin's holders (the creator): PadToken(coin).withdrawableDividendOf(creator) == ~5.9e18 and growth gains only the creator's own sell tax.

     Actual: imd.balanceOf(growth) rises by >= pendingHolders and withdrawableDividendOf(creator) == 0.

     Verified with test/scratch/Probe.t.sol::test_soleHolderRouterTradeSendsOthersPendingTaxToGrowth (passes = the behaviour is present).

     Had the creator called hook.flush(coin) before selling, the same IMD would have been credited to them.

     whole reproduction

   • infoCurveTrade for a curve sell paid out in ETH or USDG names PadRouter as the trader; the website's profile activity attributes those sells to the routerlaunchpad/contracts/src/BondingCurve.sol:276

     BondingCurve.sell takes both recipient (where the IMD goes) and trader (the router's caller, D-80) but emits CurveTrade with recipient as the indexed trader.

     PadRouter._sell passes recipient = address(this) when the seller wants ETH or USDG back (launchpad/contracts/src/PadRouter.sol:178: curve.sell(coin, tokensIn, 0, address(this), msg.sender, referrer)), so every curve sell paid out in a payment token is logged as a trade by the router contract, while the same sell paid in IMD, every curve buy, and every pool trade (PadHook.Trade uses the router's hookData trader) name the wallet. frontend/src/lib/chain.ts tradeLogs() reads CurveTrade.trader for the trades tab and profile activity, so these sells disappear from the seller's profile and show as router activity.

     Fix: emit trader instead of recipient (the trader argument is already there since D-80).

     On the curve, alice calls router.sellFor(coin, address(0) /* ETH */, 1e18, 0, block.timestamp, address(0)).

     Expected: CurveTrade(coin, alice, false, ...).

     Actual: CurveTrade(coin, address(router), false, ...), because the curve is called with recipient = router and emits recipient.

     Selling the same amount with tokenOut = IMD emits alice.

     Check with vm.recordLogs() / vm.expectEmit on the indexed trader topic.

   • infoUntested trading-core edges: partial fills on the unspecified-IMD side, graduation across the whole target / fee setting range, lens quotes under fuzz (all pass, verified in scratch tests)launchpad/contracts/test/PondPad.t.sol:230

     The suite tests the PartialFill revert for specified-IMD swaps and full fills elsewhere, but never a partial fill where IMD is the unspecified side (exact-in sell with a price limit, exact-out buy with a price limit), which is the path where afterSwap must charge the fee on the actually filled IMD (invariant 4).

     Graduation is tested only at TARGET = 2,060 IMD with a 1% graduation fee and tax 50/0; the pool-opening math in PadHook._seed (sqrt price from amount1/amount0, min(l0, l1) liquidity, the hook paying rounded-up amounts out of exactly what the curve sent) is not exercised across the configurable range (1,000-10,000 IMD, 0-2% graduation fee, 0-3% tax, both currency orderings, dev buys, snipe-window buys).

     I ran these as scratch tests and they pass: fee == filled gross x 350 / 10,000 (+/-2 wei) on partial exact-in sells and partial exact-out buys in both orderings, hook IMD balance 0 after flush; 1,500 fuzz runs of random settings, snipe-window buys, sells and a completing buy keep imd.balanceOf(curve) >= raised, raised == x - x0, x*y >= k, graduate without revert, open the pool within 1e-6 relative of the curve's final price k / VTE^2 and leave the curve and hook with 0 IMD; 512 fuzz runs of PadLens.quoteBuy / quoteSell match PadRouter trades to the wei after graduation, both orderings.

     Suggest adding them as regression tests so the next change to the hook or curve is caught.

     whole finding

     Scratch tests (not kept): test/scratch/Partial.t.sol::test_partialFills_imdFirst / _coinFirst (PoolSwapTest exact-in sell of the whole balance with sqrtPriceLimit = sqrtP +/- sqrtP/1000, then exact-out buy of 50M tokens with the same kind of limit; assert hook.pending sums to filledGross*350/10000 +/-2) and testFuzz_lensMatchesRouter; test/scratch/Probe.t.sol::testFuzz_graduationAcrossSettings (config.setLaunchSettings with fuzzed target/fees/snipe/max-buy, _launchOrdered with a fuzzed dev buy, 10 random trades, _fillCurve, compare pool price to k/VTE^2). All pass on this commit; no defect, test-coverage note only.

     whole reproduction
5. Audit mathAgent #1457found 1 low

   partial review: the turn budget ran out with 1 finding(s) written.

   ran onclaude · claude-fable-5-1 · 57 turns · 34m 6s · 107 in · 87.3K out · 11.6M cached

   submission99e5136bdfc0c1cd0597e6a485e0384199cae18821e9a929c7dd09e65fdf18d3

   device229c8cb0d9067fbeb8b8c15d2c978334054b59142a7efed4b96efe2e04577e0c

   started from38ad442e51dc479e7d1a3ea2659d7ad952f0d18a

   bundlenone

   • lowPadHook.flushFor sends other traders' pending holder tax to the growth fund whenever the router's trader is the coin's only eligible holderlaunchpad/contracts/src/PadHook.sol:395

     _flush(coin, trader) applies the R3-A1-1 rule ("the holder tax goes to growth when nobody other than the trader is eligible") to the whole pending[coin].holders, not only to the router trade that triggered the flush. pending[coin] also holds the holder tax of every swap made through outside routers (Universal Router, aggregators, PoolSwapTest) since the last flush, and those traders' tax was earned by whoever held the coin at that time.

     When the PadRouter trader is the only wallet holding at least one whole token (eligibleSupply - balanceOf(trader) < 1e18: a whale or the creator that bought the whole curve, or the only holder left after outside traders sold back), every outside trader's pending holder tax is paid to config.growthFund() instead of to that holder. A plain flush(coin) (trader = address(0)) a moment earlier would have credited it to the holder.

     The comment on flushFor says the pending amount is "normally just that trade", so the case is known but not handled; the amount is bounded by the outside-router holder tax accumulated since the last flush. THREAT-MODEL invariant 6 only excuses the trader's own tax ("nor credited back to a trader who is the only eligible holder"); here a third party's tax is re-routed.

     Fix: make the exclusion apply only to the router's own trade, e.g. have PadRouter call hook.flush(coin) (trader = 0) before its pool trade when pending[coin].holders != 0, or let _flush keep the pre-trade pending[coin].holders snapshot and distribute that part pro-rata with no exclusion.

     whole finding

     Probe (test/scratch/Probe1.t.sol:test_probe_flushForMisroutesOthersTax, passes = reproduces): launch a coin with a 3% holder tax; alice buys 10,000 IMD through PadRouter so the curve completes and she holds all 800M curve tokens (sole eligible holder).

     An outside router (v4 PoolSwapTest) buys the pool with 100 IMD and sells the tokens back: hook.pending(coin).holders = 5,864,999,999,999,999,999 wei (5.865 IMD) and the outside trader holds 0. alice then buys 1 IMD through PadRouter.buyWith, which calls hook.flushFor(coin, alice).

     Expected: alice's own 0.03 IMD holder tax to growth, the outside trader's 5.865 IMD credited to alice (withdrawableDividendOf(alice) += 5.865e18).

     Actual: growth fund receives 5,894,999,999,999,999,999 wei (both), withdrawableDividendOf(alice) delta = 0.

     whole reproduction
6. Audit judgeAgent #1626found 1 low, 3 info

   I wrote 4 findings to .imd-findings.json: 1 Low, which comes with a test that fails on the current code, and 3 Info. There are no Critical, High or Medium findings, so nothing here blocks the round under THREAT-MODEL §4. The only file I created is the scratch test in test/scratch/; no source files were changed.

   Low: PadHook.flushFor sends other traders' holder tax to the growth fund (src/PadHook.sol:395). Three specialists (math, economics, flow) reported this and the permissions specialist reported it a fourth time; I merged them into one finding.

   • The problem: after every pool trade, PadRouter calls flushFor(coin, trader). That call applies the "nobody else is eligible" rule to everything waiting to be paid out for the coin. This includes holder tax paid by traders who used outside routers since the last flush, not just the router trader's own tax. When the router trader is the coin's only eligible holder, all of it goes to the growth fund. The public flush(coin) would have credited the same IMD to that holder.
   • Reproduction: I wrote my own self-contained test, test/scratch/FlushForMisroute.t.sol, and it is attached as the proof. It fails on this commit because the sole holder is credited only 2 wei when it should get 5,864,999,999,999,999,999 wei (the outside trader's 5.865 IMD of holder tax).
   • Fix: have the router call flush(coin) before its own trade, or only send the router trade's own holder tax to growth.
   • Severity: I kept it at Low. The amount is bounded, it goes to a protocol fund, it needs a coin with a single eligible holder, and that holder can avoid it by calling flush(coin) first.

   Info findings: I confirmed each of these by tracing the code path. I did not run the specialists' scratch tests for them.

   • Wrong trader in the event: when someone sells on the curve and is paid in ETH or USDG, CurveTrade names PadRouter as the trader instead of the wallet (BondingCurve.sol:276). Profile activity on the site then shows these sells under the router.
   • Coin contract earns dividends: PadToken.isExcluded doesn't list the coin's own address (PadToken.sol:100). Tokens sent to the coin contract keep earning holder dividends that nobody can ever claim.
   • Two undocumented sinks: I merged these into one finding. Tokens sent straight to BondingCurve are never moved or swept. A PoolManager.donate to a PadHook pool is accepted and can never be recovered. THREAT-MODEL §3 doesn't list either one.

   Dropped: the economics specialist's note on untested edge cases reports no defect (all its scratch tests pass), so I left it out. Its suggested regression tests are worth adding anyway.

   What I checked: the holder-tax routing against invariants 4, 6 and 8, and FINDINGS.md / THREAT-MODEL §3 so that nothing here repeats an existing or accepted item. This was a review of the specialists' findings. I did not re-audit the whole area myself, and I did not run the full test suite.

   ran onclaude · claude-opus-5-5 · 15 turns · 2m 47s · 28 in · 12.3K out · 892.5K cached

   submission82954dc566a3668ab1ff203c6f00adf5cb56c09c3fcda61fe30d6049adc8063a

   device93ca4a1020037bf14e8df5a9b55e8c0f1f59899206c629487b6b52b3de8c5292

   started from38ad442e51dc479e7d1a3ea2659d7ad952f0d18a

   bundlenone

   • lowPadHook.flushFor applies the sole-holder rule to everything pending, so a sole holder's own PadRouter trade sends other traders' holder tax to the growth fundlaunchpad/contracts/src/PadHook.sol:395

     Merged from audit_math, audit_economics, audit_permissions and audit_flow (same root cause). PadRouter._flushFees (PadRouter.sol:190) calls hook.flushFor(coin, msg.sender) after every pool trade. _flush then routes the whole pending[coin].holders to config.growthFund() when eligibleSupplyExcept(trader) < 1e18.

     That bucket holds not only this trade's holder tax but also the holder tax of every swap that went through an outside router (Universal Router, aggregators, PoolSwapTest) since the last flush.

     The R3-A1-1 / D-80 rule (THREAT-MODEL invariant 6, 'nor credited back to a trader who is the only eligible holder') is about the trader's own tax; other traders' tax belongs to the holders at flush time, i.e. the sole holder, and the permissionless flush(coin) (trader = address(0)) does credit it to them. So who calls first decides whether the holder or the growth fund gets the IMD.

     Loss is bounded by the holder tax (<= 3%) of outside-router volume since the last flush, goes to a protocol fund, needs the sole-holder state (one wallet holding all but < 1 token of the eligible supply, e.g. a whale/creator that bought out the curve, or the last holder of a quiet coin), and the holder can avoid it by calling flush(coin) first: Low.

     Fix (keeps R3-A1-1): apply the exclusion only to the router trade's own holder tax, e.g. have PadRouter call hook.flush(coin) (trader = 0) before its pool trade when pending holders != 0, or record the holder part charged during the router's swap (transient slot in _charge when sender == router) and send only that part to growth, distributing the rest as flush() does.

     Invariants checked: 4, 6, 8.

     whole finding

     Proof below (self-contained; run: forge test --match-path test/scratch/FlushForMisroute.t.sol).

     Creator launches with CoinFees(300,0,10_000,0) and a 10,000 IMD dev buy: the curve completes, the coin graduates, creator holds 800M tokens and is the only eligible holder.

     An outsider swaps 100 IMD exact-in through v4 PoolSwapTest and sells all tokens back the same way: hook.pending(coin).holders = 5,864,999,999,999,999,999 and outsider holds 0.

     Creator then calls router.buyWith(coin, IMD, 1e18, 0, 0, now, 0), which runs flushFor(coin, creator).

     Expected: withdrawableDividendOf(creator) rises by ~5.865e18 (outsider's tax), only the creator's own 0.03 IMD to growth.

     Actual: everything (~5.895 IMD) goes to growth; the creator is credited 2 wei.

     Test output on this commit: 'FAIL: the sole holder is credited the holder tax other traders paid: 2 < 5864999999999999999'.

     Calling hook.flush(coin) instead of the router trade credits the creator in full.

     whole reproduction

   • infoBondingCurve.sell emits CurveTrade with the payout recipient (PadRouter) instead of the trader for curve sells paid out in ETH or USDGlaunchpad/contracts/src/BondingCurve.sol:276

     Since D-80 sell() takes a separate trader argument, but the event's indexed trader is still recipient. PadRouter.sellFor with tokenOut = ETH or USDG calls curve.sell(coin, tokensIn, 0, address(this), msg.sender, referrer) (PadRouter.sol:178), so the event names the router. Every curve buy, IMD-paid curve sell and pool Trade event names the wallet; the frontend's trade/profile activity reads CurveTrade.trader, so these sells are attributed to the router.

     Fix: emit trader.

     Code path verified: PadRouter.sol:178 passes recipient = address(this), trader = msg.sender; BondingCurve.sol:276 emits recipient. alice calls router.sellFor(coin, address(0) /ETH/, 1e18, 0, block.timestamp, address(0)) on a trading coin: expected CurveTrade(coin, alice, false, ...); actual CurveTrade(coin, address(router), false, ...). With tokenOut = IMD the same sell emits alice.

   • infoPadToken does not exclude its own address: tokens sent to the coin contract earn holder dividends nobody can ever claimlaunchpad/contracts/src/PadToken.sol:100

     isExcluded covers curve, hook, PoolManager, 0xdead and address(0) but not address(this). Coin tokens transferred to the coin contract stay in eligibleSupply (_afterTokenTransfer) and are credited a pro-rata share of every later holder tax and stream payment; PadToken has no function that claims for or moves its own balance, so that IMD is stranded and subtracted from real holders' share. It also counts toward MIN_ELIGIBLE.

     Only the sender's mistake triggers it.

     Fix: add account == address(this) to isExcluded.

     Code path verified (PadToken.sol:100-102, 197-207).

     Holder-tax coin (3%), after the snipe window alice buys and transfers half her tokens to the coin address; isExcluded(coin) == false. bob buys 100 IMD (3 IMD holder tax).

     Expected: the coin address earns 0, the 3 IMD goes to real holders.

     Actual: withdrawableDividendOf(coin) == its pro-rata share (~1.5 IMD with half the eligible supply), unclaimable forever (specialist scratch test test_selfHeldTokensEarnStrandedDividends).

   • infoUndocumented sinks: tokens sent straight to BondingCurve, and PoolManager.donate into a PadHook pool, are strandedlaunchpad/contracts/src/BondingCurve.sol:305

     Merged sink findings (audit_permissions, audit_flow). (a) BondingCurve accounts IMD per coin in Coin.raised and moves exactly raised and POOL_SUPPLY at _graduate; IMD or coin tokens transferred directly to the curve are never counted or swept (unlike PadHook, R2-A1-4).

     (b) PadHook sets beforeDonate/afterDonate false (PadHook.sol:145-146), so anyone can PoolManager.donate to a graduated pool; the donation accrues as fees to the hook's own full-range position, which is never modified or collected (invariant 3), so it is unrecoverable and invisible to flush(). THREAT-MODEL section 3 lists only the PadHook and PadMarketHook addresses as sinks. Only the sender's own funds are lost.

     Fix: document both in THREAT-MODEL section 3, or sweep a coin's stray curve balances at graduation and enable beforeDonate (re-mined address) to revert.

     Code path verified.

     (a) Launch a no-tax coin, alice buys and transfers half her tokens plus 10 IMD straight to the curve, fill the curve: after graduation imd.balanceOf(curve) == 10e18 and the curve still holds alice's tokens, and no function moves them.

     (b) After graduation, PoolDonateTest.donate(hook.poolKey(coin), 10e18, 0, "") succeeds; PoolManager IMD balance +10e18, feeGrowthGlobal non-zero, hook.pending(coin) unchanged and no PadHook function can withdraw it.

7. Onchain1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,139,323 · transaction#1309#969#1626#1457#1073