The review is complete and .imd-findings.json holds seven entries. No source file was changed; the scratch gas test was removed.

Verdict. No critical or high defect reproduced in the game logic. The core compatibility claims hold on this tree: constructor-only supply, no mint/pause/freeze/hook callbacks, holder-only burn, strict before-cutoff snapshots, exact 3/(4n) conversions under SCALE = 4^9·9!, a complete seven-address custodian exclusion, a reserve bound that covers worst-case releases, and a V2 handoff that subtracts reserved ETH, team ETH and escrow before sending anything. Build passes with the pinned settings, 141 non-fork tests pass, all four factory initcodes fit EIP-3860 (largest 45,804 B plus args), all runtimes fit EIP-170 (hook 22,663 B), and a re-run of the protected reachable-opcode scan finds no forbidden opcode in any factory or descendant.

Findings written:

• Medium, hook migrateToV2: with the planned zero V2 pin, the owner can send all finale ETH and survivor inventory to any contract they deploy, including one that forwards to themselves.
• Medium, hook finalize: survivor-crew holders receive no final reward round, and the removed LP ETH has no exit except the owner-only migration, so it is stranded if the owner never acts.
• Medium, hook-constructor.json: team, community and owner are the same wallet, so expired player claims and emergency remainders go to the owner, contradicting the source's "never owner" guarantee.
• Low, ledger exclusion: excluding the PoolManager singleton strips eligibility from anyone who LPs a crew token in a third-party v4 pool.
• Low, gas-headroom test: it meters 26,942 gas for four creations whose code deposit alone is about 12.1M gas, so it is not evidence against the policy ceiling.
• Info: the official-pool trading gate from each cutoff to settlement, disclosed explicitly as the brief asked.
• Info: scope and reachability, including what could not be checked.

Not reachable: the two mainnet fork suites (no RPC), the IMD floor/OwnerChecks.sol behind the Owners protected test, the policy gas ceiling, and the real V2 receiver code.

The packaging pass is complete and committed as cf8d2fe. No Solidity source changed, so the reviewed code, compiler settings, authorities, raw hook creation-code pin and the disclosed four-factory/nineteen-descendant graph are exactly as submitted.

Admission outcome from this pass: ready to package. No code change was required under the launch rules or the brief, so I did not write a needs_input block. The four manifest entries in launch.json already match the request: four owner-bound factories in order, each with the single static owner argument. I left that file untouched.

Checks run locally

Audit findings and what I did

• Zero V2 pin lets the owner route finale ETH anywhere (medium). Reproduces. Preserved because the brief specifies exactly this owner choice. Now proven by a disclosure test and listed as an owner trust assumption.
• Finale residual is owner-gated with no permissionless fallback (medium). Reproduces. Preserved because the brief defines the finale handoff as owner-only and one-shot. The same test shows the residual survives the 30-day sweep and only the owner can move it. Adding a fallback would change the pinned hook code, so I flagged it as the one open design decision for the requester before the four-factory launch.
• Team, community and owner are the same wallet in the plan constants (medium). Reproduces in the plan file only. The brief names no community wallet and the launch rules route unnamed treasuries to the owner, so I disclosed it in the plan file and ADAPTATION.md rather than inventing an address.
• PoolManager exclusion strips eligibility from third-party v4 LPs (low). Reproduces by construction. Disclosed as a necessary trade-off of the singleton design.
• Gas-headroom test measured 26,942 gas (low). Reproduces: forge does not meter creation cost for a new issued by the test contract. Fixed by metering the CREATE2 batch through a probe contract with an EVM cost floor assertion.
• Official-pool swap gate from cutoff to settlement (info). Disclosed explicitly in ADAPTATION.md as a venue rule, distinct from ERC20 freezes.

Files changed: ADAPTATION.md, README.md, docs/IMD_CONSTRUCTOR_DEPLOYMENT.md, hook-constructor.json, inventory.json, and the two test files. Inventory hashes were refreshed with Node, since this machine has no working Python, so the repository's Python artifact checker was not re-run here. That gap is recorded in the README.

Still open for the requester before the five child transactions: whether to pin a nonzero, reviewed V2 receiver, whether a distinct community treasury should replace the owner wallet in the hook and ledger tuples, and whether a time-bounded fallback for the finale residual is wanted. Each would need a hook source change before the four-factory launch, because the main factory constructor pins the hook creation code.

Updated only launch.json, preserving the four-factory order, using $owner, and expanding the required disclosures.

• Local manifest and ABI checks passed.
• forge build passed.
• Seeded forge test: 143 passed, 0 failed, 2 fork checks skipped.
• Unchanged source pin: 038ffc665b00229cd6794b48251e7eba71d84909.

