Done. The HAMSTER token project is built, tested, formatted, documented, and committed on main.

What was delivered

• src/HamsterToken.sol: contract HamsterToken, name and symbol HAMSTER, 18 decimals. The constructor takes no arguments and mints the whole supply once to msg.sender, which is the launch factory. There is no owner, no mint, no pause, no block-list, no tax, and no external call anywhere. EIP-2612 permit is included from OpenZeppelin unchanged.
• test/HamsterToken.t.sol: 34 tests covering metadata, exact supply, transfer and allowance success and failure paths, permit success plus expired, wrong-signer, replay and wrong-chain failures, the same admin-selector sweeps the protected floor test runs, the DELEGATECALL/CALLCODE/SELFDESTRUCT bytecode scan, raw creation-code deployment, and four fuzz tests. Tests read no environment variables.
• script/DeployHamsterToken.s.sol: a reference script whose deploy() the tests call directly. The launch itself is the factory's, so the script is for review only.
• foundry.toml pins solc 0.8.26, cancun, optimizer at 200 runs, bytecode_hash = "none", ffi off, no filesystem permissions.
• Dependencies vendored as plain files with no submodule entries: forge-std v1.11.0 and the 19-file ERC20 + ERC20Permit import closure from OpenZeppelin v5.4.0.
• README.md documents parameters, launch economics, manifest facts, assumptions, after-launch steps (none), operational responsibilities, and the security checklist items that apply.

Verification

Check	Result
forge build (clean, from scratch)	pass
forge test with the verifier's fuzz seed	34 passed, 0 failed
forge test with the default seed	34 passed, 0 failed
forge fmt --check	pass

Notes for the reviewer

• The token needs no factory, pool manager or launch-number exemptions because transfers are plain, so the manifest's constructor arguments are empty and total supply is 1000000000000000000000000000 minor units.
• Slither and Mythril are not on this machine and did not run.
• The root directory contains device-node dotfiles (.bashrc, .gitmodules and similar) that git cannot stage. They are outside my paths and I left them untouched. The commit was made with the explicit author identity passed on the command line rather than by editing git config.

I found no defects I could substantiate. .imd-findings.json contains an empty findings list and a coverage record, and no other file was changed.

What I reviewed: src/HamsterToken.sol is a plain token built on OpenZeppelin 5.4.0's standard token (ERC20) and its signature-approval extension (ERC20Permit). It overrides nothing. Its constructor mints exactly 1,000,000,000 × 10^18 to msg.sender and makes no outside calls. It has no mint function, owner, role, pause, block-list, tax or burn. The existing suite passes 34 of 34 tests. I did not run the protected launch tests, which need the verifier's environment variables. Instead, I checked their requirements against the code.

Execution Trace:

• transfer and transferFrom use the unmodified OpenZeppelin path. Each moves exactly the amount asked for, and reverts on a short balance or a zero address.
• transferFrom reduces the allowance first, except when it is unlimited.
• So the launch transfers (factory to distributor to claimants, the pool seed, and swaps both ways) all arrive in full.
• approve is the standard version. permit checks the deadline, uses a signature domain bound to the chain ID and contract address, consumes a nonce, and rejects malleable or zero-signer signatures.

Periphery:

• The deploy script is for reference only and isn't on the launch path.
• foundry.toml sets bytecode_hash = "none", as the launch requires.
• The token takes no constructor arguments and calls no other contract, so the launch addresses aren't needed.
• Nothing in it uses DELEGATECALL, CALLCODE, SELFDESTRUCT or a proxy.

First Principles:

• Supply can't grow after deployment.
• No privileged party can move or freeze a holder's balance.
• decimals() returns 18, which matches the spec.

Static analysis: Aderyn's "large numeric literal" warning at line 35 is the supply constant. Its value is correct, so I left it out. Slither reported nothing at low impact or above.

Coverage: all four entry points (approve, permit, transfer, transferFrom) are marked holds. Two invariant rows are also holds: the fixed supply, and the absence of dangerous opcodes plus decimals of 18. No row is unreached.

The manifest is written and verified. Only launch.json was added; nothing else in the tree changed.

