Implemented Hamster Hour (HAMSTER) with a fixed billion-token supply and an initialization-only hook that leaves trading unrestricted.

Verified with Solidity 0.8.26:

• forge build, including a clean offline build
• forge test: 42 passed, using the required fuzz seed
• forge fmt --check

Dependencies are vendored. Deployment parameters, assumptions, operational responsibilities, and review limits are documented in README.md and SECURITY_REVIEW.md.

Created launch.json matching the contracts, constructor arguments, permissions and required pool values.

Manifest checks and forge build passed. forge test passed all 42 tests with the supplied fuzz seed. Only launch.json is included in the deliverable.

The review found no access-control, trust-gap or asymmetry defect in either contract. It found one low-severity provenance problem outside the contracts, now recorded in .imd-findings.json. No other file in the repository was changed; all builds and probes ran in a copy under /tmp, which I deleted afterwards.

Finding 1 (low): the recorded dependency hashes are wrong for 17 vendored files. lib/dependencies.json:33 and the entries like it don't match what is on disk. SECURITY_REVIEW.md:47 says these hashes were checked, and the README says the vendored files keep their upstream content. In fact 10 v4-core files (including Hooks.sol and PoolManager.sol) and 7 forge-std files differ from their recorded hashes. I compared them with the upstream archive at the pinned commit (whose archive hash matches the record): every difference is reformatting only, with no change in meaning. OpenZeppelin and solmate match exactly. Built from either the vendored or the upstream v4-core source, the two production contracts come out with identical creation and runtime bytecode, so the launch itself is unaffected. The problem is that anyone re-checking lib/ gets 17 mismatches and can't tell reformatting from tampering. The finding includes a one-line command that lists the mismatches.

What holds:

• HamsterToken is an unmodified OpenZeppelin 5.2.0 ERC-20 that mints the full supply once to whoever deploys it. It has no owner, mint, pause, fee or blocklist. approve, transfer and transferFrom behave as standard; I traced their checks, state changes and failure paths.
• HamsterHook turns on only beforeInitialize, which rejects any caller other than its fixed pool manager (src/HamsterHook.sol:36). Because that callback is on, nobody can open the launch pool before the hook's code exists, and the factory deploys the hook and opens the pool in one transaction.
• The hook keeps no state, so pools other people open with it can't affect the launch pool.
• The remove-liquidity callbacks are off, so the factory's fee collection can't be blocked.
• Neither contract has a role that could be escalated, given up, or seized by front-running.

Checks run: forge build and forge test pass, 42 of 42. The coverage record has a holds row for each of the three token entry points and five rows for the hook-related guarantees above. Because nothing reached high severity, none of the findings carry a Foundry proof test.

Not covered: I could not run IMD's own admission tests, because they need harness files that aren't in this tree. Nothing was tested against a mainnet fork.

The review is complete and .imd-findings.json is written with an empty findings list and eight coverage rows. No file in the tree was changed. The scratch directory was removed after use.

Result: no reproducible defect in the assigned area. The deliverable is a plain OpenZeppelin v5.2.0 ERC-20 with one constructor mint and a hook that implements only beforeInitialize. Neither contract moves value, holds state, takes a fee, returns a delta or exposes a privileged role, so the Economic Security, Invariant and Flow Gap failure modes have no surface to act on.

What I verified, with evidence:

• Token conservation and exactness. The vendored OpenZeppelin files are byte-identical to the pinned upstream commit, so transfer, transferFrom and approve are the stock implementation. The project's invariant campaign and the verifier's own token floor test both pass against the compiled creation code with the policy supply and 18 decimals.
• Supply is truly fixed. One mint of 1e27 to the deployer, no mint, burn, owner, pause or upgrade path, and transfers to the zero address revert, so supply can neither grow nor shrink. The aderyn large-literal lead is just that constant, and it equals one billion tokens at 18 decimals as the README states.
• Hook has no economic surface. Only the initialization flag is set and implemented. No swap, liquidity or donate callback runs, so the factory's zero-liquidity fee collect and full removal pass untouched, and swaps match an unhooked pool exactly.
• Pre-deployment pool squat is blocked. A codeless predicted hook returns zero bytes, which Hooks.callHook rejects, and the project test reproduces that revert then succeeds once the hook exists.
• Vendored v4-core is upstream. Ten files differ from the pinned commit, but a whitespace-stripped comparison shows only formatter reflow and one pair of braces around a single-statement if. The permission validator compiled into the production hook is therefore the real one.