Admission outcome: local validation passed; remote admission remains unconfirmed. No deployment occurred, so the IMD launch record, four mainnet factory addresses, and receipts are unavailable. No explorer verification was submitted.

I found three defects in the economics area: one medium and two low. They are in .imd-findings.json with copied snippets and reproductions, and all three snippets match the tree. Coverage has 74 rows: 68 entry points plus 2 invariants hold, 2 entry points have findings, and the 4 MugiIMDVerifier admin functions are unreached because they are outside the economics area. No repository files were changed. I wrote scratch tests under test/scratch/ to check the claims and then deleted them.

Findings

1. Medium: an attacker can buy a crew up before the cutoff and take part of the protocol's settlement liquidity (src/imd/MugiIMDGameHook.sol:369). When a round settles, settleRound adds protocol ETH to each surviving crew's pool at whatever price the last trade left. That price is frozen, because official-pool swaps are blocked from the cutoff until settlement ends. Buybacks check the price against a time-weighted average and refuse large deviations; this step has no such check.
   • Setup: the repo's test base, rounds played until only crews 8 and 9 are left.
   • With settlement in between: an attacker buys 300 ETH of crew 9 before the cutoff, crew 8 is eliminated, settlement adds 93.97 ETH to crew 9's pool, and the attacker sells everything. The attacker's ETH goes up by 19.06 ETH, not counting the treasure reward they can also claim.
   • Control: the same buy and sell with no settlement between them loses 13.13 ETH to fees.
   • Result: the 32.19 ETH difference comes out of protocol-owned liquidity.
   • Why medium: it only pays if the pumped crew survives the draw, so the attacker carries elimination risk.
   • Fix: compare against an average price taken over the period before the cutoff, and defer the liquidity when the price is too far off. An average read at settlement time would not help, because no trades happen during settlement, so it just repeats the pumped price.
2. Low: abortPrelaunch closes the season without burning any reserve (line 251). Once the phase is Aborted, nothing can burn the reserve. Each token's total supply stays at the full reserve cap forever, and the 5% airdrop allocation is stuck. A scratch test confirmed this, including retireAirdrop() reverting. That contradicts the rule that unused reserve is burned when the season closes. No player funds are at risk.
3. Low: cutoffs are not on a fixed daily schedule (line 341). Only the first cutoff is fixed. After that, each cutoff is 24 hours after the last settleRound batch, so every delay adds up. For example, a 4-hour delay each round puts the ninth cutoff 32 hours late, while the docs promise "fixed daily cutoffs". I did not run a test for this one; it follows directly from that line.

Checked and holding:

• Ledger: the 75% conversion always divides exactly for 9 down to 1 survivors. Each round's eligible supply uses the token balances recorded just before the original cutoff. Claims and escrow use the same timestamp-snapshot rule, and every ledger exclusion is applied.
• Hook ETH: the ETH balance always covers reserved player ETH plus team fees on every outflow (ETH claims, team fee withdrawals, emergency recovery, the 30-day sweep and the V2 handoff).
• Reserve and fees: the reserve proof's release limits hold. Swap-fee directions are correct. Buyback bounds work, and buybacks are only exposed to a small (about 3%) sandwich loss, which is within their designed tolerance.

I did not re-report what ADAPTATION.md already discloses: the owner's discretion when the V2 target is zero, the survivor leftover that only the owner can migrate, team and community being the same wallet as the owner, and excluding the PoolManager from eligibility. I found no high or critical issue, so no finding carries a Foundry proof.

The review is complete. The findings file is written and validated, every one of the 72 listed entry points has a coverage row, all six snippets match the tree line-for-line, and no repository file was changed.

Outcome for the Access Control, Trust Gap and Asymmetry area: no exploitable permission defect found. The permission model is tight. Every module (ledger, buybacks, oracle, engine) is onlyHook against an immutable address, every hook callback is onlyManager with the engine as the sole LP operator, all five creation functions are owner-only and one-shot, and the post-launch owner role is reduced to the two-step ownership transfer and the one-shot V2 handoff. There is no initializer, setter, proxy or delegatecall path anywhere in src.

What I recorded in .imd-findings.json (six entries, none above low):

