The review is complete and .imd-findings.json holds nine findings. The working tree is otherwise untouched (the findings file and test/scratch/ are excluded by the harness's git exclude list, which is why git status is clean).

Outcome. No critical or high defect in the Solidity. The hook's fee math, delta signs, full-fill check, ERC-6909 claim backing, cumulative 70/30 split, access control and forbidden-feature list all hold up, and the hook mask 0x20cc and six-argument constructor match the brief. The substantive defects are in the worker's pre-payment validation.

Findings written:

• Medium, worker/budget.mjs:29. The worker accepts questions up to 8,000 characters, but the paid oracle door refuses anything over 2,000. Confirmed live: the free check returns question: Too big: expected string to have <=2000 characters. Such a decision is paid on-chain and refused off-chain with the 0.5 IMD spent.
• Medium, worker/budget.mjs:31. The worker never runs the free wording check and sets no allowAmbiguous/definitions. The repository's own fixture question sent to the live check came back with ambiguous_question and not_answerable blockers. Opinion-type duel decisions are refused after payment unless the reading is pinned and pre-checked.
• Low, src/CabalFundingHook.sol:216. payRequest never binds amount to Intake.priceOf; the live intake forwards overpayment whole. Reproduced with test/scratch/PayRequestPriceBinding.t.sol (1 IMD accepted for a 0.5 IMD action under a misconfigured cap).
• Low, src/CabalFundingHook.sol:30. Immutable intake plus constant action means the request fund is stranded if oracle.request@oracle-1 is retired. This is the brief's chosen design, recorded as a trust assumption.
• Low, worker/chain-adapter.mjs:65. A 300-second deadline baked into signed bytes with no fee replacement turns any slow inclusion into an Expired revert and a permanently unpaid decision.
• Info. Factory-trust note on beforeInitialize, the post-deployment configureWorker surface, a policy-vs-brief split mismatch to confirm at admission, and a coverage statement.

Verification done. Foundry suite passes offline (19 tests, 1,536 fuzz cases). Worker tests pass (25) in a scratch copy. The production-router fork review was reproduced from a scratch copy against a fresh Robinhood fork at block 92107540 in both currency orderings with zero public transactions. Live reads confirm policy 30 is unchanged (fee tier 12500, 2,500 IMD opening cap), the oracle price is still 0.5 IMD, and all pinned runtime hashes match the chain.

Not reached. The verified source of the deployed LaunchFactory, Intake, UniversalRouter and V4Quoter (checked only via runtime hashes, ABI fixtures and live calls), the browser wallet flow, and the real game question texts, which are private.

Implemented the adaptation, manifest and deployment artifacts. Changes and audit dispositions are documented in ADAPTATION.md; ABIs, constructor bytes, mined hook prediction and runtime hashes are under deployment/.

Passed:

• forge build
• 22 Solidity tests, including 1,536 fuzz cases
• 36 worker/artifact tests
• Accounting/recovery simulation and both fork currency orderings

Economics and disabled defaults are preserved. Protected configuration and dependencies are unchanged.

No public deployment or paid validation occurred. Final token addressing awaits IMD’s launch number; activation still requires verified deployment, reserve/gas funding and paid live validation.

Updated launch.json only. Verified constructors, permissions, pool settings and the notes limit.

Passed:

• Offline forge build
• 22 Foundry tests with the specified fuzz seed
• 36 Node tests
• Accounting/recovery and production-router checks in both currency orderings

Policy 30 and 0.5 IMD request pricing remain unchanged.

The findings file is written and valid, and both the project suite and my scratch probe pass. Review complete.

Outcome. The on-chain economics of CabalFundingHook and LaunchToken hold under the Economic Security, Invariant and Flow Gap checks. I found no fund-loss or misallocation defect in the contracts. One medium finding sits in the worker's admission logic, plus two info-level economic trust assumptions. Written to .imd-findings.json with 19 coverage rows (all 13 entry points answered, 18 of 19 rows resolved).

Findings

• Medium, worker/budget.mjs:23. Duel admission reserves eight decisions against the on-chain request balance only and never reads the UTC-day cap. With a 4 IMD daily cap, two duels are admitted, the first consumes the day's cap, and the second duel's first decision then spins as unavailable on every engine run while the queue stays blocked behind it until the next UTC day. Reproduced with a local adapter mirroring the suite's harness plus the contract's own LimitExceeded revert. Suggested fix keeps the design: reserve against the day's remaining cap as well, or classify a cap revert as a dated wait instead of a generic error.
• Info, src/CabalFundingHook.sol:131. The tax binds to one pool id. A hookless CABAL/IMD pool trades untaxed, so request and treasury revenue depends on liquidity staying in the official pool. Matches the brief's stated scope; reported as an economic assumption for reserve sizing.
• Info, src/LaunchToken.sol:18. PvP eligibility is a spot balance, so one 50,000 CABAL stake can qualify many wallets in sequence between queue entries. Matches the brief; reported for the game-server designer.

Leads rejected after tracing. All slither and aderyn lines on harvest and payRequest (reentrancy, divide-before-multiply, uninitialized local): the reentrancy guard, exact balance-delta checks and the algebraic identity for the cumulative 70/30 split close each path. Dust swaps under 25 wei pay no tax, which is economically irrelevant. Front-running harvest(amount) only causes a revert, not loss.

Verification run. The 22 project tests pass offline. My probe at test/scratch/EconomicsProbe.t.sol passes six cases covering the parallel-pool scope, partial-fill reverts in both pre-charged modes, dust rounding, spot eligibility and the ninth-payment day-cap revert. forge-std is not vendored, so the probe uses the repo's Vm-interface pattern; no critical or high finding exists, so no proof file is attached.

Not reached. I did not re-read policy 30's current 2,500 IMD valuation or re-verify live router, quoter and Intake deployments over the network. Those rows rely on the committed fork-review snapshot and are marked unreached.

Review complete. Findings and coverage are written to .imd-findings.json in the repository root, validated as JSON, with both snippets confirmed against the current tree.

Outcome. No critical, high or medium defects in the Solidity control flow. The hook's swap, harvest, donation, treasury and payment paths all trace as the brief specifies, in both currency orderings and all four swap modes. Two low-severity worker control-flow findings are reported.

What I covered

• Traced beforeSwap and afterSwap through the vendored v4 Hooks and PoolManager.swap, confirming the specified-delta sign handling, the full-fill check against the raw pool delta, and that the ERC-6909 claim mint nets the hook delta to zero.
• Verified the cumulative 70/30 identity in harvest is exact and cannot underflow, and that unlockCallback is reachable only from the hook's own harvest.
• Checked beforeInitialize against the deployment flow: a predicted address without code fails InvalidHookResponse, and the fork review shows the factory as initializer.
• Confirmed the mined mask 0x20cc equals the five declared permissions and matches launch.json.
• Ran the existing 22 Foundry tests (all pass) plus five scratch tests under test/scratch/ for partial fills in every mode, a 1-wei exact-output sell, and chunked harvest splits. All pass; one initial failure was my own fixture exceeding liquidity and reverting PartialFill as designed.
• Read the worker's store, engine, budget and chain adapter for cross-transaction flow.

Findings (both low)

1. admit in the worker reserves eight decisions against requestBalance only and never reads the hook's UTC-day cap. Reproduced: four matches admitted with a 1 IMD daily cap, 32 decisions reserved, two payable that day.
2. A decision whose payment reverted on chain is marked failed and never retried, while re-enqueueing the same key returns the failed row without error. Reproduced against the in-memory store.

Not done. No high-severity proof tests were written because none was warranted. forge-std is not vendored, so any proof test would need the repo's own cheatcode interface pattern. The UTC-day double-window and the unpinned tickSpacing/CABAL in beforeInitialize were already dispositioned in ADAPTATION.md and are not repeated. No repository file was modified apart from .imd-findings.json and test/scratch/.

The review is complete and recorded in .imd-findings.json at the repository root. Both snippet anchors match the tree, the JSON parses, and git reports no tracked files changed (scratch tests and the findings file are untracked, as intended).

What I checked. I read the Senior Auditor's Mindset and the Math Precision, Boundary and Numerical Gap guides, then traced every CabalFundingHook and LaunchToken entry point for rounding direction, zero-rounding, overflow, downcasts, unsigned subtraction, and the seams between precision, boundaries and the ledger invariants. I rebuilt offline, reran the 22 Foundry tests (1,536 fuzz cases) and 36 Node tests, all passing, and added two scratch probes to pin exact numbers.

Result: the on-chain arithmetic holds.

• The four tax formulas match the brief exactly, every pre-charged side is full-fill checked against the raw AMM delta, and all amounts are bounded to int128 before use.
• The cumulative split formula is exactly floor(7T/10) with no overflow and no chunk dependence. Slither's divide-before-multiply line is a false positive.
• The ledger conservation invariants hold on every path, including donations and failed intake calls.
• The permission mask, constructor order and pool fee in launch.json are consistent with the hook.

Findings (2):

1. Low, worker/budget.mjs:23. Duel admission reserves 8 decisions against the on-chain balance only and ignores the contract's UTC-day cap. Reproduced with a Node scratch test against the real store, engine and budget: 16 matches admit against a 10 IMD day cap, the 21st payment reverts LimitExceeded, and the engine resets and retries that one job every tick, starving every other admitted match for the rest of the day with no halt or diagnostic. No funds are lost. The suggested fix adds the day cap to the admission bound and gives the engine a distinct non-looping state for it.
2. Info, src/CabalFundingHook.sol:141. Atomic-unit rounding edge: exact-input buys below 25 wei are untaxed, and 1-wei exact-output trades pay up to 4 wei. This is exactly the specified floor/ceil behaviour, bounded to 1 wei per swap in the protocol's favour, and needs no change.

Coverage. All 13 listed entry points have rows (12 hold, worker admission carries finding 1), plus invariant and manifest rows. One row is marked unreached: I did not re-execute the Anvil fork of the production router within the time budget, so quote/execution parity rests on the supplied reports.

The review is complete and written to .imd-findings.json at the repository root. The working tree is otherwise unchanged.

Scope

Files read in full: src/CabalFundingHook.sol, src/LaunchToken.sol, test/CabalFundingHook.t.sol, launch.json, deployment/*, ADAPTATION.md, the deployment and project READMEs, the factory ABI fixture, and the fork and protocol reports. I checked the code against the Pashov Access Control, Trust Gap and Asymmetry guides plus the Senior Auditor's Mindset. Not reached in depth: the Node worker's internal admission and lease logic, which lives off chain and outside the assigned area. Its 36 tests pass.

Severity counts: 0 Critical · 0 High · 0 Medium · 0 Low · 1 Info

What ran. The offline Foundry build and all 22 Solidity tests pass, including the 1,536 fuzz cases. The Node worker, oracle-client and manifest tests pass. A scratch probe I wrote and removed confirmed the claims the suite did not cover directly: a stranger cannot bind the pool, the factory cannot rebind a second pool, a wrong fee or non-IMD pool is refused even from the factory, an outsider who unlocks the PoolManager cannot reach unlockCallback or burn or move the hook's ERC-6909 claims, and the owner's only power is configureWorker.

Artifacts. The shipped hook runtime hex differs from a fresh compile only in the six patched immutable slots, and its keccak equals the recorded hash. Token bytes and both ABIs are byte-identical to the compiled output. Constructor order and the 0x20cc mask match the manifest.

[I-1] Owner authority depends on the $owner placeholder resolving to the named address

Location: launch.json:10 The brief fixes the owner to 0x4251…5c5d and lists $owner as the fifth argument, which the manifest follows. The placeholder resolves to the owner the launch request names, else the payer. Because the owner is immutable and is the only caller of configureWorker, a request that omits the owner permanently hands worker and cap authority to the payer. This is a pre-deployment input to confirm, not a code defect.

Observations (non-blocking)

• beforeInitialize does not pin the launch token or tick spacing. The factory is the sole initializer and binds in the same transaction, so this is the documented trust assumption, not a gap.
• harvest, payTreasury, deposit and syncDonations are permissionless by design. A stranger calling them can only move value into the fixed ledgers or to the immutable treasury.
• Worker and owner remain trusted to submit legitimate request bodies. Daily and per-request caps bound, but do not eliminate, waste by a compromised worker.

Coverage

All 13 listed entry points have rows, 12 holds and 1 finding on configureWorker pointing at the info item, plus four invariant rows covering the permission mask, artifact integrity, the absence of owner economic powers, and the default-disabled deployment state.

Added tests and review evidence entirely under test/.

• forge build and all 57 Foundry results pass.
• 3,536 fuzz cases and 49,152 invariant calls pass.
• All 36 Node tests, local recovery E2E, and router forks in both currency orderings pass.
• Policy 30 and the 0.5 IMD request price remain unchanged.

No new implementation defects confirmed. Production files remain untouched; deployment and operation remain disabled.

Details: test/REVIEW.md and test/review-results/.

The review is complete and written to .imd-findings.json. No tracked file was changed.

Outcome. The Solidity is sound. The two reproducible defects are in the Node worker, and the one kept info item is a deployment input the source cannot enforce.

What I verified myself

• Full offline Foundry suite passes (57 tests, including both currency-ordering invariant suites) and the 36 worker, oracle-client and manifest Node tests pass.
• Every hook entry point traced: fee math matches the brief's floor/ceil rules in both orderings, pre-charged modes enforce full fills, the 70/30 split is cumulative and exact, every privileged path is limited to worker, caps and enablement, and the unlock callback can only carry the hook's own data. Slither's reentrancy lines are false positives behind nonReentrant and the manager-only callback.
• Manifest and constructor: six arguments in declaration order, permission list equals the 0x20cc mask, 12500 is the only policy 30 fee tier so beforeInitialize cannot refuse the launch pool, and the factory fork review shows the real factory as initializer.

Findings kept (3)

1. Medium, merged from three specialists. Duel admission reserves eight decisions against requestBalance only and ignores the hook's UTC-day cap. Once the cap is hit, the engine's generic error path resets and re-prepares the same capped job every tick, starving every later decision of every admitted match until the next UTC day. Reproduced with a scratch Node test driving the real store, engine and budget.
2. Low. A decision whose payment reverted is permanently failed, and re-enqueueing it returns the failed row without error, so the coordinator sees success for an unfundable decision.
3. Info. The hook owner comes from the $owner placeholder, so configureWorker authority depends on the launch request naming the brief's owner address.

Dropped. The hookless-pool, spot-balance eligibility and 1-wei rounding items match the brief's explicit design and are recorded in the coverage rows, not as defects. No specialist proof needed to be run since none attached a Solidity proof and no finding reached high severity.

Coverage. All 13 entry points answered holds with reasons, plus two invariant rows. The scratch reproduction lives in test/scratch/review-daycap.test.mjs, which is outside the submitted tree.

The responses file is excluded by the harness's own .git/info/exclude rule, so it is picked up from the working tree as intended. The revision is complete.

Outcome

Both review findings reproduced against the unchanged worker and are fixed. No Solidity changed, so the contract bytecode, constructor arguments, tax, split, reserve and admin surface are untouched.

Finding 9cb93f2… (medium, day cap) — fixed. The reproduction showed two BO5 admissions under a 4 IMD daily cap, then the capped decision returning unavailable every tick with no signed bytes, no event, and a blocked closeMatch. Changes:

• worker/day-cap.mjs (new) computes the hook's remaining UTC-day headroom from dailyLimit, spentDay and spentToday with the same day arithmetic as payRequest, counting the chain's recorded day as current until five minutes after midnight.
• worker/chain-adapter.mjs reads those three values with the balance snapshot.
• worker/budget.mjs and worker/store.mjs require the configured daily limit to match the chain and refuse a reservation, inside the same SQLite transaction, when open reservations plus eight decisions exceed today's headroom.
• worker/engine.mjs defers a capped request before preflight or signing with a dated day_cap status, records one event per day, keeps the row queued, and lets harvests and treasury payouts run behind it.

Finding 22d4a7b… (low, failed re-queue) — fixed. Re-queueing a decision whose row is failed now throws Decision payment failed instead of returning the dead row. No automatic paid retry was added.

Verification

Check	Result
forge build --offline	passes
forge test --offline with the verifier's fuzz seed	22 passed
node --test test/*.test.mjs	40 passed (4 new)
scripts/simulate.mjs on local Anvil	passed, now proves worker headroom equals the compiled hook's state and a capped request uses no nonce

Reports, validation.json and source-integrity.json were regenerated. README, deployment notes and ADAPTATION.md describe the new admission rule, the day_cap status, and the operator consequence that sixteen simultaneous BO5s need a daily cap of at least 64 IMD. .imd-responses.json answers both findings as fixed.

One limit remains as before: other simulation reverts, such as DuplicateRequest after restoring an old journal backup, still surface as unavailable and need operator reconciliation. That path spends nothing and is documented in ADAPTATION.md.

The response file is valid JSON. The git status command failed only because the sandbox blocks reading the global git config; it is not needed for the deliverable.

Outcome: the manifest is unchanged and the single advisory finding is answered as disputed in .imd-responses.json.

What I verified

• The six constructor arguments in launch.json match the hook's constructor in declaration order, and the five permissions match what getHookPermissions returns.
• The notes are 3815 characters, kind is the first field, and no hex string has odd length.
• All 22 tests pass offline with the verifier's fuzz seed.

Why the finding is disputed

• The reviewer's own text says it is not a code defect and is consistent with the brief.
• The manifest rules require the hook owner to be written as exactly $owner and refuse a hand-written address, so the manifest cannot be changed to satisfy it.
• The launch facts fix this launch's owner to 0x4251…5c5d, so the placeholder resolves to the address the brief names. The notes already say so and the deployment README already instructs reading owner() after deployment.

No file other than .imd-responses.json was created or changed.

All tests pass after this revision. With the verifier's fuzz seed, forge build and forge test ran 63 tests in 8 suites with 0 failures. I found no new defect in the implementation, so I did not write .imd-findings.json. Every change is under test/; src/, the worker, the manifest, deployment files and configuration are untouched.

What changed and why Since my last round, another contributor accepted a worker change. Before admitting a match, the worker now works out how much of the hook's daily spending limit is left. It reads dailyLimit, spentDay and spentToday from the contract, defers a request that limit would block, and refuses to re-queue a payment that already failed. No contract code changed. I added test/CabalFundingHookDayCap.t.sol to pin the contract behaviour that worker logic relies on:

• After UTC midnight with no payment yet: the views still show the previous day, and the contract still allows a full new day's limit.
• Failed payment on a new day: it leaves the old day recorded, and the limit is intact afterwards.
• Owner lowers the limit below today's spend: nothing is left for the day and nothing resets; raising it again allows exactly the difference.
• Limit not a multiple of the price: a limit one wei short of 4 IMD pays seven decisions, not eight.
• Sixteen matches: a 64 IMD limit pays all 128 decisions (sixteen matches × eight) in one day; 63.5 IMD pays only 127.
• Fuzz test (512 runs): a copy of the worker's formula never promises a payment the contract then rejects, with the worker's clock anywhere from one hour behind to five minutes ahead of the chain. Away from the five minutes after midnight it matches the contract exactly.

My first draft of two of these tests was wrong (one checked inside the worker's five-minute clock window, one ran out of deposited IMD). I fixed the tests, not the contract.

Reruns after the worker change

• Worker tests: 40/40 pass.
• Local end-to-end run: passes. A 1,000 IMD taxable trade gives 40 IMD custom fees, split 28 to requests and 12 to treasury. Eight paid decisions cost 4 IMD, and nothing was paid twice. The worker's daily-limit figure matched the compiled hook, and a request over the limit was deferred without sending any transaction.
• Live policy check (Robinhood block 92141844): policy 30 is unchanged, with the 12500 pool fee and the 2,500 IMD opening valuation. The request price is still 0.5 IMD and the live capabilities match.
• Production-router fork review (block 92141917): passes in both currency orderings, and the runtime hashes match the pinned ones.

The refreshed results are in test/review-results/, and test/REVIEW.md is updated.

Remaining limits (in test/REVIEW.md)

• Worker clock: the daily-limit check allows the worker's clock to run at most five minutes ahead of the chain. A clock further ahead across midnight would admit decisions the contract still blocks. Those payments revert before any IMD moves, so it delays payments rather than losing funds. Keep the host clock synchronized.
• Daily limit: the on-chain limit must be at least 64 IMD for sixteen simultaneous matches, and a larger request fund does not raise it.
• Before live operation: deployment and IMD admission, owner configuration, reserve and gas funding, and a paid live validation are all still required. The game integration is still separate.

Nothing has been committed or pushed.

Nothing from last round is still open, and I found nothing new to report. .imd-findings.json has an empty findings list and covers all 13 entry points, each marked "holds", plus two rows recording the confirmed fixes.

Last round's findings:

• [medium] The worker ignored the contract's daily spending cap: fixed. I re-ran my original scenario against the fixed worker code (4 IMD daily cap, 100 IMD fund, 0.5 IMD price):
  • The first match is admitted. The second is refused with "Daily spending cap reached", and still refused after the first match's 8 decisions are paid.
  • For a match whose reservation skipped admission, the engine now returns day_cap on every run. The payment is left queued, nothing is prepared, signed or sent, and the skipped day is logged only once.
  • The worker's cap calculation counts days the same way the contract does (block.timestamp / 1 days). It also keeps treating the old day as current for five minutes after midnight, so it never under-counts spending.
• [low] A failed payment could be re-queued silently: fixed. Queuing the same decision again after it failed now throws "Decision payment failed; operator review required before any re-queue".
• [info] Hook owner set through $owner: dropped. The author is right. The manifest rules require that placeholder and refuse a typed-in address, and the brief itself lists $owner for that argument. Whether the owner comes out right depends on the launch request, not the code. Reading owner() after deployment, as deployment/README.md already says, is the right check.

This round's specialist reports: they audited the code before the fix, so their three versions of the daily-cap issue and the re-queue issue are the same two findings above, now fixed. The other three are info notes describing behaviour the brief asks for:

• an untaxed second pool can be opened next to the official one;
• PvP eligibility is a live balance check, so one holding can qualify several wallets in turn;
• rounding to the smallest unit means very tiny swaps pay no tax or slightly more than 4%.

I dropped all three as not defects.

Checks run: the contracts did not change this round; only the worker, tests, scripts, docs and reports did. I read every changed worker line and found nothing the fix broke. forge test --offline passed 63 of 63 and node --test passed 40 of 40. My replay script was a temporary file outside the repository and has been deleted. I did not change any repository file except writing .imd-findings.json.