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.

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.

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.