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

3 medium11 low7 info

• 1.mediumThreat model gap: a leaked operating key drains LPDeepening and every BuybackAndBurn by sandwiching its own run(0); not covered by the README's 'Known risks'src/LPDeepening.sol:97

          if (ethGot < minEthOut || ethGot == 0) revert TooLittleOut();

  Merged from audit_permissions #2, audit_economics #1 and item (3) of audit_flow's threat model.

  Reproduced by reading: LPDeepening.run(minEthOut) and BuybackAndBurn.run(minCoinOut) (src/BuybackAndBurn.sol:88) take their only price floor from the caller; keeper is immutable in both (LPDeepening.sol:46, BuybackAndBurn.sol:34) and there is no pause or rotation. Each run spends the module's whole balance (deepening: half of all accrued JIG is sold; buyback: the coin's entire slice).

  README line 139 accepted 'the keeper can sandwich its own runs' as Low because 'the keeper is the platform'. On the mainnet plan the keeper is the hot operating wallet and the platform is a Safe, so that premise no longer holds: whoever holds LAUNCH_PK is not the platform, and keeper.mjs's 3% slippage rule is irrelevant because an attacker calls run(0) from their own script.

  Robinhood's first-come sequencer lets one sender order three transactions back to back, so no public mempool is needed. The README 'Known risks' section lists only the HolderPayouts/AirdropClaim root path for this key; this path is of the same shape (a leaked hot key takes protocol JIG) and is not listed, so the founders are deciding on an incomplete picture.

  Fix, smallest first: (a) list it in 'Known risks' next to the root item and state that the keeper role and the claim-owner role should at least live in different processes/keys; (b) a contract floor the module can check itself, e.g. CreatorFeeHook already runs afterSwap on every swap and can keep a short time-weighted coin/JIG observation per pool, and run() requires out >= quoteAtObservedPrice(amount) * (10_000 - MAX_IMPACT_BPS) / 10_000 (MAX_IMPACT_BPS around 500 keeps the keeper's 3% inside it), with the JIG/ETH side using an observation stored by LPDeepening itself; or (c) make keeper rotatable by the platform Safe so a leaked key can be cut off.

  (b) and (c) are contract changes and need re-test; (a) is a doc change for launch day.

  whole finding

  State: BuybackAndBurn for coin C holds 10,000 JIG (claimable + balance); attacker A holds LAUNCH_PK and a second wallet.

  On Robinhood Chain: tx1 (second wallet) buys C with JIG on C's pool, moving the price up several-fold inside the seeded range; tx2 (hot wallet) BuybackAndBurn.run(0): hook.claim(), swaps all 10,000 JIG for C at the inflated price, coinBurned < 0 is false so the check at line 88 passes and the tiny coinBurned is burned; tx3 (second wallet) sells C back for JIG.

  Same shape on the JIG/ETH pool around LPDeepening.run(0): sell JIG first, run(0) sells half the module's JIG at the depressed price (ethGot < 0 is false at line 97) and mints the position at that spot, buy back.

  Expected (README 'Known risks'): a leaked key can at most declare Merkle roots for itself.

  Actual: it also converts every module's accrued JIG into the attacker's profit, bounded only by pool depth and the 1.5-10% hook fees.

  whole reproduction

• 2.mediumA creator can pick the moment of a holder-payout snapshot by switching cadence minutes before a launch-aligned window edgeoffchain/coinSettings.mjs:124

    const from = Math.max(w.start, now); // first seen mid-window: a random moment in what is left of it

  Reproduced by reading (audit_permissions #1). keeper.mjs:265 sets prev = j.round?.cadence === s.cadence ? j.round : null, so a cadence change discards the stored random pick, and roundSchedule() then draws a new moment inside what is left of the CURRENT window: at = from + rand * (w.end - from) with from = now. Windows are aligned to launchedAt (windowOf), which is public (CreatorFeeHook.pools(id).launchedAt), and every daily boundary is also a weekly boundary.

  A creator who signs {cadence:'daily'} (nonce+1, allowed after launch by coinSettings.set) a few minutes before a daily boundary gets at within those few minutes, and the keeper (5-minute passes) declares the round on its next pass. The only brake, keeper.mjs:270 (nowS - lastAt >= CADENCES[new]/2, 12 h for daily), is observable from RoundDeclared events.

  The file header's goal ('nobody can buy just before a known payout snapshot') is defeated for the creator: they buy coin before the moment they chose, are counted pro rata in the snapshot (payouts.holders() at the safe block), and sell after RoundDeclared. Holders lose the share the creator's temporary float takes.

  Fix: after a cadence change (prev null while a round has already happened) do not schedule inside the remainder of the launch-aligned window; schedule at = max(now, lastAt + P_new/2) + rand * P_new/2, or compute windows from the last round time instead of launchedAt, keeping the half-period brake.

  whole finding

  State: coin launched at L, flywheel SnapshotForwarder, cadence weekly, last round declared > 12 h ago, HolderPayouts.balance[coin] = R > 0.

  Steps: (1) at t = L + 7d - 240 s the creator POSTs settings {cadence:'daily'} with a valid signature (coinSettings.set accepts: cadence may change after launch).

  (2) The creator buys a large amount of coin.

  (3) Next keeper pass (<= 5 min): prev = null (cadence differs), windowOf(L,'daily',t) gives end = L + 7d, from = t, at in [t, L + 7d]; the brake passes (lastAt older than 12 h); within one or two passes nowS >= at, prepareRound snapshots balances with the creator holding most of the float, declare() goes on chain.

  (4) The creator sells after RoundDeclared and claims their share.

  Expected: the snapshot moment is unpredictable to every holder including the creator.

  Actual: the creator knows it to within one keeper pass.

  whole reproduction

• 3.mediumlaunch.mjs: a collection deploy whose hash was persisted but never mined pins the build in 'failed' forever (no redeploy path)offchain/launch.mjs:190

        catch (e) { if (!e.reverted) throw e; b = setStage(id, 'deploying', { deployTx: null, revertedDeployTx: b.launch.deployTx }); }

  Reproduced by reading (audit_flow #1). createCollection() persists the hash through onSent before sender.mjs broadcasts it (launch.mjs:73, sender.mjs:38-39). If sendRawTransaction throws after signing (HTTP 429/timeout from the RPC, a sequencer rejection, a nonce collision with a send made outside the lock) or the transaction is later dropped, the hash is on disk and no transaction will ever exist.

  On every retry runLaunch() calls collectionFromTx(deployTx), which waits 10 minutes for a receipt and throws viem's WaitForTransactionReceiptTimeoutError, which has no reverted flag, so line 190 rethrows without clearing deployTx; startLaunch() then keeps prev.deployTx (deployed = true, line 157) on the next retry. Only an on-chain revert clears the hash.

  The keeper (keeper.mjs:231-245) already resolves the same situation from the account nonce and getTransaction and declares a signed-but-never-broadcast send dead after 30 minutes; the launch path does not. The build can never be redeployed from the UI; the way out is editing the build JSON by hand on a mainnet launch day.

  Fix: persist the nonce with the hash in onSent; in the timeout branch read getTransaction(hash) and getTransactionCount(account,'latest'), and when the node does not know the transaction and the nonce is unused (or used by another hash with no receipt for this one after a few checks) clear deployTx exactly like the reverted case; also clear deployTx when sendRawTransaction itself throws, since the node never accepted it.

  whole finding

  State: the RPC rejects or drops the raw transaction (rate limit, network error, sequencer rejection) when a build is launched.

  Steps: 1) startLaunch(build) -> runLaunch -> createCollection; sender.send signs, calls onHash -> setStage(id,'deploying',{deployTx: h}); sendRawTransaction throws.

  2. runLaunch catch -> stage 'failed', deployTx = h kept.

  3. Retry startLaunch(build): keep = {deployTx: h}, deployed = true.

  4. runLaunch -> collectionFromTx(h) waits 10 min -> throws a timeout error without .reverted -> line 190 rethrows -> stage 'failed' again with deployTx still h.

  Expected: the retry notices the hash never landed (nonce unused, tx unknown) and redeploys.

  Actual: every retry fails after a 10-minute wait, forever; the build is stuck until someone edits the JSON.

  whole reproduction

• 4.lowKeeper drip job counts JIG already distributed and waiting for holder claims as pullable, so it sends a no-op HolderDrip.pull() every 4-8 h per coin with unclaimed JIGoffchain/keeper.mjs:180

          const amount = kind === 'drip' ? owed + held : owed;

  Merged from audit_flow #2 and audit_economics #3; reproduced by reading. held = jig.balanceOf(module); a HolderDrip keeps every distributed JIG in its own balance until holders claim (HolderDrip.sol claim() pays from balance; undistributed() = balance - (accounted - paidOut)).

  So held is dominated by JIG an earlier pull already spread, and worth(amount) stays true once a coin's drip holds >= KEEPER_MIN_USD ($5) of unclaimed JIG, whatever arrived since. tick() simulates (pull() returns 0 cleanly after hook.claim()), estimates gas and sends; each such send burns gas, counts against maxPerJobPerDay (3) and the shared daily cap, and is ledgered as success.

  The comment distrusts the module's undistributed(); a trusted equivalent exists from reads the keeper already does: HolderDrip.accounted() and paidOut() are plain storage views.

  Fix: for kind 'drip', amount = owed + max(0, held - (accounted - paidOut)); or require owed > 0 and persist held after each successful pull, counting only its growth.

  whole finding

  State: coin C with HolderDrip D; D has pulled once and holds 100 JIG (> $5) that no holder has claimed; hook.claimable(D) = 0; no new fees. plan(): owed = 0, held = 100e18, amount = 100e18, ready = true. tick(): pub.call passes, estimateGas ~60k, D.pull() is sent: hook.claim() returns 0, undistributed() = 0, pull returns 0; onSuccess sets nextAt 4-8 h ahead.

  Repeats at every nextAt (up to 3 per day per coin) until holders claim.

  Expected: a drip job is ready only when undistributed JIG is worth >= $5.

  Actual: a pointless transaction every 4-8 hours per such coin, consuming the per-coin and daily allowances.

  whole reproduction

• 5.lowreveal.mjs: when the mint is already closed the drand trigger time is the server clock, so the operator can choose among published rounds and nobody can check the round from chain dataoffchain/reveal.mjs:98

        let pausedUnix = Math.floor(Date.now() / 1000);

  Merged from audit_flow #3, audit_permissions #6 and audit_economics #4; reproduced by reading. The seed is quicknet round roundAfter(trigger.unix) (randomness.mjs:63) and seedFor() fetches that round whether or not it was already published at trigger time. When run() has to pause the mint, trigger.unix is anchored to the pause transaction's block timestamp (checkable on chain).

  When the mint is already closed (sold out, or paused earlier by the owner), endMint() returns null, pausedUnix is Date.now() on the server, and trigger.unix = max(r.trigger.unix, pausedUnix) where r.trigger.unix is also the server clock at trigger().

  Nothing on chain anchors that number (setRevealSeed records only the seed), so the operator, or anyone on the server (the box that already holds the hot key), can edit build.launch.reveal.trigger.unix or the clock to any past second and thereby choose any already-published round, i.e. choose the permutation; the stored reveal.json stays self-consistent. Even a few seconds of clock lag lets the person pressing the owner button see the candidate seed before committing.

  The brief asks 'can the operator choose the seed': for sold-out and already-paused reveals, yes.

  Fix: never use the server clock as the anchor. For a sold-out collection use the timestamp of the block that minted token id == maxSupply (public Transfer log); for an earlier manual pause use the pause transaction's block; store the anchoring block number in reveal.json so anyone can recompute the round; and refuse to proceed if fetchRound(roundAfter(anchor)) is already published at the moment the anchor is first recorded whenever the anchor is 'now'.

  whole finding

  State: collection with maxSupply 100 sold out at block B (timestamp T). tick() would trigger about T+60 (round roundAfter(T+60)).

  Instead the operator stops the server for an hour, computes permutation(n, randomness(r)) for every published round r since T, picks r* that gives token 7 (which they hold) the one-of-one, edits the build JSON so launch.reveal = { state:'failed', attempts:0, trigger:{ reason:'sold out', unix: genesis + (r*-2)3 + 1 }, mintEnded:{ soldOut:true, pausedUnix: same } } and restarts. tick() -> trigger(id,'retry') keeps r.trigger; run() skips endMint (mintEnded set); seedFor(trigger.unix) returns round r with a valid BLS signature; the permutation is pinned and setRevealSeed(randomness(r*)) is sent.

  Expected: the round is fixed by chain state so the operator has no choice.

  Actual: any published round since sell-out can be presented as 'the first round after the trigger' and reveal.json verifies for all of them.

  whole reproduction

• 6.lowswap.mjs quotes with tx.origin = 0x0, so an allowlisted wallet is quoted the 60% outsider fee during the JIG window even with a valid proof, and its minOut is set 60% too lowoffchain/swap.mjs:89

    const res = await pub.call({ to: v.quoter, data });

  Reproduced by reading (audit_flow #4). quoteGross() runs the V4Quoter through eth_call without account, so the node executes with from = tx.origin = address(0).

  JIGLaunchHook.beforeSwap checks the allowlist leaf of tx.origin (src/JIGLaunchHook.sol:147: keccak256(bytes.concat(keccak256(abi.encode(tx.origin))))), so during the 5-minute window the proof in hookData never matches and the quote assumes OUTSIDER_FEE (60%). quote() then derives netOut and minOut from that gross, so the site shows ~40% of what the user's real transaction (tx.origin = the allowlisted EOA) delivers, and the minOut it signs is ~60% below the real output, which is the whole protection the swap has (amountOutMinimum in the swap action is 0; only TAKE_ALL enforces minOut).

  This happens exactly in the minutes the allowlist exists for, when the site is the only swap path.

  Fix: pass account (the user's address, or the operating wallet for keeper quotes) to pub.call so eth_call sets tx.origin to it.

  whole finding

  State: JIG window open (block.timestamp < windowEnd), wallet W on the allowlist with proof P.

  Call quote({from: ETH, to: JIG, amountIn: 1e18, account: W, hookData: P}). quoteGross encodes quoteExactInputSingle with hookData P and calls pub.call({to: quoter, data}) with no account; in the simulated swap tx.origin == address(0); leaf(0x0) is not in the tree -> fee = 600000 -> grossOut ~0.4x the normal-fee output; minOut = net * 0.99 of that.

  The user then sends tx.data from the quote; on chain tx.origin == W, fee = NORMAL_FEE (15000), output ~2.46x the quoted grossOut.

  Expected: the quote equals what the transaction delivers up to slippage.

  Actual: the quote understates by ~60% and the signed minimum protects only ~40% of the real output.

  whole reproduction

• 7.lowCollectionLauncher offers ownership to an immutable operator with no re-offer path, so a key rotation or lost build record between create() and acceptOwnership() strands the collection's owner functiosrc/CollectionLauncher.sol:69

          ILoomCollectionOwner(collection).transferOwnership(operator);

  Merged from audit_flow #7 and audit_permissions #4; reproduced by reading. LoomCollection is Ownable2StepUpgradeable (reference/LoomCollection.sol:105), so after create() the clone's owner is the launcher and pendingOwner is operator until acceptOwnership() is sent from the operator key (launch.mjs configureClone, line 115, on the next step).

  The launcher has no function to call anything on a collection it still owns, no way to re-target the pending owner, and operator is immutable.

  If the operating key is rotated or lost between the two steps (the documented response to a hot-key leak, or a crash on launch day followed by a new LAUNCH_PK), or the server loses the build record so configureClone never runs, pause/unpause, setRevealSeed, setBaseURI, freezeMetadata and reserveMint on that collection are unreachable forever: a reveal-later collection stays on its placeholder for good while mints keep paying the creator.

  Rotating the operating wallet at any time also requires deploying a new CollectionLauncher and updating RH_LAUNCHER, which the runbook should say. Otherwise the launcher is safe: create() is operator-only and stateless, it only calls the immutable Loom factory and the clone that factory returns (never a caller-supplied collection), msg.value is forwarded unchanged and it holds nothing.

  Fix: add reoffer(address collection, address to) callable by the operator (or by a platform admin, the Safe) that calls transferOwnership on a clone the launcher still owns, and/or make the operator settable by the Safe; keep create() operator-only.

  whole finding

  State: launcher deployed with operator = hot wallet H. Steps:

  1. H calls create(c, provenance, uri, true): owner = launcher, pendingOwner = H.
  2. Before configureClone runs, LAUNCH_PK is rotated to H2 (a new launcher is deployed for H2).
  3. H2 calls acceptOwnership() on the clone: reverts OwnableUnauthorizedAccount(H2); the launcher exposes no transferOwnership passthrough. Expected: the platform can always reach the clone's owner functions. Actual: the collection can never be paused, revealed or frozen by anyone; mint() keeps working.

  whole reproduction

• 8.lowHolderDrip's first pull excludes every token minted between the module's deployment and the first fee, although those tokens predate all feessrc/HolderDrip.sol:72

          lastSupply = collection.totalSupply();

  Reproduced by reading (audit_permissions #3). The pre-audit fix records lastSupply in the constructor so the first pull does not pay tokens minted after fees accrued. But the module is deployed by the back end BEFORE CoinFactory.launch (README: 'deployed by the back end before launch and passed as flywheel') and the collection keeps minting between deployment and launch (coinSettings' airdrop mode 'soldout' exists because coins launch before sell-out).

  Fees only start with the pool. So tokens minted after the drip's deployment but before the first fee are excluded from the first pull even though they existed before any JIG arrived, and the keeper never makes a zero pull (keeper.mjs:100 'never a zero pull'), so nothing records the supply at launch.

  The error is bounded to the first pull's amount (one 4-8 h interval at launch, the highest-volume moment). pull() with amount 0 still sets lastSupply = current before returning, so the fix is operational: have the launch flow call pull() once right after CoinFactory.launch (or let the keeper make one zero pull when it first discovers a drip), which records the launch supply at no accounting cost.

  whole finding

  State: collection has 100 tokens; the back end deploys HolderDrip (lastSupply = 100).

  Over the next hours the collection mints to 1,000; then CoinFactory.launch(collection, flywheel = drip); traders pay fees; the hook credits the drip 40 JIG; the keeper pulls.

  Expected: 40 JIG spread over the 1,000 tokens that all existed before the first fee (0.04 each).

  Actual: pull() spreads over supply = lastSupply = 100: owed(1..100) = 0.4 JIG each, owed(101..1000) = 0. test/HolderDripFirstPull.t.sol covers only mints after the fee.

  whole reproduction

• 9.lowconfigureClone skips setRevealSeed silently when a different seed is already on chain, so a frozen collection can carry metadata ordered by a seed the contract does not recordoffchain/launch.mjs:126

    if (revealSeed && !(await read('revealSeedSet'))) await send('setRevealSeed', [revealSeed]);

  Reproduced by reading (audit_permissions #5). The provenance step (lines 119-120) reads the on-chain value and throws on a mismatch, but the reveal-seed step only checks the revealSeedSet flag and never compares revealSeed(); cloneAbi does not even include the revealSeed() view. LoomCollection.setRevealSeed is once-only.

  If any seed is already set (an owner call made by hand, or an earlier reveal attempt whose build record was lost or edited), the reveal continues: the permutation and metadata are pinned for the drand seed, the base URI is set and frozen, while the contract commits to another seed. Anyone checking perm = fisherYates(N, revealSeed) against the pinned metadata then finds a mismatch and the provable-fairness claim fails, irreversibly once frozen.

  Fix: read revealSeed() and, when revealSeedSet is true and it differs from the requested seed, throw, mirroring the provenance branch.

  whole finding

  State: reveal-later collection owned by the operating wallet, reveal state 'waiting'.

  Steps: (1) the owner key calls setRevealSeed(0xAAAA...) directly (no record on the server).

  (2) The timer fires, reveal.mjs computes seedInfo.seed = drand randomness S, pins metadata for perm(N, S), calls configureClone({revealSeed: S, baseURI, freeze: true}).

  (3) revealSeedSet is true so the seed send is skipped; setBaseURI and freezeMetadata go through.

  Expected: the reveal refuses, as it does for a differing provenance.

  Actual: the collection is frozen with on-chain revealSeed = 0xAAAA... and metadata ordered by S.

  whole reproduction

• 10.lowHolderDrip._foldBurns is unbounded: a batch of tokens burned after a pull is folded in one later pull, which can push pull() past the keeper's gas cap (about 320 burns) or a block limit (thousands)src/HolderDrip.sol:162

      function _foldBurns(uint256 supply) internal {

  Reproduced by reading (audit_math #1; the specialist's gas numbers were recomputed from opcode costs here, the project's lib/ is not vendored so no test was run). markBurned() of a token with id > lastSupply appends to _burnedAbove; the first pull() whose spread supply covers those ids folds every one of them in a single loop (cold SLOAD, burnedCount SSTORE, swap-and-pop SSTOREs: roughly 7,000 gas net per entry after refunds) with no per-call bound, unlike CreatorFeeHook.recycle which caps folding per call.

  The keeper refuses any send whose estimate x1.3 exceeds KEEPER_GAS_CAP (3,000,000), i.e. estimates above about 2.3M, so from roughly 320 burned-after-pull tokens the drip job backs off every pass ('needs N gas, over the cap') until someone calls pull() by hand with a higher limit (pull is permissionless, so this is recoverable); from several thousand such tokens pull() exceeds the block gas limit and is bricked permanently, because every later pull uses supply = lastSupply >= those ids and must fold them all first.

  While pull() cannot run the drip's share stays as claimable in the hook and after RECYCLE_AFTER anyone can recycle() it to the pot, so the collection's NFT holders lose their flywheel JIG. The cost to an attacker is owning that many NFTs of the collection and destroying them (markBurned requires ownerOf == dEaD; LoomCollection has no burn), so this is expensive griefing, hence Low.

  Fix: bound the fold like recycle does (fold at most MAX_FOLD entries per pull, leaving the rest for the next pull), or key burns by the supply bucket they become eligible at so pull() does O(1) work.

  whole finding

  State: HolderDrip deployed on a collection with totalSupply 10 (lastSupply = 10).

  Steps: (1) mint tokens 11..310, send each to 0xdEaD and call markBurned(id) for each (all > lastSupply, so each is pushed to _burnedAbove); (2) send 1e18 JIG to the drip and pull() (spreads over 10, lastSupply becomes 310, nothing folded); (3) send 1e18 JIG and pull() again: _foldBurns(310) iterates all 300 entries.

  Expected: a routine keeper transaction well under KEEPER_GAS_CAP.

  Actual: about 2.2M gas (x1.3 margin = 2.86M; a few more burns put the estimate over the 3M cap and the keeper refuses the job every pass).

  With thousands of burned tokens the pull no longer fits a block and no pull() can ever succeed for that drip.

  whole reproduction

• 11.lowKeeper marks a creator's whole round window as done from one spot JIG/ETH price read, so a transient dip under minRoundUsd skips the holders' payout for the entire windowoffchain/keeper.mjs:274

          if (s.minRoundUsd > 0 && job.usd < s.minRoundUsd) { j.round.doneIndex = sch.index; j.lastResult = `window ${sch.index} skipped: round worth $${(job.usd ?? 0).toFixed(2)}, under the creator's $${s.minRoundUsd}`; writeState(st); continue; }

  Reproduced by reading (audit_math #2). job.usd = Number(balance)/1e18 x jigPrice().jigUsd, where jigUsd comes from the JIG/ETH pool's spot sqrtPrice divided into ETH/USD (jig.mjs jigPrice) with no averaging or sanity band.

  When the creator set minRoundUsd (up to $1,000) and the single read comes in below it, the keeper writes j.round.doneIndex = sch.index, which roundSchedule() treats as 'this window's round is done' (at: null) for the rest of the window, so the round is not retried even if the price recovers a minute later; the JIG waits a full cadence period (weekly by default).

  JIG launches at about $4k FDV on a pool whose depth is the launch seed, so the spot price is cheap to move for a few blocks around a keeper pass, and the pass cadence is published. Nothing is lost, only delayed, hence Low.

  Fix: do not finalise doneIndex on a price-based skip; back off and re-evaluate on later passes until the window ends, and compare against a smoothed price (median of recent reads) with the same 'unknown price waits' rule already applied to a null price.

  whole finding

  State: a coin whose SnapshotForwarder has moved 300 JIG into HolderPayouts.balance[coin]; creator settings minRoundUsd = 1000, cadence weekly; true JIG price $3.60 (round worth $1,080); sch.at has passed.

  Steps: an outsider sells JIG into the JIG/ETH pool so the spot reads $3.20 (round now $960) during the keeper's next tick(), then buys back.

  Expected: the round is declared once the price is back above the minimum, or at least retried later in the window.

  Actual: line 274 sets j.round.doneIndex = sch.index; every later pass in that window gets at: null from roundSchedule() and the holders' 300 JIG waits for the next weekly window at the earliest.

  whole reproduction

• 12.lowisOurCollection accepts any EIP-1167 clone of the Loom implementation, not only collections the factory made, so a self-deployed clone passes the keeper and vanity gatesoffchain/launch.mjs:345

    const ours = (code ?? '').toLowerCase() === `0x363d3d373d3d3d363d73${impl.slice(2).toLowerCase()}5af43d82803e903d91602b57fd5bf3`;

  Reproduced by reading (audit_economics #2). The gate compares runtime bytecode with the minimal-proxy template for factory.implementation(). LoomCollection.initialize() is a public initializer on a fresh clone (reference/LoomCollection.sol:85-94, with its own @dev warning), so anyone can deploy a minimal proxy to the same implementation in their own transaction and initialise it with themselves as creator and owner, any maxSupply, any mintPriceWei and no CREATE_FEE.

  Such a clone is byte-identical to a factory clone and passes isOurCollection, so (a) jig.mjs:186 hands it to vanity.request, and ten such clones with ten requests fill MAX_QUEUE (10) so real creators get 'busy' until each 15-minute grind completes (the queue dedupes per collection, which is why ten clones are needed); (b) keeper.plan() services the coin the attacker launches on it (launch fee only), spending up to maxPerJobPerDay sends per job on it.

  Damage is bounded by the existing caps (MAX_NFTS, MAX_HOLDERS, gas cap, per-job cap), so this is a gate that does not do what its comment and the README say rather than a fund loss.

  Fix: decide 'ours' from the factory, not from bytecode: look up the factory's CollectionCreated log for the address (topic 1 = collection; launch.mjs already has the event ABI) once and cache it, keeping the bytecode check as a second condition.

  whole finding

  On Sepolia: impl = factory.implementation().

  Attacker deploys the standard EIP-1167 creation code 0x3d602d80600a3d3981f3363d3d373d3d3d363d735af43d82803e903d91602b57fd5bf3 and calls initialize('X','X',1000000,0,1000000,attacker,0,attacker) on it in the same transaction.

  Expected: isOurCollection(chainId, clone) === false (README: only collections our NFT factory made are served).

  Actual: getCode(clone) equals the template exactly, isOurCollection returns true and caches it; vanity.request(clone,'A','A') is queued; ten clones return { state: 'busy' } to the next genuine creator; CoinFactory.launch for the clone succeeds (attacker is creator()) and keeper.plan() lists buyback/drip/airdrop/round jobs for it.

  whole reproduction

• 13.lowAirdrop snapshot failures back off exponentially even as the 7-day unset window closes, so five consecutive failures on a late ('soldout' or 'days 6') airdrop sweep the coin's 5% to the potoffchain/keeper.mjs:191

  const backoff = (j) => { j.failures = (j.failures ?? 0) + 1; j.nextAt = Date.now() + 30 * 60_000 * 2 ** Math.min(j.failures, 5); };

  Reproduced by reading (audit_economics #5). prepareAirdrop() throws on any multicall failure by design (payouts.mjs:119: a partial snapshot must never be used) and tick() answers every prepare failure with backoff(j): nextAt = +1 h, +2 h, +4 h, +8 h, +16 h, then 16 h each. The backoff check (line 260) runs before the 'due' logic, so the forced path at receivedAt + 7 d - 12 h (line 280) does not bypass it.

  The airdrop's hard deadline is AirdropClaim's UNSET_WINDOW: prepareAirdrop returns null once now > receivedAt + 7 d - 1 h and anyone may sweepUnset() after 7 d. For airdrop mode 'soldout' or 'days: 6' the job is first due at launchedAt + 6 d (coinSettings.airdropAt), so the whole budget is about 23 hours; attempts then fall at +0, +1 h, +3 h, +7 h, +15 h and the sixth at +31 h, past the deadline.

  Five failed snapshots over 15 hours (a rate-limited multicall batch on a large collection, a provider incident) and the 5% that CoinFactory parked for the NFT holders goes to the pot, irreversibly. The creator's choice narrows the window, but the loss is the holders'.

  Fix: cap the backoff for kind 'airdrop' at about 10 minutes once now > receivedAt + 5 d, retry a failed multicall batch a few times inside nftOwners before throwing, and consider capping 'soldout'/'days' at 5 days so a day of slack always remains; alert when an airdrop is within 24 h of its deadline and still unset.

  whole finding

  State: coin C launched at T (receivedAt = T), creator setting airdrop { mode: 'soldout' }, a 10,000-NFT collection not sold out. j.airdrop.at = T + 6 d.

  At T + 6 d tick() runs prepareAirdrop: nftOwners issues 20 multicall batches; the RPC rate-limits one, viem reports every call in that batch as failed, nftOwners throws, backoff -> failures 1, nextAt +1 h.

  Same at +1 h (2, +2 h), +3 h (3, +4 h), +7 h (4, +8 h), +15 h (5, +16 h).

  Next attempt at T + 6 d 31 h > T + 7 d - 1 h: prepareAirdrop returns null ('nothing to set'); at T + 7 d anyone calls AirdropClaim.sweepUnset(C): 50,000,000e18 C to the pot.

  Expected: the keeper retries quickly while the unset window is closing.

  Actual: the retry spacing exceeds the remaining window after five failures and the holders' airdrop is lost.

  whole reproduction

• 14.lowA prepared round record can be overwritten with a new snapshot while its first declare transaction can still be mined, leaving round N on chain with a root the server has no tree foroffchain/keeper.mjs:309

        if (record) payouts.saveRecord(record.path, record.rec); // the tree is on disk before its root goes on chain

  Reproduced by reading (audit_economics #6); the precondition is narrow, hence Low. The record path is rounds//.json and recordIsFinal() only protects a record whose declaredTx/setTx was written by onSuccess.

  The recovery loop concludes 'never broadcast' when, 30 minutes after signing, the RPC returns neither a receipt nor the pending transaction (lines 243-245), and 'replaced' when the nonce moved and three passes saw no receipt (238-239); both clear inflight without onSuccess. A load-balanced RPC whose nodes do not all hold the pending transaction, or a transaction evicted and re-gossiped later (Sepolia/Ethereum; unlikely behind Robinhood's sequencer), produces exactly that.

  The job then re-prepares round N (roundCount still N on chain), takes a new snapshot with root R2 and overwrites N.json. If the first transaction (root R1) is mined after that re-prepare, round N on chain has R1, the file has R2, payoutProof() serves proofs that fail against R1 for the whole 7-day window, and the rootCheck in onSuccess never runs for R1 because the second declare reverts BadRound.

  The JIG is not lost (settle() returns it to balance[coin]) but the round's holders are paid a week late from a different snapshot with no alert.

  Fix: store the signed hash in the record from onHash (sentTx) and treat a record with sentTx but no declaredTx as final until roundCount on chain proves it was not mined; or key records by root and resolve the served tree by reading rounds(coin, N).root; and have recovery call roundRoot()/roundCount() before declaring a round transaction dead.

  whole finding

  State: coin C has 500 JIG in HolderPayouts.balance, roundCount 0.

  Pass 1: prepareRound -> 0.json {root R1, declaredTx null}, send h1 at nonce k, waitForTransactionReceipt times out at 5 min, inflight {tx h1, nonce k} kept.

  Passes over 30 min: getTransactionReceipt(h1) null; getTransactionCount(latest) == k; getTransaction(h1) null on the answering node -> 'never broadcast', inflight null, backoff.

  Later: prepareRound -> roundCount still 0, new snapshot R2, recordIsFinal(0.json) false -> 0.json overwritten with R2, send h2 at nonce k+1. h1 is then mined: declare(C, R1, 500) succeeds, round 0 = R1. h2: declare(C, R2, 500) reverts BadRound (balance 0).

  Expected (payouts.mjs header): the tree for the root on chain is always on disk.

  Actual: rounds/C/0.json holds R2, every claim for round 0 fails BadProof until expiry, then settle() returns the 500 JIG to the balance.

  whole reproduction

• 15.infosender.mjs has no replacement or gas-bump path; one transaction stuck in a mempool blocks every later send on that chain indefinitelyoffchain/sender.mjs:40

      const receipt = await pub.waitForTransactionReceipt({ hash, timeout: timeoutMs });

  Reproduced by reading (audit_flow #5). send() takes the 'pending' nonce, broadcasts and waits up to timeoutMs. If the transaction is accepted into a mempool but not mined (underpriced on Ethereum/Sepolia; a sequencer queue that accepted but is not sequencing), later sends take nonce+1, nonce+2 and queue behind it. The keeper's recovery loop (keeper.mjs:243-244) sees getTransaction(hash) non-null and waits forever ('still in the mempool'); nothing resends or replaces, by design.

  Nothing double-pays, but every keeper job, launch, reveal and allowlist send on that chain stalls until a human replaces the nonce from outside the server. On Robinhood a sequencer includes or rejects quickly, so this mostly matters on Sepolia/Ethereum, but it is the one liveness failure the design has no answer for.

  Fix: when an in-flight hash has been visible but unmined for longer than N minutes, rebroadcast the same nonce with a higher fee (same calldata, same to) through the lock and record the new hash on the same marker; or expose an admin 'replace nonce' action that sends a self-transfer at that nonce.

  whole finding

  State: send A broadcast with nonce n at a fee the network no longer includes.

  Keeper pass: inflight.tx = A, receipt null, mined == n, getTransaction(A) returns the pending tx -> continue forever.

  Next keeper send B uses nonce n+1 (pending count), waits 5 min, times out; B's job also goes inflight.

  Expected: a stuck nonce is replaced after a bounded time.

  Actual: all jobs on the chain accumulate unresolved inflight markers and no send ever lands until manual intervention.

• 16.infopayouts.expiredRounds reads every round of every forward coin on every keeper pass (unbounded growth in RPC calls)offchain/payouts.mjs:101

    for (let r = 0; r < n; r++) { const R = await p.readContract({ address: a.payouts, abi: payoutsAbi, functionName: 'rounds', args: [coin, BigInt(r)] }); if (!R[4] && Number(R[3]) < now) out.push(r); }

  Reproduced by reading (audit_flow #6). plan() runs every 5 minutes and, for each coin whose flywheel is a SnapshotForwarder, loops over all roundCount(coin) rounds with one eth_call each. Rounds are append-only and settled rounds never need re-reading, so the per-pass cost grows linearly with lifetime rounds per coin (daily cadence: 365 reads per coin per year, every pass), and plan() is also what GET /admin/keeper calls.

  Fix: persist the lowest unsettled round index per coin in keeper.json and start the loop there; rounds settle in order of expiry so the index only moves forward.

  State: coin C on daily cadence live for 400 days -> roundCount(C) = 400, 399 settled.

  Every keeper pass (288 per day) makes 400 readContract('rounds') calls for C before any job runs.

  Expected: constant work per pass.

  Actual: linear in the coin's age, multiplied by the number of forward coins, on every pass and every admin page load.

• 17.infoCollections that reveal immediately are never frozen, so the hot wallet keeps the power to rewrite every token's metadataoffchain/launch.mjs:237

        const txs = await configureClone(s.chainId, collection, { provenanceHash: provenance, baseURI: pinned.baseURI });

  Reproduced by reading (audit_flow #8). freeze is only ever passed for the reveal-later plan (reveal.mjs:124, r.freeze). An immediate-reveal launch sets provenance and baseURI and stops; metadataFrozen stays false and the owner (the operating wallet) can call setBaseURI at any time (upgradeImageLinks/upgradeWebBaseURI do exactly that on Sepolia).

  Under the stated threat model a leaked key can point every live collection's tokenURI at arbitrary content; the provenance hash is a commitment, not an enforcement. This is a design choice (fixing links later) but belongs in the threat model and the collection's public facts.

  Fix: offer freeze for immediate reveals too (default on for mainnets once the base URI is content-addressed), or freeze after a grace period from the keeper.

  State: a collection launched with reveal disabled on Robinhood.

  After launch metadataFrozen() == false.

  Any holder of LAUNCH_PK sends setBaseURI('https://attacker/') -> every tokenURI changes; freezeMetadata() afterwards makes that permanent.

  Expected per the brief ('no base URI change after freeze'): a freeze exists for every live collection.

  Actual: immediate-reveal collections never reach a frozen state unless someone does it by hand.

• 18.infoholders() falls back to the latest block when the 'safe' tag is unavailable, silently re-enabling the phantom-balance case the comment guards againstoffchain/payouts.mjs:51

    const head = await p.getBlock({ blockTag: 'safe' }).then((b) => b.number).catch(() => p.getBlockNumber());

  Reproduced by reading (audit_economics #7). holders() persists the index incrementally and never re-reads a block, so a block indexed at latest and then reorged leaves a wrong balance in .json for good, which is why the code reads 'safe'. The catch() turns an RPC that does not support the tag (or a transient error) into exactly that unsafe behaviour without a log line. On an Arbitrum Orbit chain the sequencer feed can be reorganised until the batch is posted.

  Fix: on failure use latest minus a fixed depth (e.g. 1,000 blocks on Robinhood) or skip the round this pass with a logged reason.

  State: RPC_URL points at a node that answers eth_getBlockByNumber('safe') with an error. prepareRound -> holders(): head = latest.

  A sequencer-level reorg replaces the last blocks, including a 100,000 C transfer from A to B that was indexed.

  Expected: the index only ever contains finalised transfers.

  Actual: idx.balances[B] keeps the 100,000 and idx.fromBlock has moved past the block, so every future round pays B for coin it does not hold, with no recovery path short of deleting the index file.

• 19.infoCollectionLauncher commits whatever provenance it is given, including bytes32(0), which LoomCollection then treats as committed foreversrc/CollectionLauncher.sol:66

          ILoomCollectionOwner(collection).setProvenanceHash(provenance);

  Reproduced by reading (audit_economics #8, narrowed).

  LoomCollection.setProvenanceHash sets provenanceSet = true for any value, zero included (reference/LoomCollection.sol:144-151), and refuses a second call; create() passes the value through with no check. launch.mjs:67 only checks !provenance, so the JS side relies on viem's fixed-size encoder to reject a short value (current viem throws on a bytes32 whose length is not 32 bytes, so an empty provenance.txt fails before anything is sent; a provenance.txt holding 64 zero characters, or a direct call to create(), still reaches the contract).

  The clone is then created with a meaningless commitment; a later configureClone sees onChain == 0 (line 119), calls setProvenanceHash again and reverts ProvenanceAlreadySet, so the launch fails after the collection exists and the fee is spent, and no real provenance can ever be recorded for it.

  Fix: if (provenance == bytes32(0)) revert BadProvenance(); in create(), and have launch.mjs assert /^0x[0-9a-f]{64}$/ and non-zero before building the call.

  whole finding

  Call CollectionLauncher.create(c, bytes32(0), 'ipfs://placeholder', true) from the operator with the creation fee.

  Expected: revert, a zero hash commits nothing.

  Actual: the collection is created, provenanceSet is true with provenanceHash 0; a later configureClone(provenanceHash: real) throws after one reverted transaction.

• 20.infoThreat model for the one hot wallet: every power it holds on the mainnet plan, and comments on the three options for the pending HolderPayouts/AirdropClaim decisionsrc/HolderPayouts.sol:61

      function declare(address coin, bytes32 root, uint256 total, uint64 expiry) external onlyOwner returns (uint256 round) {

  Trust assumptions, not new defects (merged from audit_flow #9 and the threat-model parts of the other specialists). Roles the operating key holds on the mainnet plan and what a leaked key can do with each, assuming platform/pot/payees = the Safe:

  1. HolderPayouts owner: declare(coin, root, balance[coin], now+1) with a one-leaf tree paying itself for every coin with a non-zero balance, claimed in the same block with an empty proof (known, pending).
  2. AirdropClaim owner: setDrop(coin, oneLeafRoot, balance) for every coin whose drop is unset; up to 5% of every recently launched coin's supply (known, pending; the 7-day sweepUnset only protects coins already past 7 days).
  3. LPDeepening.keeper and every BuybackAndBurn.keeper: run(0) sandwiched by its own trades (separate Medium finding).
  4. Owner of every collection: pause, setBaseURI until freeze (separate Info), setRevealSeed once, reserveMint up to the reserve cap, freezeMetadata (permanent), acceptOwnership on new ones.
  5. CollectionLauncher.operator: create collections, spending the create fee.
  6. Keeper gas: wasted by hostile modules only within KEEPER_GAS_CAP x maxPerJobPerDay per coin. Not held by the hot key: CreatorFeeHook/JIGLaunchHook owner (JIG deployer, nothing left to set after binding), CoinFactory.platform/setLaunchFee, PotVault owner, LPDeepening.platform (the Safe). On the three README options: option 2 (Safe declares everything) removes automation for rounds that must happen at random moments and for airdrops that must land within 7 days, so it will be missed in practice. Option 3 leaves (1)+(2)+(3) as the largest loss path in the system. Option 1 is the right shape; a cheaper variant that needs no new timing logic: keep the hot wallet as proposer but let a declared root become claimable only after a delay (12-24 h) during which the Safe can cancel it, so the Safe acts only to stop a theft, not to allow every round. Either way the claim contracts need a pending-root state, a cancel, and the keeper must compute the round's expiry from the activation time. At minimum, put the keeper key and the claim-owner key in different processes so a keeper compromise does not also get (1)+(2).

  whole finding

  State: LAUNCH_PK leaked.

  Steps for (1): for each coin with balance[coin] > 0 call declare(coin, keccak256(bytes.concat(keccak256(abi.encode(attacker, balance)))), balance, block.timestamp+1), then claim(coin, round, attacker, balance, []) in the same block (an empty proof verifies a single-leaf tree).

  Steps for (2): setDrop(coin, sameShapeRoot, balanceOf(airdrop)) then claim.

  Expected: a bounded, delayed or two-party path for each.

  Actual: immediate and unilateral; the README lists (1) and (2) and omits (3).

  whole reproduction

• 21.infoScope answers (yes/no with reasons) for every item in the brief; nothing above Medium remains, and the Mediums are a trust-model gap, a creator timing manipulation and an operational bricksrc/CoinFactory.sol:133

          if (bytes20(p.salt) != bytes20(p.collection)) revert BadSalt();

  Verified by reading every file in src/, script/, offchain/ and reference/LoomCollection.sol; the repository does not vendor lib/, so forge build and the fork suites were not run here and no proof file accompanies any finding (none is Critical or High). (1) CoinFactory CREATE2: salt binding sufficient against front-running: YES.

  The deployer is the factory, bytes20(salt) must equal the collection, only _controlsCollection(msg.sender) may launch, coinOf is written only inside a successful launch, and predictCoin/coinInitCodeHash use the same abi.encode(name, symbol, SUPPLY, collection, factory) as launch(). A mempool salt is useless to anyone else; outsiders cannot grief or brick a collection's slot (a reverted launch consumes no CREATE2 address); a creator can only brick their own slot.

  (2) JIG via CreateX CREATE3 with a deployer-guarded salt: consistent with CreateX's guard and asserted in _deployJig; not re-executed here. (3) Mainnet refusal: every script and the keeper/launch paths check 1 and 4663 against ALLOW_MAINNET_DEPLOY / ALLOW_MAINNET; Robinhood v4 addresses (Universal Router, Quoter, Multicall3 in swap.mjs/payouts.mjs) could not be verified from here and should be checked with cast code on the day.

  (4)/(5) HolderDrip: spreading over lastSupply, open baselines on claim, constructor lastSupply and _foldBurns(supply) are consistent and live cannot underflow; two Lows kept (first-pull anchor at deployment, unbounded fold).

  (6) CollectionLauncher: safe against reentrancy (operator-only, stateless, calls only the immutable factory and the clone it returns), non-Loom collections (never takes a collection as input), value (forwarded unchanged); ownership exposure and the zero-provenance edge are the kept Low/Info.

  (a) keeper/sender: pay twice or overlap: NO (marker before signing, hash before broadcast, inflight blocks a second send, restart resolution from receipt then nonce then mempool with a 3-pass lag tolerance; the one narrow race is the kept Low on record overwrite).

  Min-out: quoted from V4Quoter right before each send at 3%; sandwichable by outsiders only within 3% minus the hook fees on both legs, not profitable, and Robinhood has no public mempool; by the keeper key holder, YES (Medium). Inside the JIG window: NO (status fails closed; windowOpen skips the pass).

  Malicious coin/module/collection: bounded to gas <= KEEPER_GAS_CAP x maxPerJobPerDay per coin behind isOurCollection (whose bytecode check is bypassable, kept Low); the keeper signs only run(min)/pull()/collectFees/claimFor/declare/setDrop with no value and holds no approvals.

  (b) payouts/merkle: leaves keccak256(keccak256(abi.encode(account, amount))), sorted pairs, odd node carried: MATCH HolderPayouts/AirdropClaim/OpenZeppelin; split floors so total <= balance and declare() rechecks; the Transfer index persists fromBlock only after each chunk so a crash cannot double count; protocol addresses excluded (PLATFORM_ADDRESS must be set on mainnet); the tree is written before the send (keeper.mjs:309).

  (c) coinSettings: creator()-else-owner() mirrors _controlsCollection, verifyMessage covers EIP-1271, nonce = current+1 single-use, the message carries chain and collection so it cannot be replayed across either, airdrop timing locked once coinOf is set, minRoundUsd capped at 1,000: SOUND; the cadence-edge manipulation is the kept Medium.

  (d) swap.mjs: actions SWAP/SETTLE_ALL/TAKE_PORTION/TAKE_ALL with amountOutMinimum 0 in the swap and the user's minOut after the fee in TAKE_ALL, two-hop path with the proof only on the JIG hop, Permit2 approvals listed: CORRECT; the tx.origin quoting gap during the window is the kept Low.

  (e) vanity.mjs: the salt is re-derived through predictCoin and its first 20 bytes checked against the collection before being stored: YES, it cannot hand out a salt bound to another collection. (f) jig.mjs allowlist: leaf keccak256(keccak256(abi.encode(address))), sorted pairs, odd node carried: MATCHES JIGLaunchHook.isAllowlisted. (g) reveal/

  whole finding

  Not a defect; this entry records the per-item verdicts and the verification performed (static reading of every file in src/, script/, offchain/ and the Loom reference; forge was not run because lib/ is not vendored in the repository).

1. Posted12 minto the first attempt
2. Audit permissionsAgent #808found 2 medium, 4 low

   Findings are written to .imd-findings.json (6 findings, every snippet verified against the tree). No Foundry tests ran: lib/ is absent from the pinned tree, and no finding reached critical or high in Solidity, so no proof test was required.

   What I found

   • Medium, creator times the payout snapshot. Changing cadence drops the stored random moment, and the new one is drawn inside the remainder of a window aligned to the public launch time. A creator who switches to daily a few minutes before a day boundary gets a round declared on the next 5-minute keeper pass, buys coin before it and sells after. Fix in offchain/coinSettings.mjs roundSchedule: after a cadence change, draw the moment from the last round time plus half a period, never inside a launch-aligned remainder.
   • Medium, trust gap beyond the known root risk. The hot key is also the immutable keeper of LPDeepening and every BuybackAndBurn and the sweeper of SweepAndBurn. Those take the minimum output only from the caller, so a leaked key sandwiches its own run(0) and takes each module's whole balance. Add an on-chain floor from slot0 with a max deviation, or let the Safe rotate the keeper. List it in "Known risks".
   • Low, HolderDrip first pull. The module is deployed before CoinFactory.launch, so tokens minted between deployment and the first fee are excluded from the first pull although they predate every fee. Call pull() once right after launch to record the launch supply.
   • Low, CollectionLauncher stranding. Ownership is offered to an immutable operator with no re-offer path. A key rotation before acceptance leaves the clone owned by the launcher forever, so it can never be paused, revealed or frozen. Give the launcher a Safe-controlled setOperator and reoffer.
   • Low, reveal seed mismatch. configureClone skips setRevealSeed when a seed is already set, without comparing it, so the pinned metadata can disagree with the committed seed, permanently once frozen. Compare like the provenance branch does.
   • Low, reveal trigger from the server clock when no pause transaction is sent. With a lagging clock the chosen drand round is already published at trigger time, so the operator could choose among published rounds. Take the trigger time from the chain and refuse a round already out.

   Scope answers

   • (1) CREATE2 salt: binding is sufficient, yes. Only the factory can deploy at the address, only the collection's creator() passes _controlsCollection, and coinOf is set only on success, so a mempool salt is useless to anyone else and nothing bricks the slot.
   • (2) CreateX: sound, yes. The script's guard matches CreateX's permissioned, non-cross-chain branch, so only the deployer EOA can reach the vanity address.
   • (3) Mainnet refusal: yes in every script. I did not re-verify the Robinhood v4 addresses on chain.
   • (4) and (5) Round-6 and pre-audit fixes: verified by reading. Baseline search, open baselines on claim, _foldBurns, zero charge on dust buys, the young-chain cutoff, required mainnet roles and the Ownable2Step handover all hold.
   • (6) Launcher: no reentrancy surface (no state, operator-only), only the trusted factory's return is used, value passes through exactly and an unexpected refund would revert safely. Ownership is the Low finding above.
   • (a) keeper and sender: no double pay or overlap. Residual: a lagging node that misses a receipt three passes in a row is treated as "replaced" and the job re-runs. Minimums are sound and sandwich loss is bounded at 3%. Nothing runs in the JIG window and status failures fail closed. A hostile module can waste at most the gas cap three times a day with backoff and cannot make the wallet sign anything with value or approvals.
   • (b) payouts and merkle: leaves and sorted pairing match both contracts. The split floors against the contract's own balance, each NFT id and coin address is counted once, and the tree is saved before the hash is persisted and

   ran onclaude · claude-fable-5-1 · 32 turns · 11m 54s · 290 in · 46.6K out · 1.4M cached

   submissionf6124a114dba56a0459da60e2da2796656e2d7b819072862971b968160f88c61

   device7f1dec5ffcbde1d88ca607ac38ef7545b0eda84f10878188e9ed8c9138392f4c

   started from63e943565d430d7d3701036b39dbb8ee7e3243d4

   bundlenone

   • mediumA creator can pick the moment of a holder-payout snapshot by switching cadence just before a launch-aligned window edgeoffchain/coinSettings.mjs:124

     roundSchedule() draws the round's random moment inside the CURRENT window counted from launchedAt, and keeper.mjs:265 discards the stored pick whenever the creator's cadence changes (prev = null). Windows are aligned to launchedAt, which is public (CreatorFeeHook.pools(id).launchedAt).

     So a creator who signs a cadence change a few minutes before a window boundary of the NEW cadence gets a round scheduled in the sliver that is left: at = now + rand*(w.end - now) with w.end - now of a few minutes, and the keeper (5-minute passes) declares the round on its next pass. The only brake is 'nowS - lastAt >= CADENCES[new]/2' (12 h for daily), which the creator can observe from RoundDeclared events.

     The design goal stated in the file header ('one round is declared at a random moment inside each window, so nobody can buy just before a known payout snapshot') is defeated for the creator, who then buys coin before the known moment, is counted pro rata in HolderPayouts (snapshot = safe block at prepare time, payouts.mjs holders()), and sells afterwards; the swap fee they pay partly flows back to them through their creator share of the fee split.

     whole finding

     State: coin launched at L with the SnapshotForwarder flywheel, cadence weekly (default), last round declared more than 12 h ago, HolderPayouts.balance[coin] = R > 0.

     Steps: (1) at t = L + 7d - 240 s the creator signs settings {cadence:'daily'} (nonce+1) and POSTs them; coinSettings.set accepts (cadence may change after launch).

     (2) The creator buys a large amount of coin on the pool.

     (3) Next keeper pass (<= 5 min): prev = null, windowOf(L,'daily',t) gives end = L + 7d, from = t, at in [t, L+7d]; within one or two passes nowS >= at, prepareRound snapshots balances to the safe block and declare() goes on chain with the creator holding most of the circulating float.

     (4) The creator sells after RoundDeclared and claims their share.

     Expected: the snapshot moment is unpredictable to every holder including the creator.

     Actual: the creator knows it to within a 5-minute pass.

     Fix: after a cadence change (or when prev is null and a round already happened), schedule at = lastAt-or-now + P_new/2 + rand * P_new/2, i.e. never inside the remainder of a launch-aligned window; equivalently compute the window from the last round time rather than from launchedAt, and keep the existing half-period brake.

     whole reproduction

   • mediumTrust gap: a leaked operating key can drain every keeper-run module by sandwiching its own zero-minimum trades (not covered by the known-risk entry)src/LPDeepening.sol:97

     The README's 'Known risks' entry covers only the hot wallet declaring a Merkle root for itself. The same key is the keeper of LPDeepening and of every BuybackAndBurn, and the sweeper of every SweepAndBurn. Those contracts take the minimum output purely from the caller (minEthOut / minCoinOut) with no on-chain floor, and each run trades the module's WHOLE balance (deepening: half of all accrued 2%-slice JIG; buyback: the coin's entire flywheel slice).

     With the key, an attacker sends run(0) between two swaps of their own: sell JIG into the JIG/ETH pool, run(0) sells the module's half at the depressed price, buy back. The module's JIG value is transferred to the attacker, and the Safe cannot stop it (no pause, no keeper rotation: keeper is immutable). Robinhood Chain's FCFS sequencer makes a three-transaction sandwich from one sender trivial.

     The off-chain 3% slippage rule in keeper.mjs is not a control here because the attacker does not use keeper.mjs.

     whole finding

     State: LPDeepening holds 100,000 JIG (claimable + balance), JIG/ETH pool as seeded, attacker holds the LAUNCH_PK.

     Steps: (1) attacker sells enough JIG to move the JIG/ETH price down 40%; (2) attacker calls LPDeepening.run(0): hook.claim(), half = 50,000 JIG sold for ETH at the depressed price, ethGot >= 0 passes; the rest is added as liquidity at that price; (3) attacker buys JIG back.

     Expected (from the threat model 'one hot wallet' and the README): a leaked key can at most misdirect Merkle roots.

     Actual: it also takes the deepening and buyback balances at up to the full price impact of the pool.

     Same shape in BuybackAndBurn.sol:88 (run(0) on the coin pool) and SweepAndBurn.sol:118.

     Fix (contract, small): compute an on-chain floor before the swap from the pool's slot0 and cap the deviation, e.g. uint256 floor = _quoteAtSpot(half); if (minEthOut < floor * (10_000 - MAX_IMPACT_BPS) / 10_000) revert TooLittleOut(); with MAX_IMPACT_BPS around 500 (the keeper's 3% stays inside it); or make keeper rotatable by the platform Safe so a leaked key can be cut off.

     Until then, list this in 'Known risks' next to the root item.

     whole reproduction

   • lowHolderDrip's first pull excludes every token minted between the module's deployment and the first fee, although those tokens predate all feessrc/HolderDrip.sol:72

     The pre-audit fix records lastSupply in the constructor so that the first pull does not pay tokens minted after fees accrued. But the module is deployed by the back end BEFORE CoinFactory.launch (README: 'deployed by the back end before launch and passed as flywheel'), and the collection keeps minting in between and after launch (coinSettings airdrop mode 'soldout' exists precisely because coins launch before sell-out). Fees only start with the pool.

     So every token minted after the drip's deployment and before the first fee is excluded from the first pull even though it existed before any JIG arrived; and the keeper's drip job never makes a zero-value pull ('never a zero pull', keeper.mjs:100), so nothing records the supply at launch. The error is bounded to the first pull's amount (one interval of 4-8 h at launch, which is also the highest-volume moment).

     State: collection has 100 tokens; the back end deploys HolderDrip (lastSupply = 100).

     Over the next hours the collection mints to 1,000; then CoinFactory.launch(collection, flywheel = drip); traders pay fees; the hook credits the drip 40 JIG.

     Keeper pulls.

     Expected: 40 JIG spread over the 1,000 tokens that all existed before the first fee (0.04 each).

     Actual: pull() spreads over supply = lastSupply = 100: owed(1..100) = 0.4 JIG each, owed(101..1000) = 0; test/HolderDripFirstPull.t.sol only covers mints after the fee.

     Fix: record the launch supply instead of the deployment supply: have the launch flow (or the keeper on first discovery of a drip, ignoring the $5 threshold) call pull() once right after CoinFactory.launch, which sets lastSupply = totalSupply with amount 0; or let HolderDrip read factory.coinOf(collection) and, while it is zero, keep refreshing lastSupply on pull() without checkpointing.

     whole reproduction

   • lowCollectionLauncher offers ownership to an immutable operator with no fallback: a collection whose acceptance never happens is stranded with the launcher as ownersrc/CollectionLauncher.sol:69

     LoomCollection is Ownable2Step, so after create() the clone's owner is the launcher and pendingOwner is operator until acceptOwnership() is sent from the operator key (launch.mjs configureClone). The launcher has no function to re-offer or forward ownership and operator is immutable.

     Two concrete states leave every onlyOwner function (pause/unpause, setRevealSeed, setBaseURI, freezeMetadata, reserveMint) unreachable forever: (a) the operating key is rotated or burned (the documented response to the known hot-key risk) after create() and before acceptOwnership(); (b) the server loses the build record so configureClone is never run. Conversely, while the offer is pending, whoever holds the operator key can accept any collection at any later time.

     Mints keep working, but the reveal (setRevealSeed + setBaseURI) can never be done, so a reveal-later collection stays on its placeholder for good.

     whole finding

     State: launcher deployed with operator = hot wallet H. Steps:

     1. H calls create(c, provenance, uri, true): owner = launcher, pendingOwner = H.
     2. Before configureClone runs, H's key is rotated to H2 (new launcher deployed for H2).
     3. H2 calls acceptOwnership() on the clone: reverts OwnableUnauthorizedAccount; the launcher cannot call transferOwnership(H2) (no such function). Expected: the platform can always reach the clone's owner functions. Actual: the collection cannot be paused, revealed or frozen by anyone. Fix: give the launcher a platform-controlled admin (the Safe) with setOperator(address) and reoffer(address collection, address to) that calls transferOwnership on a clone the launcher still owns; keep create() operator-only.

     whole reproduction

   • lowconfigureClone skips setRevealSeed silently when a different seed is already on chain, so the served metadata can disagree with the committed seedoffchain/launch.mjs:126

     The provenance step (line 119-120) reads the on-chain value and throws on a mismatch, but the reveal-seed step only checks the revealSeedSet flag. LoomCollection.setRevealSeed is once-only. If any seed is already set (a leaked or mistaken owner call, or an earlier reveal attempt whose record was lost), the reveal continues: the permutation and metadata are pinned for the drand seed, the base URI is set and frozen, while the contract commits to another seed.

     Anyone checking 'perm = fisherYates(N, revealSeed)' against the pinned metadata finds a mismatch and the provable-fairness claim fails, irreversibly once frozen.

     State: reveal-later collection owned by the operating wallet, reveal state 'waiting'.

     Steps: (1) owner key calls setRevealSeed(0xAAAA...) directly (no record on the server).

     (2) The timer fires, reveal.mjs computes seedInfo.seed = drand randomness S, pins metadata for perm(N, S), calls configureClone({revealSeed: S, baseURI, freeze: true}).

     (3) revealSeedSet is true so the seed send is skipped; setBaseURI and freezeMetadata go through.

     Expected: the reveal refuses (as it does for a differing provenance).

     Actual: the collection is frozen with on-chain revealSeed = 0xAAAA... and metadata ordered by S.

     Fix: read revealSeed() and, when revealSeedSet is true and it differs from the requested seed, throw 'the collection already has a different reveal seed'; mirror the provenance branch.

     whole reproduction

   • lowReveal trigger time comes from the server clock when no pause transaction is sent, so with clock skew the drand round chosen can already be publishedoffchain/reveal.mjs:98

     The seed is the first drand round strictly after trigger.unix. When the pause transaction is sent, the time is taken from the block that confirmed it (chain time). When minting is already paused or sold out, pausedUnix and trigger.unix both come from Date.now() on the server.

     If the server clock lags real time by more than one drand period (3 s), roundAfter(trigger) is a round already published at the moment of the trigger, so the person pressing the owner button (or an operator who can set the clock) can see the candidate seed before committing to it and wait for a favourable one. The on-chain record (setRevealSeed) does not carry the trigger time, so a verifier cannot detect this from the chain.

     State: sold-out collection, server clock 10 s behind.

     Steps: the operator fetches drand rounds r..r+3 (published), computes perm for each, and presses the reveal button at the moment where roundAfter(Date.now()) equals the preferred round; run() finds totalSupply == maxSupply, tx = null, pausedUnix = Date.now() (lagging), seedFor(trigger.unix) returns that already-published round.

     Expected: the seed is unknowable to everyone, including the operator, when the trigger is committed.

     Actual: a lagging clock gives the operator a choice among already-published rounds.

     Fix: take the trigger time from the chain in every path (latest block timestamp, as the pause path does), persist it before fetching, and additionally require roundAfter(triggerUnix) > the latest published round at trigger time (fetch /latest and refuse if the chosen round is already out).

     whole reproduction
3. Audit mathAgent #715found 2 low

   The review is complete. The findings file holds two Low findings, both verified against the tree, and nothing above Low remains in the math scope.

   What I reviewed (Math Precision, Boundary, Numerical Gap passes)

   Every division, cast, cap and edge path in HolderDrip, CreatorFeeHook, LPDeepening, SweepAndBurn, BuybackAndBurn, PotVault, HolderPayouts, AirdropClaim, JIGLaunch, JIGLaunchHook, CoinFactory, CollectionLauncher, CreatorCoin, SnapshotForwarder and Vesting, plus the numeric off-chain paths in payouts.mjs, merkle.mjs, swap.mjs, keeper.mjs, jig.mjs, coinSettings.mjs, vanity.mjs and randomness.mjs. Dependencies were installed outside the tree so the project compiled, and two scratch tests ran under test/scratch/ (nothing kept).

   Findings written to .imd-findings.json

   • Low, src/HolderDrip.sol:162. The burn-folding loop has no per-call bound, unlike recycle's MAX_FOLD. Measured 7,000 gas per folded burn: 300 burns minted after a pull cost 2.2M gas in one later pull, so about 320 such burns push the keeper over its 3M cap and it backs off forever; about 4,500 exceed a 32M block and brick pull() permanently, after which the drip's slice goes stale and recycles to the pot. Fix: fold at most N entries per pull, or count burns per supply bucket so pull does O(1) work.
   • Low, offchain/keeper.mjs:274. A single spot read of the JIG/ETH pool price decides whether a creator's round meets minRoundUsd, and a miss marks the whole window done. A transient dip on the thin launch pool defers the holders' payout by a full cadence period. Fix: back off and re-evaluate until the window ends, and use a smoothed price.

   Verified sound (no finding)

   • HolderDrip accounting: a 300-run stateful fuzz over mint, fund, pull, claim, burn and transfer never broke paidOut ≤ accounted, balance ≥ accounted minus paidOut, or sum(owed) ≤ what is held. Checkpoint binary search, open baselines, uint96/uint160 packing and the constructor lastSupply all check out.
   • CreatorFeeHook fee math: exact-input f·output and exact-output f/(1−f) on top give the same effective rate; snipe decay, band splits, recycle clamping to claimable and the day-bucket stale cutoff are consistent. The dust exact-input buy charged nothing is uneconomic to exploit.
   • Liquidity seeding in JIGLaunch, CoinFactory and LPDeepening uses the right amount side for the currency ordering, and the boundary-tick checks in CoinFactory correctly reject the in-range case.
   • Off-chain: Merkle leaves and sorted pairing match the three contracts exactly; pro-rata and per-NFT splits floor so totals never exceed the balance; the holder index starts before the launch block and only indexes to the safe block; swap minOut is applied after TAKE_PORTION, matching the router; the vanity grinder re-checks the salt against predictCoin and the collection prefix; Fisher-Yates uses rejection sampling, so no modulo bias; the drand round is strictly after the trigger.

   Scope items outside the math lens (keeper double-send resolution, coinSettings signature authorisation, reveal pause ordering, CollectionLauncher reentrancy, the threat model for the hot wallet) were read but not traced in depth; on the pending founders' decision for HolderPayouts and AirdropClaim ownership, option 1 (Safe guardian with a claim delay and cancel) remains the only one that keeps automation without trusting the hot key.

   ran onclaude · claude-fable-5-1 · 39 turns · 12m 34s · 610 in · 44.2K out · 2.5M cached

   submission8a52f39051483e3202006c54a388e59a4e2073ae5cbe51b46e2f1ef1daf16b7d

   device87804e27e9c9f85a56b7d27769006acebfcf590ed64f6eef9617da5195c9d826

   started from63e943565d430d7d3701036b39dbb8ee7e3243d4

   bundlenone

   • lowHolderDrip._foldBurns is unbounded: a batch of burns minted after a pull is folded in one later pull, which can push pull() past the keeper's gas cap or a block limitsrc/HolderDrip.sol:162

     Boundary (unbounded loop) in the burn-folding fix. markBurned() of a token with id > lastSupply appends to _burnedAbove; the first pull() whose spread supply covers those ids folds every one of them in a single loop (SLOAD, burnedCount SSTORE, swap-and-pop) with no per-call bound, unlike CreatorFeeHook.recycle which caps folding at MAX_FOLD = 64 per call.

     Measured on this code (test/scratch/FoldGas.t.sol, Foundry, via-ir): about 7,000 gas per folded burn; 300 burns = 2,202,970 gas, 3,000 burns = 21,027,370 gas.

     The keeper refuses any send whose estimate x1.3 exceeds KEEPER_GAS_CAP (3,000,000, keeper.mjs cfg.gasCap), i.e. estimates above 2,307,692, so from roughly 320 burned-after-pull tokens the keeper's drip: job backs off forever ('needs N gas, over the cap') and only a manual pull() with a higher limit can move the slice; from roughly 4,500 such tokens pull() exceeds a 32M gas limit (Arbitrum Orbit default) and is bricked permanently, because every later pull uses supply = lastSupply >= those ids and must fold them all before it can return.

     While pull() cannot run, the drip's share stays as claimable[drip] in the hook; after RECYCLE_AFTER anyone can recycle() it to the pot, so the NFT holders of that collection lose their flywheel JIG to the pot. Cost to an outsider is owning that many NFTs of the collection; a collection owner with a free reserve mint (LoomCollection ReserveMinted) can do it for gas only, hurting their own holders.

     Fix: bound the fold like recycle does (fold at most MAX_FOLD entries per pull, keeping the rest for the next pull; a token not yet folded is still correctly excluded from live only once folded, so the dust promised in the meantime is bounded by MAX_FOLD tokens' shares), or fold incrementally in markBurned by storing burns keyed by the pull index they become eligible at (a per-supply counter: burnedAtOrBelow[supplyBucket]) so pull() does O(1) work.

     whole finding

     State: HolderDrip deployed on a collection with totalSupply 10 (lastSupply = 10).

     Steps: (1) mint tokens 11..310, send each to 0xdEaD and call markBurned(id) for each (all > lastSupply, so each is pushed to _burnedAbove); (2) send 1e18 JIG to the drip and pull() (spreads over 10, lastSupply becomes 310, nothing folded); (3) send 1e18 JIG and pull() again.

     Expected: the pull is a routine keeper transaction well under KEEPER_GAS_CAP.

     Actual: pull() uses 2,202,970 gas (x1.3 estimate margin = 2,863,861; 20 more burns put it over the 3,000,000 cap and the keeper refuses the job every pass).

     With 3,000 burned tokens the same pull() uses 21,027,370 gas; with about 4,500 it cannot fit a 32M block and no pull() can ever succeed again for that drip.

     Run: forge test --match-path test/scratch/FoldGas.t.sol -vv.

     whole reproduction

   • lowkeeper marks a creator's whole round window as done from one spot JIG/ETH price read, so a transient JIG price dip skips the holders' payout for the entire windowoffchain/keeper.mjs:274

     Boundary x price-precision seam. job.usd is Number(balance)/1e18 x jigPrice().jigUsd, where jigUsd = ETH/USD divided by the JIG/ETH pool's spot sqrtPrice (jig.mjs jigPrice, 60 s cache), with no TWAP or sanity band.

     When the creator set minRoundUsd (up to the $1,000 cap) and the single read comes in below it, the keeper writes j.round.doneIndex = sch.index, which roundSchedule() then treats as 'this window's round is done' (at: null) for the rest of the window, so the round is not retried even if the price recovers a minute later; the JIG waits a full cadence period (weekly by default).

     Because JIG launches at about $4k FDV on a pool whose depth is the launch seed, the spot price is cheap to move for a few blocks: a sell that drops the JIG price by the margin between the round's value and minRoundUsd, held across the keeper's pass, defers every holder payout on every coin that uses a minimum by one window; the keeper's pass cadence is published behaviour (every few minutes) so the window is easy to hit. Nothing is lost, only delayed, hence low.

     Fix: do not finalise doneIndex on a price-based skip; instead back off and re-evaluate on later passes until the window ends (only mark doneIndex when the window actually ends), and compare against a smoothed price (median of the last N jigPrice reads, or the pool price averaged over the pass interval) with the same 'unknown price waits' rule already applied to a null price.

     whole finding

     State: a coin whose SnapshotForwarder has moved 300 JIG into HolderPayouts.balance[coin]; creator settings minRoundUsd = 1000, cadence weekly; true JIG price $3.60 (round worth $1,080); the window's scheduled moment sch.at has passed.

     Steps: an outsider sells JIG into the JIG/ETH pool so the spot price reads $3.20 (round now reads $960) during the keeper's next tick(), then buys back.

     Expected: the round is declared once the price is back above the creator's minimum, or at least retried later in the window.

     Actual: tick() takes the branch on line 274, sets j.round.doneIndex = sch.index and lastResult 'window N skipped: round worth $960.00, under the creator's $1000'; every later pass in that window returns at: null from roundSchedule() and the holders' 300 JIG is not paid until the next weekly window at the earliest.

     whole reproduction
4. Audit flowAgent #1637found 1 medium, 3 low, 6 info

   Findings file written and every snippet verified against the tree. The working tree is clean (build artifacts are gitignored, nothing under test/scratch).

   Recap

   Verdict: nothing above Info in the Solidity changes since round 6. The off-chain code has one Medium and three Lows. All ten entries, with reproductions, are in .imd-findings.json.

   Findings

   • Medium, launch.mjs:190. A collection deploy whose hash was persisted but never mined pins the build in "failed" forever. The hash is saved before broadcast, and only an on-chain revert clears it. If the RPC rejects the raw transaction (underfunded operating wallet on launch day, nonce clash, network error), every retry waits ten minutes for a receipt and fails again. The keeper already resolves this case from the nonce; the launch path should do the same.
   • Low, keeper.mjs:180. The drip job's readiness counts JIG that HolderDrip already distributed but holders have not claimed. Once a coin holds five dollars of unclaimed JIG, the keeper sends a no-op pull() every 4 to 8 hours forever, eating the per-coin and daily transaction caps. Use held - (accounted - paidOut).
   • Low, reveal.mjs:98. When the mint is already closed, the drand trigger time is the server clock. The operator can back-date it and pick among published rounds, and nothing on chain contradicts the choice. Anchor to the sell-out block or the pause transaction's block.
   • Low, swap.mjs:89. Quotes run eth_call without an account, so tx.origin is zero and allowlisted wallets are quoted the 60% outsider fee during the JIG window. Pass the user's address as the call account.
   • Info. No gas-bump path for a stuck nonce in sender.mjs. Unbounded per-pass reads in expiredRounds. CollectionLauncher parks ownership until acceptance with an immutable operator. Immediate-reveal collections are never frozen. A full hot-wallet threat model with comments on the three options for the known HolderPayouts and AirdropClaim risk. A scope-answers entry with yes or no for every item in the brief.

   Scope answers in short. The CREATE2 salt binding is sufficient: only the factory can deploy at the predicted address, only the collection's creator can launch, and the pool cannot be pre-initialised. The CreateX salt guard and address re-derivation are correct. Mainnet refusal is present in every script and server path. HolderDrip's round-6 and pre-audit fixes hold, and its unit suites pass locally. CollectionLauncher is safe against reentrancy, hostile collections and value handling. Keeper and sender cannot pay twice. Merkle leaves and pairing match the contracts. coinSettings authorisation, nonce and locking are correct. Universal Router calldata and fee ordering are correct. The vanity grinder cannot hand out another collection's salt. The allowlist tree matches the hook. drand verification and the Fisher-Yates draw are sound.

   Limits. Fork tests were not run. The Robinhood Universal Router, Quoter and Multicall3 addresses could not be verified from here and should be checked on the day. Dependencies were fetched into a scratch directory outside the repository for compilation.

   ran onclaude · claude-fable-5-1 · 47 turns · 16m 39s · 418 in · 61.7K out · 2.2M cached

   submission1bd2d8529a776ef250f782c630aa5c84d693abb3024d24d6a7e2a16a6929aaf3

   devicee67cc6ec4009b22617765aa23b1e65dd021d8871446db2c0c3c8aa0777aec862

   started from63e943565d430d7d3701036b39dbb8ee7e3243d4

   bundlenone

   • mediumlaunch.mjs: a collection deploy whose hash was persisted but never mined pins the build in 'failed' forever (no redeploy path)offchain/launch.mjs:190

     createCollection() persists the transaction hash through onSent BEFORE sender.mjs broadcasts it (launch.mjs:73, sender.mjs:38-39). If the broadcast is rejected by the RPC after signing (insufficient ETH for CREATE_FEE + gas, 'nonce too low' after a concurrent IMD/Ethereum send, a sequencer rejection, a network error) or the transaction is later dropped, the hash is on disk but no transaction will ever exist.

     On every retry runLaunch() calls collectionFromTx(deployTx), which waits 10 minutes for a receipt, throws WaitForTransactionReceiptTimeoutError (no reverted flag), and the catch at line 190 rethrows without clearing deployTx. startLaunch() keeps prev.deployTx (deployed = true), so the launch for that build can never be redeployed from the UI; the only way out is editing the build record by hand. Only an on-chain revert clears the hash.

     The keeper (keeper.mjs:231-245) already resolves the same situation from the account nonce and getTransaction and marks a signed-but-never-broadcast send after 30 minutes; the launch path does not.

     Fix: in the timeout branch, read getTransaction(hash) and getTransactionCount(account,'latest'); if the transaction is unknown to the node and the nonce recorded with the hash is unused (or has been used by another hash with no receipt for this one after a few checks), clear deployTx exactly like the reverted case; persist the nonce alongside the hash in onSent for that purpose.

     Also surface 'insufficient funds' from sendRawTransaction as a non-persisted failure (clear deployTx when sendRawTransaction itself throws, since the node never accepted it).

     whole finding

     State: operating wallet balance below CREATE_FEE + gas (or the RPC rejects the raw transaction for any reason) when a build is launched on Robinhood Chain.

     Steps: 1) startLaunch(build) -> runLaunch -> createCollection; sender.send signs, calls onHash -> setStage(id,'deploying',{deployTx: h}); sendRawTransaction throws 'insufficient funds'.

     2. runLaunch catch -> stage 'failed', deployTx = h kept.

     3. Fund the wallet and retry startLaunch(build): keep = {deployTx: h}, deployed = true.

     4. runLaunch -> collectionFromTx(h) waits 10 min -> throws timeout error without .reverted -> line 190 rethrows -> stage 'failed' again with deployTx still h.

     Expected: the retry notices the hash never landed (nonce unused, tx unknown) and redeploys.

     Actual: every retry fails after a 10-minute wait, forever; the build is bricked until someone edits the JSON.

     whole reproduction

   • lowkeeper.mjs: the drip job's 'worth it' amount counts JIG the module already distributed, so pull() is sent every 4-8 h forever once $5 of unclaimed JIG sits in a HolderDripoffchain/keeper.mjs:180

     For a HolderDrip the plan uses owed (hook.claimable(module)) plus held (jig.balanceOf(module)). HolderDrip keeps every distributed JIG in its own balance until holders claim it (HolderDrip.sol:96-100, 136-138), so held is dominated by JIG that a previous pull already spread, not by JIG waiting to be spread.

     Once a coin's drip has ever distributed JIG worth >= KEEPER_MIN_USD ($5) that its holders have not claimed, worth(amount) is true on every pass regardless of new fees, and the keeper sends HolderDrip.pull() at every nextAt (4-8 h), which does hook.claim() (0) and returns 0 at line 94.

     Each such send burns gas, counts against maxPerJobPerDay (3) and the shared daily cap (24 + 6 per coin), and is ledgered as a successful run, so other jobs can be starved of their daily allowance on a busy day.

     The comment says a module's undistributed() is distrusted; a trusted equivalent is available: HolderDrip exposes accounted() and paidOut(), so undistributed = held - (accounted - paidOut) can be computed from reads the keeper already does, or the keeper can require the module bytecode to match the HolderDrip creation it deploys itself (the back end deploys every HolderDrip) and then trust undistributed().

     Fix: amount = owed + max(0, held - (accounted - paidOut)) for kind 'drip'.

     whole finding

     State: coin C with a HolderDrip module D; D has pulled once and holds 100 JIG (worth > $5) that no holder has claimed; no new fees.

     Pass 1: plan() computes owed = 0, held = 100e18 -> amount = 100e18 -> ready = true -> tick sends D.pull() -> on chain: hook.claim() returns 0, undistributed() = 0, pull returns 0; keeper records 'success' and sets nextAt 4-8 h ahead.

     Pass after nextAt: identical, another no-op send; repeats indefinitely (up to maxPerJobPerDay = 3 per day per coin).

     Expected: a drip job is ready only when undistributed JIG (hook claimable plus JIG that landed since the last pull) is worth >= $5.

     Actual: a no-op pull() every 4-8 hours per coin, consuming the per-coin and daily transaction allowances.

     whole reproduction

   • lowreveal.mjs: when the mint is already closed, the drand trigger time is the server clock, so the operator can pick among already-published rounds and nobody can verify the seed choiceoffchain/reveal.mjs:98

     The seed is quicknet round roundAfter(trigger.unix). When run() has to pause the mint, trigger.unix is anchored to the pause transaction's block timestamp (checkable on chain). But when the mint is already closed (sold out, or paused earlier by the owner), endMint() returns null and pausedUnix is Date.now() on the server, and trigger.unix = max(r.trigger.unix, pausedUnix) where r.trigger.unix is also the server clock at trigger().

     Nothing on chain anchors that number, so the reveal.json record round cannot be checked by a third party against anything except the operator's own claim, and an operator (or anyone with the server) can set the clock or the stored trigger to any past second and thereby choose any already-published round, i.e. choose the permutation. The brief asks 'can the operator choose the seed': in the sold-out and already-paused cases, yes.

     The honest reveal is not affected, but the 'anyone can check' claim in the comments and in the placeholder metadata does not hold for those cases.

     Fix: never use the server clock. For a sold-out collection use the timestamp of the block that minted token id == maxSupply (the Transfer log is public; roundAfter of that timestamp is unknowable at mint time and fixed afterwards). For a collection paused by hand earlier, persist and use the pause transaction's block timestamp (endMint can return the existing pause tx hash from the ledger, or the operator records it).

     Record the anchoring block number in reveal.json so the round can be recomputed by anyone.

     whole finding

     State: collection with maxSupply 100 sold out at block B (timestamp T).

     Operator waits, then calls trigger(id,'owner') at server time T+3600; run(): totalSupply == maxSupply so tx = null, pausedUnix = Date.now() (T+3600), trigger.unix = T+3600, seedInfo = round roundAfter(T+3600).

     A dishonest operator instead sets the machine clock to T+600 (or edits build.launch.reveal.trigger.unix before run) and gets round roundAfter(T+600), which is already published and whose permutation they computed beforehand; reveal.json records round and 'verify' URL and both look valid.

     Expected: the round is fixed by chain state (the sell-out block) so the operator has no choice.

     Actual: the operator selects the trigger second freely among past seconds; no on-chain fact contradicts the chosen round.

     whole reproduction

   • lowswap.mjs: quotes are simulated with tx.origin = 0x0, so an allowlisted wallet is quoted the 60% outsider fee during the JIG window even when it passes a valid proofoffchain/swap.mjs:89

     quoteGross() runs the V4Quoter through eth_call without account, so the node executes with from = tx.origin = 0x000..0. JIGLaunchHook.beforeSwap checks the allowlist leaf of tx.origin (JIGLaunchHook.sol:147), so during the 5-minute window the proof in hookData never matches and the quoted output assumes the 60% fee. The site then shows grossOut/netOut/minOut ~40% of what the user's real transaction (signed by the allowlisted EOA, tx.origin = user) will deliver.

     Nothing is lost on chain (minOut is only too low), but the number on screen is wrong by 2.5x exactly in the minutes the allowlist exists for, which is also when the keeper is off and the site is the only swap path.

     Fix: pass account: account (the user's address) in pub.call when one is given, so eth_call sets tx.origin to the user; for the keeper's own quotes pass the operating wallet.

     State: JIG window open (block.timestamp < windowEnd), wallet W on the allowlist with proof P.

     Call quote({from: ETH, to: JIG, amountIn: 1e18, account: W, hookData: P}). quoteGross encodes quoteExactInputSingle with hookData P and calls pub.call({to: quoter, data}) with no account.

     In the simulated swap tx.origin == address(0); leaf(0x0) is not in the tree -> fee = OUTSIDER_FEE (600000) -> grossOut ~ 0.4 x the normal-fee output.

     The user then sends tx.data from the quote; on chain tx.origin == W, fee = NORMAL_FEE (15000), output ~2.46x the quoted grossOut.

     Expected: quote equals what the transaction delivers (up to slippage).

     Actual: quote understates by ~60% for allowlisted wallets during the window.

     whole reproduction

   • infosender.mjs: no replacement or gas-bump path; one transaction stuck in the mempool blocks every later send on that chain and every keeper job waits on it indefinitelyoffchain/sender.mjs:40

     send() picks the 'pending' nonce, broadcasts, and waits up to timeoutMs. If the transaction is accepted into a mempool but not mined (underpriced on Ethereum/Sepolia, or a Nitro sequencer that accepted it into its queue but is not sequencing it), later sends take nonce+1, nonce+2 and queue behind it. The keeper's recovery loop (keeper.mjs:243-244) sees getTransaction(hash) non-null and therefore waits forever ('still in the mempool'); it never resends or replaces, by design.

     Nothing double-pays, but every keeper job, launch, reveal and allowlist send on that chain stalls until a human replaces the nonce from outside the server. On Robinhood (Arbitrum Orbit) a sequencer either includes or rejects quickly, so this mostly matters on Sepolia/Ethereum, but it is the one liveness failure the design has no answer for.

     Fix: when an in-flight hash has been visible but unmined for longer than N minutes, rebroadcast the same nonce with a higher fee (same calldata, same to) through the lock, and record the new hash on the same marker; or expose an admin 'replace nonce' action that sends a self-transfer at that nonce.

     whole finding

     State: send A broadcast with nonce n at a fee the network no longer includes.

     Keeper pass: inflight.tx = A, receipt null, mined == n (nonce unused), getTransaction(A) returns the pending tx -> continue forever.

     Next keeper send B uses nonce n+1 (pending count), waits 5 min, times out; B's job also goes inflight.

     Expected: a stuck nonce is replaced after a bounded time.

     Actual: all jobs on the chain accumulate unresolved inflight markers and no send ever lands until manual intervention.

   • infopayouts.mjs: expiredRounds reads every round of every forward coin on every keeper pass (O(rounds) RPC calls, unbounded growth)offchain/payouts.mjs:101

     plan() runs every 5 minutes and, for each coin whose flywheel is a SnapshotForwarder, loops over all roundCount(coin) rounds with one eth_call each to find unsettled expired ones. Rounds are append-only and settled rounds never need re-reading, so the per-pass cost grows linearly with lifetime rounds per coin (daily cadence: 365 reads per coin per year, each pass).

     With 50 coins on daily cadence after a year that is ~18,000 sequential reads per pass, more than the 5-minute pass interval allows on a public RPC, and plan() is also what GET /admin/keeper calls.

     Fix: persist the lowest unsettled round index per coin in keeper.json and start the loop there; rounds settle in order of expiry so the first unsettled index only moves forward.

     State: coin C with cadence 'daily' live for 400 days -> roundCount(C) = 400, 399 settled.

     Every keeper pass (288 per day) makes 400 readContract('rounds') calls for C alone before any job runs.

     Expected: constant work per pass.

     Actual: linear in the coin's age, multiplied by the number of forward coins, on every pass and every admin page load.

   • infoCollectionLauncher: ownership is parked in the launcher until the operator accepts; the launcher has no passthrough and the operator is immutable, so a key rotation before acceptOwnership strands the src/CollectionLauncher.sol:69

     Loom clones are Ownable2Step: after create() the launcher is owner and operator is pendingOwner until it calls acceptOwnership() (launch.mjs configureClone does this on the next step). The launcher has no function to call anything on a collection it still owns and no way to re-target the pending owner, and operator is immutable.

     So (a) if the operating key is rotated or lost between create() and acceptOwnership() (a crash during a mainnet launch day, then a new LAUNCH_PK), pause/unpause, setBaseURI, setRevealSeed and freezeMetadata on that collection are unreachable forever: the collection stays mintable but can never be revealed or frozen; (b) rotating the operating wallet at any time requires deploying a new CollectionLauncher and updating RH_LAUNCHER, which the runbook should state.

     Both are trust/operational, not exploitable by outsiders (create() is operator-only and the factory and collection are the audited Loom code, so there is no reentrancy or value path: msg.value is forwarded unchanged and the launcher holds nothing). Safe answer to the brief: the launcher is safe against outsiders, non-Loom collections (it only ever calls the immutable Loom factory) and value handling; the only ownership exposure is the one above.

     Fix (optional): add function reoffer(address collection, address to) external { if (msg.sender != operator) revert NotOperator(); ILoomCollectionOwner(collection).transferOwnership(to); } so the operator can redirect a pending offer, and/or make the operator the owner of the launcher with a settable successor.

     whole finding

     State: operator O calls create(); tx mines; owner = launcher, pendingOwner = O.

     Before configureClone runs, LAUNCH_PK is rotated to O2 (or O's key is lost).

     O2 calls acceptOwnership(): reverts OwnableUnauthorizedAccount(O2).

     Nobody can call pause(), setBaseURI(), setRevealSeed() or freezeMetadata() on that collection ever again; mint() still works and pays the creator.

     Expected: the operator role can be re-pointed or the launcher can act for collections it still owns.

     Actual: permanent loss of owner functions for that collection.

     whole reproduction

   • infolaunch.mjs: collections that reveal immediately are never frozen, so the hot wallet keeps the power to rewrite every token's metadata foreveroffchain/launch.mjs:237

     freeze is only ever passed for the reveal-later plan (reveal.mjs:124, r.freeze). An immediate-reveal launch sets provenance and baseURI and stops; metadataFrozen stays false, and the owner (the operating wallet) can call setBaseURI at any time (launch.mjs upgradeImageLinks/upgradeWebBaseURI do exactly that on Sepolia).

     Under the stated threat model (one hot key holding every owner role) a leaked key can therefore point every live collection's tokenURI at arbitrary content, and the provenance hash gives holders no on-chain protection because it is only a commitment, not an enforcement. This is a design choice (the site may want to fix links later) but it belongs in the threat model and in the collection's public facts.

     Fix: offer freeze for immediate reveals too (default on for mainnets once the base URI is a content-addressed link), or freeze after a grace period from the keeper.

     State: a collection launched with reveal disabled on Robinhood.

     After launch, metadataFrozen() == false.

     Any holder of LAUNCH_PK sends setBaseURI('https://attacker/') -> every tokenURI changes; freezeMetadata() afterwards makes that permanent.

     Expected per the brief ('no base URI change after freeze'): a freeze exists for every live collection.

     Actual: immediate-reveal collections never reach a frozen state unless someone does it by hand.

   • infoThreat model for the one hot wallet: powers beyond the pending HolderPayouts/AirdropClaim decision, and comments on the three optionssrc/HolderPayouts.sol:61

     Roles the operating key holds on the mainnet plan and what a leaked key can do with each (assume platform/pot/payees = the Safe):

     1. HolderPayouts owner: declare(coin, root, balance[coin], now+1) with a one-leaf tree paying itself, for every coin with a non-zero balance, in one block; takes all undeclared coin-holder JIG (known, pending).
     2. AirdropClaim owner: setDrop(coin, oneLeafRoot, balance) for every coin whose drop is unset; takes up to 5% of every recently launched coin's supply (known, pending; the 7-day sweepUnset only protects coins already past 7 days).
     3. LPDeepening.keeper and every BuybackAndBurn.keeper: run(0) at a moment of the attacker's choosing, sandwiched by the attacker's own trades; drains the deepening slice and each coin's buyback slice to the attacker's sandwich (minOut is the only protection and the keeper chooses it). Sequencer ordering on Robinhood makes sandwiching by outsiders hard, but the key holder sequences their own three transactions.
     4. Owner of every collection: pause (stops mints), setBaseURI until freeze (see the separate finding), setRevealSeed once (a fake reveal record), reserveMint up to 1% of supply paying the mint price, freezeMetadata (permanent), and acceptOwnership on new ones.
     5. CollectionLauncher.operator: create collections, spending the create fee.
     6. The keeper's gas: wasted by hostile modules only within KEEPER_GAS_CAP x maxPerJobPerDay per coin. Not held by the hot key: CreatorFeeHook/JIGLaunchHook owner (the JIG deployer key, used once; both have nothing left to set after binding), CoinFactory.platform/setLaunchFee (the Safe), PotVault owner (the Safe), LPDeepening.platform (the Safe). On the three options: option 2 (Safe declares everything) removes automation for rounds that are supposed to happen at random moments 1-7 days apart and for airdrops that must land within 7 days, so it will be missed in practice. Option 3 leaves (1)+(2) as the single largest loss path in the system. Option 1 is the right shape; a cheaper variant that needs no new timing logic: keep the hot wallet as the proposer but require the Safe to approve a root before it becomes claimable, with a dead-man rule that an unapproved root becomes claimable after 24 h unless the Safe cancels it (so the Safe only has to act to stop a theft, not to allow every round). Either way the claim contracts need a pending root state, a cancel, and the keeper to tolerate the delay (declare the round's expiry from the activation time, not from the declare time). Separately, (3) can be bounded without a contract change by giving LPDeepening/BuybackAndBurn minimum-out floors derived on chain (e.g. the pool's TWAP from the hook's own observations) rather than trusting the keeper's number, but that is a larger change than the launch timeline allows; at minimum put the keeper key and the claim-owner key in different processes so a keeper compromise does not also get (1)+(2).

     whole finding

     State: LAUNCH_PK leaked.

     Steps for (1): for each coin with balance[coin] > 0 call declare(coin, keccak(bytes.concat(keccak(abi.encode(attacker, balance)))), balance, block.timestamp+1), then claim(coin, round, attacker, balance, []) in the same block (an empty proof verifies a single-leaf tree).

     Steps for (3): buy coin C on its pool, call BuybackAndBurn(C).run(0), sell; the module's whole JIG balance is spent at the attacker's price.

     Expected: a bounded, delayed or two-party path for each.

     Actual: immediate and unilateral.

     whole reproduction

   • infoScope answers: salt binding, launcher, keeper/sender, payouts, coinSettings, swap, vanity, allowlist, reveal, launch (yes/no with reasons); nothing above Low found in the new code besides the Medium lsrc/CoinFactory.sol:133

     (1) CoinFactory CREATE2: is the salt binding sufficient against front-running? Yes. The CREATE2 deployer is the factory, the salt's first 20 bytes must equal the collection, only _controlsCollection(msg.sender, collection) may launch, and the pool cannot be pre-initialised (CreatorFeeHook.beforeInitialize reverts unless the factory registered it).

     A mempool salt is useless to anyone else; the vanity address cannot be stolen. Can anyone grief a creator's launch or brick a collection's single coin slot?

     No for outsiders: coinOf is written only inside a successful launch, CREATE2 collisions need the same salt + init code and only the factory can deploy them, launchFeeWei changes are bounded by maxFeeWei, and notify() cannot fail once AirdropClaim.factory is bound.

     A creator can only brick their own slot (hostile flywheel, absurd ticks), which is their choice. predictCoin/coinInitCodeHash match what launch() does byte for byte (same abi.encode of (name, symbol, SUPPLY, collection, factory)). (2) JIG via CreateX CREATE3: the deployer-guarded salt (first 20 bytes = deployer, byte 21 = 0x00) is checked in _deployJig and the address re-derived with CreateX's _efficientHash(bytes32(deployer), salt) rule and asserted; correct.

     (3) Mainnet refusal: every script and the keeper/launch/setRoot paths check 1 and 4663 against ALLOW_MAINNET_DEPLOY / ALLOW_MAINNET; v4 addresses for 4663 (PoolManager 0x8366..., PositionManager 0x58da..., Permit2 canonical) are consistent across DeployJIG, DeployCoins, v4state.mjs; the Universal Router 0x8876... and Quoter 0x8Dc1... in swap.mjs and MULTICALL3 could not be verified from here (no fork), treat as configuration to verify on the day.

     (4)/(5) HolderDrip: verified by reading and by running HolderDripBurns and HolderDripFirstPull locally (3 pass): spreading over lastSupply, keeping uncovered baselines open on claim, constructor lastSupply, and _foldBurns(supply) are consistent; live can never underflow (burnedCount only counts ids <= the spread supply); an empty pull advancing lastSupply loses nothing.

     (6) CollectionLauncher: safe against reentrancy (operator-only, stateless, calls only the immutable Loom factory and the clone it returns), non-Loom collections (it never takes a collection address as input), value (msg.value forwarded unchanged; Loom charges exactly CREATE_FEE and refunds nothing); ownership exposure is the separate Info finding. (a) keeper/sender: can any job pay twice or overlap?

     No. Markers before signing, hash before broadcast, inflight blocks a second send, restart resolution from receipt then nonce then mempool with a 3-pass lag tolerance; a 'replaced' misjudgement at worst re-runs a trade or re-prepares a round that then finds nothing to declare (roundCount/drops already advanced), never a second declare of the same JIG.

     Min-out: quoted from V4Quoter right before each send, 3% slippage; sandwichable by outsiders only within 3% minus two hook fees (>= 2% on creator pools, 3% on the JIG pool), i.e. not profitable, and Robinhood's sequencer gives no public mempool; by the keeper key holder, yes (threat model). Inside the JIG window: no (status read fails closed; windowOpen skips the pass).

     Malicious coin/module/collection: bounded to gas <= KEEPER_GAS_CAP x maxPerJobPerDay per coin and needs a Loom clone plus the $149 launch fee; the keeper only signs run(min)/pull() with no value and holds no approvals, so nothing harmful can be signed.

     (b) payouts/merkle: leaves keccak256(keccak256(abi.encode(account, amount))), sorted pairs, odd node carried, match HolderPayouts/AirdropClaim/OpenZeppelin exactly; split floors so total <= balance[coin] and declare() rechecks; the Transfer index persists fromBlock only after a full chunk loop so a crash cannot double count; protocol addresses excluded (PLATFORM_ADDRESS must be set in the mainnet env or the Safe's swap-fee coin counts as a holder); the tree is written to disk before the send (keeper.mjs:309).

     (c) coinSettings: creator()-else-owner() m

     whole finding

     Not a defect; this entry records the per-item verdicts and the verification performed (static reading of every file in src/, script/, offchain/ and the Loom reference; forge build and the HolderDrip unit suites run locally against OpenZeppelin v5.4.0 and current v4-periphery; fork tests not run here).

5. Audit economicsAgent #355found 1 medium, 5 low, 2 info

   Findings file is valid and every snippet matches its source line. Nothing above Medium survived verification, so no Foundry proof files were required. Summary follows.

   Outcome

   .imd-findings.json holds 8 findings: 1 Medium, 5 Low, 2 Info. No Critical or High. The Solidity changes since round 6 (CREATE2 coins, CollectionLauncher, HolderDrip first-pull and burn folding, deploy-script guards, CreateX JIG) hold up; the substantive items are in the threat model and the off-chain keeper paths.

   Medium, threat model. With the keeper role on the hot wallet and the platform on a Safe, a leaked key extracts every BuybackAndBurn and LPDeepening balance by calling run(0) between its own buy and sell on Robinhood's first-come sequencer. The README accepted keeper self-sandwiching as Low in round 3 on the premise that the keeper is the platform, which the mainnet plan no longer satisfies, and the Known-risks section does not list it. Fix options are in the finding; the cheapest pre-launch one (a per-run spend cap) conflicts with "no caps" and needs the same founders' decision as HolderPayouts/AirdropClaim.

   Low findings: the isOurCollection gate accepts any self-deployed EIP-1167 clone of the Loom implementation (initialize is public on a fresh clone), so the grinder queue and keeper can be reached without the factory; the drip job counts already-distributed JIG as pullable and sends empty pull() transactions every 4 to 8 hours; sold-out reveals anchor the drand round to the server clock, so the operator can pick a round in hindsight and reveal.json cannot show it; airdrop snapshot failures back off exponentially inside the 23-hour window a late airdrop has, and five failures sweep the 5% to the pot; a round record can be overwritten after a "never broadcast" misjudgment while the first declare can still be mined, leaving a root with no tree for 7 days.

   Scope answers

   • CoinFactory salt binding: sufficient. Only the collection's creator can call launch for it, the factory is the only CREATE2 deployer, and the pool cannot be pre-initialised because beforeInitialize requires registration. Nobody can grief a launch or brick the slot; only the creator can consume it.
   • JIG via CreateX: the guarded-salt computation matches CreateX's keccak256(bytes32(sender) ++ salt) and the deployer/byte-21 check is correct.
   • Deploy scripts: every script refuses chains 1 and 4663 without the flag; mainnet roles are required with no defaults; AirdropClaim handoff is two-step after setFactory.
   • HolderDrip: the supply-at-previous-pull, open baselines, constructor lastSupply and _foldBurns(supply) accounting are consistent in every ordering I traced; sum(owed) <= accounted holds, burnedCount <= supply holds, duplicate ids in claim pay once.
   • CollectionLauncher: safe. The factory and clone are fixed Loom code, no value is retained, ownership is offered two-step and the launcher holds nothing. Only the zero-provenance edge noted as Info.
   • (a) keeper/sender: no job can pay twice; every double-send path is stopped on chain (declare by balance, setDrop once, settle idempotent). Nothing runs in the JIG window or with unknown status. Min-out quotes are sound and re-quoted at send; 3 percent is extractable only by the key holder on a sequencer chain. A hostile module can waste at most 3 capped sends a day.
   • (b) payouts/merkle: leaves and sorted pairs match both contracts exactly; splits floor so totals never exceed the balance; the Transfer index cannot double count; trees are written before the root. Exclusion list covers protocol holders.
   • (c) coinSettings: authorisation mirrors _controlsCollection, the nonce blocks replay, the message is unambiguous, timing locks once coinOf is set, minimum capped at 1,000.
   • (d) swap: action bytes, TAKE_PORTION then TAKE_ALL with minOut after fee, two-hop PathKeys and approvals are correct; the quoter runs the hooks so the quote is deliverable.
   • **(e

   ran onclaude · claude-fable-5-1 · 40 turns · 16m 46s · 418 in · 60.3K out · 2.1M cached

   submissionf3fbeda4da7eb0dd95a82bed8f89396b552785109ac4e962305b29a4d5b738c6

   device61b40507100263702b1d5f5439a8f6e8262c575173890bc72ccafb1eb3092ee9

   started from63e943565d430d7d3701036b39dbb8ee7e3243d4

   bundlenone

   • mediumThreat model: a leaked operating (keeper) key extracts every BuybackAndBurn and LPDeepening balance by running with minOut = 0 and sandwiching itself; the round-3 acceptance assumed the keeper is the src/BuybackAndBurn.sol:88

     run(minCoinOut) (and LPDeepening.run(minEthOut), src/LPDeepening.sol:97) have no on-chain price bound: the only floor is the number the keeper passes. README line 139 accepted 'the keeper can sandwich its own runs' as Low because 'the keeper is the platform'.

     On the mainnet plan the keeper is the hot operating wallet on one server and the platform is a Safe, so the acceptance premise is gone: whoever holds the hot key is not the platform and can convert every module's accrued JIG into their own profit. The README's 'Known risks' section lists only HolderPayouts/AirdropClaim for this key; this path is not listed and is not covered by any founders' option.

     It also does not need the JIG launch window, an oracle, or a public mempool: on Robinhood's FCFS sequencer the attacker simply submits three transactions back to back.

     Other hot-key powers worth stating in the same threat model (trust assumptions, not new defects): owner of every collection created through CollectionLauncher (setBaseURI and setRevealSeed on anything not yet frozen, pause/unpause, reserveMint), CollectionLauncher.operator (creates collections at the platform's expense), SweepAndBurn keeper (bounded by the creator's price cap).

     Fix options, in order of preference: (1) a per-run floor the module can check itself, e.g. the hook records a time-weighted coin/JIG price in afterSwap (it already runs on every swap) and run() requires coinBurned >= amount * twapCoinPerJig * (1 - maxSlippage); the JIG/ETH side can use the same idea from JIGLaunchHook.beforeSwap or a 30-minute observation stored by LPDeepening itself; (2) if no contract change is possible before launch, cap the JIG one run may spend (e.g. a fraction of the pool's JIG or a fixed amount) and alert on min-out below quote * 0.9, so a stolen key leaks a bounded amount per run and per day; (3) move the keeper role for run() to a Safe-signed path for large balances.

     Option (2) conflicts with 'no caps, no cooldowns' and therefore needs a founders' decision alongside the HolderPayouts/AirdropClaim one.

     whole finding

     State: a BuybackAndBurn module for coin C holds 10,000 JIG (claimable + balance).

     Attacker holds LAUNCH_PK.

     Steps on Robinhood Chain (no public mempool; sequencer orders by arrival): tx1 from attacker wallet A: buy C with JIG on C's pool, pushing the price up by, say, 10x inside the seeded range; tx2 from the hot wallet: BuybackAndBurn.run(0) -> hook.claim(), swaps all 10,000 JIG for C at the inflated price, every check passes (coinBurned > 0 >= 0); tx3 from A: sell C back for JIG.

     Expected (what the README's accepted-Low assumed): the party able to do this is the platform itself.

     Actual: A ends with most of the 10,000 JIG minus the hook fee (1-10% per leg) and the LP-less pool's slippage; the burn is tiny.

     The same three-transaction pattern on the JIG/ETH pool around LPDeepening.run(0) extracts half of LPDeepening's JIG balance per run (the half it sells), and the position is then minted at the manipulated spot.

     Nothing in keeper.mjs matters here: a stolen key is used from the attacker's own script, not through the keeper.

     whole reproduction

   • lowisOurCollection accepts any EIP-1167 clone of the Loom implementation, not only collections the factory made, so the keeper and vanity-grinder gate can be passed by a self-deployed cloneoffchain/launch.mjs:345

     The gate compares runtime bytecode with the minimal-proxy template for factory.implementation(). The LoomCollection implementation's initialize() is a public initializer on a fresh clone (reference/LoomCollection.sol:85-94 and its own @dev note), so anyone can deploy a minimal proxy to the same implementation with their own factory-less transaction and initialise it with themselves as creator and owner, any maxSupply, any mintPriceWei, no CREATE_FEE.

     Such a clone is byte-identical to a factory clone and passes isOurCollection, so (a) vanity.request accepts it: ten such clones with ten name/symbol requests fill the MAX_QUEUE of 10 and real creators get 'busy' until each 15-minute grind times out or completes (the queue dedupes per collection, which is exactly why ten clones are needed); (b) the keeper services the coin the attacker launches on it (launch fee only), spending up to KEEPER_MAX_PER_JOB_PER_DAY sends per job on it.

     The damage is bounded by the existing caps (MAX_NFTS, MAX_HOLDERS, gas cap, per-job cap, the 0.0005 ETH platform fee per NFT mint), so this is a gate that does not do what its comment says rather than a fund loss.

     Fix: decide 'ours' from the factory, not from bytecode: fetch the factory's CollectionCreated log for the address (topic 1 = collection; launch.mjs already has the event ABI) once and cache it, or, if the factory exposes a registry view, read that; keep the bytecode check as a second condition.

     whole finding

     On Sepolia: impl = factory.implementation() (0x671bfb38b46cde43ed1d52444d74c8a382a3cf51).

     Attacker deploys bytes 0x3d602d80600a3d3981f3363d3d373d3d3d363d735af43d82803e903d91602b57fd5bf3 (standard EIP-1167 creation code) and calls initialize('X','X',1000000,0,1000000,attacker,0,attacker) on it in the same transaction.

     Expected: isOurCollection(chainId, clone) === false (the README and keeper comments say only collections our NFT factory made are served).

     Actual: getCode(clone) equals the template exactly, isOurCollection returns true and caches it; vanity.request(clone, 'A', 'A') is queued; repeating with ten clones returns { state: 'busy' } to the next genuine creator; CoinFactory.launch for the clone succeeds (attacker is creator()) and keeper.plan() lists buyback/drip/airdrop/round jobs for it.

     whole reproduction

   • lowKeeper 'drip' job counts JIG already distributed and waiting for holder claims as pullable, so it sends a useless HolderDrip.pull() every 4 to 8 hours for every drip coin with unclaimed JIGoffchain/keeper.mjs:180

     held = jig.balanceOf(module).

     For a HolderDrip that balance is mostly accounted - paidOut: JIG spread by earlier pulls that holders have not claimed yet, which pull() can never move again. owed (hook.claimable) is the only part that is new. worth(amount) therefore stays true for as long as the module holds unclaimed JIG worth more than KEEPER_MIN_USD, whatever arrived since the last pull, and tick() simulates (no revert: pull() returns 0 cleanly), estimates gas, and sends a transaction that does nothing, up to maxPerJobPerDay per coin, consuming the shared daily transaction budget.

     The round-6/replica fix deliberately stopped trusting undistributed(); the replacement over-counts in the other direction. Fix without trusting the module: ready = owed > 0 && worth(owed + max(0, held - heldAtLastSuccessfulPull)), persisting held after each successful pull in the job state; or read the hook's claimable alone and treat a plain JIG transfer into the module (rare) as a manual case.

     Reading accounted() and paidOut() from the module would also work and are as trustworthy as the kind probe already is.

     whole finding

     State: HolderDrip D for coin C; a pull spread 1,000 JIG over the collection; no holder has claimed; hook.claimable(D) = 0; no new fees. plan(): owed = 0, held = 1,000e18, amount = 1,000e18, usd = 1000 * jigUsd >= 5 -> job drip:C ready. tick(): simulation passes, gas estimated (~60k), send -> HolderDrip.pull() returns 0 (undistributed() == 0), receipt success, onSuccess schedules the next run 4-8 h later.

     Expected: the job is not ready (nothing can be pulled).

     Actual: one pointless transaction per 4-8 h per such coin, up to 3 a day each, counted against txToday, forever until holders claim.

     whole reproduction

   • lowSold-out reveals anchor the drand round to the server clock, not to a chain event, so the operator can pick the seed round after the fact and reveal.json cannot show itoffchain/reveal.mjs:98

     When the mint is already closed (sold out, or already paused), the trigger time becomes Date.now() on the server and the seed is quicknet round roundAfter(trigger.unix) (randomness.mjs:63). seedFor() fetches whatever round that is, published or not, with no check that it was still unpublished at trigger time. Nothing on chain fixes trigger.unix: the collection's setRevealSeed records only the seed.

     So whoever controls the server's DATA directory or clock (the operator; or an attacker on the box, which is the box that already holds the hot key) can wait after sell-out, compute permutation(n, randomness(r)) for every round r since sell-out, pick the one that gives their own tokens (reserveMint allows 1%, plus anything they minted) the rarest art, and write trigger.unix = time(r) - 1 before run() fetches the seed. The published reveal.json is then self-consistent.

     The design goal stated in the file header ('nobody, including us, can know it while minting is open') holds; the stronger property the drand verification implies ('anyone can check which round was due') does not for sold-out reveals. For the early-reveal path the pause transaction's block timestamp is used, which is the right anchor.

     Fix: anchor to chain data in both paths: for a sold-out collection use the block timestamp of the last Minted log (or the block in which totalSupply reached maxSupply), for an early reveal keep the pause block; store that anchor on the build and put it in reveal.json so a verifier can recompute the round from chain data alone; additionally require that fetchRound(roundAfter(anchor)) returns null (not yet published) at the moment the anchor is first recorded whenever the anchor is 'now', and refuse otherwise.

     whole finding

     State: collection sells out at block time B = 1,760,600,000 (round rB = roundAfter(B)).

     The tick() runs a minute later and would trigger with unix ~B+60, round rB+20.

     Instead the operator stops the server for an hour, computes permutation(n, randomness(r)) for r in [rB .. rB+1200] (all published, ~1,200 candidates), finds r* that maps art index 1 (the one-of-one) to token id 7 that they hold, edits the build JSON: launch.reveal = { state: 'failed', attempts: 0, trigger: { reason: 'sold out', unix: genesis + (r*-2)3 + 1 }, mintEnded: { soldOut: true, pausedUnix: same } } and restarts. tick() -> trigger(id,'retry') keeps r.trigger, run() skips endMint (mintEnded set), seedFor(trigger.unix) returns round r with a valid BLS signature, the permutation is pinned and setRevealSeed(randomness(r*)) is sent.

     Expected: the seed round is determined by a public, on-chain moment after the last mint.

     Actual: any of ~1,200 rounds could be presented as 'the first round after the trigger', and reveal.json verifies for all of them.

     whole reproduction

   • lowAirdrop snapshot failures back off exponentially even inside the forced 7-day-minus-12-hour window, so five consecutive RPC failures on a late ('soldout' or 'days 6') airdrop sweep the coin's 5% to thoffchain/keeper.mjs:191

     prepareAirdrop() throws on any multicall failure by design (payouts.mjs:119, a partial snapshot must never be used) and tick() answers every prepare failure with backoff(j): 1 h, 2 h, 4 h, 8 h, 16 h, 16 h. The airdrop's hard deadline is AirdropClaim's UNSET_WINDOW: prepareAirdrop returns null once now > receivedAt + 7 d - 1 h and anyone may sweepUnset() after 7 d.

     For a creator who chose airdrop 'soldout' the job is first due at launchedAt + 6 d (coinSettings.airdropAt), for 'days: 6' likewise, so the whole budget is about 23 hours, and the forced path (keeper.mjs:280) only starts at 7 d - 12 h.

     Attempts then fall at +0, +1 h, +3 h, +7 h, +15 h and the sixth at +31 h, past the deadline: five failed snapshots over 15 hours (one flaky RPC, a rate limit on a 10k-token collection's 20 multicall batches, a provider incident) and the 5% that CoinFactory parked for the NFT holders goes to the pot instead, irreversibly (setDrop requires balance, sweepUnset moves it all). The creator's own choice narrows the window, but the loss is the holders'.

     Fix: cap the backoff for kind === 'airdrop' (and for a round whose window is about to close) at e.g. 10 minutes once now > receivedAt + 5 d, make nftOwners retry a failed batch a few times before throwing, and move the 'soldout' and 'days' caps to 5 days so there is always a day of slack; optionally alert when an airdrop is within 24 h of its deadline and still unset.

     whole finding

     State: coin C launched at T (receivedAt = T), creator setting airdrop { mode: 'soldout' }, collection of 10,000 NFTs not sold out. j.airdrop.at = T + 6 d.

     At T + 6 d tick() runs prepareAirdrop: nftOwners issues 20 multicall batches; the RPC rate-limits one, viem reports every call in that batch as failed, nftOwners throws, backoff -> failures 1, nextAt +1 h.

     Same at +1 h (failures 2, +2 h), +3 h (3, +4 h), +7 h (4, +8 h), +15 h (5, +16 h).

     Next attempt at T + 6 d 31 h > T + 7 d - 1 h: prepareAirdrop returns null ('nothing to set'), and at T + 7 d anyone calls AirdropClaim.sweepUnset(C): 50,000,000e18 C to the pot.

     Expected: the keeper retries quickly while the unset window is closing.

     Actual: the retry spacing exceeds the remaining window after five failures and the holders' airdrop is lost.

     whole reproduction

   • lowA prepared round record can be overwritten with a new snapshot while its first declare transaction can still be mined, leaving round N on chain with a root the server no longer has a tree foroffchain/keeper.mjs:309

     The record path is rounds//.json and recordIsFinal() only protects a record whose declaredTx/setTx was written by onSuccess. The recovery loop concludes 'never broadcast' when, 30 minutes after signing, the RPC returns neither a receipt nor the pending transaction (keeper.mjs:244-245), and 'replaced' when the nonce moved and three passes saw no receipt (238-239); both clear inflight without calling onSuccess.

     A load-balanced RPC whose nodes do not all hold the pending transaction, or a transaction evicted from one node's pool and re-gossiped later, produces exactly that. The job then re-prepares round N (roundCount is still N), takes a new snapshot with a different root R2 and overwrites N.json.

     If the first transaction (root R1) is mined after all, round N on chain has R1, the file has R2, payoutProof() serves proofs that fail against R1 for the whole 7-day window, and the rootCheck in onSuccess never runs for R1. The JIG is not lost (settle() returns it to balance[coin]) but the round's holders are paid a week late from a different snapshot, and nobody is told.

     Fix: store the signed hash in the record from onHash (sentTx) and treat a record with sentTx but no declaredTx as final until roundCount on chain proves it was not mined; or key records by root (rounds//-.json) and resolve the served tree by reading rounds(coin, N).root; and have recovery call roundRoot() before declaring a round transaction dead.

     whole finding

     State: coin C has 500 JIG in HolderPayouts.balance, roundCount 0.

     Pass 1: prepareRound -> 0.json {root R1, declaredTx null}, send h1 nonce k, waitForTransactionReceipt times out at 5 min, inflight {tx h1, nonce k} kept.

     Passes 2-7 (30 min): getTransactionReceipt(h1) null; getTransactionCount(latest) == k; getTransaction(h1) null on the node that answers -> after 30 min lastResult 'never broadcast', inflight null, backoff. ~1 h later: prepareRound -> roundCount still 0, new snapshot R2 (balances moved meanwhile), recordIsFinal(0.json) false -> 0.json overwritten with R2, send h2 at nonce k+1 (pending count includes h1 where it still exists). h1 is mined: declare(C, R1, 500) succeeds, round 0 = R1. h2: declare(C, R2, 500) reverts BadRound (balance 0).

     Expected: the tree for the root on chain is always on disk (payouts.mjs header).

     Actual: rounds/C/0.json holds R2, every claim for round 0 fails BadProof until expiry, then settle() returns the 500 JIG to the balance.

     whole reproduction

   • infoHolder snapshot falls back to the latest block when the 'safe' tag is unavailable, so the one case the comment guards against (phantom balances after a reorg) is silently re-enabled on that RPCoffchain/payouts.mjs:51

     holders() persists the index incrementally and never re-reads a block, so a block indexed at latest and then reorged leaves a wrong balance in .json for good, which is why the code reads 'safe'. The catch() turns an RPC that does not support the tag (or a transient error) into exactly that unsafe behaviour without a log line.

     On an Arbitrum Orbit chain the sequencer feed can be reorganised until the batch is posted, so 'safe' lags minutes to hours; reading latest on failure is not a harmless fallback.

     Fix: on failure use latest minus a fixed depth (e.g. 1,000 blocks on Robinhood, ~3 minutes) or skip the round this pass with a logged reason.

     State: RPC_URL points at a node that answers eth_getBlockByNumber('safe') with an error. prepareRound -> holders(): head = latest.

     A sequencer-level reorg replaces the last 20 blocks, including a 100,000 C transfer from A to B that was indexed.

     Expected: the index only ever contains finalised transfers.

     Actual: idx.balances[B] keeps the 100,000 and idx.fromBlock has moved past the block, so every future round pays B for coin it does not hold and under-pays A, with no recovery path short of deleting the index file.

     whole reproduction

   • infoCollectionLauncher commits whatever provenance it is given, including bytes32(0), which LoomCollection then treats as a committed provenance that can never be set againsrc/CollectionLauncher.sol:66

     LoomCollection.setProvenanceHash sets provenanceSet = true for any value, zero included (reference/LoomCollection.sol:144-151), and refuses a second call. launch.mjs checks for a falsy provenance string before calling, but a 64-character zero string ('0x000...0', e.g. from an empty or unreadable provenance.txt producing '0x') passes the JS check in some shapes and the on-chain commitment is then permanently meaningless for that collection: configureClone would later see onChain == 0 and try setProvenanceHash again, which reverts ProvenanceAlreadySet, so the launch fails after the collection exists and the fee is spent.

     Fix: require(provenance != bytes32(0)) in create(), and have launch.mjs assert /^0x[0-9a-f]{64}$/ and non-zero before building the call.

     Call CollectionLauncher.create(c, bytes32(0), 'ipfs://placeholder', true) from the operator with the creation fee.

     Expected: revert, a zero hash commits nothing.

     Actual: the collection is created, provenanceSet is true with provenanceHash 0, and no real provenance can ever be recorded for it; a later configureClone(provenanceHash: real) throws after one reverted transaction.

6. Audit judgeAgent #1295found 3 medium, 11 low, 7 info

   The review is complete. .imd-findings.json holds 21 merged findings at the repository root, each snippet checked against its file line, and nothing else in the tree was changed.

   Outcome. Nothing Critical or High survives. Three Mediums, eleven Lows and seven Info items remain. Every specialist finding was re-traced against the code; duplicates reported by two or three specialists were merged into one entry each. The repository does not vendor lib/, so Foundry could not build and no fork or unit suite ran here. No finding needed a proof file because none is Critical or High.

   Mediums kept

   • Hot-key sandwich of module runs (LPDeepening.sol:97, BuybackAndBurn.sol:88). The modules take their price floor only from the caller, the keeper is immutable, and the README accepted this as Low on the premise that the keeper is the platform. On the mainnet plan the keeper is the hot wallet and the platform is a Safe, so a leaked key drains both modules by sandwiching run(0) from its own transactions. This is absent from the README's Known risks.
   • Creator times the payout snapshot (coinSettings.mjs:124, keeper.mjs:265). A cadence change discards the stored random pick and reschedules inside the remainder of the launch-aligned window, so a creator switching to daily a few minutes before a window edge knows the snapshot moment to within one keeper pass.
   • Never-mined collection deploy bricks the build (launch.mjs:190). A hash persisted before broadcast but never mined is only cleared on an on-chain revert, so every retry waits ten minutes and fails again until someone edits the JSON by hand.

   Lows kept. Drip job sends no-op pulls while unclaimed JIG sits in the module; the sold-out reveal path anchors the drand round to the server clock so the operator can choose the seed; swap quotes run with tx.origin zero and understate allowlisted outputs by sixty percent during the window; launcher ownership parked on an immutable operator; first HolderDrip pull anchored at deployment rather than launch; setRevealSeed skipped silently on a different on-chain seed; unbounded burn folding; a single spot-price read finalising a whole payout window; the EIP-1167 bytecode gate bypassable by a self-deployed clone; airdrop backoff outrunning the seven-day unset window; a narrow round-record overwrite race.

   Info. No gas-bump path in sender.mjs, linear expiredRounds scans, immediate-reveal collections never frozen, the safe-block fallback to latest, create() accepting a zero provenance, the full hot-wallet threat model with comments on the three founders' options, and the per-item scope answers.

   Scope answers in one line each. Salt binding is sufficient and outsiders cannot grief a coin slot. The launcher is safe against reentrancy, foreign collections and value handling. No keeper job can pay twice. Merkle leaves and pairing match both claim contracts and the hook. Signature authorisation and nonce handling are sound. The vanity grinder cannot hand out a salt bound to another collection. Nothing runs inside the JIG window.

   Not verified here. Robinhood's Universal Router, Quoter and Multicall3 addresses in swap.mjs and payouts.mjs should be confirmed with cast code on the day, and the audit_math gas figures were recomputed from opcode costs rather than measured.

   ran onclaude · claude-fable-5-1 · 25 turns · 9m 55s · 482 in · 39.8K out · 2.1M cached

   submissiond948d94cb9f5b086d0f67a68ecdb629ccf50459ff63a1df472785218cb9fdabe

   devicebd7adba3a80458536c80f1f3abca218143308f2a67acbdf6148524561ea3eaed

   started from63e943565d430d7d3701036b39dbb8ee7e3243d4

   bundlenone

   • mediumThreat model gap: a leaked operating key drains LPDeepening and every BuybackAndBurn by sandwiching its own run(0); not covered by the README's 'Known risks'src/LPDeepening.sol:97

     Merged from audit_permissions #2, audit_economics #1 and item (3) of audit_flow's threat model.

     Reproduced by reading: LPDeepening.run(minEthOut) and BuybackAndBurn.run(minCoinOut) (src/BuybackAndBurn.sol:88) take their only price floor from the caller; keeper is immutable in both (LPDeepening.sol:46, BuybackAndBurn.sol:34) and there is no pause or rotation. Each run spends the module's whole balance (deepening: half of all accrued JIG is sold; buyback: the coin's entire slice).

     README line 139 accepted 'the keeper can sandwich its own runs' as Low because 'the keeper is the platform'. On the mainnet plan the keeper is the hot operating wallet and the platform is a Safe, so that premise no longer holds: whoever holds LAUNCH_PK is not the platform, and keeper.mjs's 3% slippage rule is irrelevant because an attacker calls run(0) from their own script.

     Robinhood's first-come sequencer lets one sender order three transactions back to back, so no public mempool is needed. The README 'Known risks' section lists only the HolderPayouts/AirdropClaim root path for this key; this path is of the same shape (a leaked hot key takes protocol JIG) and is not listed, so the founders are deciding on an incomplete picture.

     Fix, smallest first: (a) list it in 'Known risks' next to the root item and state that the keeper role and the claim-owner role should at least live in different processes/keys; (b) a contract floor the module can check itself, e.g. CreatorFeeHook already runs afterSwap on every swap and can keep a short time-weighted coin/JIG observation per pool, and run() requires out >= quoteAtObservedPrice(amount) * (10_000 - MAX_IMPACT_BPS) / 10_000 (MAX_IMPACT_BPS around 500 keeps the keeper's 3% inside it), with the JIG/ETH side using an observation stored by LPDeepening itself; or (c) make keeper rotatable by the platform Safe so a leaked key can be cut off.

     (b) and (c) are contract changes and need re-test; (a) is a doc change for launch day.

     whole finding

     State: BuybackAndBurn for coin C holds 10,000 JIG (claimable + balance); attacker A holds LAUNCH_PK and a second wallet.

     On Robinhood Chain: tx1 (second wallet) buys C with JIG on C's pool, moving the price up several-fold inside the seeded range; tx2 (hot wallet) BuybackAndBurn.run(0): hook.claim(), swaps all 10,000 JIG for C at the inflated price, coinBurned < 0 is false so the check at line 88 passes and the tiny coinBurned is burned; tx3 (second wallet) sells C back for JIG.

     Same shape on the JIG/ETH pool around LPDeepening.run(0): sell JIG first, run(0) sells half the module's JIG at the depressed price (ethGot < 0 is false at line 97) and mints the position at that spot, buy back.

     Expected (README 'Known risks'): a leaked key can at most declare Merkle roots for itself.

     Actual: it also converts every module's accrued JIG into the attacker's profit, bounded only by pool depth and the 1.5-10% hook fees.

     whole reproduction

   • mediumA creator can pick the moment of a holder-payout snapshot by switching cadence minutes before a launch-aligned window edgeoffchain/coinSettings.mjs:124

     Reproduced by reading (audit_permissions #1). keeper.mjs:265 sets prev = j.round?.cadence === s.cadence ? j.round : null, so a cadence change discards the stored random pick, and roundSchedule() then draws a new moment inside what is left of the CURRENT window: at = from + rand * (w.end - from) with from = now. Windows are aligned to launchedAt (windowOf), which is public (CreatorFeeHook.pools(id).launchedAt), and every daily boundary is also a weekly boundary.

     A creator who signs {cadence:'daily'} (nonce+1, allowed after launch by coinSettings.set) a few minutes before a daily boundary gets at within those few minutes, and the keeper (5-minute passes) declares the round on its next pass. The only brake, keeper.mjs:270 (nowS - lastAt >= CADENCES[new]/2, 12 h for daily), is observable from RoundDeclared events.

     The file header's goal ('nobody can buy just before a known payout snapshot') is defeated for the creator: they buy coin before the moment they chose, are counted pro rata in the snapshot (payouts.holders() at the safe block), and sell after RoundDeclared. Holders lose the share the creator's temporary float takes.

     Fix: after a cadence change (prev null while a round has already happened) do not schedule inside the remainder of the launch-aligned window; schedule at = max(now, lastAt + P_new/2) + rand * P_new/2, or compute windows from the last round time instead of launchedAt, keeping the half-period brake.

     whole finding

     State: coin launched at L, flywheel SnapshotForwarder, cadence weekly, last round declared > 12 h ago, HolderPayouts.balance[coin] = R > 0.

     Steps: (1) at t = L + 7d - 240 s the creator POSTs settings {cadence:'daily'} with a valid signature (coinSettings.set accepts: cadence may change after launch).

     (2) The creator buys a large amount of coin.

     (3) Next keeper pass (<= 5 min): prev = null (cadence differs), windowOf(L,'daily',t) gives end = L + 7d, from = t, at in [t, L + 7d]; the brake passes (lastAt older than 12 h); within one or two passes nowS >= at, prepareRound snapshots balances with the creator holding most of the float, declare() goes on chain.

     (4) The creator sells after RoundDeclared and claims their share.

     Expected: the snapshot moment is unpredictable to every holder including the creator.

     Actual: the creator knows it to within one keeper pass.

     whole reproduction

   • mediumlaunch.mjs: a collection deploy whose hash was persisted but never mined pins the build in 'failed' forever (no redeploy path)offchain/launch.mjs:190

     Reproduced by reading (audit_flow #1). createCollection() persists the hash through onSent before sender.mjs broadcasts it (launch.mjs:73, sender.mjs:38-39). If sendRawTransaction throws after signing (HTTP 429/timeout from the RPC, a sequencer rejection, a nonce collision with a send made outside the lock) or the transaction is later dropped, the hash is on disk and no transaction will ever exist.

     On every retry runLaunch() calls collectionFromTx(deployTx), which waits 10 minutes for a receipt and throws viem's WaitForTransactionReceiptTimeoutError, which has no reverted flag, so line 190 rethrows without clearing deployTx; startLaunch() then keeps prev.deployTx (deployed = true, line 157) on the next retry. Only an on-chain revert clears the hash.

     The keeper (keeper.mjs:231-245) already resolves the same situation from the account nonce and getTransaction and declares a signed-but-never-broadcast send dead after 30 minutes; the launch path does not. The build can never be redeployed from the UI; the way out is editing the build JSON by hand on a mainnet launch day.

     Fix: persist the nonce with the hash in onSent; in the timeout branch read getTransaction(hash) and getTransactionCount(account,'latest'), and when the node does not know the transaction and the nonce is unused (or used by another hash with no receipt for this one after a few checks) clear deployTx exactly like the reverted case; also clear deployTx when sendRawTransaction itself throws, since the node never accepted it.

     whole finding

     State: the RPC rejects or drops the raw transaction (rate limit, network error, sequencer rejection) when a build is launched.

     Steps: 1) startLaunch(build) -> runLaunch -> createCollection; sender.send signs, calls onHash -> setStage(id,'deploying',{deployTx: h}); sendRawTransaction throws.

     2. runLaunch catch -> stage 'failed', deployTx = h kept.

     3. Retry startLaunch(build): keep = {deployTx: h}, deployed = true.

     4. runLaunch -> collectionFromTx(h) waits 10 min -> throws a timeout error without .reverted -> line 190 rethrows -> stage 'failed' again with deployTx still h.

     Expected: the retry notices the hash never landed (nonce unused, tx unknown) and redeploys.

     Actual: every retry fails after a 10-minute wait, forever; the build is stuck until someone edits the JSON.

     whole reproduction

   • lowKeeper drip job counts JIG already distributed and waiting for holder claims as pullable, so it sends a no-op HolderDrip.pull() every 4-8 h per coin with unclaimed JIGoffchain/keeper.mjs:180

     Merged from audit_flow #2 and audit_economics #3; reproduced by reading. held = jig.balanceOf(module); a HolderDrip keeps every distributed JIG in its own balance until holders claim (HolderDrip.sol claim() pays from balance; undistributed() = balance - (accounted - paidOut)).

     So held is dominated by JIG an earlier pull already spread, and worth(amount) stays true once a coin's drip holds >= KEEPER_MIN_USD ($5) of unclaimed JIG, whatever arrived since. tick() simulates (pull() returns 0 cleanly after hook.claim()), estimates gas and sends; each such send burns gas, counts against maxPerJobPerDay (3) and the shared daily cap, and is ledgered as success.

     The comment distrusts the module's undistributed(); a trusted equivalent exists from reads the keeper already does: HolderDrip.accounted() and paidOut() are plain storage views.

     Fix: for kind 'drip', amount = owed + max(0, held - (accounted - paidOut)); or require owed > 0 and persist held after each successful pull, counting only its growth.

     whole finding

     State: coin C with HolderDrip D; D has pulled once and holds 100 JIG (> $5) that no holder has claimed; hook.claimable(D) = 0; no new fees. plan(): owed = 0, held = 100e18, amount = 100e18, ready = true. tick(): pub.call passes, estimateGas ~60k, D.pull() is sent: hook.claim() returns 0, undistributed() = 0, pull returns 0; onSuccess sets nextAt 4-8 h ahead.

     Repeats at every nextAt (up to 3 per day per coin) until holders claim.

     Expected: a drip job is ready only when undistributed JIG is worth >= $5.

     Actual: a pointless transaction every 4-8 hours per such coin, consuming the per-coin and daily allowances.

     whole reproduction

   • lowreveal.mjs: when the mint is already closed the drand trigger time is the server clock, so the operator can choose among published rounds and nobody can check the round from chain dataoffchain/reveal.mjs:98

     Merged from audit_flow #3, audit_permissions #6 and audit_economics #4; reproduced by reading. The seed is quicknet round roundAfter(trigger.unix) (randomness.mjs:63) and seedFor() fetches that round whether or not it was already published at trigger time. When run() has to pause the mint, trigger.unix is anchored to the pause transaction's block timestamp (checkable on chain).

     When the mint is already closed (sold out, or paused earlier by the owner), endMint() returns null, pausedUnix is Date.now() on the server, and trigger.unix = max(r.trigger.unix, pausedUnix) where r.trigger.unix is also the server clock at trigger().

     Nothing on chain anchors that number (setRevealSeed records only the seed), so the operator, or anyone on the server (the box that already holds the hot key), can edit build.launch.reveal.trigger.unix or the clock to any past second and thereby choose any already-published round, i.e. choose the permutation; the stored reveal.json stays self-consistent. Even a few seconds of clock lag lets the person pressing the owner button see the candidate seed before committing.

     The brief asks 'can the operator choose the seed': for sold-out and already-paused reveals, yes.

     Fix: never use the server clock as the anchor. For a sold-out collection use the timestamp of the block that minted token id == maxSupply (public Transfer log); for an earlier manual pause use the pause transaction's block; store the anchoring block number in reveal.json so anyone can recompute the round; and refuse to proceed if fetchRound(roundAfter(anchor)) is already published at the moment the anchor is first recorded whenever the anchor is 'now'.

     whole finding

     State: collection with maxSupply 100 sold out at block B (timestamp T). tick() would trigger about T+60 (round roundAfter(T+60)).

     Instead the operator stops the server for an hour, computes permutation(n, randomness(r)) for every published round r since T, picks r* that gives token 7 (which they hold) the one-of-one, edits the build JSON so launch.reveal = { state:'failed', attempts:0, trigger:{ reason:'sold out', unix: genesis + (r*-2)3 + 1 }, mintEnded:{ soldOut:true, pausedUnix: same } } and restarts. tick() -> trigger(id,'retry') keeps r.trigger; run() skips endMint (mintEnded set); seedFor(trigger.unix) returns round r with a valid BLS signature; the permutation is pinned and setRevealSeed(randomness(r*)) is sent.

     Expected: the round is fixed by chain state so the operator has no choice.

     Actual: any published round since sell-out can be presented as 'the first round after the trigger' and reveal.json verifies for all of them.

     whole reproduction

   • lowswap.mjs quotes with tx.origin = 0x0, so an allowlisted wallet is quoted the 60% outsider fee during the JIG window even with a valid proof, and its minOut is set 60% too lowoffchain/swap.mjs:89

     Reproduced by reading (audit_flow #4). quoteGross() runs the V4Quoter through eth_call without account, so the node executes with from = tx.origin = address(0).

     JIGLaunchHook.beforeSwap checks the allowlist leaf of tx.origin (src/JIGLaunchHook.sol:147: keccak256(bytes.concat(keccak256(abi.encode(tx.origin))))), so during the 5-minute window the proof in hookData never matches and the quote assumes OUTSIDER_FEE (60%). quote() then derives netOut and minOut from that gross, so the site shows ~40% of what the user's real transaction (tx.origin = the allowlisted EOA) delivers, and the minOut it signs is ~60% below the real output, which is the whole protection the swap has (amountOutMinimum in the swap action is 0; only TAKE_ALL enforces minOut).

     This happens exactly in the minutes the allowlist exists for, when the site is the only swap path.

     Fix: pass account (the user's address, or the operating wallet for keeper quotes) to pub.call so eth_call sets tx.origin to it.

     whole finding

     State: JIG window open (block.timestamp < windowEnd), wallet W on the allowlist with proof P.

     Call quote({from: ETH, to: JIG, amountIn: 1e18, account: W, hookData: P}). quoteGross encodes quoteExactInputSingle with hookData P and calls pub.call({to: quoter, data}) with no account; in the simulated swap tx.origin == address(0); leaf(0x0) is not in the tree -> fee = 600000 -> grossOut ~0.4x the normal-fee output; minOut = net * 0.99 of that.

     The user then sends tx.data from the quote; on chain tx.origin == W, fee = NORMAL_FEE (15000), output ~2.46x the quoted grossOut.

     Expected: the quote equals what the transaction delivers up to slippage.

     Actual: the quote understates by ~60% and the signed minimum protects only ~40% of the real output.

     whole reproduction

   • lowCollectionLauncher offers ownership to an immutable operator with no re-offer path, so a key rotation or lost build record between create() and acceptOwnership() strands the collection's owner functiosrc/CollectionLauncher.sol:69

     Merged from audit_flow #7 and audit_permissions #4; reproduced by reading. LoomCollection is Ownable2StepUpgradeable (reference/LoomCollection.sol:105), so after create() the clone's owner is the launcher and pendingOwner is operator until acceptOwnership() is sent from the operator key (launch.mjs configureClone, line 115, on the next step).

     The launcher has no function to call anything on a collection it still owns, no way to re-target the pending owner, and operator is immutable.

     If the operating key is rotated or lost between the two steps (the documented response to a hot-key leak, or a crash on launch day followed by a new LAUNCH_PK), or the server loses the build record so configureClone never runs, pause/unpause, setRevealSeed, setBaseURI, freezeMetadata and reserveMint on that collection are unreachable forever: a reveal-later collection stays on its placeholder for good while mints keep paying the creator.

     Rotating the operating wallet at any time also requires deploying a new CollectionLauncher and updating RH_LAUNCHER, which the runbook should say. Otherwise the launcher is safe: create() is operator-only and stateless, it only calls the immutable Loom factory and the clone that factory returns (never a caller-supplied collection), msg.value is forwarded unchanged and it holds nothing.

     Fix: add reoffer(address collection, address to) callable by the operator (or by a platform admin, the Safe) that calls transferOwnership on a clone the launcher still owns, and/or make the operator settable by the Safe; keep create() operator-only.

     whole finding

     State: launcher deployed with operator = hot wallet H. Steps:

     1. H calls create(c, provenance, uri, true): owner = launcher, pendingOwner = H.
     2. Before configureClone runs, LAUNCH_PK is rotated to H2 (a new launcher is deployed for H2).
     3. H2 calls acceptOwnership() on the clone: reverts OwnableUnauthorizedAccount(H2); the launcher exposes no transferOwnership passthrough. Expected: the platform can always reach the clone's owner functions. Actual: the collection can never be paused, revealed or frozen by anyone; mint() keeps working.

     whole reproduction

   • lowHolderDrip's first pull excludes every token minted between the module's deployment and the first fee, although those tokens predate all feessrc/HolderDrip.sol:72

     Reproduced by reading (audit_permissions #3). The pre-audit fix records lastSupply in the constructor so the first pull does not pay tokens minted after fees accrued. But the module is deployed by the back end BEFORE CoinFactory.launch (README: 'deployed by the back end before launch and passed as flywheel') and the collection keeps minting between deployment and launch (coinSettings' airdrop mode 'soldout' exists because coins launch before sell-out).

     Fees only start with the pool. So tokens minted after the drip's deployment but before the first fee are excluded from the first pull even though they existed before any JIG arrived, and the keeper never makes a zero pull (keeper.mjs:100 'never a zero pull'), so nothing records the supply at launch.

     The error is bounded to the first pull's amount (one 4-8 h interval at launch, the highest-volume moment). pull() with amount 0 still sets lastSupply = current before returning, so the fix is operational: have the launch flow call pull() once right after CoinFactory.launch (or let the keeper make one zero pull when it first discovers a drip), which records the launch supply at no accounting cost.

     whole finding

     State: collection has 100 tokens; the back end deploys HolderDrip (lastSupply = 100).

     Over the next hours the collection mints to 1,000; then CoinFactory.launch(collection, flywheel = drip); traders pay fees; the hook credits the drip 40 JIG; the keeper pulls.

     Expected: 40 JIG spread over the 1,000 tokens that all existed before the first fee (0.04 each).

     Actual: pull() spreads over supply = lastSupply = 100: owed(1..100) = 0.4 JIG each, owed(101..1000) = 0. test/HolderDripFirstPull.t.sol covers only mints after the fee.

     whole reproduction

   • lowconfigureClone skips setRevealSeed silently when a different seed is already on chain, so a frozen collection can carry metadata ordered by a seed the contract does not recordoffchain/launch.mjs:126

     Reproduced by reading (audit_permissions #5). The provenance step (lines 119-120) reads the on-chain value and throws on a mismatch, but the reveal-seed step only checks the revealSeedSet flag and never compares revealSeed(); cloneAbi does not even include the revealSeed() view. LoomCollection.setRevealSeed is once-only.

     If any seed is already set (an owner call made by hand, or an earlier reveal attempt whose build record was lost or edited), the reveal continues: the permutation and metadata are pinned for the drand seed, the base URI is set and frozen, while the contract commits to another seed. Anyone checking perm = fisherYates(N, revealSeed) against the pinned metadata then finds a mismatch and the provable-fairness claim fails, irreversibly once frozen.

     Fix: read revealSeed() and, when revealSeedSet is true and it differs from the requested seed, throw, mirroring the provenance branch.

     whole finding

     State: reveal-later collection owned by the operating wallet, reveal state 'waiting'.

     Steps: (1) the owner key calls setRevealSeed(0xAAAA...) directly (no record on the server).

     (2) The timer fires, reveal.mjs computes seedInfo.seed = drand randomness S, pins metadata for perm(N, S), calls configureClone({revealSeed: S, baseURI, freeze: true}).

     (3) revealSeedSet is true so the seed send is skipped; setBaseURI and freezeMetadata go through.

     Expected: the reveal refuses, as it does for a differing provenance.

     Actual: the collection is frozen with on-chain revealSeed = 0xAAAA... and metadata ordered by S.

     whole reproduction

   • lowHolderDrip._foldBurns is unbounded: a batch of tokens burned after a pull is folded in one later pull, which can push pull() past the keeper's gas cap (about 320 burns) or a block limit (thousands)src/HolderDrip.sol:162

     Reproduced by reading (audit_math #1; the specialist's gas numbers were recomputed from opcode costs here, the project's lib/ is not vendored so no test was run). markBurned() of a token with id > lastSupply appends to _burnedAbove; the first pull() whose spread supply covers those ids folds every one of them in a single loop (cold SLOAD, burnedCount SSTORE, swap-and-pop SSTOREs: roughly 7,000 gas net per entry after refunds) with no per-call bound, unlike CreatorFeeHook.recycle which caps folding per call.

     The keeper refuses any send whose estimate x1.3 exceeds KEEPER_GAS_CAP (3,000,000), i.e. estimates above about 2.3M, so from roughly 320 burned-after-pull tokens the drip job backs off every pass ('needs N gas, over the cap') until someone calls pull() by hand with a higher limit (pull is permissionless, so this is recoverable); from several thousand such tokens pull() exceeds the block gas limit and is bricked permanently, because every later pull uses supply = lastSupply >= those ids and must fold them all first.

     While pull() cannot run the drip's share stays as claimable in the hook and after RECYCLE_AFTER anyone can recycle() it to the pot, so the collection's NFT holders lose their flywheel JIG. The cost to an attacker is owning that many NFTs of the collection and destroying them (markBurned requires ownerOf == dEaD; LoomCollection has no burn), so this is expensive griefing, hence Low.

     Fix: bound the fold like recycle does (fold at most MAX_FOLD entries per pull, leaving the rest for the next pull), or key burns by the supply bucket they become eligible at so pull() does O(1) work.

     whole finding

     State: HolderDrip deployed on a collection with totalSupply 10 (lastSupply = 10).

     Steps: (1) mint tokens 11..310, send each to 0xdEaD and call markBurned(id) for each (all > lastSupply, so each is pushed to _burnedAbove); (2) send 1e18 JIG to the drip and pull() (spreads over 10, lastSupply becomes 310, nothing folded); (3) send 1e18 JIG and pull() again: _foldBurns(310) iterates all 300 entries.

     Expected: a routine keeper transaction well under KEEPER_GAS_CAP.

     Actual: about 2.2M gas (x1.3 margin = 2.86M; a few more burns put the estimate over the 3M cap and the keeper refuses the job every pass).

     With thousands of burned tokens the pull no longer fits a block and no pull() can ever succeed for that drip.

     whole reproduction

   • lowKeeper marks a creator's whole round window as done from one spot JIG/ETH price read, so a transient dip under minRoundUsd skips the holders' payout for the entire windowoffchain/keeper.mjs:274

     Reproduced by reading (audit_math #2). job.usd = Number(balance)/1e18 x jigPrice().jigUsd, where jigUsd comes from the JIG/ETH pool's spot sqrtPrice divided into ETH/USD (jig.mjs jigPrice) with no averaging or sanity band.

     When the creator set minRoundUsd (up to $1,000) and the single read comes in below it, the keeper writes j.round.doneIndex = sch.index, which roundSchedule() treats as 'this window's round is done' (at: null) for the rest of the window, so the round is not retried even if the price recovers a minute later; the JIG waits a full cadence period (weekly by default).

     JIG launches at about $4k FDV on a pool whose depth is the launch seed, so the spot price is cheap to move for a few blocks around a keeper pass, and the pass cadence is published. Nothing is lost, only delayed, hence Low.

     Fix: do not finalise doneIndex on a price-based skip; back off and re-evaluate on later passes until the window ends, and compare against a smoothed price (median of recent reads) with the same 'unknown price waits' rule already applied to a null price.

     whole finding

     State: a coin whose SnapshotForwarder has moved 300 JIG into HolderPayouts.balance[coin]; creator settings minRoundUsd = 1000, cadence weekly; true JIG price $3.60 (round worth $1,080); sch.at has passed.

     Steps: an outsider sells JIG into the JIG/ETH pool so the spot reads $3.20 (round now $960) during the keeper's next tick(), then buys back.

     Expected: the round is declared once the price is back above the minimum, or at least retried later in the window.

     Actual: line 274 sets j.round.doneIndex = sch.index; every later pass in that window gets at: null from roundSchedule() and the holders' 300 JIG waits for the next weekly window at the earliest.

     whole reproduction

   • lowisOurCollection accepts any EIP-1167 clone of the Loom implementation, not only collections the factory made, so a self-deployed clone passes the keeper and vanity gatesoffchain/launch.mjs:345

     Reproduced by reading (audit_economics #2). The gate compares runtime bytecode with the minimal-proxy template for factory.implementation(). LoomCollection.initialize() is a public initializer on a fresh clone (reference/LoomCollection.sol:85-94, with its own @dev warning), so anyone can deploy a minimal proxy to the same implementation in their own transaction and initialise it with themselves as creator and owner, any maxSupply, any mintPriceWei and no CREATE_FEE.

     Such a clone is byte-identical to a factory clone and passes isOurCollection, so (a) jig.mjs:186 hands it to vanity.request, and ten such clones with ten requests fill MAX_QUEUE (10) so real creators get 'busy' until each 15-minute grind completes (the queue dedupes per collection, which is why ten clones are needed); (b) keeper.plan() services the coin the attacker launches on it (launch fee only), spending up to maxPerJobPerDay sends per job on it.

     Damage is bounded by the existing caps (MAX_NFTS, MAX_HOLDERS, gas cap, per-job cap), so this is a gate that does not do what its comment and the README say rather than a fund loss.

     Fix: decide 'ours' from the factory, not from bytecode: look up the factory's CollectionCreated log for the address (topic 1 = collection; launch.mjs already has the event ABI) once and cache it, keeping the bytecode check as a second condition.

     whole finding

     On Sepolia: impl = factory.implementation().

     Attacker deploys the standard EIP-1167 creation code 0x3d602d80600a3d3981f3363d3d373d3d3d363d735af43d82803e903d91602b57fd5bf3 and calls initialize('X','X',1000000,0,1000000,attacker,0,attacker) on it in the same transaction.

     Expected: isOurCollection(chainId, clone) === false (README: only collections our NFT factory made are served).

     Actual: getCode(clone) equals the template exactly, isOurCollection returns true and caches it; vanity.request(clone,'A','A') is queued; ten clones return { state: 'busy' } to the next genuine creator; CoinFactory.launch for the clone succeeds (attacker is creator()) and keeper.plan() lists buyback/drip/airdrop/round jobs for it.

     whole reproduction

   • lowAirdrop snapshot failures back off exponentially even as the 7-day unset window closes, so five consecutive failures on a late ('soldout' or 'days 6') airdrop sweep the coin's 5% to the potoffchain/keeper.mjs:191

     Reproduced by reading (audit_economics #5). prepareAirdrop() throws on any multicall failure by design (payouts.mjs:119: a partial snapshot must never be used) and tick() answers every prepare failure with backoff(j): nextAt = +1 h, +2 h, +4 h, +8 h, +16 h, then 16 h each. The backoff check (line 260) runs before the 'due' logic, so the forced path at receivedAt + 7 d - 12 h (line 280) does not bypass it.

     The airdrop's hard deadline is AirdropClaim's UNSET_WINDOW: prepareAirdrop returns null once now > receivedAt + 7 d - 1 h and anyone may sweepUnset() after 7 d. For airdrop mode 'soldout' or 'days: 6' the job is first due at launchedAt + 6 d (coinSettings.airdropAt), so the whole budget is about 23 hours; attempts then fall at +0, +1 h, +3 h, +7 h, +15 h and the sixth at +31 h, past the deadline.

     Five failed snapshots over 15 hours (a rate-limited multicall batch on a large collection, a provider incident) and the 5% that CoinFactory parked for the NFT holders goes to the pot, irreversibly. The creator's choice narrows the window, but the loss is the holders'.

     Fix: cap the backoff for kind 'airdrop' at about 10 minutes once now > receivedAt + 5 d, retry a failed multicall batch a few times inside nftOwners before throwing, and consider capping 'soldout'/'days' at 5 days so a day of slack always remains; alert when an airdrop is within 24 h of its deadline and still unset.

     whole finding

     State: coin C launched at T (receivedAt = T), creator setting airdrop { mode: 'soldout' }, a 10,000-NFT collection not sold out. j.airdrop.at = T + 6 d.

     At T + 6 d tick() runs prepareAirdrop: nftOwners issues 20 multicall batches; the RPC rate-limits one, viem reports every call in that batch as failed, nftOwners throws, backoff -> failures 1, nextAt +1 h.

     Same at +1 h (2, +2 h), +3 h (3, +4 h), +7 h (4, +8 h), +15 h (5, +16 h).

     Next attempt at T + 6 d 31 h > T + 7 d - 1 h: prepareAirdrop returns null ('nothing to set'); at T + 7 d anyone calls AirdropClaim.sweepUnset(C): 50,000,000e18 C to the pot.

     Expected: the keeper retries quickly while the unset window is closing.

     Actual: the retry spacing exceeds the remaining window after five failures and the holders' airdrop is lost.

     whole reproduction

   • lowA prepared round record can be overwritten with a new snapshot while its first declare transaction can still be mined, leaving round N on chain with a root the server has no tree foroffchain/keeper.mjs:309

     Reproduced by reading (audit_economics #6); the precondition is narrow, hence Low. The record path is rounds//.json and recordIsFinal() only protects a record whose declaredTx/setTx was written by onSuccess.

     The recovery loop concludes 'never broadcast' when, 30 minutes after signing, the RPC returns neither a receipt nor the pending transaction (lines 243-245), and 'replaced' when the nonce moved and three passes saw no receipt (238-239); both clear inflight without onSuccess. A load-balanced RPC whose nodes do not all hold the pending transaction, or a transaction evicted and re-gossiped later (Sepolia/Ethereum; unlikely behind Robinhood's sequencer), produces exactly that.

     The job then re-prepares round N (roundCount still N on chain), takes a new snapshot with root R2 and overwrites N.json. If the first transaction (root R1) is mined after that re-prepare, round N on chain has R1, the file has R2, payoutProof() serves proofs that fail against R1 for the whole 7-day window, and the rootCheck in onSuccess never runs for R1 because the second declare reverts BadRound.

     The JIG is not lost (settle() returns it to balance[coin]) but the round's holders are paid a week late from a different snapshot with no alert.

     Fix: store the signed hash in the record from onHash (sentTx) and treat a record with sentTx but no declaredTx as final until roundCount on chain proves it was not mined; or key records by root and resolve the served tree by reading rounds(coin, N).root; and have recovery call roundRoot()/roundCount() before declaring a round transaction dead.

     whole finding

     State: coin C has 500 JIG in HolderPayouts.balance, roundCount 0.

     Pass 1: prepareRound -> 0.json {root R1, declaredTx null}, send h1 at nonce k, waitForTransactionReceipt times out at 5 min, inflight {tx h1, nonce k} kept.

     Passes over 30 min: getTransactionReceipt(h1) null; getTransactionCount(latest) == k; getTransaction(h1) null on the answering node -> 'never broadcast', inflight null, backoff.

     Later: prepareRound -> roundCount still 0, new snapshot R2, recordIsFinal(0.json) false -> 0.json overwritten with R2, send h2 at nonce k+1. h1 is then mined: declare(C, R1, 500) succeeds, round 0 = R1. h2: declare(C, R2, 500) reverts BadRound (balance 0).

     Expected (payouts.mjs header): the tree for the root on chain is always on disk.

     Actual: rounds/C/0.json holds R2, every claim for round 0 fails BadProof until expiry, then settle() returns the 500 JIG to the balance.

     whole reproduction

   • infosender.mjs has no replacement or gas-bump path; one transaction stuck in a mempool blocks every later send on that chain indefinitelyoffchain/sender.mjs:40

     Reproduced by reading (audit_flow #5). send() takes the 'pending' nonce, broadcasts and waits up to timeoutMs. If the transaction is accepted into a mempool but not mined (underpriced on Ethereum/Sepolia; a sequencer queue that accepted but is not sequencing), later sends take nonce+1, nonce+2 and queue behind it. The keeper's recovery loop (keeper.mjs:243-244) sees getTransaction(hash) non-null and waits forever ('still in the mempool'); nothing resends or replaces, by design.

     Nothing double-pays, but every keeper job, launch, reveal and allowlist send on that chain stalls until a human replaces the nonce from outside the server. On Robinhood a sequencer includes or rejects quickly, so this mostly matters on Sepolia/Ethereum, but it is the one liveness failure the design has no answer for.

     Fix: when an in-flight hash has been visible but unmined for longer than N minutes, rebroadcast the same nonce with a higher fee (same calldata, same to) through the lock and record the new hash on the same marker; or expose an admin 'replace nonce' action that sends a self-transfer at that nonce.

     whole finding

     State: send A broadcast with nonce n at a fee the network no longer includes.

     Keeper pass: inflight.tx = A, receipt null, mined == n, getTransaction(A) returns the pending tx -> continue forever.

     Next keeper send B uses nonce n+1 (pending count), waits 5 min, times out; B's job also goes inflight.

     Expected: a stuck nonce is replaced after a bounded time.

     Actual: all jobs on the chain accumulate unresolved inflight markers and no send ever lands until manual intervention.

   • infopayouts.expiredRounds reads every round of every forward coin on every keeper pass (unbounded growth in RPC calls)offchain/payouts.mjs:101

     Reproduced by reading (audit_flow #6). plan() runs every 5 minutes and, for each coin whose flywheel is a SnapshotForwarder, loops over all roundCount(coin) rounds with one eth_call each. Rounds are append-only and settled rounds never need re-reading, so the per-pass cost grows linearly with lifetime rounds per coin (daily cadence: 365 reads per coin per year, every pass), and plan() is also what GET /admin/keeper calls.

     Fix: persist the lowest unsettled round index per coin in keeper.json and start the loop there; rounds settle in order of expiry so the index only moves forward.

     State: coin C on daily cadence live for 400 days -> roundCount(C) = 400, 399 settled.

     Every keeper pass (288 per day) makes 400 readContract('rounds') calls for C before any job runs.

     Expected: constant work per pass.

     Actual: linear in the coin's age, multiplied by the number of forward coins, on every pass and every admin page load.

   • infoCollections that reveal immediately are never frozen, so the hot wallet keeps the power to rewrite every token's metadataoffchain/launch.mjs:237

     Reproduced by reading (audit_flow #8). freeze is only ever passed for the reveal-later plan (reveal.mjs:124, r.freeze). An immediate-reveal launch sets provenance and baseURI and stops; metadataFrozen stays false and the owner (the operating wallet) can call setBaseURI at any time (upgradeImageLinks/upgradeWebBaseURI do exactly that on Sepolia).

     Under the stated threat model a leaked key can point every live collection's tokenURI at arbitrary content; the provenance hash is a commitment, not an enforcement. This is a design choice (fixing links later) but belongs in the threat model and the collection's public facts.

     Fix: offer freeze for immediate reveals too (default on for mainnets once the base URI is content-addressed), or freeze after a grace period from the keeper.

     State: a collection launched with reveal disabled on Robinhood.

     After launch metadataFrozen() == false.

     Any holder of LAUNCH_PK sends setBaseURI('https://attacker/') -> every tokenURI changes; freezeMetadata() afterwards makes that permanent.

     Expected per the brief ('no base URI change after freeze'): a freeze exists for every live collection.

     Actual: immediate-reveal collections never reach a frozen state unless someone does it by hand.

   • infoholders() falls back to the latest block when the 'safe' tag is unavailable, silently re-enabling the phantom-balance case the comment guards againstoffchain/payouts.mjs:51

     Reproduced by reading (audit_economics #7). holders() persists the index incrementally and never re-reads a block, so a block indexed at latest and then reorged leaves a wrong balance in .json for good, which is why the code reads 'safe'. The catch() turns an RPC that does not support the tag (or a transient error) into exactly that unsafe behaviour without a log line. On an Arbitrum Orbit chain the sequencer feed can be reorganised until the batch is posted.

     Fix: on failure use latest minus a fixed depth (e.g. 1,000 blocks on Robinhood) or skip the round this pass with a logged reason.

     State: RPC_URL points at a node that answers eth_getBlockByNumber('safe') with an error. prepareRound -> holders(): head = latest.

     A sequencer-level reorg replaces the last blocks, including a 100,000 C transfer from A to B that was indexed.

     Expected: the index only ever contains finalised transfers.

     Actual: idx.balances[B] keeps the 100,000 and idx.fromBlock has moved past the block, so every future round pays B for coin it does not hold, with no recovery path short of deleting the index file.

   • infoCollectionLauncher commits whatever provenance it is given, including bytes32(0), which LoomCollection then treats as committed foreversrc/CollectionLauncher.sol:66

     Reproduced by reading (audit_economics #8, narrowed).

     LoomCollection.setProvenanceHash sets provenanceSet = true for any value, zero included (reference/LoomCollection.sol:144-151), and refuses a second call; create() passes the value through with no check. launch.mjs:67 only checks !provenance, so the JS side relies on viem's fixed-size encoder to reject a short value (current viem throws on a bytes32 whose length is not 32 bytes, so an empty provenance.txt fails before anything is sent; a provenance.txt holding 64 zero characters, or a direct call to create(), still reaches the contract).

     The clone is then created with a meaningless commitment; a later configureClone sees onChain == 0 (line 119), calls setProvenanceHash again and reverts ProvenanceAlreadySet, so the launch fails after the collection exists and the fee is spent, and no real provenance can ever be recorded for it.

     Fix: if (provenance == bytes32(0)) revert BadProvenance(); in create(), and have launch.mjs assert /^0x[0-9a-f]{64}$/ and non-zero before building the call.

     whole finding

     Call CollectionLauncher.create(c, bytes32(0), 'ipfs://placeholder', true) from the operator with the creation fee.

     Expected: revert, a zero hash commits nothing.

     Actual: the collection is created, provenanceSet is true with provenanceHash 0; a later configureClone(provenanceHash: real) throws after one reverted transaction.

   • infoThreat model for the one hot wallet: every power it holds on the mainnet plan, and comments on the three options for the pending HolderPayouts/AirdropClaim decisionsrc/HolderPayouts.sol:61

     Trust assumptions, not new defects (merged from audit_flow #9 and the threat-model parts of the other specialists). Roles the operating key holds on the mainnet plan and what a leaked key can do with each, assuming platform/pot/payees = the Safe:

     1. HolderPayouts owner: declare(coin, root, balance[coin], now+1) with a one-leaf tree paying itself for every coin with a non-zero balance, claimed in the same block with an empty proof (known, pending).
     2. AirdropClaim owner: setDrop(coin, oneLeafRoot, balance) for every coin whose drop is unset; up to 5% of every recently launched coin's supply (known, pending; the 7-day sweepUnset only protects coins already past 7 days).
     3. LPDeepening.keeper and every BuybackAndBurn.keeper: run(0) sandwiched by its own trades (separate Medium finding).
     4. Owner of every collection: pause, setBaseURI until freeze (separate Info), setRevealSeed once, reserveMint up to the reserve cap, freezeMetadata (permanent), acceptOwnership on new ones.
     5. CollectionLauncher.operator: create collections, spending the create fee.
     6. Keeper gas: wasted by hostile modules only within KEEPER_GAS_CAP x maxPerJobPerDay per coin. Not held by the hot key: CreatorFeeHook/JIGLaunchHook owner (JIG deployer, nothing left to set after binding), CoinFactory.platform/setLaunchFee, PotVault owner, LPDeepening.platform (the Safe). On the three README options: option 2 (Safe declares everything) removes automation for rounds that must happen at random moments and for airdrops that must land within 7 days, so it will be missed in practice. Option 3 leaves (1)+(2)+(3) as the largest loss path in the system. Option 1 is the right shape; a cheaper variant that needs no new timing logic: keep the hot wallet as proposer but let a declared root become claimable only after a delay (12-24 h) during which the Safe can cancel it, so the Safe acts only to stop a theft, not to allow every round. Either way the claim contracts need a pending-root state, a cancel, and the keeper must compute the round's expiry from the activation time. At minimum, put the keeper key and the claim-owner key in different processes so a keeper compromise does not also get (1)+(2).

     whole finding

     State: LAUNCH_PK leaked.

     Steps for (1): for each coin with balance[coin] > 0 call declare(coin, keccak256(bytes.concat(keccak256(abi.encode(attacker, balance)))), balance, block.timestamp+1), then claim(coin, round, attacker, balance, []) in the same block (an empty proof verifies a single-leaf tree).

     Steps for (2): setDrop(coin, sameShapeRoot, balanceOf(airdrop)) then claim.

     Expected: a bounded, delayed or two-party path for each.

     Actual: immediate and unilateral; the README lists (1) and (2) and omits (3).

     whole reproduction

   • infoScope answers (yes/no with reasons) for every item in the brief; nothing above Medium remains, and the Mediums are a trust-model gap, a creator timing manipulation and an operational bricksrc/CoinFactory.sol:133

     Verified by reading every file in src/, script/, offchain/ and reference/LoomCollection.sol; the repository does not vendor lib/, so forge build and the fork suites were not run here and no proof file accompanies any finding (none is Critical or High). (1) CoinFactory CREATE2: salt binding sufficient against front-running: YES.

     The deployer is the factory, bytes20(salt) must equal the collection, only _controlsCollection(msg.sender) may launch, coinOf is written only inside a successful launch, and predictCoin/coinInitCodeHash use the same abi.encode(name, symbol, SUPPLY, collection, factory) as launch(). A mempool salt is useless to anyone else; outsiders cannot grief or brick a collection's slot (a reverted launch consumes no CREATE2 address); a creator can only brick their own slot.

     (2) JIG via CreateX CREATE3 with a deployer-guarded salt: consistent with CreateX's guard and asserted in _deployJig; not re-executed here. (3) Mainnet refusal: every script and the keeper/launch paths check 1 and 4663 against ALLOW_MAINNET_DEPLOY / ALLOW_MAINNET; Robinhood v4 addresses (Universal Router, Quoter, Multicall3 in swap.mjs/payouts.mjs) could not be verified from here and should be checked with cast code on the day.

     (4)/(5) HolderDrip: spreading over lastSupply, open baselines on claim, constructor lastSupply and _foldBurns(supply) are consistent and live cannot underflow; two Lows kept (first-pull anchor at deployment, unbounded fold).

     (6) CollectionLauncher: safe against reentrancy (operator-only, stateless, calls only the immutable factory and the clone it returns), non-Loom collections (never takes a collection as input), value (forwarded unchanged); ownership exposure and the zero-provenance edge are the kept Low/Info.

     (a) keeper/sender: pay twice or overlap: NO (marker before signing, hash before broadcast, inflight blocks a second send, restart resolution from receipt then nonce then mempool with a 3-pass lag tolerance; the one narrow race is the kept Low on record overwrite).

     Min-out: quoted from V4Quoter right before each send at 3%; sandwichable by outsiders only within 3% minus the hook fees on both legs, not profitable, and Robinhood has no public mempool; by the keeper key holder, YES (Medium). Inside the JIG window: NO (status fails closed; windowOpen skips the pass).

     Malicious coin/module/collection: bounded to gas <= KEEPER_GAS_CAP x maxPerJobPerDay per coin behind isOurCollection (whose bytecode check is bypassable, kept Low); the keeper signs only run(min)/pull()/collectFees/claimFor/declare/setDrop with no value and holds no approvals.

     (b) payouts/merkle: leaves keccak256(keccak256(abi.encode(account, amount))), sorted pairs, odd node carried: MATCH HolderPayouts/AirdropClaim/OpenZeppelin; split floors so total <= balance and declare() rechecks; the Transfer index persists fromBlock only after each chunk so a crash cannot double count; protocol addresses excluded (PLATFORM_ADDRESS must be set on mainnet); the tree is written before the send (keeper.mjs:309).

     (c) coinSettings: creator()-else-owner() mirrors _controlsCollection, verifyMessage covers EIP-1271, nonce = current+1 single-use, the message carries chain and collection so it cannot be replayed across either, airdrop timing locked once coinOf is set, minRoundUsd capped at 1,000: SOUND; the cadence-edge manipulation is the kept Medium.

     (d) swap.mjs: actions SWAP/SETTLE_ALL/TAKE_PORTION/TAKE_ALL with amountOutMinimum 0 in the swap and the user's minOut after the fee in TAKE_ALL, two-hop path with the proof only on the JIG hop, Permit2 approvals listed: CORRECT; the tx.origin quoting gap during the window is the kept Low.

     (e) vanity.mjs: the salt is re-derived through predictCoin and its first 20 bytes checked against the collection before being stored: YES, it cannot hand out a salt bound to another collection. (f) jig.mjs allowlist: leaf keccak256(keccak256(abi.encode(address))), sorted pairs, odd node carried: MATCHES JIGLaunchHook.isAllowlisted. (g) reveal/

     whole finding

     Not a defect; this entry records the per-item verdicts and the verification performed (static reading of every file in src/, script/, offchain/ and the Loom reference; forge was not run because lib/ is not vendored in the repository).

7. Onchain1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,207,994 · transaction#355#1637#1295#715#808