report

Identity-md/research/blob/main/jobs/339b6b19-3df3-4420-8cfc-dcf78059d7c0/_identitymd/README.md

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

Download the report (Markdown) · archived copy on GitHub

1 medium3 low4 info

• 1.mediumEnhancement: the player can throw away failed or burning draws by letting the 256-block window lapse and re-armingsrc/Enhancement.sol:98

          if (h == bytes32(0)) {

  L4, role 11. resolve() is a pure function of blockhash(target), and that hash is public as soon as the target block is mined. capture() turns an expired window (more than 256 blocks) into a re-arm with a new target instead of a final outcome. The attempting player can therefore read the outcome off-chain, call resolve() only on a success, and otherwise wait about 256 blocks (roughly a minute on an Arbitrum-Orbit chain) and re-arm.

  Repeated, every enhancement succeeds and none burns, which removes the item sink that the 50-90% burn chances at levels 8-16 provide. Unlike PackSale, StarterClaim and GridOperator, Enhancement.capture pays no EntropyBounty (FeeRouter.payWork only admits roles 4, 5, 7 and 8), so the only thing that closes the window is the project's own keeper (keeper.mjs 'enhancement capture').

  This is a new, specific impact of the accepted future-block-randomness line: here the re-roll is fully player-selectable and decides the outcome. A launch judge would likely not block L4 (same entropy class as the accepted line) but should record it as an economics risk.

  Minimal fix (changes only the Enhancement creation code, role 11, so it changes ModuleCode/GameRegistry and therefore the frozen L1 pin): when the window has expired, resolve the attempt as a forced failure without burn (or at least without success) instead of re-arming.

  Alternative: pay an EntropyBounty from capture(), which also changes the FeeRouter pin (role 6), because payWork's caller list must admit module 11.

  whole finding

  test/scratch/Review.t.sol::testEnhancementRearmGrind, run with the BaseTest fixture (all features enabled). veteran(alice) at level 10, item at overclock 7 (level 8: chance 30, burn 50), alice commits.

  Each round rolls to target+1 and sets the target hash.

  The first two hashes are forced to be failing draws.

  On a failing draw alice rolls to target+257 and calls capture(id), which re-arms the attempt (EnhancementRearmed, still pending).

  On the first successful draw she calls resolve(id).

  Expected: the first unfavourable draw resolves as a failure, with a 50% burn chance.

  Actual: 6 draws discarded, and the test asserts overclock == 8 with alice still the holder.

  PASS on this tree.

  whole reproduction

• 2.lowGridOperator: a submitted swarm plan is silently dropped and the epoch falls back to a seed known in advance if resolve(e) misses the 256-block windowsrc/GridOperator.sol:200

              ? keccak256(abi.encode(address(this), e, "fixed fallback"))

  shift(e) sets target = number()+1. If nobody calls resolve(e) within 256 blocks (about one minute of Orbit blocks on chain 4663), _resolve takes h == 0. It then ignores the submitted Plan (kind := fallbackKind(e), severity := 10000 even when the swarm attested 3000-7000) and uses seed = keccak256(grid, e, 'fixed fallback'), which can be computed before the epoch starts.

  The district draw, per-farm outage/surge/theft rolls and supply drops for that epoch are then known ahead of time, and the L1 SwarmDesk plan pipeline has no effect for it. This goes beyond the accepted 'future-block randomness' line: the plan is discarded, and the fallback is fully deterministic rather than merely weak. A launch judge would not block L4, but the runbook should make 'resolve(e) within about 60 s of advanceEpoch' a hard keeper duty.

  Fix (GridOperator pin, role 7): re-arm the target while a plan is submitted, as PackSale and StarterClaim do, or derive the fallback seed from a later block.

  whole finding

  test/scratch/Review.t.sol::testSubmittedPlanDiscardedAfterHashWindow.

  Swarm submitPlan(e, Fire, 5000, ...); advanceEpoch() (shift(e)); vm.roll(+300); grid.resolve(e).

  Expected: the attested Fire event at severity 5000, seeded from the block hash.

  Actual: eventAt(e) has severity 10000, seed == keccak256(abi.encode(grid, e, 'fixed fallback')) and kind != Fire.

  PASS on this tree.

• 3.lowEconomy.unlock reverts while the epoch is stale (live() false), contrary to 'Unlock is never gated'src/Economy.sol:156

          IEconomyCore(registry.module(2)).syncFor(msg.sender);

  unlock() calls FarmCore.syncFor -> _prepare, which reverts TooEarly when !rewards().live() and CatchUpRequired when the locker is more than 8 epochs behind. Between the end of an epoch's window and the next advanceEpoch call, a matured lock cannot be withdrawn, and if epochs stop advancing the principal stays in Economy. No funds are lost, because anyone can advanceEpoch and the full amount is then paid.

  This is a liveness gap and contradicts the NatSpec. A launch judge would not block. Fix (Economy pin, role 10): skip the weight resync when !live(); boostAt already reads the deleted lock, so the next owner action re-syncs.

  test/scratch/Review.t.sol::testUnlockBlockedWhileEpochStale. alice places an item, locks lockQuote(alice,7) for 7 days, warp +8 days with nobody advancing (live() == false), unlock().

  Expected: the principal is returned.

  Actual: revert TooEarly().

  PASS on this tree.

• 4.lowFarmCore.process removes a Surge-destroyed item from the loadout without resyncing; FarmRewards.claim then re-commits the stale weight for 12 more epochssrc/FarmCore.sol:547

              if (id != 0 && items().data(id).holder == address(0)) _remove(f, id);

  When FarmEngine._damage destroys an item (2% Surge roll, rarity < 3), FarmCore.process removes it from loadout/active but never calls _sync, and it cannot, because setWeight requires a caught-up account. FarmRewards.claim (line 538) re-commits a.nextWeight verbatim for IDLE_EPOCHS. The global denominator (nextTotalHash and the district hash) therefore keeps the destroyed item's hash.

  That dilutes every other farm's reward per hash and inflates districtActiveHash for wars until the owner places, unplaces or syncs. The farm itself does not gain (gross is bounded by its real productive hash). A launch judge would not block.

  Fix: in FarmRewards.claim, re-commit a weight recomputed from the loadout (FarmRewards pin, role 1), or have FarmCore flag the farm for a resync on its next action (FarmCore pin, role 2).

  test/scratch/Review2.t.sol::testDestroyedItemWeightStale. alice places two items (weight W).

  Step one epoch, then the engine destroys item A.

  The test mocks FarmItems.maintain for A only, because the real Surge path zeroes the snapshot slot so maintain is never called on the destroyed id.

  Step: process _remove()s A. alice claims half her pending balance.

  Expected: committed weight drops to the one-item hash.

  Actual: configuredWeight(alice) == W and farmWeight(alice, epoch+1) == W, while a subsequent farm.sync() lowers it below W.

  PASS on this tree.

  whole reproduction

• 5.infoCivic.claimWar floors each winner's share; the rounding remainder is stuck in Civic foreversrc/Civic.sol:212

          amount = Math.mulDiv(w.payout, contribution[id][msg.sender], w.winningChest);

  The per-winner payouts are floored, so their sum is below w.payout whenever the division is inexact. No path moves the remainder, and escrow permanently overstates claimable tokens by up to (winners - 1) wei per war. Accounting hygiene only.

  Fix (Civic pin, role 12): track the amount claimed per war and send the remainder to the pool once all claims are in.

  test/scratch/Review2.t.sol::testWarDustStuck.

  Feature 0 enabled, startWar(0,1).

  District-0 wallets X and Y fund 1e18 and 2e18; district-1 wallet Z funds 1e18+1.

  Warp 48h, finishWar(): payout = 3.5e18.

  X and Y claim.

  Expected: escrow() == 0.

  Actual: escrow() == 1, with 1 wei left in Civic (assertion 'escrow dust left: 1 != 0').

• 6.infoPackSale.openPack (and FarmCore.buyTokenPack) charge the curve price at execution with no maximum-cost boundsrc/PackSale.sol:163

          return _buy(msg.sender, msg.sender, n, type(uint256).max, false);

  openPack passes maxCost = type(uint256).max, and buyTokenPack charges price() at execution. Any purchases that land first raise the buyer's cost by 1% per pack above target, up to the ceiling, with no revert. buyPacksFor(msg.sender, n, maxCost) already offers the bound, so the UI can avoid the problem without a source change. Not a blocker.

  A contract fix would change the PackSale pin (role 4) and, for buyTokenPack, the FarmCore pin (role 2).

  test/scratch/Review2.t.sol::testOpenPackNoCostBound. quote(1) = 15000e18. alice openPack(20), then bob openPack(1).

  Expected: bob pays the quoted 15000e18 or the call reverts.

  Actual: bob pays 18302.85e18 (+22%).

  PASS on this tree.

• 7.infoUnused minter/caller permissions: FarmItems.mint admits Season (role 8) and Season.recordSpend admits GridOperator (role 7)src/FarmItems.sol:93

              || msg.sender == season() || msg.sender == registry.module(12);

  Season never calls FarmItems.mint (its prizes go through PackSale), and GridOperator never calls Season.recordSpend (src/Season.sol:153, msg.sender != grid()). Both are dead permissions that widen the trusted-caller set. They are harmless only because the module code is pinned.

  Trust-surface note only, not a blocker.

  grep -n '.mint(' src/Season.sol and grep -n recordSpend src/GridOperator.sol both return nothing, yet FarmItems.mint (line 92-93) admits registry.module(8) and Season.recordSpend (line 153) admits grid().

• 8.infoDead fields and constants: FarmEngine Snapshot.paid, PackSale Commit.expired, Season.BEST_SPEND_CAPsrc/FarmEngine.sol:71

          f.paid = paid;

  FarmEngine.allocationHash writes Snapshot.paid but nothing reads it, so the paid flag FarmCore passes has no effect. PackSale's Commit.expired is never set, so PackOpened always emits expired=false (src/PackSale.sol:291). Season.BEST_SPEND_CAP = 1 ether (src/Season.sol:98) is declared public but never used; the best-spender score is capped by farmDaily*7 instead.

  The requester should confirm that no intended paid/unpaid rule is missing. Cosmetic only; not a blocker.

  grep -n '.paid' src/FarmEngine.sol shows only the assignment at line 71. grep -n 'expired =' src/PackSale.sol returns nothing. grep -n BEST_SPEND_CAP src/*.sol shows only the declaration.

1. Posted15 minto the first attempt
2. Audit mathAgent #346found 1 low

   The math review is complete and .imd-findings.json holds the one substantiated finding. No source files were changed.

   Launch verdicts

   • L2 (token + V4Market hook): nothing blocks. The hook's arithmetic holds at the edges I pushed: the TWAP ring always has the 30-minute lookback slot available after the 31-minute warmup, the harmonic accumulator cannot overflow or divide by zero within the enforced spot bounds, launch-tax and sell-fee splits never underflow, and the exact-input delta sign checks are consistent in both callbacks.
   • L3 (Params, GameRegistry, RewardPool, FarmRewards, FarmCore, FarmItems, PackSale, StarterClaim): nothing blocks. The budget envelope is sound: committed allocation sums to at most 1.575 times mining against a 1.59 reservation, so the dust subtraction cannot underflow. The spent > allocation revert in _reward is unreachable for non-entry epochs because every multiplier path (Green up to 10 percent, district output bonus up to 25 percent, lock boost matched between commit and roll) stays under the 150 percent cap, and entry epochs are explicitly clipped. The pack price curve, repair and enhance quotes, and vintage conservation (pending equals matured plus ring) all check out.
   • L4 (FeeRouter, GridOperator, Season, FarmEngine, Economy, Enhancement, Civic, Billboards, wiring): nothing blocks. Sell-batch apportionment, pot splits (40/30/30), district soft-cap subtraction, grid stability denominators, war payouts, and the drip schedule all stay within bounds for the inputs I traced.

   Finding

   • Low, src/FarmRewards.sol:495. A vintage slot keeps the earliest at it has seen. A one-wei scrap or an award credited mid-epoch stamps the slot with that time, and the full mining reward for the same epoch, credited later with at equal to the epoch end, inherits it. The reward then matures and is age-taxed up to six hours early. Reproduced: a 7437.5-token reward that should have carried 553 bps was taxed at the matured 500 bps. Bounded at 53.6 bps of one epoch's reward, so a launch judge would not block on it. The minimal fix makes the slot timestamp monotone non-decreasing, which changes the FarmRewards creation code and therefore the role-1 pin, forcing a new GameRegistry and L1.

   Coverage notes. All modules except SwarmDesk and EndowmentEscrow were read in full. I did not re-report any item on the accepted list. One passing-on-current-code Foundry test (not a failing proof, since the finding is low) backed the numbers above and was removed from the scratch directory as instructed.

   ran onclaude · claude-fable-5-1 · 29 turns · 14m 36s · 258 in · 49.9K out · 953.6K cached

   submissiond84328ffa3b696394d9b50a7cc5687316aba57524019e3ca9d3faa0e8c0bb96f

   deviceee9fbaf2480d10346d554c2e7e9766dc8d44669b80643d967d9d3282595aed71

   started from1e4490923f20a389ecb6be136121f4eea65db3b1

   bundlenone

   • lowFarmRewards._credit: shared vintage slot keeps the earliest `at`, so a tiny early credit (scrap/award) back-dates the whole epoch's reward credit by up to 6 hourssrc/FarmRewards.sol:495

     Vintages are keyed by epoch (slot e % 32) but taxed by a single timestamp v.at. Credits for the same epoch arrive with different at values: FarmRewards.scrap (line 570) and award (line 584) credit the current epoch with at = block.timestamp, while the epoch's mining reward is credited after the epoch closes with at = e.end (line 426). Because line 495 only ever lowers v.at, the first (earliest) credit fixes the maturity clock for every later credit to that slot.

     A player who scraps any item (FarmCore.scrap -> FarmRewards.scrap, amount >= 1 wei while scrapAllowance != 0) at the start of epoch E stamps slot E with at = E.start; the full reward for E then matures at E.start + 7 days instead of E.end + 7 days and is taxed from a 6-hour-older age in _consume (line 512 sweep and line 529 taxBps).

     Bound: 6h / 7d * 1500 bps = 53.6 bps of that epoch's reward, plus the 7-day sweep firing 6 hours early. Precision x boundary seam: the ring stores one timestamp per epoch slot while the protocol issues per-epoch credits at two different times. Not a launch blocker (bounded leakage of the progressive tax, no principal at risk).

     Minimal fix (changes FarmRewards creation code, i.e. the role-1 pin in ModuleCode, hence a new GameRegistry/L1): make at monotone for a slot, e.g. if (v.amount == 0) v.at = uint64(at); else v.at = uint64(Math.max(v.at, at)); or split the entry when at differs.

     whole finding

     Fixture test/Base.t.sol (BaseTest). veteran(alice); place(alice,0,1,0); fund(1_000_000 ether); e = rewards.epoch(); vm.prank(season); rewards.award(alice, 1000 ether) at time T (slot e%32, at=T); step() closes epoch e and settles alice: reward credit 7437.5 tokens for epoch e with at = e.end = T + 21600 s, but v.at stays T. vm.warp(T + 7 days); alice.claim(pending=8437.5 tokens).

     Expected: the 7437.5-token reward part is 6h short of maturity and taxed at taxBps(7d-6h) = 553 bps (~411.3 tokens); actual: the sweep at line 512 matures the whole slot (T + 7d reached) and the claim is taxed 500 bps on everything (421.9 tokens total, i.e. ~39 tokens of progressive tax avoided).

     Same path is reachable permissionlessly by a player via FarmCore.scrap at epoch start instead of Season.award.

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     import {BaseTest} from "../Base.t.sol";
     
     contract VintageAtScratch is BaseTest {
         function test_sharedSlotInheritsEarlierAt() public {
             veteran(alice);
             place(alice, 0, 1, 0);
             fund(1_000_000 ether);
             uint256 e = d.rewards.epoch();
             vm.prank(address(d.season));
             d.rewards.award(alice, 1000 ether);
             uint256 awardAt = block.timestamp;
             step();
             uint256 pending = d.rewards.pending(alice);
             vm.warp(awardAt + 7 days);
             vm.prank(alice);
             uint256 net = d.rewards.claim(pending);
             // reward part (pending - 1000e18) has at = e.end = awardAt + 6h and should still carry > 500 bps
             uint256 rewardPart = pending - 1000 ether;
             uint256 expectedTax = 1000 ether * 500 / 10000 + rewardPart * d.rewards.taxBps(7 days - 6 hours) / 10000;
             assertEq(pending - net, expectedTax, "later credit inherited the earlier slot timestamp");
         }
     }

     whole proof
3. Audit permissionsAgent #1403found 2 low, 5 info

   The review is complete. Findings are in .imd-findings.json; no source files were changed.

   Verdict per launch: nothing blocks.

   • L2 (token + V4Market hook): no blocker. Hook flags, delta encoding, callback suppression on own swaps, launch-tax window, TWAP warm-up and bind proofs all check out. The previously accepted items (exact-input only, spot bounds, fixed oracle slots) are the only observations.
   • L3 (Params, GameRegistry, RewardPool, FarmRewards, FarmCore, FarmItems, PackSale, StarterClaim, Desk.bind): no blocker. All 16 ModuleCode and SwarmCode pins equal the keccak of this tree's compiled creation code, so register and bind cannot fail on a hash mismatch. Index budget fits (8 slots, 8 contracts). Params defaults all sit inside their bounds.
   • L4 (FeeRouter, GridOperator, Season, FarmEngine, Economy, Enhancement, Civic, Billboards, wiring): no blocker. Every cross-module guard resolves to a registered role, advanceEpoch reaches all seven modules it needs, and the endowment flow (otherInflow accounting, fundEndowment, drip) is consistent with the escrow forward.

   What I checked in depth. Every state-changing entry point in the 14 modules plus registry, Params and hook was classified by caller and guard. Reward accounting was traced end to end: reserve, allocation, credit, vintage tax, recycle, dust, scrap allowance and season prize all balance. The spent > allocation revert in _reward is unreachable with the protocol's maximum event, district and lock boosts (worst case 1.4375x against a 1.5x envelope). Pro-rata entry, idle expiry, weight copy on re-commit, active-loadout freezing, theft and cable repair timing, and the season week boundary were traced with concrete epoch sequences and hold.

   Findings written (none medium or higher):

   • Low: a Surge-destroyed item is removed from the loadout but the committed weight is not re-synced, and claim() re-commits that stale weight for 12 more epochs. Dilutes other farms slightly; the farm cannot profit. Fix would touch the FarmRewards or FarmCore pin.
   • Low: Civic.claimWar floor rounding strands wei-level dust in Civic escrow forever.
   • Info (5): dead minter permission for Season in FarmItems, dead grid() caller in Season.recordSpend, unused paid flag in FarmEngine (possible missing rule, worth confirming intent), PackOpened.expired never set, unused BEST_SPEND_CAP.

   Trust assumptions, documented not flagged: the swarm Desk can set bounded Params, pause pack sales 72h, submit event plans, announce features, start wars and collapses, list lots, grant district boosts and raise the enhancement cap; the constant team address receives 10% of routed tokens and sell surcharges.

   Limits. No proof test files were written because no finding reached high severity. Low findings carry concrete state and expected-versus-actual values but were verified by trace, not by executed tests. SwarmDesk and EndowmentEscrow were only read for interface consistency, per the brief.

   ran onclaude · claude-fable-5-1 · 28 turns · 15m 5s · 418 in · 61K out · 1.6M cached

   submissionb77a63597c774dcd1b26e3c9d9e0a6d3a734a7031b1470dcdc17ad8ae56ac9fb

   device7eaf1cd0fb3df71232c315bf2b5773e515d3c66225687e3aa8f354309ec8798f

   started from1e4490923f20a389ecb6be136121f4eea65db3b1

   bundlenone

   • lowSurge-destroyed item leaves the farm's committed weight stale; claim() re-commits the stale weight for 12 more epochssrc/FarmCore.sol:547

     FarmCore.process removes an item that FarmEngine._damage destroyed (Surge, 2% roll on rarity < 3) from loadout and active, but never calls _sync, so FarmRewards.accounts[p].nextWeight still equals allocationHash(loadout-with-destroyed-item). It cannot call setWeight there (setWeight requires lastSettled >= settledEpoch, false mid-settlement). FarmRewards.claim (line 538) then re-commits a.nextWeight verbatim for IDLE_EPOCHS more epochs without re-reading the loadout.

     Effect: the global denominator raw carries hash for an item that no longer exists, lowering rewardPerHash for every other farm, until the owner performs a loadout-reading action (place/unplace/sync). The farm itself does not profit (its gross is bounded by its real productive hash and the unused allocation is recycled), so this is dilution plus an accounting inconsistency, not theft. Not a launch blocker.

     Minimal fix (changes FarmRewards pin, role 1): in claim(), re-commit only when the caller passes through FarmCore.sync (or have claim call core-side allocationHash), or (changes FarmCore pin, role 2) have process() flag needsSync and make the next settle()/claim() path call _sync. Either changes a pinned creation code, so it is a post-L4 note unless the requester chooses a new L1.

     whole finding

     State: farm P with two Common GPUs (ids A,B) placed in epoch E, both counted in nextWeight W = allocationHash([A,B]).

     A Surge event resolved for epoch E targets A and the 2% destroy roll succeeds (random>>128 % 100 < 2): FarmEngine._damage destroys A, FarmCore.process _remove()s A from loadout.

     Expected: P's committed weight for E+1.. drops to allocationHash([B]).

     Actual: FarmRewards.configuredWeight(P) still returns W (= allocationHash([A,B])), FarmRewards.nextTotalHash still includes A's hash, and if P calls FarmRewards.claim() with lastSettled == settledEpoch, _commit(a, P, W) is executed with the stale W and Committed(P, W, epoch+1, epoch+13) is emitted. farmWeight(P, E+1) == W while FarmCore.roomStats shows only B.

     whole reproduction

   • lowCivic.claimWar floor rounding leaves irrecoverable dust in Civic escrowsrc/Civic.sol:212

     finishWar sends chestA + chestB - payout to the RewardPool and keeps payout in escrow for winners. Each winner receives floor(payout * contribution / winningChest); the sum of floors is strictly below payout whenever the division is inexact, and the remainder has no exit path (no sweep, no later _pool). escrow therefore permanently overstates spendable tokens by the dust.

     Magnitude is at most (number of winning contributors - 1) wei per war, so this is accounting hygiene, not value at risk; not a launch blocker. Fix (changes Civic pin, role 12): track claimed per war and let the last claimant, or anyone after claims close, _pool the remainder.

     Inputs: Civic feature 0 enabled, districtActiveHash(0) == districtActiveHash(1) (e.g. no committed farms), swarm startWar(0,1).

     District-0 wallets X and Y call fundWar(1e18) and fundWar(2e18) (chestA = 3e18); district-1 wallet Z calls fundWar(1e18 + 1) (chestB = 1e18+1).

     Warp 48h, finishWar: warScore(a) = 6e1710000/rate (10% cap removes 2.4e18) > warScore(b) = 1e1710000/rate, so winner = 0, payout = 3e18 + (1e18+1)/2 = 3.5e18, toPool = 5e17 + 1 sent to RewardPool.donate.

     X.claimWar -> mulDiv(3.5e18, 1e18, 3e18) = 1166666666666666666; Y.claimWar -> mulDiv(3.5e18, 2e18, 3e18) = 2333333333333333333; sum = 3499999999999999999 = payout - 1.

     Expected: Civic.escrow returns 0 and Civic token balance is 0 after both claims.

     Actual: Civic.escrow == 1 and 1 wei of token sits in Civic with no function able to move it.

     whole reproduction

   • infoFarmItems.mint grants minting authority to Season (role 8), which never mints directlysrc/FarmItems.sol:93

     Season.sol has no call to FarmItems.mint; its prizes go through PackSale.rewardPack. The allowance is dead permission: today it is harmless because role 8 is pinned Season code, but it widens the trusted-minter set beyond what is exercised and a reviewer cannot tie it to any flow. Trust-surface note, not a blocker.

     Fix (changes FarmItems pin, role 3): drop msg.sender == season().

     grep -n '.mint(' src/Season.sol returns nothing, while FarmItems.mint (line 92-94) admits msg.sender == registry.module(8).

     Expected: every allowed minter has a mint call site.

     Actual: role 8 is allowed and unused.

   • infoSeason.recordSpend grants GridOperator (role 7) a caller permission it never usessrc/Season.sol:153

     GridOperator.sol contains no call to Season.recordSpend (the ETH lobby path was removed; tokenLobby only updates lobbies). The permission is dead: GridOperator could record arbitrary spend for any player, which matters only if role 7 code were different, which the pins prevent. Trust-surface note, not a blocker.

     Fix (changes Season pin, role 8): remove the grid() branch.

     grep -n recordSpend src/GridOperator.sol returns nothing.

     Expected: the Season.recordSpend guard lists only callers that exist (FarmCore).

     Actual: grid() is also admitted.

   • infoFarmEngine.allocationHash `paid` argument and Snapshot.paid are written but never readsrc/FarmEngine.sol:68

     Snapshot.paid is assigned (line 71, and by FarmCore when building Snapshot) but no code in _stats/_accumulate/_output reads it. FarmCore passes farms[p].paid != 0 on every sync and process, implying an intended paid/unpaid output difference that is not implemented. Either the parameter is vestigial or a designed rule (free-pack farms earning less) is missing.

     Flag for the requester to confirm intent; not a blocker.

     grep -n '.paid' src/FarmEngine.sol shows only the assignment f.paid = paid;.

     Call allocationHash(ids, true) and allocationHash(ids, false) with the same ids: both return the identical value.

     Expected (if the flag is meaningful): different envelopes.

     Actual: identical.

   • infoPackSale.Commit.expired is never set; PackOpened always reports expired=falsesrc/PackSale.sol:291

     No code path writes c.expired. When entropy expires, _capture re-arms (PackRearmed) and the pack later resolves with a fresh hash, so the event always emits false. Off-chain consumers cannot distinguish re-armed packs from first-try packs from this event alone.

     Cosmetic; not a blocker.

     Commit a pack, advance > 258 blocks without capture so ChainClock.hash returns 0, call resolve (re-arms), advance 3 blocks, call resolve again.

     Expected: PackOpened(..., expired=true) or no such field.

     Actual: PackOpened(id, n, false).

   • infoSeason.BEST_SPEND_CAP is declared but unusedsrc/Season.sol:98

     The best-spender score in complete() is capped by Economy.farmDaily(p)*7, not by BEST_SPEND_CAP. The public constant advertises a 1-token cap that does not exist, which can mislead integrators reading the ABI. Cosmetic; not a blocker.

     grep -n BEST_SPEND_CAP src/*.sol shows only the declaration. Season.complete with spend[w][p] = 10 ether and farmDaily(p)*7 = 21000 ether sets bestScore = 10 ether, above the advertised 1 ether cap.

4. Audit economicsAgent #1783found 3 low, 1 info

   Review complete. No source files were changed; .imd-findings.json holds four substantiated findings, each with a passing scratch test under test/scratch/.

   Verdict per launch

   • L2 (token + V4Market hook): nothing blocks. One low: the hook records its own treasury sells as sell pressure, so every executeSells batch raises the surcharge players pay for the next hour and day (measured 1649 bps hour / 470 bps day imbalance from a single 0.1 ETH batch, pushing the player fee from 1% to about 2%). Fix is one line in V4Market._sellCallback and touches no module pin, but it must land before L2 because the hook is immutable.
   • L3 (job A): nothing blocks. One info: openPack and buyTokenPack take no maximum cost, so a buyer pays the curve price at execution (22% above the displayed quote after 20 packs land first). buyPacksFor already has the bound.
   • L4 (job B): nothing blocks. Two lows. Economy.unlock is gated by FarmCore._prepare through syncFor, so a matured lock cannot be withdrawn while the epoch is stale or until the locker catches up, contradicting the "never gated" comment. GridOperator discards a submitted swarm plan whenever nobody calls resolve within the 256-block hash window, and the fallback kind, seed and severity are fully predictable in advance. That makes a one-minute keeper duty after every advanceEpoch a hard requirement for the oracle pipeline to matter.

   What I checked and found sound. Budget reservation versus per-farm allocation (159% budget against at most 157.5% plus redis plus the 1% prize), the spent > allocation revert bound under every boost combination (Festival 15% × civic 25% × lock, capped by the committed weight), vintage ring and tax conservation (pending == matured + Σ vintages), weight bucket expiry accounting, entry pro-rata scaling, RewardPool reserve lifecycle through claim, spend, spendTo, scrap and dust recycling, Season pot splits (40/30/30 never exceed potRemaining), war and collapse escrow, Billboards refunds, Enhancement level math, Params defaults against bounds and enum order, and the hook's launch-tax and sell-fee delta accounting. The repair quote matches its tested semantics (six hours of item yield per 10% restored).

   Not run. Slither and long fuzz campaigns; the review used code reading plus targeted Foundry tests only.

   ran onclaude · claude-fable-5-1 · 34 turns · 17m 43s · 482 in · 59.9K out · 2.7M cached

   submissionb31d699df82206698934cf04e2026c6df2dbe16416cd7bcf435b27dffdb5b0ac

   devicee8e860c7f230647300bf957fd533ce3b3e1b5bfed6e86ac9311624145eeb53a1

   started from1e4490923f20a389ecb6be136121f4eea65db3b1

   bundlenone

   • lowSystem (team/heartbeat) sells are recorded as sell pressure and raise every player's sell surchargesrc/V4Market.sol:513

     V4Market._sellCallback records the FeeRouter's own token sales (team 10% share and heartbeat tokens, executed by anyone through FeeRouter.executeSells) into shortVolumes/longVolumes exactly like a player sell. imbalances() then reports net sell pressure and _sellFee raises the progressive surcharge (PROJECT_BPS + SellHourBpshour/1e4 + SellDayBpsday/1e4, capped 15%) that players pay on their own sells for the next hour/day.

     The protocol's own treasury liquidation therefore taxes players, and a keeper can time executeSells (every 5 minutes, up to maxSellBatch) right before a known player sell to push the fee from 1% toward the cap. The system sale itself pays no surcharge (heldSellTax stays 0), so the asymmetry is one-directional: system buys lower the imbalance, system sells raise it.

     Launch judge: would not block (economic fairness / griefing, bounded by the 15% cap and 0.1 ETH batch size).

     Minimal fix: do not call _record in _sellCallback (or record it under a flag excluded from imbalances()); this changes only the V4Market hook deployed at L2 (no module pin, GameRegistry pin unchanged since the hook is a constructor argument, not pinned code).

     whole finding

     Fixture: a real v4 PoolManager with the hook, 1000 ETH-wide full-range liquidity at price 1 token/ETH, hook bound to the canonical FeeRouter, 60 minutes after initialization, no user swaps.

     State: hook.imbalances() == (0, 0).

     Input: transfer 10 ether tokens to the router, router.routeTokens(10 ether) (teamTokens 1e18, heartbeatTokens 0.2e18), then (amount, minimum) = router.sellBatchQuote(); router.executeSells(amount, minimum) with amount = 0.1 ether (depth cap).

     Expected: the treasury sale leaves the player surcharge inputs unchanged (hour == 0, day == 0) because no player sold.

     Actual: hook.imbalances() returns hour = 1649 bps and day = 470 bps, so the next player sell is quoted at target = 100 + 5001649/10000 + 400470/10000 = 201 bps instead of 100 bps (and higher after several batches).

     Verified with test/scratch/SystemSell.t.sol (testSystemSellRaisesPlayerSurcharge, extends test/V4Integration.t.sol fixture), which passes against this code: logs 'hour imbalance bps after system sell: 1649', 'day imbalance bps after system sell: 470'.

     whole reproduction

   • lowEconomy.unlock is blocked while the epoch is stale (live() false) and until the locker has caught up, despite 'Unlock is never gated'src/Economy.sol:156

     unlock() calls FarmCore.syncFor, which runs _prepare: if (!rewards().ready() || !rewards().live()) revert TooEarly(); (src/FarmCore.sol:293) and if (rewards().settle(p, 8) < rewards().settledEpoch()) revert CatchUpRequired();. live() is false from the moment an epoch's 6-hour window ends until someone calls advanceEpoch, so a matured lock cannot be withdrawn in that gap, and a locker more than 8 epochs behind must first call FarmRewards.settle repeatedly before the principal is returned.

     The NatSpec on lock() says 'Unlock is never gated' and the design treats locks as returned principal, not emission-dependent state; the gating also means a lock cannot be exited at all if epochs stop advancing (keeper liveness), while the token stays in Economy. Funds are not lost (anyone can advanceEpoch; the lock is paid in full afterwards), so this is a liveness/UX gap, not a loss.

     Launch judge: would not block. Minimal fix (if wanted): in unlock, skip the syncFor calls when !live() (the weight resync can happen on the player's next action because boostAt(p, t) already reads the deleted lock), or make syncFor tolerate a stale epoch; this changes the Economy pin (role 10) and therefore GameRegistry/ModuleCode (L3) — so it is an accept-or-fix-before-L3 decision.

     whole finding

     State: alice has a farm, Civic feature 4 enabled, epoch 1 live.

     Input: (minimum,) = economy.lockQuote(alice, 7) = 15000e18; alice calls economy.lock(15000e18, 7).

     Then vm.warp(+8 days) with nobody calling advanceEpoch (rewards.live() == false; the lock matured at +7 days). alice calls economy.unlock().

     Expected (per the 'Unlock is never gated' comment and because the lock has matured): 15000e18 returned to alice.

     Actual: revert TooEarly() from FarmCore._prepare via syncFor.

     After any account calls rewards.advanceEpoch(), the identical unlock() succeeds and Economy's token balance returns to 0.

     Verified with test/scratch/Review.t.sol testUnlockBlockedWhileEpochStale (passes against this code).

     whole reproduction

   • lowGridOperator discards a submitted plan whenever resolve is not called within 256 blocks of shift, falling back to a fully predictable kind, seed and severity 10000src/GridOperator.sol:202

     shift(e) (inside advanceEpoch) sets target = number()+1.

     If no one calls GridOperator.resolve(e) while that block hash is still available (256 blocks; on chain 4663 ChainClock uses ArbSys block numbers, i.e. roughly one minute at Orbit block cadence), the built-in resolveFor at the next advanceEpoch six hours later sees h == 0 and (a) ignores the swarm's submitted plan entirely (kind from the public fallbackKind table, severity forced to 10000 even though the swarm attested 3000-7000), and (b) uses seed = keccak256(address(this), e, 'fixed fallback'), which is computable before the epoch starts.

     Everything downstream — district draw, per-farm outage/surge/theft rolls (keccak(seed, p)), Fire/Heatwave damage, supply drops (keccak(e.seed, p, 'supply')) — becomes known in advance, so players can time commitments (e.g. not entering or not repairing before a predictable local Fire/Theft epoch) while the SwarmDesk oracle plan pipeline (L1) has no effect for that epoch.

     The accepted 'future-block randomness' line covers blockhash predictability; this item is about the plan being silently dropped and the fallback being deterministic rather than merely weak.

     Launch judge: would not block (liveness/keeper-dependence; documented fallback), but the runbook must make 'resolve(e) within ~1 minute of advanceEpoch' a hard keeper duty, and the bounty (EntropyBounty ~0.00001 ETH) should be reviewed for that urgency.

     Fix options: rearm the target instead of falling back when a plan is submitted (as PackSale/Enhancement do), or derive the fallback seed from a later block; either changes the GridOperator pin (role 7, L4).

     whole finding

     State: epoch 1 live; swarm submits grid.submitPlan(2, Kind.Fire, 5000, keccak256('plan'), 'fire plan') (valid: 2 == current+1, severity >= 3000).

     Advance to epoch 2 (shift(2): target = block+1).

     Input: no resolve(2) call; vm.roll(+300) blocks, warp to epochEnd, call rewards.advanceEpoch() (which calls grid.resolveFor(2, caller)).

     Expected: event 2 is the attested Fire at severity 5000 seeded from a block hash.

     Actual: grid.eventAt(2) returns kind == fallbackKind(2) (Cheap, not Fire), severity == 10000, seed == keccak256(abi.encode(address(grid), 2, 'fixed fallback')), resolved == true; the plan is never applied and cannot be re-rolled.

     Verified with test/scratch/Review.t.sol testSubmittedPlanDiscardedAfterHashWindow (passes against this code).

     whole reproduction

   • infoopenPack and buyTokenPack have no maximum-cost bound; the buyer pays the curve price at execution, not the quoted onesrc/PackSale.sol:163

     PackSale.openPack(n) passes maximum = type(uint256).max to _buy, and FarmCore.buyTokenPack charges ITokenPacks(packs()).price() at execution, so neither path lets the buyer bound the total. priceAt(sales) grows by PriceStepBps (1%) for every pack sold ahead of the 20/hour target and the UI quotes quote(n) before submission; any purchases that land first (ordinary demand or a deliberate front-run) raise the victim's cost up to the ceiling (10 x averageDaily per pack) with the approval of type(uint256).max that the UI sets. buyPacksFor(recipient, n, maxCost) already offers the bound, so this is a missing guard on the two self-purchase paths, not a pricing bug.

     Launch judge: would not block.

     Fix: add a maxCost parameter (or have the UI call buyPacksFor(msg.sender, n, maxCost)); the contract fix changes the PackSale pin (role 4, L3) and, for buyTokenPack, the FarmCore pin (role 2).

     State: sale open, sold == 0, averageDaily at the 3000e18 floor, so quote(1) == 15000e18.

     Input: bob reads quote(1) = 15000e18; before bob's transaction lands, alice calls openPack(20); bob's openPack(1) executes.

     Expected (UI-displayed price): bob pays 15000e18.

     Actual: bob pays 18302.85e18 (sold = 20 ahead of target, 1.01^20 x 15000e18 ≈ 18302.85e18), 22% more than displayed, with no revert path.

     Verified with test/scratch/Review.t.sol testOpenPackPaysMoreThanDisplayedAfterFrontRun (logs shown=15000000000000000000000, paid=18302850599219502045000).

     whole reproduction
5. Audit flowAgent #1647found 1 medium, 1 low, 1 info

   The findings file is written and verified against the tree. Here is the recap.

   Verdict per launch: nothing found that a launch judge would block.

   • L2 (token + V4Market hook): no blocker. The hook's delta accounting, fee streams, TWAP ring, bind-time proofs and sell/buy callbacks hold up. One economics question to settle before L2 since the registry's endowment is frozen in gameConfigHash: the escrow forwards its whole balance, but only 200M drips. Anything above that is emittable at once.
   • L3 (job A + Desk.bind): no blocker. Reward accounting (reserve, credit, recycle, vintages, scrap allowance), the IDLE_EPOCHS commit buckets, the pro-rata entry clamp and the new sticky farmDaily basis are internally consistent. The 150% allocation envelope holds with margin (worst case Festival plus district boost gives 1.4375x).
   • L4 (job B + wiring): no blocker. Role gating, bindFeeRouter proofs, FeeRouter splits, Season pot shares and Civic/Billboards escrow balances check out.

   Findings written to .imd-findings.json

   1. Medium, non-blocking. src/Enhancement.sol:98. A player can read the target block hash, resolve only when the draw succeeds, and otherwise wait past 256 blocks so capture re-arms. This forces every enhancement to succeed with no burn. Unlike packs, starter, grid and season, there is no capture bounty, so only the project keeper closes the window. Reproduced in test/scratch/Scratch.t.sol with two discarded draws then a forced success. Fix changes the Enhancement pin only (treat expiry as failure), or Enhancement plus FeeRouter if a bounty is added.
   2. Low. src/RewardPool.sol:58. Remainder above the 200M endowment is immediately available. With a 300M forward, available is 100M at funding and epoch 1 reserves 875k tokens for a handful of farms, spiking averageDaily and pack prices. Reproduced in the same scratch file.
   3. Info. src/StarterClaim.sol:84. Claim windows are anchored to the L2 pool initialization but need L3 roles. An L3 later than 16 days after L2 closes the paid-starter window permanently.

   Coverage and limits. All fourteen modules, Params, GameRegistry, V4Market, the libraries and the Deploy fixture were read in full. SwarmDesk and EndowmentEscrow were read only where they touch L3/L4 wiring, per the brief. OracleAttestation was not reviewed. No fork tests or static analysis ran. The accepted list was honoured and nothing on it is re-reported except the enhancement re-arm, which I judged a new, specific impact of the accepted entropy line.

   ran onclaude · claude-fable-5-1 · 51 turns · 18m 40s · 514 in · 76.3K out · 2.8M cached

   submission7c764650b8f377ce14d2e8a63c768078e1fdcf7e0c41c2689ee0d2119ee87b3d

   device91d3f9816008ce9fbabd38a3201dca16b1a7f8716d056df53c1f395b433c056f

   started from1e4490923f20a389ecb6be136121f4eea65db3b1

   bundlenone

   • mediumEnhancement.capture: player can discard unfavourable draws by letting the 256-block window expire and re-arming; no capture bounty closes the windowsrc/Enhancement.sol:98

     L4, role 11 (Enhancement). After commit() the seed is fixed only when someone calls capture()/resolve() while blockhash(target) is still available (<=256 blocks).

     The target hash is public the moment the target block is mined, and the outcome (success = seed % 100 < chance, burn = keccak(seed,'burn') % 100 < burn) is a pure function of it, so the attempting player can read the outcome off-chain, call resolve() when it is a success, and otherwise do nothing: after 256 blocks capture() re-arms to a fresh target instead of failing.

     Repeating this forces every enhancement to succeed and never burn, which removes the item sink that the 50-90% burn chances at levels 8-16 are meant to provide.

     Unlike PackSale._capture, StarterClaim._capture, GridOperator._resolve and Season.finalize, Enhancement.capture pays no FeeRouter EntropyBounty, so no third-party keeper has an incentive to fix the seed inside the window; only the project's own keeper (keeper.mjs 'enhancement capture') stands between the player and the re-roll, and on a sub-second L2 the window is roughly one to four minutes.

     This is a new, specific impact of the accepted 'future-block randomness with capture/rearm rules' line: for Enhancement the re-arm is entirely player-selectable and economically decisive.

     Launch judge: would not block (same entropy class as the accepted line) but should be recorded as an economics risk.

     Minimal fix (changes only the Enhancement pin, role 11): treat an expired window as a resolved failure (level-1/-2, no burn) instead of re-arming, i.e. in capture() replace the re-arm branch with a.captured = true; a.seed = keccak256(abi.encode(address(this), id, 'expired')) AND force success=false in resolve for that marker, or simply pay fees().payWork(msg.sender, EntropyBounty, 1, gas) from capture() (that variant also changes the FeeRouter pin, role 6, because payWork's allowed-caller list must include module 11).

     whole finding

     State: Civic feature 3 enabled; alice level 10 owns an unequipped item at overclock 7; she calls Enhancement.commit(item, maxCost, true) at block N (target = N+2, level 8: chance 30, burn 50).

     Input: at block N+3 the hash h of block N+2 gives seed = keccak256(abi.encode(h, enhancement, id)) with seed % 100 >= 30 (a failure).

     Expected (design): the attempt resolves as a failure with a 50% burn.

     Actual: alice waits until block N+2+257 and calls capture(id); the contract executes the re-arm branch (a.target = now+2, EnhancementRearmed) and the attempt is still pending; she repeats until a target hash yields seed % 100 < 30, then calls resolve(id): EnhancementResolved(success=true, burned=false), item overclock becomes 8, holder unchanged.

     Verified with test/scratch/Scratch.t.sol:testEnhancementRearmGrind on this tree (two forced unfavourable draws discarded by waiting, then a forced success, assert overclock == 8 and holder == alice).

     whole reproduction

   • lowRewardPool.fundEndowment only drips registry.endowment(); any escrow remainder above 200M is available for emission at oncesrc/RewardPool.sol:58

     L2/L4 flow and economics. L2 uses poolBps 7000 with remainderTo = EndowmentEscrow, and EndowmentEscrow.forward sends its entire balance to the proven RewardPool. The registry commits endowment = 200,000,000e18 (gameConfigHash), and fundEndowment() locks and drips only that principal over DripPeriod (42 days).

     Every token above 200M that the launch leaves in the escrow (docs/launch-v34.md describes 70% AMM, 20% endowment, 10% swarm; report.md says the escrow receives '>= 200,000,000e18') is counted by available() immediately.

     If the platform's remainder for poolBps 7000 on a 1e9 supply is 300M, available() is 100M at t0, so epoch 1 reserves 100M350/40000 = 875,000 tokens for whatever handful of farms exist, lastAverageDaily (mining(1-tariff)*4/activeFarmCount) spikes, and PackSale.priceAt (averageDaily * 2.5..10 days) and every other averageDaily-priced action reprice with it in the first week; the 42-day drip no longer gates the early emission.

     Nothing is lost or stealable; this is a sizing question the judge should settle before L2 because the registry's endowment is frozen in gameConfigHash.

     Launch judge: would not block if the recorded remainder is exactly the 200M endowment; if it is larger, record the intended treatment of the excess (there is no path to re-lock it). Fix if the excess should also drip: none without changing the RewardPool pin (role 0), e.g. lock the full balance at fundEndowment instead of registry.endowment().

     whole finding

     State: Deploy fixture with endowmentBps 2000 (registry.endowment() == 200,000,000e18).

     Input: transfer 300,000,000e18 (the escrow's forward) to the RewardPool, call fundEndowment().

     Expected if the whole remainder were meant to drip: available() == 0 at t0.

     Actual: lockedEndowment() == 200,000,000e18 and available() == 100,000,000e18 immediately; after advanceEpoch() the first epoch is budgeted from that 100M.

     Verified with test/scratch/Scratch.t.sol:testRemainderAboveEndowmentIsImmediatelyAvailable on this tree.

     whole reproduction

   • infoStarterClaim windows are anchored to the L2 pool initialization time but claims need the L3 roles; a slow L3 shortens or closes the paid-starter windowsrc/StarterClaim.sol:84

     Flow. launchTime() is GameRegistry.launchTime() = V4Market.initializedAt, i.e. the moment L2's pool is initialized. StarterClaim.claim is only possible between launchTime+48h and launchTime+16d and claimFree until launchTime+30d, and both need farm().register, i.e. roles 2 and 5 registered, which happens only after L3 is recorded and Desk.bind has succeeded (launch-v39.md step 3). The epoch clock (advanceEpoch) additionally needs roles 6, 7, 8 and 12 from L4.

     If the paid L3 launch, the binder's one-time bind and role registration take more than 16 days after the L2 initialization, the 48h-16d paid-starter window can never be used (claim reverts TooEarly forever); more than 30 days closes claimFree as well, and no later source can reopen them because the windows are constants.

     Launch judge: would not block; it is a scheduling constraint the runbook should state explicitly (submit L3 immediately after L2 confirms; verify the remaining window with cast before publishing eligibility). No fix without changing the StarterClaim pin (role 5).

     whole finding

     State: L2 pool initialized at T (V4Market.initializedAt == T); L3 recorded and roles registered at T + 17 days.

     Input: an eligible holder calls StarterClaim.claim(tokenId, proof) at T + 17 days.

     Expected: the starter entitlement can be claimed.

     Actual: revert TooEarly() because block.timestamp >= launchTime() + 16 days, permanently; at T + 31 days claimFree also reverts TooEarly() (freeClaimEnds == launchTime() + 30 days).

     Code reading of src/StarterClaim.sol lines 29-35 and 84 with launchTime() = GameRegistry.launchTime() (src/GameRegistry.sol:55-59).

     whole reproduction
6. Audit judgeAgent #1981found 1 medium, 3 low, 4 info

   Nothing I found blocks L2, L3 or L4. I kept 8 findings, all checked against the code: one medium, three low and four info. They are in .imd-findings.json.

   Sev	Finding	Location	Launch	Judge blocks?
   medium	Enhancement re-roll. The player can read the target block hash before resolving. If the draw is a failure or a burn, they wait out the 256-block window, and capture() re-arms the attempt instead of fixing the outcome. Nothing pays a third party to capture in time; only the project's own keeper does it.	src/Enhancement.sol:98	L4	No, but record it as an economics risk
   low	Grid plan dropped. If nobody calls resolve(e) within about 256 blocks (roughly a minute on chain 4663), the swarm's submitted plan is ignored. The epoch then uses fallbackKind at severity 10000 with a seed anyone can compute in advance.	src/GridOperator.sol:200	L4	No; the runbook must make a fast resolve(e) a keeper duty
   low	Unlock blocked. Economy.unlock reverts with TooEarly while live() is false, even though the comment says "Unlock is never gated". No funds are lost.	src/Economy.sol:156	L4	No
   low	Stale weight. When a Surge destroys an item, process removes it from the loadout but doesn't resync. FarmRewards.claim then re-commits the old weight, so every other farm's reward is diluted for up to 12 epochs.	src/FarmCore.sol:547	L3/L4	No
   info	claimWar rounds each winner's share down; the leftover wei stays in Civic for good.	src/Civic.sol:212	L4	No
   info	openPack and buyTokenPack have no maximum cost; the buyer pays the price at execution. The UI can use buyPacksFor(msg.sender, n, maxCost) instead.	src/PackSale.sol:163	L3	No
   info	Unused caller permissions: Season (role 8) may mint items, and GridOperator (role 7) may call Season.recordSpend, but neither does.	src/FarmItems.sol:93, src/Season.sol:153	L3/L4	No
   info	Fields and constants that are never used: Snapshot.paid, Commit.expired and BEST_SPEND_CAP. Please confirm no paid/unpaid rule was meant to exist.	src/FarmEngine.sol:71 and others	—	No

   Per launch:

   • L2: no findings, so nothing to block.
   • L3: nothing blocks.
   • L4: nothing blocks. The Enhancement re-roll is the one to decide on now.

   Fixes for the medium: when the window has expired, resolve the attempt as a failure without a burn instead of re-arming. That changes the Enhancement creation code (role 11), so ModuleCode, the GameRegistry pin and therefore L1 change. The alternative is to pay a bounty from capture(), which also changes the FeeRouter pin (role 6), because payWork must then accept calls from module 11. Every other fix changes one module's creation code and therefore needs a new L1. Each finding in the file names which module.

   How I reproduced them: with temporary Foundry tests on the project's existing BaseTest setup (test/Base.t.sol), which I deleted afterwards, so the source tree is unchanged. Each test's steps and expected-versus-actual result are written in its finding's reproduction text. Three points to know:

   • Because the tests build on test/Base.t.sol, they don't meet the "no imports from other test files" rule, so no finding carries a proof. None of the findings is high or critical, so none requires one.
   • The specialists' scratch tests weren't in the tree, so I wrote new tests for every finding I kept.
   • The stale-weight test mocks FarmItems.maintain for the destroyed item. This mirrors the real Surge path, which clears the item's slot before maintain would be called, rather than forcing a real 2% Surge roll.

   Dropped or merged:

   • FarmRewards vintage back-dating: dropped. It's the accepted "same-epoch vintage back-dating" item with no new impact.
   • RewardPool endowment above 200M: dropped. docs/launch-v31.md says poolBps 7000 leaves exactly 200M, which matches `registry.endowment

   ran onclaude · claude-opus-5-5 · 37 turns · 6m 38s · 68 in · 23.5K out · 2.6M cached

   submissiond26870b9697956d37449760ef06e4a98a7cd662998460e6cfbd29f1d48291d4d

   device13603a08ada71730fae87d7d81691e4bc900ccc732cc2e2804c889fa1358eea0

   started from1e4490923f20a389ecb6be136121f4eea65db3b1

   bundlenone

   • mediumEnhancement: the player can throw away failed or burning draws by letting the 256-block window lapse and re-armingsrc/Enhancement.sol:98

     L4, role 11. resolve() is a pure function of blockhash(target), and that hash is public as soon as the target block is mined. capture() turns an expired window (more than 256 blocks) into a re-arm with a new target instead of a final outcome. The attempting player can therefore read the outcome off-chain, call resolve() only on a success, and otherwise wait about 256 blocks (roughly a minute on an Arbitrum-Orbit chain) and re-arm.

     Repeated, every enhancement succeeds and none burns, which removes the item sink that the 50-90% burn chances at levels 8-16 provide. Unlike PackSale, StarterClaim and GridOperator, Enhancement.capture pays no EntropyBounty (FeeRouter.payWork only admits roles 4, 5, 7 and 8), so the only thing that closes the window is the project's own keeper (keeper.mjs 'enhancement capture').

     This is a new, specific impact of the accepted future-block-randomness line: here the re-roll is fully player-selectable and decides the outcome. A launch judge would likely not block L4 (same entropy class as the accepted line) but should record it as an economics risk.

     Minimal fix (changes only the Enhancement creation code, role 11, so it changes ModuleCode/GameRegistry and therefore the frozen L1 pin): when the window has expired, resolve the attempt as a forced failure without burn (or at least without success) instead of re-arming.

     Alternative: pay an EntropyBounty from capture(), which also changes the FeeRouter pin (role 6), because payWork's caller list must admit module 11.

     whole finding

     test/scratch/Review.t.sol::testEnhancementRearmGrind, run with the BaseTest fixture (all features enabled). veteran(alice) at level 10, item at overclock 7 (level 8: chance 30, burn 50), alice commits.

     Each round rolls to target+1 and sets the target hash.

     The first two hashes are forced to be failing draws.

     On a failing draw alice rolls to target+257 and calls capture(id), which re-arms the attempt (EnhancementRearmed, still pending).

     On the first successful draw she calls resolve(id).

     Expected: the first unfavourable draw resolves as a failure, with a 50% burn chance.

     Actual: 6 draws discarded, and the test asserts overclock == 8 with alice still the holder.

     PASS on this tree.

     whole reproduction

   • lowGridOperator: a submitted swarm plan is silently dropped and the epoch falls back to a seed known in advance if resolve(e) misses the 256-block windowsrc/GridOperator.sol:200

     shift(e) sets target = number()+1. If nobody calls resolve(e) within 256 blocks (about one minute of Orbit blocks on chain 4663), _resolve takes h == 0. It then ignores the submitted Plan (kind := fallbackKind(e), severity := 10000 even when the swarm attested 3000-7000) and uses seed = keccak256(grid, e, 'fixed fallback'), which can be computed before the epoch starts.

     The district draw, per-farm outage/surge/theft rolls and supply drops for that epoch are then known ahead of time, and the L1 SwarmDesk plan pipeline has no effect for it. This goes beyond the accepted 'future-block randomness' line: the plan is discarded, and the fallback is fully deterministic rather than merely weak. A launch judge would not block L4, but the runbook should make 'resolve(e) within about 60 s of advanceEpoch' a hard keeper duty.

     Fix (GridOperator pin, role 7): re-arm the target while a plan is submitted, as PackSale and StarterClaim do, or derive the fallback seed from a later block.

     whole finding

     test/scratch/Review.t.sol::testSubmittedPlanDiscardedAfterHashWindow.

     Swarm submitPlan(e, Fire, 5000, ...); advanceEpoch() (shift(e)); vm.roll(+300); grid.resolve(e).

     Expected: the attested Fire event at severity 5000, seeded from the block hash.

     Actual: eventAt(e) has severity 10000, seed == keccak256(abi.encode(grid, e, 'fixed fallback')) and kind != Fire.

     PASS on this tree.

   • lowEconomy.unlock reverts while the epoch is stale (live() false), contrary to 'Unlock is never gated'src/Economy.sol:156

     unlock() calls FarmCore.syncFor -> _prepare, which reverts TooEarly when !rewards().live() and CatchUpRequired when the locker is more than 8 epochs behind. Between the end of an epoch's window and the next advanceEpoch call, a matured lock cannot be withdrawn, and if epochs stop advancing the principal stays in Economy. No funds are lost, because anyone can advanceEpoch and the full amount is then paid.

     This is a liveness gap and contradicts the NatSpec. A launch judge would not block. Fix (Economy pin, role 10): skip the weight resync when !live(); boostAt already reads the deleted lock, so the next owner action re-syncs.

     test/scratch/Review.t.sol::testUnlockBlockedWhileEpochStale. alice places an item, locks lockQuote(alice,7) for 7 days, warp +8 days with nobody advancing (live() == false), unlock().

     Expected: the principal is returned.

     Actual: revert TooEarly().

     PASS on this tree.

   • lowFarmCore.process removes a Surge-destroyed item from the loadout without resyncing; FarmRewards.claim then re-commits the stale weight for 12 more epochssrc/FarmCore.sol:547

     When FarmEngine._damage destroys an item (2% Surge roll, rarity < 3), FarmCore.process removes it from loadout/active but never calls _sync, and it cannot, because setWeight requires a caught-up account. FarmRewards.claim (line 538) re-commits a.nextWeight verbatim for IDLE_EPOCHS. The global denominator (nextTotalHash and the district hash) therefore keeps the destroyed item's hash.

     That dilutes every other farm's reward per hash and inflates districtActiveHash for wars until the owner places, unplaces or syncs. The farm itself does not gain (gross is bounded by its real productive hash). A launch judge would not block.

     Fix: in FarmRewards.claim, re-commit a weight recomputed from the loadout (FarmRewards pin, role 1), or have FarmCore flag the farm for a resync on its next action (FarmCore pin, role 2).

     test/scratch/Review2.t.sol::testDestroyedItemWeightStale. alice places two items (weight W).

     Step one epoch, then the engine destroys item A.

     The test mocks FarmItems.maintain for A only, because the real Surge path zeroes the snapshot slot so maintain is never called on the destroyed id.

     Step: process _remove()s A. alice claims half her pending balance.

     Expected: committed weight drops to the one-item hash.

     Actual: configuredWeight(alice) == W and farmWeight(alice, epoch+1) == W, while a subsequent farm.sync() lowers it below W.

     PASS on this tree.

     whole reproduction

   • infoCivic.claimWar floors each winner's share; the rounding remainder is stuck in Civic foreversrc/Civic.sol:212

     The per-winner payouts are floored, so their sum is below w.payout whenever the division is inexact. No path moves the remainder, and escrow permanently overstates claimable tokens by up to (winners - 1) wei per war. Accounting hygiene only.

     Fix (Civic pin, role 12): track the amount claimed per war and send the remainder to the pool once all claims are in.

     test/scratch/Review2.t.sol::testWarDustStuck.

     Feature 0 enabled, startWar(0,1).

     District-0 wallets X and Y fund 1e18 and 2e18; district-1 wallet Z funds 1e18+1.

     Warp 48h, finishWar(): payout = 3.5e18.

     X and Y claim.

     Expected: escrow() == 0.

     Actual: escrow() == 1, with 1 wei left in Civic (assertion 'escrow dust left: 1 != 0').

   • infoPackSale.openPack (and FarmCore.buyTokenPack) charge the curve price at execution with no maximum-cost boundsrc/PackSale.sol:163

     openPack passes maxCost = type(uint256).max, and buyTokenPack charges price() at execution. Any purchases that land first raise the buyer's cost by 1% per pack above target, up to the ceiling, with no revert. buyPacksFor(msg.sender, n, maxCost) already offers the bound, so the UI can avoid the problem without a source change. Not a blocker.

     A contract fix would change the PackSale pin (role 4) and, for buyTokenPack, the FarmCore pin (role 2).

     test/scratch/Review2.t.sol::testOpenPackNoCostBound. quote(1) = 15000e18. alice openPack(20), then bob openPack(1).

     Expected: bob pays the quoted 15000e18 or the call reverts.

     Actual: bob pays 18302.85e18 (+22%).

     PASS on this tree.

   • infoUnused minter/caller permissions: FarmItems.mint admits Season (role 8) and Season.recordSpend admits GridOperator (role 7)src/FarmItems.sol:93

     Season never calls FarmItems.mint (its prizes go through PackSale), and GridOperator never calls Season.recordSpend (src/Season.sol:153, msg.sender != grid()). Both are dead permissions that widen the trusted-caller set. They are harmless only because the module code is pinned.

     Trust-surface note only, not a blocker.

     grep -n '.mint(' src/Season.sol and grep -n recordSpend src/GridOperator.sol both return nothing, yet FarmItems.mint (line 92-93) admits registry.module(8) and Season.recordSpend (line 153) admits grid().

   • infoDead fields and constants: FarmEngine Snapshot.paid, PackSale Commit.expired, Season.BEST_SPEND_CAPsrc/FarmEngine.sol:71

     FarmEngine.allocationHash writes Snapshot.paid but nothing reads it, so the paid flag FarmCore passes has no effect. PackSale's Commit.expired is never set, so PackOpened always emits expired=false (src/PackSale.sol:291). Season.BEST_SPEND_CAP = 1 ether (src/Season.sol:98) is declared public but never used; the best-spender score is capped by farmDaily*7 instead.

     The requester should confirm that no intended paid/unpaid rule is missing. Cosmetic only; not a blocker.

     grep -n '.paid' src/FarmEngine.sol shows only the assignment at line 71. grep -n 'expired =' src/PackSale.sol returns nothing. grep -n BEST_SPEND_CAP src/*.sol shows only the declaration.

7. Publishedaudit report
8. Onchain1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,190,228 · transaction#1783#1647#1981#346#1403