Implemented the token, combined hook/prize machine, launch manifest, heartbeat templates, documentation, and vendored dependencies.

Validation passed:

• forge build
• forge test: 50 tests; 8,192 invariant calls
• forge fmt --check
• Manifest, bytecode, and heartbeat checks

Hook runtime: 20,753 bytes, below the 24,576-byte limit.

Post-launch setup requires the real deployment block/address, one-time questionHash configuration, and a funded weekly schedule. Keeper rewards are deducted before the documented 70/10/20 split.

No deployment, broadcast, or RPC calls were made.

Updated only launch.json. Schema constraints, constructor ABI and permissions validated; forge build succeeded and all 54 tests passed.

Launch blocker: the required native-ETH pool is rejected by the existing IMD-only hook. Confirmed locally and documented first in notes. No deployment performed.

The review is complete. Findings are in .imd-findings.json at the repository root, with coverage rows for all 29 listed entry points plus four invariant and manifest rows. The scratch tests I used to confirm the findings were removed, so the tree is unchanged apart from the findings file.

What I checked. I read the Senior Auditor's Mindset and the Access Control, Trust Gap and Asymmetry guides, mapped every role and guard in HackathonMachine, and traced each entry point's checks and value exits. The project builds, and all 50 existing tests and 5 invariants pass. I wrote five probe tests against a real local PoolManager to confirm candidates before reporting them.

Findings, most severe first.

• Medium, attacker-selected attestation. Any valid attestation signed in this hook's domain with the pinned questionHash settles the round, and the first one submitted wins. Because the heartbeat fixes the block window and names this hook as consumer, anyone can pay the oracle for a fresh run with the same body and submit whichever result favours them. Two differently-signed attestations with different winners were both accepted in a probe. The fix is a scope decision for the requester, since the brief chose permissionless submission.
• Medium, questionHash has no correction path. The signer and domain version rotate through a 7-day timelock so IMD changes never strand the machine, but questionHash is one-shot. A wrong pin or an IMD canonicalization change leaves every future settlement reverting while entry fees and the 2% swap fee keep accumulating with no exit.
• Low, buy fallback forced by the submitter. Submitting from inside the caller's own PoolManager unlock makes the winner-token purchase revert on AlreadyUnlocked and silently stream the 10% instead. Reproduced with a keeper contract. The winner still receives IMD, so impact is limited to the purchase guarantee and the retained own-pool fee.
• Low, weekly slot griefing. Anyone can register junk under a builder's payout address for one entry fee, blocking that address for the week.
• Info, documented owner veto. A deny queued less than 48 hours before round close is invisible to the panel but effective at submission, so the round rolls. Recorded as a trust assumption with a reproduction, not as a defect.

What holds. All owner setters are correctly guarded and capped, both timelocks behave as specified, all four hook callbacks and the unlock callback authenticate the PoolManager, the self-call guard on the buy is sound, the stream and deny-generation logic is consistent across claim and recycle, and the manifest's permissions and constructor order match the implementation.

Not reported. The slither strict-equality and timestamp lines are sentinel checks and view functions with no harmful path. The owner front-running a registrant with a higher entry fee was reproduced but rejected as an admin-by-design power with no unprivileged amplifier. I did not go deep on the fee arithmetic in the swap callbacks, which belongs to another specialist's area.

All four snippets match their source lines exactly, and the coverage record has 33 rows covering every one of the 29 listed entry points plus the invariants and the heartbeat docs. The review is complete; .imd-findings.json is written at the repository root, and test/scratch/ holds only my throwaway reproductions.

Summary

Scope covered: Economic Security, Invariant and Flow Gap passes over HackathonMachine, OracleAttestation, HackToken, launch.json, docs/heartbeat.json/schedule.json, against the Pashov guides and the v4 / oracle-consumer references. The existing suite (50 tests incl. 5 stateful invariants) builds and passes; I confirmed the hook's fee-delta assumptions against vendored v4-core Hooks.beforeSwap/afterSwap, traced every writer of the conservation equation liquidBalance + feeClaims == openPot + closingPot + streamLiability, and every exit path of IMD from the pot.

Result: no critical/high/medium defects found in my area. The core accounting is sound: fees mint ERC-6909 claims (so a fresh manager works), specified-IMD partial fills revert instead of over-charging, settlement redeems claims before paying, the buy path is bounded and falls back atomically, and the deny/generation logic cannot revive revoked streams.

