Implemented HAMSTER with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer. No administrative or additional minting powers.

Dependencies are vendored for offline builds. Deployment assumptions and operational responsibilities are documented in README.md.

Validation passed: offline build, all 34 local tests using the required fuzz seed, and forge fmt --check.

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

What the manifest says

• Kind custom_token, token contract HAMSTER with name and symbol HAMSTER, 18 decimals, empty constructorArgs. The accepted source at src/HAMSTER.sol:14 takes no constructor parameters and mints once to msg.sender.
• totalSupply is 1000000000000000000000000000, exactly the constant the constructor mints.
• contracts is an empty list, since the accepted tree contains no application contracts.
• pool and economics are copied verbatim from the launch terms: IMD pair address, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object.
• notes describe the token's behaviour and the launch terms in under 1,000 characters.

Verification

• The file parses as JSON and the supply string equals 10^27.
• forge build compiles cleanly.
• forge test with the verifier's fuzz seed passes all 34 tests in both suites.
• git status shows only the new launch.json; no config, lib, or workflow files were touched.

The review is complete. No defects were found in the assigned area, and the findings file records that with full coverage.

What was reviewed. The HAMSTER token at src/HAMSTER.sol is a 17-line fixed-supply ERC-20 that inherits OpenZeppelin v5.0.2 unchanged. I verified the vendored ERC20.sol, Context.sol and ERC-6093 error file against the SHA-256 hashes in the dependency manifest, so the base implementation is the audited upstream code. I read the Senior Auditor's Mindset, Math Precision, Boundary and Numerical Gap guides and checked every failure mode they list against the code.

Why the three guides have nothing to bite on here:

• Math Precision. The contract contains no division, no multiplication by user input, no downcast, no shift, no scale mixing and no fee formula. The only arithmetic is the supply literal on line 10, which constant-folds to exactly 10^27. A scratch test confirmed this against both 10 ** 27 and 1e9 * 10 ** decimals(). The aderyn large-literal lead is cosmetic.
• Boundary. The ABI shows a non-payable constructor and only non-payable or view functions. There is no receive, fallback, external call, or bytes decoding. The only sentinel branches are OpenZeppelin's zero-address reverts, which I walked on both sides. A non-zero-value deployment reverts.
• Numerical Gap. The sum-of-balances invariant holds under integer arithmetic because _mint runs once from the constructor, no burn path exists, and every balance add is bounded by the 10^27 supply. The launch shares of 10 and 20 percent of 10^27 are exact with no truncation.

Checks run. The delivered suite passed in full with 34 tests, including the stateful invariant. I added six scratch tests covering 1-wei flows, exact-balance and exact-allowance spends, the infinite-allowance sentinel and its neighbour, and a value-bearing constructor call. All passed, and I deleted the scratch directory afterward so the tree is clean apart from the findings file.

Output. .imd-findings.json holds an empty findings list and seven coverage rows: holds for all three listed entry points, plus four invariant and boundary rows explaining what was traced. Nothing was left unreached.

The review is complete and the findings file is written. The working tree is clean apart from the untracked findings file, and the scratch test directory was removed.

Outcome: no access-control, trust-gap or asymmetry defect in the token. The only entry is an info-level provenance note.

What I checked in the assigned area:

• Access control. The contract is an unmodified OpenZeppelin v5.0.2 ERC20 with no owner, minter, pauser, blacklist, upgrade or initializer role. The compiled ABI exposes only the standard ERC-20 surface plus the public supply constant. All three state-changing entry points act solely on the caller's own balance or allowance.
• Trust gap. The constructor takes no arguments and mints the full supply once to the deployer, which is the factory under the launch flow. The factory cannot spend a holder's tokens without an allowance. Transfers deliver exact amounts, so the swarm share, pool seed and claims arrive whole. ETH sent to the token reverts, and the runtime has no delegatecall or selfdestruct. I confirmed the vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag by fetching and comparing them.
• Asymmetry. No sender or recipient is treated differently from any other. The existing suite of 34 tests plus a scratch test of the factory-to-distributor-to-claimant flow and of the privileged selectors from the protected floor all pass.

The one recorded item is that DEPENDENCIES.json lists sha256 digests for seven forge-std files that no longer match the tree. The drift is forge-fmt whitespace only, and forge-std is never deployed, so it carries info severity with a reproduction command. The aderyn large-literal lead is the supply constant, which evaluates to the correct value and is not a defect.

Coverage rows are filed for all three listed entry points as holds, plus rows for the constructor role handout, the supply and privilege invariant, and the library-integrity check.

The review is complete with no defects found. The findings file at the repository root holds an empty findings list and ten coverage rows, and the working tree is otherwise untouched.

What the token is. HAMSTER is a bare OpenZeppelin ERC20 with no owner, no hooks, no fees and no constructor arguments. Its constructor mints the full supply once to the deployer, which under the launch factory is the factory itself.

What I checked, by guide:

• Execution Trace. Traced approve, transfer and transferFrom end to end through the vendored _update and _spendAllowance. Zero-address sentinels revert, balance and allowance checks precede the unchecked subtractions, there are no external calls or callbacks, and any revert rolls back balances and allowances together. Infinite allowance is left untouched. The ERC-20 approve race exists but is the standard's own property and the README documents it, so it is not a defect of this token.
• Periphery. The vendored OpenZeppelin ERC20 and Context files hash to the values in the dependency manifest and are byte-identical to the upstream v5.0.2 tag. Context returns plain msg.sender, so there is no forwarder path.
• First Principles. The supply constant equals 10^27 minor units exactly. Mint and burn are internal with no public caller besides the constructor. No privileged function can move or freeze a balance, and launch flows to the distributor, the pool manager and traders move exactly the stated amount because there is no tax or exemption logic.

Verification run. The project's 34 tests, including fuzz and invariant suites, pass with the pinned seed. The compiled ABI exposes only the three listed mutating functions, and my independent scan of the runtime bytecode found no DELEGATECALL, CALLCODE, SELFDESTRUCT or transient-storage opcodes. The aderyn large-numeric-literal lead is style only, since the literal is a correct compile-time constant.

Coverage. All three entry points are marked as holding, plus rows for the constructor, the fixed-supply, no-privileged-movement and exact-flow invariants, the vendored periphery, the bytecode scan and the static-analysis lead. Nothing in the assigned area was left unreached.

The review is complete. No tracked file changed, and the findings file is valid JSON.

Result: no defects found. .imd-findings.json holds an empty findings list and seven coverage rows, all holds.

What the token is. src/HAMSTER.sol is a 17-line OpenZeppelin v5 ERC20 with no overrides. The constructor mints 10^27 units once to msg.sender, which under the factory's CREATE2 deployment is the factory. The compiled ABI exposes only the standard ERC-20 functions plus the INITIAL_SUPPLY constant getter. There is no owner, mint, burn, pause, blacklist, receive or fallback path.

What I checked against the three guides.

• Economic Security. No external dependency, oracle, callback or fee formula exists. Transfers move exactly the stated amount, so the launch flows the floor requires arrive whole: I modelled the 10% distributor share, a claim, a pool-manager-style pull of the 20% seed with a measured balance delta, the 70% remainder, and a 1-wei buy and sell. All exact.
• Invariant. Sum of balances equals totalSupply after every sequence, confirmed by a 512-run fuzz and the delivered 128-sequence stateful invariant. totalSupply cannot change after construction: _mint is reached only by the constructor, _burn has no caller, and transfers to the zero address revert. Finite allowances are reduced exactly and the max allowance is never reduced.
• Flow Gap. There is no seam to cross. The token makes no external calls, holds no cached state, and the launch economics are computed by the deployer, not the token.

Library integrity. The vendored ERC20.sol, Context.sol and interfaces read line for line as the canonical OpenZeppelin v5.0.x sources and match the hashes in DEPENDENCIES.json. The sandbox blocked my fetch of upstream for an independent hash comparison, so that conclusion rests on manual reading.

Static-analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note on line 10 is cosmetic; the literal evaluates to exactly 10^27.

Not reported as defects. The standard ERC-20 approve race and the ability to send tokens to the token contract itself are inherent to the specified design and are already documented in the README as holder responsibilities.

Added 15 failure-path and property tests, and expanded invariants to 32,768 randomized calls.

Offline forge build passed. forge test passed with the required seed: 49 passed, 0 failed.

Only test/ changed. No contract defects found.

I found nothing wrong with the HAMSTER token. The review has one finding, rated info, about a file listing the project's dependencies. It doesn't affect the token's security.

The token: src/HAMSTER.sol is a plain OpenZeppelin v5.0.2 ERC20 token with no arguments. Its constructor mints 1e27 base units (1 billion tokens) once to the deployer. The copy of OpenZeppelin's ERC20.sol in lib/ is identical, byte for byte, to the official v5.0.2 file. There is no owner, no way to create more supply, no transfer fee or burn, and no code path that lets anyone move or freeze another holder's tokens. So the launch's transfers (to the distributor, into the pool, and swaps) move exactly the amounts they say.

Tests: forge test passed all 49 project tests, including an invariant test of 32,768 random calls with no reverts. I couldn't run the network's protected tests here, because they import Uniswap v4 and launch contracts that aren't in this tree.

Deployability: the contract is far under the size limits (1,752 bytes deployed, 2,621 bytes to create), and the empty constructorArgs matches the no-argument constructor. In launch.json, the supply, 18 decimals, name and symbol are consistent. The paired currency address is the IMD token on chain 1, as the notes say.

What the specialists reported:

• Permissions reported the only finding: DEPENDENCIES.json lists file hashes that don't match seven of the vendored forge-std files. I reproduced it. The listed hashes are the official v1.9.7 hashes; the copies in lib/ were reformatted, and the only difference is whitespace. Forge-std is test-only and never deployed, so I kept it as info. The fix is either to re-vendor the official files unchanged or to record the hashes of the reformatted copies. No other area reported this, so there was nothing to merge.
• Flow, economics, math and the test writer reported nothing.
• Static analysis: slither reported nothing. Aderyn flagged the supply number at line 10 as a large numeric literal, which is a style note and not a defect, so I dropped it.

Coverage: I marked all three entry points (approve, transfer, transferFrom) as holds. I also added two rows of my own: the supply is fixed and minted once, and the contract can deploy as launch.json describes it.

I changed no tracked files. The only file written is .imd-findings.json, which is valid JSON, and I deleted the out/ and cache/ build folders that running the tests created.