Implemented Hamster Hour (HAMSTER): 1 billion tokens, 18 decimals, minted once to the deployer. No minting or administrative powers afterward.

Included vendored dependencies, tests, and deployment documentation.

Verified:

• forge build
• forge test: 29 passed using the required fuzz seed
• forge fmt --check

Full factory/pool integration remains for the launch verifier’s separate harness.

Done. launch.json is written and is the only changed file.

What the manifest says

• Token HamsterHour from src/HamsterHour.sol, name "Hamster Hour", symbol "HAMSTER", 18 decimals.
• Empty constructorArgs, matching the accepted parameterless constructor.
• totalSupply is the constructor's INITIAL_SUPPLY in minor units, one billion times ten to the eighteenth.
• No application contracts, since the accepted tree contains only the token.
• Pool and economics copied exactly as the launch gives them: IMD pair, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object verbatim.
• Notes under 1,000 characters describing the token's fixed supply and absence of privileged powers.

Checks run

• A JSON check confirmed only the schema's six top-level keys, the verbatim economics, and the supply value.
• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 29 tests.
• git status shows only the new launch.json.

The findings file is valid, the snippet matches line 3 of DEPENDENCIES.md exactly, and the working tree is clean apart from the required output file.

Result: the token holds on every check in the Economic Security, Invariant and Flow Gap guides. One low-severity defect was found, outside the economics area. .imd-findings.json holds that finding plus eight coverage rows.

What I verified

• The token is the unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint of 1e27 units to msg.sender. I confirmed the vendored ERC20.sol is byte-identical to upstream.
• All three entry points trace clean through OpenZeppelin's code. There is no fee, burn, exemption list, callback, admin role, receive, fallback, delegatecall or selfdestruct, so every launch flow moves exactly what it says and no seed or swap can revert on the token's side.
• Supply conservation holds: the only writer is OpenZeppelin's internal update function, mint is reachable only from the constructor, and burn is never called. The project's test suite passes with the README's seed, including the stateful invariant run.
• The launch economics are consistent with the token's supply and decimals. The opening price and single-sided liquidity derived from the stated cap sit well inside Uniswap v4's bounds in either currency order.

The one finding (low)

DEPENDENCIES.md says the vendored files are unmodified and that the recorded checksums verify them. Running the documented check fails on seven forge-std files. The recorded hashes are the real upstream hashes. The vendored copies were reformatted after the fact, and the difference is whitespace only, so no behavior changes. This affects only test tooling and the release integrity claim.

Not covered

The protected launch tests need Uniswap v4 sources and deployer environment variables that are not in this tree, so I did not execute them. I reasoned about those flows from the token's code instead.

The review is complete and .imd-findings.json is written with one finding and nine coverage rows. No tracked file was changed.

Outcome. The Access Control, Trust Gap and Asymmetry passes found no defect in the token itself. HamsterHour is the unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint of 1e27 units to its immediate deployer. There are no roles, initializers, exempt lists, hooks, fees, burns, receive or fallback paths, and no forbidden opcodes in the runtime bytecode.

What was verified.

• All three entry points (approve, transfer, transferFrom) hold. Each writes only the caller's own balance or allowance row, the deployer cannot pull a holder's funds without an allowance, finite allowances decrease by exactly the moved amount, infinite allowances stay untouched, and both transfer paths reject the zero recipient identically. I confirmed this with a scratch suite under test/scratch/ that passes on the current code, alongside the 29 shipped tests and the stateful invariant run.
• The compiled ABI exposes exactly the three state-changing functions the verifier listed. Unknown selectors and ETH transfers revert, matching the protected floor's admin-call probes.
• The five vendored OpenZeppelin files are byte-identical to upstream at the pinned commit.
• The runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL or CREATE.