Findings written (4):

1. Low — register keys uniqueness on payout alone, so anyone paying one entry fee can squat another address's payout and lock it out for the round (front-run reproduces; test_payoutSquattingBlocksVictim).
2. Low — register pulls the live entryFee with no caller cap; an owner setEntryFee(100e18) landing first charges 10× the quoted fee (test_entryFeeFrontRun).
3. Info — The 10% token buy's spot-relative 1% limit is sandwichable; only the entrant's minRateX96 floor is absolute. I measured it honestly: unprofitable on the launch pool (−23.5k IMD for the attacker) and floor-blocked on a thin 0.05% pool; extractable value is bounded by the entrant's own slack. Already acknowledged in the README.
4. Info — Trust assumptions per spec: 7-day signer rotation hands winner selection to the owner's key; one-shot setQuestionHash permanently strands the pot if mis-set.

Not reached in depth (outside my area): manifest initialPrice vs. token/IMD address ordering, and whether the factory's tick spacing matches the hardcoded 60 — both belong to the manifest reviewer and I flagged them only in coverage notes.

Review complete. The findings file is written and validated, and no tracked files were touched (only .imd-findings.json and the disposable test/scratch/ probes).

Outcome: no critical or high defects in the control flow. The swap fee path, settlement, stream, deny-list, timelock and unlock-callback flows all trace cleanly against the Execution Trace, Periphery and First Principles checklists. The existing 50 tests pass, and nine additional probes I wrote confirmed the paths the suite does not exercise: the 10% token purchase works with IMD as either currency0 or currency1, settlement redeems pending fee claims correctly before paying, and the accounting identity holds in every writer pair.

Reported findings

• Low, registration squatting. register accepts any payout from any caller and enforces one slot per payout per round, so a griefer can front-run a builder for 10 IMD and attach disqualifying metadata to the builder's published address. The builder can re-enter from another address, so impact is bounded.
• Low, timelock execution race. executeSigner and executeDomainVersion are permissionless with no execution window. A rotation maturing between the oracle's Monday issuance and the keeper's submission can be fired by anyone, which invalidates that week's already-signed attestation and rolls the entire pot to the next round's winner. Reproduced end to end: a 1000 IMD pot moved to the following round.
• Info, spot-relative purchase limit. The 0.5% execution bound is measured from same-transaction spot, so only the entrant's floor constrains a sandwiching submitter. On the launch pool the attack lost about 24k IMD for the attacker while cutting the winner's HACK by 44%, so it is griefing only, as the README already notes.

Coverage. All 29 listed entry points have a row, plus three invariant rows. Three entry points carry findings and the rest hold. Nothing was left unreached. Static-analysis leads (strict equalities, uninitialized locals, reentrancy after the self-call) were each traced and found benign.

Added adversarial tests and stateful invariants for accounting, attestations, timelocks, prize purchases, streams, and ERC-20 behavior. All changes are under test/.

Validation passed: forge build --offline and forge test --offline — 76 passed, 0 failed, 0 skipped. Manifest and heartbeat checks also passed. No implementation defects were reproduced.

The review is complete. The findings file is at .imd-findings.json with 2 findings and 32 coverage rows, and no tracked file was modified.

What I audited. The Math Precision, Boundary and Numerical Gap guides against HackathonMachine, OracleAttestation and HackToken. I traced every fee formula through v4-core's delta accounting in both currency orderings, the round and window arithmetic, the pot split, the stream vesting, the claim and deny accounting, and the purchase path. The full suite passes (50 tests including the invariant run), and I added scratch probes for the cases it does not cover: the buy path with IMD as currency0, sub-50-wei buys, 1-wei exact-output sells, and pots exactly at and just below the 5 IMD reward floor. All of those behaved as the brief and README state.

Findings.