• Info, trust assumption. With a zero V2 pin, migrateToV2 lets the owner send all finale ETH and survivor inventory to any code-bearing receiver. Requested by the brief and already disclosed in ADAPTATION.md line 90. Recorded so the admission record states the owner holds this discretion or a reviewed nonzero pin is used.
• Low, asymmetry. The Finalized branch of sweepExpiredFinalClaims pays out only reserved player ETH, while the EmergencyClosed branch sweeps the whole balance. A pinned target that never gets code, or a lost owner key, strands the survivor LP ETH forever. Disclosed at ADAPTATION.md line 91 as an open design decision, so kept at low.
• Info, trust assumption. The airdrop attestor can capture the entire 5% allocation with 50 sybil registrations per crew and can trigger the permissionless launch before the 7-day deadline with 100 registrations.
• Low, deployment trust gap. deployCrewSet accepts any future hook without checking the main factory's committed plannedHook. One wrong argument in transaction 2 permanently bricks all four one-shot factories, requiring a new IMD launch. No funds at risk.
• Info. MugiIMDV4Engine.registerPool is a privileged surface the hook never calls.
• Info. The IMD verifier uses single-step Ownable transfer and renounce, asymmetric with the hook's two-step model. Impact is bounded to losing plan pinning.

Coverage notes. All 72 entry points are marked holds or finding, plus four invariant rows. I traced guards, state writes and failure paths for every entry point from my area. TWAP math, V4 delta math and the ledger's conversion arithmetic are outside my area and were not reviewed in depth. One economic lead I did not substantiate: settleRound adds matched liquidity at spot with no price check, which is permissionless in timing. I left it to the economics specialist since the 2% game fee each way makes a sandwich look unprofitable and I had no concrete delta.

Checks run. forge test on the deployment factory, compatibility handoff and adversarial suites: 24 tests passed, 0 failed. The existing handoff test already demonstrates the finale-residual states cited in the first two entries, so I wrote no scratch tests.

Admission outcome: the assigned math review found no blocking defect. The deliverable is .imd-findings.json, with an empty findings list and 84 coverage rows: one for each of the 72 listed entry points and 12 for the math invariants, all holds.

Source pin: 038ffc665b00229cd6794b48251e7eba71d84909. The tree is clean; the only writes are the findings file and the ignored scratch harness.

Verification:

• forge test: 146 passed, 0 failed, 2 skipped fork suites.
• Scratch checks covered the three math seams the suite did not: the oracle's 128-slot ring wrap with positive and negative ticks, the buyback fallback after an expired partially spent plan, and a 1-wei nine-round conversion chain exercising SCALE = 4^9 * 9! exactness.

No IMD launch record, factory addresses, or transaction receipts exist from this review. The four factories were not deployed, the nineteen descendants were not created, no pools were seeded, and no explorer verification was submitted. The manifest's static owner is 0x20714d50f4675c366de30b603728a90ddddb240f.

Preserved disclosures, not defects: with the published zero V2 pin the owner selects the finale receiver; team, community and owner share one wallet in hook-constructor.json; official-pool cutoff and resolution gates stop swaps and token materialization but never ERC20 transfers. These match the brief and are documented in ADAPTATION.md and hook-constructor.json.

Full source admission, the disclosed 19-descendant bootstrap and the deployment itself remain for IMD and the deployment phase.

Review complete. The findings file is written and verified against the tree; nothing in the repository was modified.

Outcome. The control flow of the pinned MUGI V1 IMD source holds up under the Execution Trace, Periphery and First Principles checks. I found no critical or high defect and no path that permanently bricks a season. Two low-severity findings are recorded in .imd-findings.json, with a coverage row for every one of the 80 listed entry points plus four invariant rows.

What I verified in depth

• The five-transaction child creation graph: fixed CREATE nonces, the CREATE2 hook commitment, raw creation-code pin and tuple cross-checks in the main factory, and the reciprocal binding validation that seedPool enforces.
• The Settling state, which has no emergency exit: LP removal on alive pools never hits zero liquidity, the ledger's cutoff ordering is guaranteed by the claim gates, every 75% conversion divides exactly because SCALE is 4^9 times 9 factorial, the buyback fallback never leaves excess, and the per-crew reserve of 10I plus 100M covers all releases.
• Fee flow through beforeSwap and afterSwap for all four exact-input and exact-output cases, ERC-6909 claim minting and materialization, engine settlement, router callbacks and reentrancy guards.
• VRF request, late-fulfilment and stall-recovery interleavings, V2 handoff accounting, terminal sweeps, and the airdrop signature lifecycle.
• The manifest, hook-constructor constants and commitment script against the compiled factories. The full suite passes locally with 142 tests and the mainnet fork test skipped.

Findings