What launch.json describes

• Kind is custom_token, with the token contract named HamsterToken, name and symbol HAMSTER, 18 decimals.
• Constructor arguments are an empty list, matching the accepted contract's argument-free constructor, which mints the whole supply once to the deployer.
• Total supply is the constructor's TOTAL_SUPPLY in minor units, 1,000,000,000 tokens times ten to the eighteenth.
• Contracts list is empty. The accepted tree holds only the token; the deploy script is a local reference and is not launched.
• Pool and economics are copied exactly as the brief gives them: IMD as the paired currency, fee 12500, tick spacing 60, the provenance-only initial price, and the requester's economics object verbatim.
• Notes run to about 1,600 characters and describe only the token that exists in the tree.

Checks run

• A script confirmed the manifest's keys, supply string, economics and pool match the brief exactly, and that the contract name and notes are within length limits.
• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 34 tests.
• Git status shows launch.json as the only change.

The review is complete. The findings file is written, the JSON parses, the quoted snippet matches lines 32 to 35 of the source exactly, and the working tree is clean apart from .imd-findings.json (which is gitignored).

Outcome: no math, boundary or numerical-gap defect in HamsterToken. One info-level observation was recorded, and no finding opens a revision.

What was checked

• Library provenance. All 19 vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tag, downloaded and diffed outside the repository. The token adds no arithmetic of its own beyond the supply constant.
• Math Precision guide. The supply literal evaluates in uint256 to exactly 1e27 with no uint8 overflow of the power term. There is no division, downcast, scale mixing or fee rounding anywhere in the token. The unchecked subtractions in the ERC20 library sit behind explicit balance and allowance checks, and the unchecked additions are bounded by the 1e27 supply. This also closes the aderyn large-literal lead.
• Boundary guide. The token makes no external calls, has no payable, receive or fallback function and decodes no bytes. Edge inputs were executed in a scratch Foundry test: balance plus one reverts with the exact error, max uint reverts, zero transfers succeed, allowance of max minus one decrements while exactly max is infinite, a permit deadline equal to the block timestamp is accepted and one second later is rejected, high-s and invalid-v signatures are refused before the nonce is consumed, and owner or spender of zero reverts.
• Numerical Gap guide. Balances sum to total supply after odd-sized multi-hop transfers. The launch shares of 10, 15 and 75 percent of 1e27 divide with no remainder, so no dust appears at the seed, swarm or remainder flows.

Finding recorded (info). The DECIMALS constant feeds TOTAL_SUPPLY, but decimals() is inherited unchanged and returns its own hard-coded 18. Both are 18 today and nothing fails, so this is a maintenance seam rather than a defect. It is reported as info with an explicit statement that no shipped input misbehaves.

Coverage. All four listed entry points have a row marked holds, with four additional invariant rows. Existing suite: 34 tests pass. Scratch boundary suite: 15 tests passed before I removed it, since no critical or high finding needs a proof file.

The review is complete and .imd-findings.json is written. The working tree is clean apart from the findings file and my scratch test, which the gitignore already excludes.

Result: no access-control, trust-gap or asymmetry defect found. The token is OpenZeppelin ERC20 plus ERC20Permit with a constructor that mints the fixed supply to the deployer, and nothing else.

What I verified for the three guides:

• Access control. The permission model is empty. The compiled ABI exposes exactly the four state-changing entry points and no mint, burn, owner, initializer, pause, blacklist or upgrade path. The deployer has no power over holders beyond its own balance, confirmed by the existing tests and a scratch test.
• Trust gap. With no privileged actor and no economic formula inside the token, none of the seams the guide describes can be instantiated. The only trust assumption is the launch's own: the factory receives the whole supply.
• Asymmetry. The approve, permit and transferFrom trio reach the same internal functions with mirrored checks. Scratch tests confirm permit rejects malleated signatures, replay on a second deployment, and a zero spender, and that allowance decrements exactly.
• Dependency integrity. All 19 vendored OpenZeppelin files are byte-identical to upstream v5.4.0 and all forge-std sources match tag v1.11.0, so the library code the token inherits is what it claims to be.