One trust assumption worth the judge's note, not a finding: the hook accepts any initializer and any pool key after deployment. A third party could open a second pool with it, including a dynamic-fee key whose LP fee stays zero, but they can do the same with no hook at all, and the launch pool is unaffected.

Not reached: the hook and owner floor tests could not be run locally because they import mocks and a HookFlags library that live in the verifier toolchain, not this repository. The project's own tests cover the same behaviors.

The review is complete and recorded in .imd-findings.json. The production contracts hold up; the one substantiated defect is in the vendored-dependency provenance.

Outcome

• No defect in src/. The hook enables only beforeInitialize, refuses every caller but its immutable PoolManager, returns the right selector, holds no storage, and never participates in swaps, liquidity changes, donations, or the factory's zero-liquidity fee collect. The token is an unmodified OpenZeppelin v5.2.0 ERC-20 that mints the whole supply once to its deployer. The existing suite passes, and a scratch probe I wrote and then removed confirmed behaviour on native-ETH, zero-fee, max-fee and dynamic-fee pools, with the protected floor's CREATE2 deployment path.

• One low finding, periphery. The local review claims every vendored file was hash-checked against the recorded manifest, and the README says vendored files retain upstream content. Running that check gives 17 mismatches across v4-core and forge-std. I diffed each mismatched file against the pinned upstream commit: every difference is formatting only, and the OpenZeppelin files the token compiles from are byte-identical to upstream. So the compiled contracts are built from upstream-equivalent code, but the shipped integrity evidence is false and would not catch a real edit to the Hooks library later. The finding gives the exact one-line command that reproduces the mismatches and the hash for Hooks.sol on both sides.

Coverage

Entry point	Verdict
HamsterToken.approve / transfer / transferFrom	holds
HamsterToken and HamsterHook constructors, beforeInitialize, getHookPermissions	holds
Initialization-before-code, no-op-on-trading, statelessness invariants	holds
Vendored lib/ provenance	finding 1

No finding reaches critical or high, so no proof test is attached. The guides' areas I could not exercise are outside the code: the real launch factory's atomic deploy-and-initialize transaction and the mainnet IMD pair token, which the protected harness and fork rehearsal cover separately.

I added two test files on top of the existing 42 tests. forge test passes with the required seed: 52 tests, 0 failures, 0 skips. That count leaves out my own scratch check, which is deleted before submission.

test/HamsterPoolInvariant.t.sol holds the invariant tests for value held in the pool. A handler runs random sequences of swaps (exact-in and exact-out, both directions, random hook data), liquidity adds and removals, the factory's zero-liquidity fee collect, donations and time passing. Every action runs on the hooked Hamster pool and also on an identical pool with no hook, through twin actors. Over 64 runs × 48 calls (3,072 calls, 0 reverts) these held after every call:

• Both pools stay identical: price, tick, liquidity and fee growth. The LP fee stays at 12500 and the pool's liquidity equals the total the test tracked.
• Each pair of twin actors ends with the same balances in both tokens.
• The hook never holds tokens, ETH, claims or open debts, and the PoolManager is left locked with nothing unsettled and no ETH.
• The 1e27 HAMSTER supply always adds up across every holder.
• At the end of each sequence, every position can be fully withdrawn from both pools, and the twins still match.

test/HamsterLaunch.t.sol does the launch in one transaction through a helper contract that deploys the token and the hook and opens the pool, as the factory does:

• Launch and hook attachment:
  • The launch opens the pool with the hook in its pool key, and the full supply goes to the deployer.
  • The same pool without the hook is a different pool, and the launch pool can't be opened a second time.
• Failed launches leave nothing behind:
  • A salt that gives the wrong hook address reverts the whole launch.
  • So do pool terms the PoolManager rejects (tick spacing 0, a fee over 100%, a price out of range). No token or hook is left deployed.
  • Reusing the same salt reverts.
• Opening the pool early:
  • Someone who predicts the token and hook addresses can't open the launch pool before the launch.
  • If the launch were split across two transactions, anyone could open the pool first at a price they choose. The hook relies on the launch being one transaction, as the README says.
• Hook behaviour:
  • A fuzz test shows the hook's only callback returns the right answer to the PoolManager for any input and keeps no state.
  • The runtime code of both the hook and the token has no SELFDESTRUCT, DELEGATECALL or CALLCODE.