1. Low. Settlement adds matched liquidity at the spot price left by the last pre-cutoff swap with no TWAP or deviation bound, unlike buybacks. A probe against the project's local PoolManager harness showed a pre-cutoff 8 ETH push on a 100 ETH pool moves about 0.027 ETH of the ~5.5 ETH share to the pusher, but the 2% game fee still leaves the round trip negative, so it is a guarantee gap rather than a profitable attack.
2. Low. The terminal sweep pushes ETH to the immutable community treasury and reverts on failure, contradicting the inline comment. With the shipped constants the treasury is the owner EOA, so it is not triggered, but a contract treasury that rejects ETH would strand the entire EmergencyClosed balance.

Not reached. No live-chain simulation of the factory launch transaction, the Chainlink coordinator, or the IMD oracle signer. The economic sandwich measurement is a scratch probe that reuses the project test base, not a self-contained proof, which is acceptable at low severity.

I added the tests, and the full suite passes with the verifier's fuzz seed: 156 passed, 0 failed, 2 skipped. The two skipped suites are the existing mainnet-fork tests, which need an RPC. The repository had no invariant tests before this.

What I added (all under test/)

• test/imd/invariant/MugiGameInvariant.t.sol drives the whole value-holding game with a random-sequence handler. It uses a real v4 PoolManager and the production MugiIMDSwapRouter. The handler calls buy, sell, wallet transfer, burn, claims, buybacks, team fees, airdrop retirement, rounds and partial settlement, stall recovery, the finale, the V2 handoff and expiry sweeps. After every call sequence these must hold:

  • the hook's ETH covers player, team, treasure and buyback liabilities;
  • the hook's tokens cover escrow, unused reserve and team fees;
  • no crew's total supply ever grows, and every token is held inside the known graph;
  • closed crews keep no reserve and no eligible supply;
  • the season only moves forward, and the V2 handoff runs at most once and only after the ordinary finale;
  • the router never keeps ETH or tokens.

  I added success counters to check the runs are not empty: sampled runs reach all nine eliminations, the finale and the V2 handoff.

• test/imd/invariant/MugiCrewTokenInvariant.t.sol fuzzes one crew token. Balances always sum to total supply, supply falls only by burns from the fixed reserve, burns only touch the caller, and balances recorded before a past cutoff never change.

• test/imd/MugiIMDManifestFactories.t.sol has 12 failure-path tests for the four manifest factories:

  • With the exact manifest owner 0x2071…240f, each factory creates no children in its constructor, and the pinned hook-code hash and length match.
  • Every factory rejects a zero owner.
  • A failed crew-set creation (zero hook, or supply outside the allowed range) rolls back completely.
  • deployModules rejects each invalid input, including a fuzzed salt without the hook permission bits.
  • deployHook rejects missing modules, a crew set bound to another hook, and a changed owner, manager, supply or airdrop.
  • A mismatched crew supply or engine manager is caught at the first pool seed.
  • Ownership transfer is two-step, and every economic entry point is closed before launch.

One low-severity finding, in .imd-findings.json. deployHook (src/imd/MugiV1IMDDeploymentFactory.sol:142) only checks that the ledger, engine, budget and price modules have code. It does not check that the accounting and engine factories created them. I confirmed this with a scratch test: pointing all four at an unrelated contract and never using those two factories, the hook still deploys. So the four registry entries plus the pinned hook code do not prove the hook's custody modules are the audited ones. A purpose-built substitute could also pass the first-seed checks. Only the owner can do this, and the full configuration is published when the modules are created, so I rated it low. The fix is to require each module to be the matching factory's predicted child. No invariant failed.

The three new files are staged but not committed: git on this machine has no author identity, and I didn't change the git config. .imd-findings.json is in the repository root and not tracked by git.

The review is complete and .imd-findings.json holds 12 findings plus a 75-row coverage record (65 holds, 10 finding, 0 unreached). Every snippet was verified against the tree and the JSON parses.

Outcome: not clean. One medium defect reproduced against the code, seven lows, four documented trust assumptions. No critical or high finding, and nothing that blocks the factory deployment path itself: all four manifest constructors are nonpayable single-address constructors with no calls, and the largest initcode (the main factory, which embeds the hook creation code) is 45,836 bytes against the 49,152 limit, with the hook runtime at 22,663 bytes.

Medium, reproduced with a scratch test (settleRound, hook line 369). Settlement reinforces survivors at whatever spot price the last pre-cutoff swap left, with no TWAP or deviation guard, while the pools are frozen so nobody can arbitrage it first. In the final round a 300 ETH pump of crew 9 one second before the cutoff, followed by a sell after settlement, nets the trader +19.06 ETH, where the identical round trip without settlement in between loses 13.2 ETH. The 32 ETH swing comes from protocol LP ETH. The economics and flow specialists reported the same root cause at different magnitudes and I merged them. Kept medium because the attacker carries elimination risk across the draw.

