Implemented HAMSTER with 18 decimals and 1 billion tokens minted once to the deployer. No admin powers or transfer taxes.

Included offline dependencies, deployment documentation, and tests for factory distribution of the 10% pool / 80% vault / 10% Swarm allocations.

Verified with the requested fuzz seed:

• forge build passed
• forge test passed: 30 unit/fuzz tests plus two stateful invariants
• forge fmt --check passed

Actual pool integration remains with the platform verifier.

Done. The manifest is written and verified.

What was written: launch.json at the repository root, the only new or changed file in the working tree.

• Token is HamsterToken, name and symbol HAMSTER, 18 decimals, empty constructorArgs, and totalSupply of 10^27 minor units. The compiled ABI confirms a parameterless constructor, and the source mints exactly that constant to msg.sender.
• Contracts is an empty list. The accepted tree contains only the token, and the README records that the "vault" is the requester's 80% treasury allocation rather than a deployed contract.
• Pool and economics are copied exactly as the launch reference gives them: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's verbatim economics object.
• Notes describe the token's behavior, the absence of application contracts, the allocation split, and the requester's Twitter and website, within the 4000-character limit.

Verification: forge build succeeded and forge test with the pinned fuzz seed passed all 31 tests. A script check confirmed the manifest has only schema keys, correct types, the exact pool and economics objects, and a notes string of valid length. git status --porcelain shows only the untracked launch.json, with nothing outside the allowed path.

The review is complete. The findings file holds an empty findings list and seven coverage rows, and no source or config file was changed.

Outcome: no defects found in the economics area. HamsterToken is a 17-line fixed-supply token on the unmodified OpenZeppelin v5.0.2 ERC-20. It has no fee, burn, mint, admin role, callback, oracle or external dependency, so none of the Economic Security, Invariant or Flow Gap failure modes has a code path to attach to.

What I verified:

• Supply and allocation math. The constructor mints exactly 1e27 base units to the deployer, which is the CREATE2 factory. The 10 / 80 / 10 split of that supply divides with no rounding remainder, and the token has no code that could short or redirect the pool seed, the swarm share or the 80% sent to the requester's address.
• Launch flows move exactly what they say. A scratch Foundry test drove factory to distributor, pool manager and remainder recipient, a distributor claim, pool transfers in both directions and a transferFrom pull. Every balance matched and the sum of balances equalled total supply. The project's own 31 tests, including the 128-run stateful invariant, also pass.
• Entry points. approve, transfer and transferFrom all trace to unmodified OpenZeppelin internals with the expected reverts on zero addresses, insufficient balance and overspent allowance. All three are recorded as holding.
• Dependency integrity. The six vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag fetched from GitHub, so the library the token inherits from is what it claims to be.
• Static analysis lead. The aderyn large-numeric-literal note on line 12 is the constant 1_000_000_000 * 10 ** 18, which evaluates exactly to the manifest supply. Not a defect.

Not covered, and outside the token's code: the README's manifest table claims Ethereum chain ID 1 and an IMD pairing. Those are manifest-step inputs for the platform to validate, not something the token enforces, so I did not treat them as findings.

The review is complete and .imd-findings.json is written in the repository root.

Result: no defect in the token's permission model. HAMSTER is the unmodified OpenZeppelin v5.0.2 ERC-20 with one constructor mint to the deployer. It has no owner, initializer, proxy, pause, blocklist, fee, hook, or privileged mover. The build and all 31 project tests pass, including the invariant suite and the forbidden-opcode scan.

Coverage against the three assigned guides

• Access Control: all three state-changing entry points (approve, transfer, transferFrom) only touch the caller's own balance or allowance row. Mint and burn are internal with no reachable caller. Marked holds.
• Trust Gap: the token carries no economics, so no access-times-economics seam exists. The one trust assumption is recorded in a coverage row: the factory forwards 80% of supply to the requester's wallet with no on-chain lock, which is fixed by the job's remainderTo and cannot be changed by the token.
• Asymmetry: transfer and transferFrom reach the same _update path, differing only by the allowance spend. Self-transfer, zero-value and zero-address branches behave symmetrically. Marked holds.