• Low, with proof. The purchase in _buy caps the sqrt-price move at 0.5% from spot in addition to the entrant's own floor. On a pool shaped like this launch (900M HACK seeded one-sided at the manifest's opening price, the policy's 2,500 IMD cap), the purchase only fits when it is below roughly 0.5% of the pool's virtual IMD depth. Pots of 12, 20 and 50 IMD buy; pots of 100 IMD and above all fall back to the stream even with a floor that accepts any price. The same 97 IMD trade executes on that pool without the band. No funds are lost, but the brief's token purchase becomes unreachable for ordinary weekly pots. The proof test fails on the current code and passes with the band removed, with the existing 50 tests still green.
• Info. The hook accepts either currency ordering in beforeInitialize, while the mandated opening price only values HACK at 2,500 IMD when HACK sorts below IMD. Recorded as an open item for the deployer rather than a contract defect.

Things I checked and found sound, with numbers. Fee floors and the exact-output gross-up round as documented, the specified-side partial-fill equality is exact for full fills, the reward and 70/10/20 split conserve to the wei with carry absorbing dust, winnerBps at 9000 cannot underflow carry, the claims-to-liquid redemption is backed by swapper-settled IMD so liquidBalance always covers streams and rewards, and the attestation window plus the 5-minute tolerance cannot let a result for one round settle a neighbouring one.

Not reached. Nothing in my area was left unreached. Outside it, I did not assess gas sufficiency of the 500k purchase budget against third-party hooks beyond the fallback behaviour.

The review is complete. No tracked file was changed (git diff is empty; test/scratch/ is gitignored), all 11 snippets match their path:line exactly, and .imd-findings.json holds the findings plus a 34-row coverage record (all 29 ABI entry points answered, plus the four required invariants and the heartbeat).

Summary

Reproduction basis: full suite builds and passes (76/76); I wrote test/scratch/Judge.t.sol (9 reproductions, all behave as reported) and re-ran the specialists' band proof, which fails on the current code and passes with the floor-only fix (verified on a temporary patch, source restored).

Findings (ranked):

Dropped: nothing — every specialist finding reproduced. The slither/aderyn leads (strict equalities, timestamp use, "reentrancy" in submitResult) all trace to intended logic under nonReentrant/CEI and produced no finding.

One decision for the requester: finding 3 needs a scope choice (machine-as-requester via Intake, a dispute window favouring the earliest issuedAt, or an explicit trust assumption that the panel is reproducible). The Solidity for finding 1 is correct; only the manifest needs fixing.

Implemented targeted fixes and answered all 10 findings in .imd-responses.json.

Build, tests, invariants, supplied proof, formatting, and manifest validation pass. Hook runtime: 23,221 bytes.

Competing oracle requests remain an explicitly documented trust assumption, using the report’s offered resolution. No RPCs or deployment performed.

Corrected launch.json to use the IMD/HACK pair and removed the obsolete blocking note. Recorded the finding as fixed in .imd-responses.json.

Schema validation and forge build passed. All 75 tests passed, including protected checks and invariants. No contracts or configuration changed.

The review is complete. The findings file holds zero defects and a 38-row coverage record.

Earlier reproducible findings, all confirmed fixed against the revised code

• launch.json pairing (high): pool.pairedCurrency is now the IMD address and the blocking note is gone. The validator exits 0, and the protected floor test initialises the IMD/HACK pool from the factory probe at the manifest price.
• Fixed sqrt-price band (medium): the band is replaced by TickMath boundary limits. Both supplied proofs pass on the revised code, with a 1,000 IMD pot buying HACK and streaming 693 IMD.
• First valid attestation settles (medium): the author took the documentation option I offered. README and the security review state the oracle-consistency assumption, the paid re-roll race and the lack of schedule priority. Permissionless submission is the brief's requirement, so this is settled as a documented trust assumption.

Earlier advisories

• Nested-unlock buy skip, slot squatting, third-party rotation execution and the entry-fee race are fixed. My scratch reproductions confirm the new revert paths, repair via updateEntry, owner-only execution and the fee ceiling.
• The one-shot questionHash, settlement-time deny check, submitter sandwich and currency ordering remain disputed or documented, with regression tests kept. None is a code defect to reopen.

Fresh pass on the changed lines found nothing new. The transient-lock check runs before any state change, updateEntry has the same validation as register and stops at close, and the boundary-limited buy still enforces exact fill and the entrant's floor. Static-analysis leads were benign on inspection.

Verification run: full suite 90 passed, 0 failed. Scratch suite 5 passed. Protected hook floor 4 passed with manifest-derived inputs. The tree is unchanged apart from the ignored findings file and scratch directory.