I found no high or critical defects. The one real launch problem is that platform fees can't reach the treasury until the payer hands their fee position over to the Hook. I wrote three findings to .imd-findings.json and changed no repository files. I did not deploy anything and am not claiming a deployment succeeded.

What checks out:

• Tests: all 36 tests under the default test root pass with no skips, including the 26 mandatory cases in ACCEPTANCE.json.
• Core package: the compiled QuorumBoundCore creation code is 39,860 bytes and its keccak256 is 0x3bd4bffb…6c0d. That matches PREREQUISITES.json. On mainnet, creationHash() at 0xa4709b43… returns the same value.
• Constitution: the sha256 of constitution.en.md matches the pinned bdcd5942…28d7. Code exists at the constitution and core-package addresses, and QProbeToken binds both with no constructor arguments.
• Hook permissions: getHookPermissions() returns exactly beforeInitialize, beforeAddLiquidity, beforeSwap and afterSwap. That matches launch.json, and the hook's own constructor checks the address bits. beforeInitialize only accepts the factory, and the pool settings fit the policy: fee 12500, tick spacing 60, 90% to the pool.
• Size and gas: the factory launch uses about 13.31M execution gas; adding calldata cost I estimate it stays under 16,777,216. Hook initcode is 18,090 bytes and token initcode 3,087, both under 49,152. Every runtime is under 24,576; the largest is the hook at 8,314.

Findings:

1. Medium – fee collection reverts in a real launch. QuorumIssuanceHook.sol:82 requires the factory's fee recipient for the launch to be the Hook. A real launch sets it to the payer, so collectPlatformFees reverts and the payer keeps the fees. The tests hide this by setting the recipient to the predicted Hook at launch. The payer has to call LaunchFactory.setRequester(launchNumber, hook), and the final chain checks need to confirm it.
2. Low – stale launch.json notes. They still say "Do not submit or deploy this draft" and describe the package as pending, which contradicts PREREQUISITES.json.
3. Info – stale entries in PREREQUISITES.json. It still lists "Deploy new package…" and a placeholder address while also saying no new deployment is required.

Read: every file in src/ (all 19 contracts; the hook, router, quota, core package, token and launch-proof contracts in depth). I also read all the tests, launch.json, PREREQUISITES.json, ACCEPTANCE.json, the evidence and policy fixtures, and the external factory ABIs.

Not reached:

• I skimmed QuorumTreasury, QuorumWork and QuorumMembership rather than auditing them line by line; the passing tests are what cover them.
• I only had the external factory and pool manager as compiled ABIs and bytecode, not their source.
• I did not confirm on chain that the current official launch policy is still version 34.

Committed as dae0a09. The working tree is clean and the pinned suite hashes are untouched.

Outcome: the project is ready for manifest dispatch for the second Quorum Compatibility Probe test. No file under src/ changed, so the core creation hash, the zero-argument token and the hook's reviewed bytecode are exactly what was already verified.

What I verified

• Prerequisites are VERIFIED_DEPLOYED and I rechecked them live on Ethereum at block 26230371. The package's creationHash() and the bytes reconstructed from its two on-chain parts equal the compiled core byte for byte. The constitution contract's stored text equals the committed English text. IMD reports symbol IMD and 18 decimals.
• getHookPermissions() returns exactly beforeInitialize, beforeAddLiquidity, beforeSwap, afterSwap, and the four callbacks carry the IHooks selectors. Undeclared callbacks are not implemented.
• Transaction limits hold with the real factory bytecode: about 13.77M gas estimated for the full launch transaction in forge, and 13.25M in two Osaka Anvil rehearsals with the 16,777,216 cap enforced. Initcodes and all eleven deployed runtimes are under their caps.
• Full default suite: 42 tests pass with the verifier's fuzz seed, including all 26 mandatory cases. The gate script passes in submission mode.

Audit findings

• The medium finding reproduced. With the payer as requester, platform-fee collection reverts and claimFees pays the payer. I kept the guard, since the hook cannot change the factory's requester and removing it would break 50/50 accounting, and added a test covering the one-time setRequester(launchNumber, hook) handover and the correct split afterwards. It is disclosed in README.md, ADAPTATION.md and PREREQUISITES.json as a required post-launch chain check.
• The stale launch.json notes and PREREQUISITES.json lists both reproduced and are fixed. The manifest's structural fields are unchanged.

One disclosed risk: both constructors need mainnet state. The token checks code at the pinned addresses and the hook creates the Core through the package, as the brief requires, so an admission simulation on an empty chain without a fork would revert. ADAPTATION.md lists this, along with the launch-reference items I deliberately did not apply, such as the ETH-settled hook fee and an owner argument, because the requester's immutable governance rules forbid them.