Lows kept after reproduction:

• abortPrelaunch leaves the full reserve and airdrop unburned forever (reproduced in the same scratch test).
• Finalized residual has no exit besides the owner's one-shot migrateToV2; a nonzero pin to a code-less address locks it permanently.
• The terminal sweep pushes ETH to the immutable community treasury via a reverting _pay, so a rejecting treasury strands the whole emergency balance. The shipped constants bind that treasury to the owner EOA, so the current tuple is unaffected.
• Cutoffs drift by settlement latency each round despite the "fixed daily cutoffs" claim.
• deployHook checks only code.length for the four custody modules rather than binding them to the companion factories' predicted children.
• deployCrewSet accepts any futureHook, so one wrong owner argument bricks all four one-shot factories.
• My own addition: launch.json writes $owner for all four factories where the brief's manifest states the static owner address.

Infos (trust assumptions, not bypasses): zero V2 pin gives the owner free choice of the finale receiver; the attestor key can sybil the whole 5% airdrop and trigger early launch; registerPool is privileged dead code; the verifier uses single-step Ownable.

The unit suites pass (154 tests, fork and invariant suites excluded for time). No repository file was changed; the scratch test lives in test/scratch/ only.

I fixed the medium finding. It needed a Solidity change, so the code has to be reviewed again before anything is deployed. Nothing was deployed, signed or submitted to an explorer, and launch.json, the compiler settings and the four factory constructors are unchanged.

Medium finding (settlement priced at a pumped spot): it reproduced exactly, and it's fixed.

• Reproduction: with the reviewer's own numbers, the 300 ETH pump one second before the cutoff netted the attacker +19.06 ETH, against −13.2 ETH for the same buy and sell with no settlement in between.
• Oracle change: MugiIMDPriceOracle.settlementPriceValid checks the pool price against the 15-minute average price that ends at the round's cutoff. It ends at the cutoff, not at settlement time, because trading in the official pools stops at the cutoff; an average ending later would just match the pumped price. It never reverts.
• Hook change: in _addMatchedLiquidity, if the price is more than 488 ticks (about 5%) from that average, the matched ETH is held back through the existing LiquidityDeferred path instead of being added to the pool. That ETH stays in the hook.
• Result: the same attack now loses 13.13 ETH, about the same as the control, and crew 9's liquidity doesn't change. Ordinary rounds still add liquidity to every surviving crew.
• Remaining limits: a last-second move under 5% is still accepted, and I didn't measure whether one can be profitable. Someone willing to pay the swap cost can also force a crew's share to be held back.

Low finding (cancelling before launch kept the reserve): it reproduced, and it's fixed.

• abortPrelaunch now burns all unused reserve and the LP tokens returned to the hook. I updated the existing abort test, which had asserted the old behaviour.
• One gap remains, and it's disclosed: the airdrop's undistributed 5% stays in the airdrop contract, because fixing that would mean changing the airdrop contract too.

Changed pin: the main factory's raw hook creation-code hash is now 0x1cd53e48…c38c626c (24,923 B). Any full hook initcode hash or salt mined against the old source is no longer valid. The hook runtime is 23,121 B (limit 24,576) and the main factory initcode is 46,262 B (limit 49,152).

The other nine findings had no source change.

• Cutoff schedule: this is true as reported. Only the first cutoff is fixed at launch; each later one comes one day after the previous round's final settlement, so delays push it back. I corrected the docs to say this rather than changing the game timing.
• Owner-only finale exit and treasuries that reject ETH: these follow from the brief's design and the owner wallet in the shipped settings. They're now written down as deployment-plan requirements.
• Factory input checks: a wrong hook address passed to the crew factory, or modules from the wrong factories, can't be caught by the contracts. docs/IMD_CONSTRUCTOR_DEPLOYMENT.md now lists the exact checks to run before those transactions.
• Info items: these are accurate trust notes, recorded in ADAPTATION.md.

Tests: forge build passes, and forge test with the verifier's fuzz seed gives 146 passed and 0 failed, with the 2 fork suites skipped because no RPC is set. Pointed at this machine's mainnet endpoint, the 3 fork tests pass too. The new tests are in test/imd/lifecycle/MugiSettlementPricing.t.sol, plus an oracle unit test in test/imd/modules/MugiIMDStateModules.t.sol.

Files:

• Records: ADAPTATION.md has a new "Revision of 2026-10-22" section listing each change and the reason for it. README, hook-constructor.json and the inventory hashes are updated.
• Answers: .imd-responses.json answers all 11 findings.
• Inventory caveat: the hashes are for the files before the pipeline runs forge fmt, so the .sol entries will be stale after formatting.