One informational note was recorded. The public DECIMALS constant feeds TOTAL_SUPPLY but the inherited decimals() getter never reads it, so the two agree today only because both say 18. Changing the constant would re-scale the supply while the getter kept answering 18. This is not a defect in the current state, and I said so in the finding.

Coverage: all four listed entry points are marked holds, with four extra rows for the supply invariant, privileged roles, dependency integrity and the informational note. Nothing in my area was left unreached.

The review is complete. The findings file validates, its one cited snippet matches the tree exactly, and no tracked file was changed.

Result: no defects in the assigned area. The HAMSTER token is OpenZeppelin ERC20 plus ERC20Permit with nothing added, and every economic, invariant and flow-gap failure mode in the three guides was checked against it without finding a failing input.

What I verified:

• Vendored library integrity. All 19 OpenZeppelin files under lib/ are byte-identical to a fresh clone of upstream tag v5.4.0. The token's whole runtime behaviour is therefore upstream's.
• Supply conservation. A scratch invariant suite drove transfer, approve, transferFrom and permit with random actors and amounts for 128,000 calls. Total supply stayed at exactly 1e27 and the sum of balances always equalled it, with zero reverts.
• No growth or privileged paths. The ABI exposes only the four state-changing functions listed plus views. The disassembled runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT. Its single external opcode is the ecrecover STATICCALL inside permit.
• Launch flows. There is no tax, burn, hook or exemption list, so the factory to distributor, distributor to claimant, factory to pool, and trader swap flows move the nominal amount. The constructor takes no arguments and calls no contract, so the factory's CREATE2 holds the full supply. The protected harness itself depends on v4-core and environment variables not in this tree, so I reasoned about it rather than ran it.
• Permit edge cases. Expired deadline, wrong signer, replay, other chain id, zero owner and high-s malleable signatures all revert, with the nonce unchanged.
• Static-analysis lead. The large-literal note at line 35 is benign. A literal base with a non-literal exponent is computed in uint256, and the project's tests assert the supply equals 1e27.

One info-level entry is recorded, with a passing demonstration test under test/scratch/: ERC-2612 permits can be front-run by any relayer. The allowance still lands on the signed spender and nothing goes to the griefer, but an integrator that bundles permit with transferFrom in one call will revert. That is inherent to the standard and the README already documents relayability, so it needs no change to the token. It is there so the launch's router or claim UI authors wrap permit defensively.

The coverage record answers all four entry points, four invariants and the one analyzer lead. The deliverable is .imd-findings.json at the repository root, with the scratch tests left under test/scratch/ as evidence.

Added failure-path, rollback, permit-security, and four stateful invariant tests. All changes are under test/.

forge build and forge test pass with the required seed: 68 tests passed, including 24,576 invariant handler calls.

No defects found in the tested scope. Coverage limits are documented in test/README.md; external launch integration checks were not run.

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

Outcome: no defects. HamsterToken is a plain fixed-supply OpenZeppelin ERC20 with ERC20Permit, and every check I ran holds.

What I verified

• Every vendored OpenZeppelin file is byte-identical to upstream v5.4.0, so the inherited transfer, approve and permit logic is exactly the audited library.
• The existing suite of 68 tests passes. A scratch probe confirmed decimals, supply, the mint to the deployer, and the permit nonce, replay and relay behaviour.
• The runtime bytecode contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, and creation and runtime sizes are far under the limits.
• The manifest uses only schema keys, has empty constructor arguments matching the no-argument constructor, and copies the economics verbatim.

Specialist findings

• The two reports about the DECIMALS constant not being wired to decimals() share one root cause, so I merged them into one info note. I reproduced the latent seam with a copy of the contract whose constant is set to 9: supply rescales, but decimals() still returns 18. The shipped code is consistent, so no change is required.
• The permit front-running report reproduces, but it is standard ERC-2612 behaviour that the README already documents. I kept it as an info note for integrators only.

Coverage: all four entry points answered, three holds and one tied to the info note on permit, plus two invariant rows for fixed supply and manifest shape.