Open after this work: IMD's manifest integration, audits and the official launch; then reading Hook.core() and the registry record, and the payer's setRequester handover.

I found no permission defect I could reproduce, so .imd-findings.json has an empty findings list. It also has a coverage row for all 76 entry points: 61 holds and 15 unreached. I changed no files and wrote no Foundry proofs, since there was nothing to prove.

What I traced (Access Control, Trust Gap and Asymmetry):

• QuorumIssuanceHook:
  • getHookPermissions() sets exactly beforeInitialize, beforeAddLiquidity, beforeSwap and afterSwap. The constructor checks the hook's address bits against that same list, and launch.json lists the same four.
  • Every callback accepts calls only from the PoolManager and enforces this pair with fee 12500 and tick spacing 60.
  • Only the factory that deployed the hook can initialize the pool (once) or add liquidity.
  • Swaps must come through the hook's own router with a trader set.
  • rewardPaid accepts calls only from the treasury.
  • collectPlatformFees checks the factory's registry record and that the fee requester is the hook itself.
• QuorumCoreCode.create: anyone can call it, but each new core's reward reporter is whoever called it, and the hook refuses any core whose reporter isn't the hook. The creation bytes are re-hashed on every call.
• QuorumSwapRouter: the callback accepts only the PoolManager during an active trade. The trader is always msg.sender, there is a reentrancy flag, and both the 3% tax and the price bounds are checked.
• QuorumTreasury:
  • Every function that moves funds can only be called by QuorumWork.
  • Operating plans can only spend operating funds.
  • Income received while a plan runs is still split 50/50, and only the operating account can send it ETH.
• QuorumOperatingAccount: only the treasury can call it. Calls to the two tokens are limited to transfer, approvals are cleared afterwards, and leftover balances go back to the treasury.
• QuotaPrototype: every write function can only be called by the hook.
• QuorumMembership and QuorumWork: the seat, agent and owner checks, plan-hash commitment, exclusion of targets and beneficiaries from voting, and ballot approval all hold.

Leads I checked and dropped:

• Treasury-held QPROBE can't be sold through the pool, because only purchased amounts carry a sell allowance. The design intends this and a test documents it.
• An operating plan can deposit its own budget back as revenue. That only happens through a plan governance approved.

Not reached (15 rows): AuthenticatedRouterPrototype, RestrictedPoolPrototype, WorkCyclePrototype and the LocalToken/LocalSeats fixtures. None of them is part of the launch the hook builds.

Not checked: I didn't run the test suite, and I didn't check the factory's liquidity path, i.e. that the sender the hook sees when liquidity is added really is the factory. That needs the official factory's code or the mainnet chain, so a later check against the deployed contracts should confirm it.

I found no math defects I could reproduce, so .imd-findings.json has an empty findings list. It also has 77 coverage rows: every listed entry point plus one row for the size and gas limits. No repository files were changed. The full default test suite passed: 108 tests, 0 skipped.

What I checked, against the constitution's numbers:

• 3% tax: it is 3% of the actual IMD amount the pool moves, rounded up, on both buys and sells. On a sell the tax can never exceed what the seller receives (for a 1-unit sell, tax is 1 and proceeds are 0), so it can't underflow. The tax splits correctly between the trader and the treasury, and the price bounds are checked against the true total paid and received.
• 50/50 revenue split: half goes to next week's allowances and the odd unit goes to operations, checked separately for IMD and the project token. Each deposit must arrive in full before it is counted.
• Weekly allowance settlement: the budget is fixed when settlement starts and each seat gets the budget divided by registrations, rounded down. Every qualified registration also counts as registered, so the total paid can't exceed the budget. The leftover rolls into a week that can't have started settling yet, and suspended members stay in the denominator.
• Original-allocation quota: unlocking matches the rules exactly (nothing at one week, 25% at two, +12.5% per week, full at eight) without overflow. Sales use up purchase quota first, then unlocked allocation, then reward quota.
• Voting: approval needs at least 5 eligible seats and yes votes of at least two-thirds of the electorate, rounded up. The time limits for funding, acceptance, repair and expiry fit together, with no gap or overlap at the edges. A suspension executed in week 10 covers weeks 11–14, and a second one can't be proposed while one is scheduled or active.
• Membership: response hours, the 126-hour requirement, exit ending the current week's qualification, and stake carried over on key rotation all behave as the constitution states. Old and new registrations of the same seat never qualify for the same week, so a seat can't be counted twice.
• Size and gas limits: the largest deployed contract is QuorumWork at 17,027 bytes (limit 24,576). The core's creation code is 39,860 bytes (limit 49,152). The measured launch transaction used 13,614,283 gas, run under the 16,777,216 cap.