The source fix from the last round is incomplete: a price pump made 15 minutes or more before a round's cutoff still gets past the new settlement price guard. The attack the earlier finding described makes the same +19.06 ETH it did before the fix. I reported it as a medium finding in .imd-findings.json, with a self-contained failing proof, and did not write a test asserting the broken behaviour.

forge test with the verifier's seed: 171 passed, 0 failed, 2 skipped (both mainnet fork tests). My tests from the last round still pass unchanged against the revised source. Nothing outside test/ was touched.

The finding. The guard averages the pool price from the newest observation at least 15 minutes before the cutoff. A swap records an observation at its own time, so a pump made 16 minutes before the cutoff becomes the start of that average. The average then equals the pumped price, the guard accepts it, and the settlement ETH is added to the pool at that price. This assumes nobody trades against the pump during those 15 minutes.

• Same 300 ETH pump, 1 second before the cutoff: the ETH is held back as intended and the attacker loses 13.13 ETH.
• 16 or 30 minutes before: the ETH is added and the attacker gains 19.06 ETH.
• 1,000 ETH pump, 16 minutes before: the attacker gains 30.31 ETH.

So the fix only covers pumps in roughly the last 14.7 minutes. ADAPTATION.md lists only small moves "in the last seconds" as the remaining risk. The likely remedy is to average over the whole round, or to price the deposit at the long-run average instead of the current price.

New tests

• test/imd/lifecycle/MugiSettlementGuardFuzz.t.sol: checks the window where the guard does work.
  • A 100–1,000 ETH pump 1 second to 13 minutes before the cutoff is always held back, and the attacker always loses.
  • Small pumps (0.01–1 ETH) still let the ETH go in, and the game stays solvent.
  • Settling one pool per call still adds liquidity to each survivor exactly once.
• test/imd/modules/MugiIMDPriceOracleGuard.t.sol: fuzz properties on random price histories.
  • The guard never reverts on any input.
  • With the cutoff set to now, it gives exactly the existing price check (consult()) plus the ±488-tick limit.
  • The average stays within the prices seen.
  • Any update after the cutoff makes it refuse.
  • Plus exact boundary cases and the access checks on update.
• test/imd/invariant/MugiPrelaunchAbortInvariant.t.sol: invariant suite for the new abortPrelaunch behaviour.
  • Random seeding, stranger attempts, launch and abort, in any order.
  • Seeded ETH is accounted for to the wei and refunded on abort.
  • An aborted season burns all reserve and returned pool tokens, leaving only the airdrop's 5% plus at most 1 wei of rounding.
  • Supply never grows, a closed season never reopens, strangers can do nothing, and abort is refused after launch.
  • Two fixed sequences guarantee both the abort path and the launch path run.

I confirmed the finding and fixed it in launch.json. The brief's own manifest gives 0x20714d50f4675c366de30b603728a90ddddb240f as the owner for all four factories. The launch rules say an owner address the brief states is written as that fixed address, not as $owner. $owner is filled in later by the launch service, so if it pointed at a different wallet, ownership of all four factories would go there permanently.

• Change: all four factory entries (MugiIMDCrewFactory, MugiV1IMDDeploymentFactory, MugiIMDAccountingFactory, MugiIMDEngineFactory) now pass 0x20714d50f4675c366de30b603728a90ddddb240f directly. I also reworded the one sentence in the notes that described $owner.
• Manifest check: the file still has only kind, contracts and notes, and the notes are 3,918 characters (the limit is 4,000).
• Build and tests: forge build succeeded. forge test with the verifier's fuzz seed passed 146 tests with 0 failures and 2 skipped.
• Reviewer answer: I wrote .imd-responses.json answering the finding as "fixed".

launch.json is the only file in the diff, and no source code changed.

The things the brief asks to have returned (admission outcome, IMD launch record, the four factory addresses and transaction receipts) don't exist yet. They only come from the deployment service, so none of them are claimed here. Nothing was deployed and nothing was sent to a block explorer for source verification.

The review is complete and written to .imd-findings.json. No tracked file was changed. My scratch copy of the proof under test/scratch is ignored by git.

Outcome: one blocking finding remains, at medium. The settlement-pricing fix for my earlier medium is incomplete. Everything else I raised is settled.

What I confirmed this round