One informational finding, written to .imd-findings.json: the hook accepts a pool opened with the dynamic-fee flag. That pool's LP fee is stuck at 0%, because only the hook could raise it and this hook can't. So anyone can open a second, zero-fee HAMSTER pool carrying IMD's hook. It doesn't touch the launch pool, which the factory opens atomically at the 1.25% fee. I confirmed the behaviour with a scratch test and reported it rather than writing a test that treats it as correct.

I found no defect that blocks the launch. Nothing outside test/ was changed, and nothing has been committed.

The review is complete and .imd-findings.json is written. No tracked file was changed; the scratch test lives under the gitignored test/scratch directory.

Result: no math, boundary or numerical-gap defect in the production code. The two contracts contain almost no arithmetic to fail. HamsterToken is a byte-identical OpenZeppelin v5.2.0 ERC-20 with a single constructor mint of 1e27 units. HamsterHook enables only beforeInitialize, performs no arithmetic, and defers every range check to the PoolManager.

What I verified in my area

• Token arithmetic edges. Full-supply transfer, zero and self transfers, allowance exactly equal to the amount, allowance one short, max allowance never decrementing, max-minus-one decrementing, and balance-plus-one reverting with no partial state. The project's own 8,192-call invariant also holds.
• Supply versus v4 limits. The supply fits comfortably in v4's int128 delta fields. Seeding seventy percent of supply single-sided into a full-range position at a price near the policy's 2,500 IMD market cap, then buying and running the factory's zero-liquidity fee collect, all succeed.
• Hook flag math. The permission bit, mask and README values agree with the vendored Hooks library, which I confirmed is token-identical to upstream at the pinned commit.
• Boundary enumeration. Pool initialization through the hook at fee 0, 12500, the maximum LP fee and the dynamic flag, at tick spacing 1, 60 and 32767, and at the minimum and maximum valid prices all pass. Out-of-range prices are rejected by core, not the hook. The hook has no payable path, receive, fallback, external call, bytes decoding or sentinel branch.

One informational finding, outside my area. The README and SECURITY_REVIEW claim the vendored sources were hash-checked against lib/dependencies.json, but 17 of the 86 recorded hashes do not match the checked-in files. The recorded values are the upstream hashes. The checked-in copies were reformatted after download. I compared all ten affected v4-core files to upstream with whitespace stripped and every difference is formatting only, so the test results stand. The author should re-vendor the raw bytes or regenerate the hash file.

Coverage record. All three listed entry points (approve, transfer, transferFrom) are marked holds, plus five invariant rows covering the token constructor, the hook constructor, the beforeInitialize callback, the hook's receive/fallback surface, and the supply-versus-v4-limits check. Nothing was left unreached.

The review is complete. The findings file is written and valid, the scratch test is removed, and the working tree has no stray files.

Outcome. No defect in the deployable code. The three specialist hash reports were one root cause and are merged into one low finding. The tester's dynamic-fee note reproduces and is kept as informational. One stale README line is added as informational.

Findings written to .imd-findings.json:

• Low, provenance record is false. 17 of 86 vendored files under lib/ do not match the SHA-256 digests the repository records, while SECURITY_REVIEW.md line 47 says that check was run. I fetched five of the drifted v4-core files from the pinned upstream commit. The recorded digests are the pristine upstream hashes, and the checked-in copies differ only by formatter line wrapping plus braces around one single-statement if in Hooks.sol. The OpenZeppelin ERC20 the token compiles from matches upstream byte for byte, so the deployed contracts are unaffected. Fix is to re-vendor and keep the formatter off lib/, or regenerate the digests and drop the "upstream content" wording.
• Info, dynamic-fee pools accepted. A scratch test opened a HAMSTER pool with the dynamic-fee flag on this hook. It opened at a zero LP fee, and no caller can raise it because the hook never calls updateDynamicLPFee. The launch pool is unaffected and the README documents that the hook validates no pool terms, so this is a design choice for the author to confirm.
• Info, README contradicts the tree. README.md line 64 says the repository deliberately contains no launch.json. The manifest step committed one. The manifest itself matches the code: one constructor word written as $poolManager, permissions matching getHookPermissions, lowercase paired currency, fee 12500 accepted.

Coverage. All three listed entry points hold. They are unmodified OpenZeppelin v5.2.0 ERC-20 functions with a single constructor mint to the deployer and no admin path. I added rows for the hook's constructor and callback, the manifest, and the factory's zero-liquidity fee collect, which the hook cannot block since no removal or swap callback is enabled.

Checks run. Full project suite passed with 52 tests and no failures. forge fmt --check passed. The slither lead was empty and the aderyn large-literal lead is an underscore-separated constant, not a defect.