The findings file is in place at the repository root (the harness's own exclude rule keeps it out of git, which is expected), and the scratch tests live only under the ignored test/scratch/. The review is complete.

Outcome

No critical, high or medium defect was found. The .imd-findings.json file holds one low finding and four informational entries. The full kept suite passes on the code as it is (90 tests, including both invariant campaigns), the hook runtime is 23,221 bytes, the token 1,502 bytes, and neither contains DELEGATECALL, CALLCODE or SELFDESTRUCT.

Contracts read in full: src/HackToken.sol, src/HackathonMachine.sol, src/OracleAttestation.sol, src/HookFlags.sol (unused by production code), every test under test/, launch.json, docs/*, and the vendored v4-core paths the hook depends on (PoolManager, Hooks, Pool.swap, BeforeSwapDelta, transient-state and state libraries, Lock, CurrencyReserves, ERC6909Claims, SafeCast).

Reached over the network (read-only public RPC): the mainnet IMD token is a non-proxy LayerZero OFT ERC20 with 18 decimals and no pause, blacklist or fee selectors; the attester and the policy owner are EOAs; the deployed PoolManager contains the transient slot constants the hook reads, so its unlock check and getSlot0 work against mainnet.

Not reachable: the launch factory and how it calls initialize (the hook requires the factory itself to be msg.sender, otherwise the launch reverts safely), the resolution of the $poolManager, $owner and $factory placeholders, and the oracle's canonical question hash.

Findings

• Low. payingWallet is taken from $owner (src/HackathonMachine.sol:161). The repository's own policy snapshot names hookAdmin = 0xcecc…a551 while the README assumes $owner is the paying wallet. If they differ, the paying wallet can register and win, and every owner power sits with 0xcecc…, including the one-shot question pin without which no round can ever settle. The resolution could not be verified here. No code change is recommended because a separate constructor argument would alter the manifest.
• Info. Deny list recycles vested-but-unclaimed prize IMD, not only unvested amounts. Intentional per the README and delayed 48 hours, so it is recorded as a trust assumption with a design-preserving softening if the requester wants one.
• Info. beforeInitialize accepts either currency ordering, so the manifest's opening price is only right when the mined HACK address sorts below IMD. The deployer should confirm the predicted ordering and price; enforcing it on-chain would make the launch revert in the other case.
• Info. Untested edges: owner distinct from paying wallet, a hostile hook on the entrant's purchase pool, and a gas-exhausting prize token. I checked all three with scratch tests. Every hostile attempt was refused by the reentrancy guard or ended in the documented stream fallback with accounting intact.
• Info. Coverage and privileged powers holders must trust: the attester key (an EOA, with a 7-day rotation delay and no emergency stop), the owner's ability to stall settlement through panel floors or censor a payout after 48 hours, first-valid-attestation-wins settlement, and keeper timing of the winner purchase within the entrant's floor.

What the adapter should do

Nothing in the Solidity needs changing for this launch. Before deployment the service should confirm what $owner resolves to, and that the factory calls PoolManager.initialize directly with the HACK/IMD key at fee 12500 and spacing 60, since the hook refuses anything else.

Added src/LaunchToken.sol using the existing HackToken implementation; creation and runtime bytecode match exactly. Added regression tests and updated ADAPTATION.md.

IMD pairing, launch.json, existing contracts, configuration, and dependencies remain unchanged.

forge build passed. forge test: 102 passed, 0 failed, 0 skipped.

Added failure-path tests for oracle signatures, claim transfers, reentrancy, and ETH-pair rejection. Strengthened custody invariants with vesting and rollback checks.

Offline forge build and forge test passed: 116 tests, zero failures or skips.

Only test/ changed. IMD pairing and launch.json remain unchanged. No new defects found.

The review is complete. The findings file is written at .imd-findings.json, the scratch tests are removed, and no source or configuration file was changed.

Outcome: no permission bypass found. I traced every state-changing entry point from the Access Control, Trust Gap and Asymmetry guides and found the permission model tight. The suite of 102 existing tests passes on this tree. All three items I report are informational trust assumptions, each with a concrete state and a reproduction I ran, and none calls for a code change.

What I report

• Owner and paying wallet share one constructor argument. The README promises the payer is excluded from prizes and holds the one-shot question pin, but the reference says $owner resolves from policy, and the policy snapshot names hookAdmin 0xcecc29b0… (a plain EOA on mainnet). If the service resolves $owner to that admin while a different wallet pays, the actual payer stays eligible and only the policy admin can pin the question. The existing imported-audit test reproduces this; the deployer's resolved $owner is the evidence still needed.
• Plain register accepts any live fee. The owner can sandwich it with a fee raise to 100 IMD. The overcharge lands in the pot, not with the owner. Already documented, with registerWithMaxFee as the guard.
• Winner share and panel floors are read live at settlement. The owner can shrink a closed round's stream from 792 to 594 IMD out of 1000, or invalidate an already-issued attestation by raising the floors. Funds stay in the pot and roll forward. Already documented.

What holds, in depth

• Manager-only callbacks are bound to the one initialized pool, fees are minted only as the hook's own ERC6909 claims, and the hook's own buy charges the same 2% explicitly where v4 skips its callbacks.
• The unlock path requires manager caller, entered guard and an exact calldata hash set in the same call. The self-call buy boundary rejects outside callers.
• Entry updates and buy configuration are payout-only and frozen at close. Owner and keepers cannot change route, recipient or floor.
• Deny, signer and domain-version changes are owner-only with public delays, and the deny generation asymmetry (pending cancel preserves streams, active removal revokes them) matches the documented intent.
• Mainnet reads confirm the constructor inputs: the IMD address is an 18-decimal OFT-style ERC20 with no pause selector, and the attester is an EOA.

Coverage. All 34 listed entry points have a row, plus three invariant rows. Three admin setters and the two result and registration paths are marked finding pointing at the informational items; everything else is holds. Nothing is unreached.

The review is complete. The findings file is in place at the repository root, and no source or configuration file was changed.

Outcome: no reproducible defect in the control flow. The findings list is empty and the coverage record answers all 34 listed entry points plus two invariants, every row holds with a one-line reason.

What I traced, against the Execution Trace, Periphery and First Principles guides:

• Hook fee path in src/HackathonMachine.sol against the vendored v4 dispatch in lib/v4-core/src/libraries/Hooks.sol. The specified-IMD fee is minted as an ERC6909 claim in beforeSwap and credited back through the hook delta, so the hook nets zero and the claim is always backed. The unspecified path charges 2% of executed IMD. Partial specified fills revert whole, as documented. Own swaps are skipped by v4 and compensated by the explicit own-fee in the buy.
• Settlement. The manager-unlocked guard, replay keys, window checks, eligibility recheck, pot split and stream write all sit in the right order. The 500,000-gas buy sub-call is fixed regardless of the outer gas, so a keeper cannot starve it into fallback.
• Buy sub-call periphery. A hostile prize-pool hook that reenters the machine, nests a launch-pool swap, or injects credit via settleFor ends in a revert of the sub-call and a stream fallback with no loss. Only the machine can take its own positive deltas, and claims cannot be burned without allowance.
• Streams and denial. Claimed is monotonic, recycle sets total to claimed, and the denied state is permanent after recycle, so the post-recycle normal claim path is unreachable and cannot underflow.

Evidence I ran. The existing 102-test suite passes. Six scratch probes under test/scratch/ also pass, covering the settleFor gift, hook reentry, keeper gas starvation over a range of limits, a 10 IMD pot, the deny/recycle/removeDeny claim sequence, and the exact-output gross-up on a real PoolManager. The static-analysis leads (strict equalities, uninitialized locals, reentrancy-after-call) were each checked and are either view-only, intentional defaults, or covered by the reentrancy guard.

Documented residuals I did not report as findings, because the code behaves as the README and docs/security-review.md state: price ordering is not validated at initialization, the entrant's floor is the only buy price protection, deny is a delayed censorship power, the one-shot question pin has no correction path, and initialization requires the factory to call the manager directly.

Not reachable here. Behaviour of the real IMD token and attester contract on mainnet, and the production deployer's initialization route, cannot be verified from this tree.

The review is complete and .imd-findings.json holds the result. No tracked files were changed. The scratch tests live under test/scratch/, which git ignores.

What I covered. I read the Senior Auditor's Mindset and the Math Precision, Boundary and Numerical Gap guides, then traced every division, cast, rounding and boundary in the hook fee paths, the settlement split, the vesting stream, the deny recycling and the round accounting. I also traced the Uniswap v4 delta plumbing in the vendored Hooks and Pool libraries to confirm the full-fill equality check and the claim minting net to zero. The existing suite of 102 tests passes. I probed the mainnet IMD token over a public RPC: it has code, reports symbol IMD with 18 decimals, and its selectors match a LayerZero OFT, so the exact-amount accounting in register and fundRound is sound.

Findings, ranked.

• Low, with a failing proof. The submitter reward steps from 1% to a flat 5 IMD at a pot of exactly 5 IMD, so the winner's stream is not monotone in pot size. A 4.99 IMD pot streams 3.95 IMD to the winner. A 5.00 IMD pot streams nothing, since the submitter takes all of it. The winner only recovers the 4.99 IMD payout once the pot reaches 9.94 IMD. This is reachable because the entry fee may be set as low as 1 IMD. The author's tests already assert this edge as intended, so the judge may treat it as a specified behaviour; the proof asserts monotonicity and fails on the current code.
• Low. On exact-output HACK purchases the hook charges 2% of the pool's IMD input rather than 2% of what the buyer pays, so the effective fee is 1.96%. On the fixture pool, the same HACK amount costs 100 IMD with a 2.00 IMD fee by exact input and 99.96 IMD with a 1.96 IMD fee by exact output. The other three swap modes charge exactly 2% of gross. A gross-up on that one branch fixes it without changing the design.
• Info. The manifest's initialPrice encodes the 2,500 IMD cap only if the deployed HACK address sorts below the IMD address. Otherwise the same number means 1 HACK = 400,000 IMD. The author already documents this and the reference says the deployer derives the opening price from policy, so I report it only for the record with the concrete number.

Coverage. All 34 listed entry points have a row, plus two invariant rows. Two rows carry findings, the rest hold, none are unreached. Nothing in my area turned up a loss-of-funds defect: the fee delta math, the partial-fill rejection, the settlement conservation and the vesting arithmetic all check out with concrete values.

The review is complete. The findings file is written and validated, and no tracked file was changed.

Outcome. The economics of HackathonMachine hold up under the Economic Security, Invariant and Flow Gap checks. I found no loss-of-funds defect. I report one low finding and one informational observation, both reproduced locally with scratch tests that pass on the current code with the numbers quoted.

Findings written to .imd-findings.json:

• Low, src/HackathonMachine.sol:531. The winner can point the 10% purchase at a pool where they are the only liquidity provider. The allocation then lands in their own position as IMD in the same block. A 1,000 IMD pot yields a 693 IMD stream and a 99 IMD purchase, and the winner withdrew 98.999… IMD immediately. A later owner denial recycled only the 693 IMD stream. The README describes the clawback as covering all unpaid stream amounts and does not say the purchased share is exempt from both the vest and the clawback. This is a documentation and trust-assumption gap, not a code change within the agreed design.
• Info, src/HackathonMachine.sol:453. In a thin prize pool, an unrelated address can force the gas-capped purchase into stream fallback by adding 25 one-tick positions along the buy's path for about 4.1M gas. The winner still receives the IMD, so nothing is lost. The README attributes fallback to hostile hooks, hostile tokens, liquidity removal or submitter timing, not to third parties.

Coverage. All 34 listed entry points have a row, plus three invariant rows. Every row is holds except configureBuy and submitResult, which reference the two findings. I traced the four swap fee modes in both currency orderings against the vendored v4 Hooks and Pool libraries, the balance equation through every writer, settlement conservation, rollover, streams, denial recycling, and the unlock callback paths.

Static-analysis leads. None reproduced as a defect. The strict-equality and uninitialized-local lines are benign, and the state change after the purchase call at line 453 is protected by the shared reentrancy guard, the manager-only callback and the calldata-hash binding.

Not reached or not verifiable here. Signature and EIP-712 domain details were only skimmed as outside my area. The production factory's initialization route, the resolved $owner, the mainnet IMD token's behavior and the opening-price currency ordering cannot be checked without the deployer or a fork, and the repository already documents them as open deployment items.