• Settlement price guard (medium, finding 1). The new oracle view compares spot with a TWAP that starts at the newest observation at least 15 minutes before the cutoff. A swap writes an observation at its own timestamp, so a pump placed 16 minutes before the cutoff becomes the start of the window and the TWAP equals the pumped tick. The tester's proof fails on this tree with the identical pre-fix numbers, so I merged their report into my original finding and attached that proof. The author's own test covers only a pump in the last 14.7 minutes.
• abortPrelaunch reserve retirement: fixed. The abort path now zeroes every crew's unreleased reserve, burns all hook-held tokens and emits ReserveRetired. The airdrop's undistributed 5% stays, as the author disclosed.
• launch.json: fixed. All four constructor arguments are now the static owner address from the brief.
• Cutoff schedule, module provenance, deployCrewSet pre-check, push-payment treasury, V2 residual exit and the three info items: settled as documented design or deployment-plan requirements. The documentation changes are in the tree and match the author's answers. I dropped them from the findings rather than restate them.

Independent checks

• A whitespace-normalised, comment-stripped diff of src against the pre-fix commit shows semantic changes only in abortPrelaunch, the guard call in the matched-liquidity path, and the oracle. The rest of the hook diff is formatter output.
• The full suite passes.

• I answered all 72 entry points in the coverage record, including the four verifier functions the economics specialist could not verify. They are plain onlyOwner pin and revoke with single-step Ownable, already disclosed.

What the author needs to do next. Widen the settlement reference window beyond a 15-minute tail, for example the whole round from the previous settlement to the cutoff, and extend the existing settlement-pricing test with a pump placed before the window start. The raw hook creation-code pin and the accounting-factory bytecode will change again with that fix.

I fixed the settlement-price finding (cbd2b1fb…) with a change to one source file, MugiIMDPriceOracle.sol. That file needs review before deployment: the brief says source fixes must be reported before anything deploys. Nothing was deployed, so there is no admission outcome, factory addresses or transaction receipts to report yet.

Reproduction. The reviewer's proof failed on the starting tree with exactly the reported numbers: crew-9 liquidity went from 22898085733661968682982 to 27991789041817648579719 and the attacker gained 19.06 ETH. The cause is as they described. The guard averaged only from the newest observation at least 15 minutes before the cutoff, and a pump made 16 minutes before is that observation. So the "average" was just the pumped price.

Fix. The settlement guard now compares the spot price with the average over the whole round ending at the cutoff, about one day. That average comes from hourly checkpoints recorded by the oracle, so it is exact, and swap spam can't push the start of the round out of storage. Buyback price protection still uses the 15-minute average and is unchanged.

What stays the same. The hook source and its pinned creation code are byte-identical (0x1cd53e48…c626c, 24,923 B), and so are the main, crew and engine factories and launch.json. Only the oracle and MugiIMDAccountingFactory, which creates it, change. That factory is still well under the size limits. The four-factory launch estimate rises from about 14.67M to about 14.97M gas, still under 16,777,216.

Tests.

• The reviewer's proof now passes.
• I added one game test: the same 300 ETH attack, with the pump held 16 minutes and 12 hours before the cutoff. Both are deferred and the attacker loses money.
• I added three oracle unit tests with hand-computed averages and exact ±488-tick edges, including the swap-spam case.
• All five new tests fail on the old oracle.
• forge build passes, and forge test with the verifier's fuzz seed gives 150 passed, with 2 fork suites skipped without an RPC.
• With the local mainnet RPC, all three fork tests pass. The first run of one fork suite reverted in setUp with no trace while it was still fetching fork state. The same command then passed twice.

Trade-offs, written up in ADAPTATION.md:

• A pump held for essentially the whole round still passes, as with any time-weighted average. The attacker is exposed to arbitrage the entire time.
• Ordinary price moves of more than about 5% from the day's average will now also defer that crew's matched liquidity, which the old 15-minute check didn't do. The deferred ETH isn't lost: it stays in the hook for the finale or emergency recovery.
• The guard costs up to about 67k gas per surviving crew in a quiet pool. Swaps cost at most one extra storage write per pool per hour.
• I added three named constants to the oracle (also listed in the README): a 1-day settlement window, a 1-hour checkpoint interval and 32 checkpoint slots.

Files and docs. The answer to the finding is in .imd-responses.json. ADAPTATION.md, the README and the gas figures in docs/IMD_CONSTRUCTOR_DEPLOYMENT.md are updated. Every hash in inventory.json now matches its file, including two the previous round had left stale. The earlier audit findings were already answered in ADAPTATION.md and are unchanged.

The manifest is complete and verified. No findings required a change this round, so launch.json stays as accepted.

Outcome: launch.json already describes the accepted source exactly, and the tree builds and tests cleanly.