The one finding, low severity. DEPENDENCIES.md claims every vendored file is unmodified and tells the operator to run sha256sum --check DEPENDENCIES.sha256. That command fails on the committed tree for seven forge-std files, because they were re-wrapped by the formatter after the hashes were recorded. The hashes themselves match upstream, and the differences are whitespace-only, so behaviour is unaffected and only test dependencies are involved. The fix is to re-copy those files verbatim or regenerate the checksum file and correct the wording.

Not reached. Pool initialization and swap mechanics against a real PoolManager were not executed here. The token has no exempt list or transfer hook, so those flows cannot be shorted, but the protected harness remains the authority for them.

The review is complete and the findings file is written. The git tree shows no tracked changes.

Result: one low-severity finding, no defects in the token's control flow.

The token is a 16-line wrapper over the unmodified OpenZeppelin v5.0.2 ERC20. I traced all three state-changing entry points through the Execution Trace, Periphery and First Principles checklists:

• approve, transfer, transferFrom behave as standard. Zero-address sentinels revert, insufficient balance or allowance reverts atomically with no partial state, unlimited allowance stays unchanged, and no fee or burn alters the launch flows. No stale reads, no cross-transaction state, no privileged paths.
• Constructor mints exactly 10^27 units to msg.sender with no arguments, so a CREATE2 factory deployment holds the whole supply. Name, symbol and 18 decimals match the brief.
• Compiled artifact exposes only those three non-view functions and the runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE. The aderyn "large numeric literal" lead evaluates to the correct value and is not a defect.
• Vendored OpenZeppelin files are byte-identical to the pinned upstream commit.

Finding 1 (low): DEPENDENCIES.md claims upstream files are unmodified and that the checksum file verifies them, but running the documented check fails with exit code 1. Seven forge-std files were re-wrapped by the formatter after hashing. The recorded hashes match genuine upstream, so the files on disk are the ones that drifted. This is test-only code with no runtime impact, but the documented provenance check fails as shipped. The fix is to restore the upstream bytes and exclude lib/ from forge fmt, or regenerate the hashes and correct the claim.

Coverage record has 11 rows: the three entry points plus eight invariants checked, all holds except the vendoring row linked to the finding. No launch.json exists in the tree yet, so manifest review is noted as not yet applicable. Build, 29 tests and forge fmt --check all pass.

The review is complete. The deliverable is at .imd-findings.json — valid JSON, findings plus coverage, and readable at the repository root. git status is clean only because the harness's own .git/info/exclude lists that filename, which is expected, not a lost file.

Result: no defects in the assigned area. The math-precision, boundary and numerical-gap passes came back clean, and I checked each failure mode the guides name against the actual code rather than assuming the vendored library was honest.

The arithmetic is exact at every point that matters:

The two unchecked subtractions in the vendored ERC20 are both guarded by a preceding balance or allowance check, so neither can underflow, and the unchecked balance addition cannot overflow because the balance sum is capped at 1e27. The one boundary-plus-precision seam I found — the allowance decrement, where a spend equal to the allowance must land on exactly zero while an allowance of 2^256-1 is skipped entirely — sits on the correct side of its guard. I also reproduced aderyn's large-numeric-literal lead at src/HamsterHour.sol:10 and dismissed it: the literal is the intended supply and does not overflow.

One substantiated finding, outside my area but reproducible, so I reported it as low: DEPENDENCIES.md:3 claims the vendored files are byte-identical to upstream and gives sha256sum --check DEPENDENCIES.sha256 as the proof, but that command fails on 7 of 36 files, all lib/forge-std/. I fetched the pinned upstream commit and confirmed the recorded hashes are upstream-correct and the seven vendored copies were reformatted with whitespace and line-wrapping only, with no semantic change. Test-only impact, no on-chain effect; the fix is to regenerate those seven hashes.

Coverage records 6 rows and answers all three entry points as holds, with the invariants on supply conservation and on the absence of any division or narrowing cast.

I changed no repository files. forge build succeeds and the full suite passes 29 tests, including the stateful invariant at 32768 calls with 0 reverts.