Not covered: I marked the three prototype contracts (AuthenticatedRouterPrototype, RestrictedPoolPrototype, WorkCyclePrototype) as unreached. The launch doesn't deploy them, so I only checked that the prototype router's tax formula matches the real router's.

Outside my area, for the judge: I didn't confirm that fee 12500 is in the current launch policy's fee tiers, or the opening-price policy. Plain token transfers sent straight to the treasury, rather than through the hook or the revenue sink, aren't counted and can't be recovered. I didn't report that because the rules don't promise otherwise.

Review complete. The findings file is written and verified against the tree.

Result: one high and one low finding in the economics area, written to .imd-findings.json with 80 coverage rows.

• High, governance capture through the recusal list (src/QuorumWork.sol:178). An operation proposer can name any addresses as "beneficiaries", and those seats are silently struck from the electorate before assembly. Combined with the 5-voter minimum and a threshold computed on the assembled electorate, a proposer plus four allied seats can pass a plan that transfers the entire IMD and project operating balance to an outside wallet, in any DAO of up to roughly 70 qualified seats. The proof test under test/scratch/RecusalCapture.t.sol builds a 10-seat core, strikes four honest seats, passes the drain with 4 yes votes, and fails on the current code with the expected message. The same 4 votes fail without the false declaration. The proof uses the repository's inline cheat-code interface because this tree ships no forge-std.
• Low, stranded direct transfers to the treasury (src/QuorumTreasury.sol:66). Any token sent to the treasury by plain transfer raises its balance but no ledger, and no function can ever allocate or move it.

What I verified and found sound: the 3% ceil tax on actual AMM deltas both ways with single atomic deposit, the 50/50 split per asset with odd unit to operations, the allowance-pool-equals-scheduled-sum invariant across batched settlement and carry, work reserve and release symmetry across every stage, quota ordering (purchase, then unlocked grant, then rewards), fixed stake carry and refund paths, operating execution isolation with non-nested income and un-resplit refunds, and the hook's pair, fee and initialization guards. The existing 82 positive and compatibility tests pass.

Not reached: the legacy prototypes (AuthenticatedRouterPrototype, RestrictedPoolPrototype, WorkCyclePrototype) are outside the launch composition and are marked unreached. Behavior of the live IMD token under blacklist or pause was not testable here and is assumed standard.

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

Outcome. The production control flow for the second Quorum Compatibility Probe launch holds up well under the Execution Trace, Periphery and First Principles checklists. I traced every state-changing entry point listed by the verifier, plus three invariants, and found no critical, high or medium defect. Three low-severity findings are recorded in .imd-findings.json, each with a concrete input or state, and the first two were confirmed by running scratch tests against the compiled system.

Findings.

• Operating-account sweep bypasses the 50/50 split (low). Any supported-asset balance already sitting on the persistent operating account is returned as an "unused budget refund" and booked 100% to operating funds. Confirmed: 100 IMD sent to the account before a no-op approved operation raised operatingFunds by exactly 100 IMD with zero allowance share.
• Direct transfers to the treasury are frozen forever (low). No entry point reconciles balance against the ledger buckets. This is reachable from protocol paths too, since a work proposal may name the treasury itself as recipient and the resulting self-transfer silently drops the budget from earnedWork. Confirmed for the direct transfer case.
• Weekly settlement scans every enrollment id ever created (low). Exited and rotated ids are never pruned and every ballot depends on the preceding week being settled. Measured about 14,900 gas per id and about 476k gas per batch of 32, so a roster history of 1,000 ids already costs 32 transactions each week.

Coverage. All 78 listed entry points have rows, 74 marked holds and 4 pointing at the findings above, plus rows for the allowance-pool/scheduled-sum invariant, the once-only income split during operations, and the launch manifest's constructor-argument and 0x28c0 permission match. Nothing was left unreached. The hook callbacks, router settlement for both currency orders, treasury ledger math, work-cycle stage machine, suspension scheduling and membership key rotation were traced in depth. Prototype and local-fixture contracts were read and marked as non-launch surfaces.

What I could not do. The full default test suite was not rerun end to end because the via-IR build alone took about 20 minutes of the budget; the 11 inherited pool and governance tests that my scratch suite pulled in all passed, and the factory launch measured 13,308,250 gas with an 18,154-byte hook initcode, consistent with the manifest's claims.