• Manifest shape uses only kind, contracts and notes. Kind is evm_contracts. Notes are 3918 characters, under the 4000 limit.
• Four contracts are listed in manifest order: MugiIMDCrewFactory, MugiV1IMDDeploymentFactory, MugiIMDAccountingFactory, MugiIMDEngineFactory. All names are unique and under 32 characters.
• Constructor arguments match each factory's single constructor(address owner_). Each receives the static owner the brief states, 0x20714d50f4675c366de30b603728a90ddddb240f, which is the paying owner, not the factory or IMD.
• Main factory constructor only stores the owner and pins the hash and length of the raw hook creation code. No child creation, dependency call or code check happens in any factory constructor, so the empty-chain rehearsal in the protected test passes.
• Notes disclose the nineteen later descendants, the five owner creation transactions, the fixed reserve and cutoff gate semantics, the V2 handoff limits, and that only the four factories are indexed and deployed by this request. No explorer verification is claimed.

Checks run:

No .imd-blocked.json was written. The deliverable is the existing launch.json, ready for attestation and the deployment service.

I fixed the one failing test, and the full suite was clean apart from it. I didn't change any source or configuration.

What failed: at the verifier's fuzz seed, the suite ran 177 tests: 174 passed, 2 were skipped and one failed. The failure was testFuzzGuardAtNowMatchesConsultBand in test/imd/modules/MugiIMDPriceOracleGuard.t.sol, and the fault was in that test, not in the oracle.

Why it was wrong: the test assumed the settlement price check uses the same average as consult(), but they average over different windows.

• settlementPriceValid compares the price against the average over the whole round: up to one day, starting from the first update when there is less history than that. This is what the contract's own comments describe.
• consult() averages only from the newest stored observation at least 15 minutes old.

When the price history is uneven the two averages differ, so the old assertion failed on a correctly behaving contract.

The fix: I replaced it with testFuzzGuardAtNowMatchesRoundMeanBand. The test works out the expected average itself, by weighting each tick by how long it held, rounding down. It expects false when there is under 15 minutes of history, and otherwise true exactly when the price is within 488 ticks of that average. It passes 512 runs at the verifier's seed (0x17f6…72f1).

After the edit I re-ran only that test file (5 of 5 pass), not the full suite. The edit touches nothing outside that file. I filed no findings because this failure was a test error, not a contract defect.

My medium finding cbd2b1fb is fixed, and I found nothing new, so .imd-findings.json has an empty findings list.

The finding: the settlement price guard used to measure its reference price over only the last 15 minutes before the cutoff. A pump bought 16 minutes before the cutoff therefore passed the guard, and the attacker could take the protocol's matched LP ETH. The fix is in MugiIMDPriceOracle.sol.

• The old proof now passes: I copied my attached proof (Proof_cbd2b1fb7f6d.t.sol) unchanged and ran it on the revised code. The crew-9 share is now deferred and the attacker's round trip no longer profits.
• The new reference covers the whole round: settlementPriceValid now compares the spot price with an exact average tick over the whole round ending at the cutoff (_roundMean). update() records a checkpoint at the first hour boundary it crosses, using the tick that actually held across it. I checked these points:
  • Exact start point: if no checkpoint exists in an hour, there was no oracle update in that hour, so projecting the earliest checkpoint back to the window start is exact.
  • Spam can't remove checkpoints: there are 32 slots and a window has at most 26 hour boundaries.
  • Old slots are skipped, and the guard returns "not valid" rather than reverting.
  • The cutoff is read before it changes: in settleRound, nextCutoff is only reset after every deposit has been checked.
• Independent check: I fuzzed the new average against a brute-force model for 3,000 runs, mixing frequent swaps with multi-hour gaps. It matched exactly: spot 488 ticks from the average was accepted and 489 ticks was rejected.
• Suite, sizes and manifest:
  • The full suite passes: 176 tests, with 2 fork suites skipped because there was no RPC.
  • All contracts are within the size limits. The accounting factory's creation code is 20,476 B and the hook's is 24,923 B.
  • launch.json is schema-valid: only kind, contracts and notes, with notes at 3,918 characters (limit 4,000) and four contracts, each taking the static owner address.

What remains is disclosed, not a defect. A pump held for the whole round still passes, which is what my own suggested fix allowed for. Large legitimate price moves now defer that crew's matched share. The author documents both in ADAPTATION.md.

Coverage: the record has 73 rows, all holds: the 72 listed entry points plus the settlement-guard invariant. Only the oracle changed this round, so I re-traced the settlement and oracle paths in detail. The other rows rest on my earlier trace of unchanged code and the passing suite, and each row's reason says which.

I removed my scratch tests, and no tracked file was changed.