Done. The full suite passes under the verifier's seed, the token has no defect to report, and one informational provenance finding is recorded.

What I found

The token is the unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint, and every OpenZeppelin file matches its recorded hash. I read it adversarially and found no behavioural defect. The one irregularity is outside the token: seven vendored forge-std files do not match the hashes in DEPENDENCIES.sha256, although README.md promises the check passes. That is test tooling only, so I recorded it as an info finding in .imd-findings.json rather than a code defect.

What I added (three new files beside the existing suite, which I left untouched)

• test/HamsterHour.edges.t.sol: 33 tests on the inputs the happy path misses. Deployment with ETH, raw creation code with no arguments, any deployer address, ETH and unknown selectors sent to the token, the launch floor's supply-growth and freeze-or-seize call lists, one wei over balance, max uint, tokens stranded in the token contract, allowance checked before balance, unlimited versus max-minus-one allowances, self-approval, and no Approval event on transferFrom. Fuzzed round trips, split spends, exact revert arguments and event arguments.
• test/HamsterHour.launch.t.sol: 13 tests shaped like the launch. One-call CREATE2 deployment at a predicted address with a supply check inside the same call, a salt collision, the swarm's tenth arriving and claimable whole, the pool share pulled by allowance and capped, a stranger buying and selling back without loss, and a runtime bytecode scan for DELEGATECALL, CALLCODE, SELFDESTRUCT, and any CALL, STATICCALL or CREATE.
• test/HamsterHour.ledger.invariant.t.sol: a ghost-ledger invariant suite with six holders plus the token itself and a precompile as sinks. The handler drives every failure path inside try/catch, asserting the exact ERC-6093 error and no state change, so fail_on_revert stays on. Invariants: fixed supply, tracked balances sum to supply, balances and allowances equal the external ledger, nobody sends more than they received, whatever reaches the token contract never leaves, and the token holds no ETH. An after-run check guarantees failure paths were actually exercised.

Results under the verifier's seed

The whole run takes about one minute, almost all of it the ledger invariants. Files are formatted with forge fmt and the build is clean. The new files are uncommitted in the working tree, matching how the earlier contribution was left for the platform's commit step.

The review found one low-severity problem. Nothing in the token contract itself was wrong. I wrote one finding and five coverage rows to .imd-findings.json.

The finding (low). All five specialist reports describe the same problem, so I merged them into one.

• DEPENDENCIES.md line 3 says the vendored files are unmodified copies of upstream and that sha256sum --check DEPENDENCIES.sha256 proves it.
• I ran that check (with the macOS shasum equivalent). Seven forge-std files under lib/forge-std/src fail it.
• I downloaded Vm.sol from the pinned upstream commit. Its hash matches line 18 of DEPENDENCIES.sha256, so the recorded hashes are right and the vendored files are what changed.
• After stripping all spaces, tabs and newlines, Vm.sol, StdAssertions.sol and console.sol are identical to upstream. The change is reformatting only.
• All OpenZeppelin files the token is built from pass the check, so the deployed bytecode is not affected. That is why it stays low.

No finding carries a proof test, since proofs are only required for critical or high findings.

Coverage. I marked all three entry points as holds:

• approve, transfer, transferFrom: src/HamsterHour.sol is a plain OpenZeppelin v5.0.2 ERC20 with nothing overridden. Transfers move exactly the stated amount, with no fees or exemptions. Allowances work as standard: finite ones go down by the amount spent and the maximum value is treated as unlimited.
• Fixed supply: the constructor mints 1e27 once to the deployer, and there is no other way to mint or burn.
• Deployment: the token takes no constructor arguments, links no libraries and is well under the size limit. launch.json agrees with the constructor on supply, decimals and arguments.

Checks run: forge build succeeded and forge test passed 76 of 76 tests. The static-analysis line about a large numeric literal is just the 1e27 supply constant, so I didn't report it.