One info-level finding, outside the assigned area. DEPENDENCIES.json records upstream hashes for seven forge-std files that the tree ships in a whitespace-reformatted form, so a reviewer verifying provenance from the record gets a mismatch. I downloaded both upstream archives to confirm. The archive hashes match, all six OpenZeppelin files are byte-identical to upstream, and the seven forge-std files differ only in whitespace. The production dependency is unaffected. No proof test was needed since nothing reached high severity.

Coverage record: 9 rows, covering all 3 listed entry points plus 6 invariant and provenance checks. Nothing was left unreached.

The review is complete. The findings file is written at .imd-findings.json and the tree is otherwise unchanged.

Result: no math defects. The token is 17 lines wrapping the unmodified OpenZeppelin v5.0.2 ERC-20, and every arithmetic path in the Math Precision, Boundary and Numerical Gap guides holds against it.

What I checked and confirmed:

• Supply constant. The literal at src/HamsterToken.sol:12 constant-folds to exactly 1e27 (90 bits), minted once through a checked add. Decimals are 18 and match the scale. The aderyn large-literal lead is dismissed.
• Transfer arithmetic. Balance subtraction is guarded before the unchecked block, and balance addition is bounded by total supply. Transfers of 1 wei, the full balance, self-transfers, type(uint256).max and supply+1 all behave exactly as the standard specifies.
• Allowance arithmetic. The max sentinel skips the decrement, max-1 is treated as finite, and an allowance equal to the spent amount leaves exactly zero. Balance failures do not consume allowance.
• Launch split. 1e27 divides evenly by 10000, so the 10/80/10 split and the swarm's 2/8 split produce no rounding dust. With no fee or burn, every launch flow arrives whole.
• Pool price. A 1000 IMD cap over 1e9 tokens gives a tick around ±138162, well inside Uniswap v4 bounds in either currency order. The deployer derives this, not the token.
• Vendored OpenZeppelin. All five files are byte-identical to the upstream v5.0.2 tag.

I ran the project's 31 tests plus eight scratch boundary probes. All passed, and the scratch directory has been removed.

One info-level finding outside my area. DEPENDENCIES.json records SHA-256 hashes for seven forge-std files that no longer match the tree. The drift is whitespace only, from a format pass before the vendored-file ignore took effect. It affects test tooling only, but it contradicts the README's reproducibility claim, so I reported it with the exact hash mismatch as reproduction.

The coverage record answers all three listed entry points as holds, plus five invariant rows for the constructor, launch split, pool price, library integrity and the absence of receive/fallback.

The review is complete and .imd-findings.json is written with one low-severity finding and nine coverage rows. No tracked files were changed.

Outcome. The HAMSTER token's on-chain code holds under all three guides. The contract is a 17-line wrapper around an unmodified OpenZeppelin v5.0.2 ERC-20 that mints the full supply to the deployer once. I found no defect in it.

What I verified

• Execution trace. All three entry points were traced through the vendored base. Zero-address checks, balance and allowance shortfalls, and the allowance-before-transfer ordering in transferFrom all revert atomically. Unchecked arithmetic is bounded by the fixed supply. No callbacks, no external calls, no sentinel paths beyond the documented infinite allowance.
• Periphery. Every vendored OpenZeppelin file is byte-identical to the upstream v5.0.2 archive, which I downloaded and diffed. Context returns plain msg.sender with no forwarder.
• First principles. The constructor's only assumption is that msg.sender is the factory, which CREATE2 from launchCustom guarantees. Supply is exactly 1e27, decimals are 18, and the ABI exposes no mint, burn, pause, owner or blacklist surface, so every assertion in the protected launch floor is satisfied by hand-trace.
• Build and tests. Clean compile, 31 of 31 tests pass with the README's fuzz seed, formatter check clean. The aderyn large-literal lead is the supply constant and not a defect.

The one finding (low). DEPENDENCIES.json records upstream SHA-256 hashes for forge-std v1.9.7, but seven of those test-only files were reformatted after vendoring and no longer match. I confirmed the differences are whitespace only, so no behaviour changed. The README's claim that the hashes verify each included file is therefore false for those seven. The fix is either to restore the upstream bytes or to record the current hashes.

Not reached. The protected launch suite could not run locally because it needs v4-core and launch environment variables. No launch.json exists yet. I confirmed the pair-token address has code on Ethereum mainnet, consistent with the README's chain statement, but did not confirm it is the IMD token.

The HAMSTER token test suite is complete and green: all 66 tests pass under the verifier's fuzz seed, and the working tree contains only the three new files under test/.

What I found. The token in src/HamsterToken.sol is a stock OpenZeppelin v5.0.2 ERC-20 that mints the full supply to the deployer and adds nothing else. I confirmed the vendored OpenZeppelin files match the SHA-256 hashes recorded in the dependency manifest. No defect surfaced in any unit, fuzz or invariant run, so there is no findings file to report.

What I added, building on the existing unit and invariant suites rather than rewriting them:

• test/HamsterToken.launch.t.sol mirrors the protected harness. An etched probe at a factory address deploys the creation code through raw CREATE2 in one call, checking the manifest supply inside that call. It covers the predicted address, a wrong manifest supply, a salt collision, a second launch number, the exact 10/80/10 split that empties the factory, uneven swarm claims that drain the distributor whole, pool pull-and-payout by allowance, and the privileged-call lists from the protected test run from both a stranger and the factory.
• test/HamsterToken.properties.t.sol runs 1000-run property tests with pinned edge cases: round trips, one unit either side of a balance or allowance, allowance above balance, max-minus-one allowance, self transferFrom needing a self allowance, repeated calls, and exact event counts for transfer, transferFrom, approve and the constructor.
• test/HamsterToken.launch.invariant.t.sol is a second invariant harness over the post-launch allocations. Its handler mixes successful moves with six explicit failure paths (overdraw, pull beyond allowance, zero recipient, stranger pulls, privileged selectors, ether) and checks that each leaves no trace. Invariants cover fixed supply, tracked balances summing to supply, per-account inflow and outflow ledgers, the distributor holding the swarm share less claims, no allowance without approval, and unchanged runtime code.

The files are not committed, since nothing asked for a commit and no dependencies were installed.

The review is complete and .imd-findings.json is written at the repository root. No repository files were changed.

Outcome: the token is sound. src/HamsterToken.sol is a 17-line, argument-free OpenZeppelin v5.0.2 ERC-20 that mints exactly 1e27 units to the factory and has no owner, mint, burn, tax, pause or upgrade path. The vendored ERC20.sol is byte-identical to the upstream v5.0.2 archive, whose hash I verified. All 66 tests pass with the README's seed, forge fmt --check is clean, and the compiled runtime and creation code are far under the size limits.

Findings kept (2):

• Low, merged from three specialists. DEPENDENCIES.json records upstream hashes for seven forge-std files that were reformatted in the tree, so the provenance check the README documents fails on them. I reproduced it by recomputing all 36 hashes (29 match, 7 do not), downloading the recorded v1.9.7 archive, and confirming each of the seven differs only in whitespace. Production code is unaffected, so it stays low.
• Info, mine. README line 53 still says no launch.json is included, but the later accepted manifest commit added one at the root. The manifest itself checks out against the schema rules and the constructor.

Coverage: all three state-changing entry points marked holds, with the OpenZeppelin paths traced, plus rows for the constructor and supply invariant, CREATE2 deployability, the manifest, and the aderyn literal lead (not a defect). No critical or high findings, so no proof tests were needed.