I built the Hamster (HAMSTER) token and committed it as fb94392. forge build, forge test (14 of 14 pass, run with the verifier's fuzz seed) and forge fmt --check all pass. I didn't run the protected launch checks (Token.protected.t.sol, Owners.protected.t.sol) here, because they need the launch harness and the values it supplies.

Token (src/HamsterToken.sol)

• The contract is called HamsterToken. Its name() is Hamster, its symbol() is HAMSTER, and it has 18 decimals.
• It is a plain ERC-20 built on OpenZeppelin v5.1.0. The constructor mints all 1,000,000,000 tokens once to whoever deploys it, which will be the launch factory.
• It has no owner, no way to mint more, no fees, no pause and no blocklist. No one can move or freeze another holder's tokens.
• It returns the Twitter handle @hamsterhourgame through TWITTER().

The 10% / 80% / 10% split happens during the launch, not inside the token. The factory sends 10% to the swarm's distributor and puts 10% into the pool. The other 80% goes to the dev vault at 0xee2aaa315cf7ed169f93148d30d24af9318dbb66. A test checks that each share arrives exactly.

Tests (test/HamsterToken.t.sol) cover:

• name, symbol, decimals and the one-time mint;
• the exact launch split;
• transfers and approvals that should work, and ones that should fail (too little balance or allowance, zero addresses);
• that mint, owner, pause, blocklist and seize calls don't exist;
• randomised tests that the total supply never changes.

Setup

• foundry.toml pins solc 0.8.26 with bytecode_hash = "none" and the optimizer on.
• forge-std and OpenZeppelin are copied into lib/ as plain files, not git submodules, so the build works offline.
• README.md records the assumptions, launch settings and responsibilities. There is nothing to configure after launch.
• I didn't write a launch.json; the manifest step does that.

Two things to know:

1. Stray .gitmodules file: OpenZeppelin's own .gitmodules file couldn't be removed from lib/openzeppelin-contracts/ because the sandbox blocks deleting it. Git ignores a .gitmodules outside the repository root, and I also added it to .gitignore, so it isn't part of the commit.
2. Commit author: no git identity was set on this machine, so I made the commit with your email (civic.cvc7@gmail.com) as the author, passed only for that one commit. I didn't change the git config.

The dev vault's 80% isn't locked or vested by the token. If you want it locked, that's up to you.

Done. The manifest is written and verified; launch.json is the only changed file.

What the accepted tree contains. One contract, HamsterToken in src/HamsterToken.sol. It is a plain OpenZeppelin ERC-20 with a parameterless constructor that mints the whole supply to msg.sender. There are no application contracts, no owner and no privileged entry points.

What launch.json says.

• kind is custom_token, token contract HamsterToken, name Hamster, symbol HAMSTER, 18 decimals.
• constructorArgs is empty, matching the no-argument constructor.
• totalSupply is 1,000,000,000 tokens in minor units, equal to the TOTAL_SUPPLY constant the constructor mints.
• contracts is an empty list, since the tree deploys nothing besides the token.
• pool and economics are copied exactly from the launch reference: IMD pair address, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object verbatim.
• notes describe the token, the 10/10/80 payout the factory performs, and the @hamsterhourgame Twitter handle. The swarm's share is mentioned only as the factory's action, never as a manifest allocation.

Checks run. JSON parses, totalSupply equals 10^27, and economics matches the required object. The build compiles cleanly and all 14 tests pass with the verifier's fuzz seed. Git status shows launch.json as the only new file; nothing else was touched.

I found no defects in the HAMSTER token's economics. .imd-findings.json has an empty findings list and a coverage record that answers all three entry points, plus three invariants. I changed no project files, and the existing test suite passes (14 of 14).

What I checked

• The token code: src/HamsterToken.sol is a plain ERC-20 built on OpenZeppelin v5.1.0. The constructor mints the whole supply (1,000,000,000 tokens with 18 decimals) once, to whoever deploys it. After that there is no way to mint or burn, no owner, no pause, no blocklist, no fee and no transfer hook.
• The OpenZeppelin library copy: I read the bundled ERC-20 and helper code against the standard v5.1.0 behaviour and found no changes. Every transfer moves exactly the amount requested, and none of it can destroy the contract or run another contract's code in its place.
• The launch payouts: because transfers are exact, each payout arrives in full: the swarm's 10%, the 10% pool seed (poolBps = 1000), the 80% to the dev vault address, and later trades through the pool. Those come to exactly 100M, 100M and 800M tokens, with no rounding.

Coverage

• approve, transfer and transferFrom: holds.
• Invariants, all holding: the supply is fixed and all goes to the deployer; the 10/10/80 split works; nobody has special power over holders' balances.
• Static-analysis leads: the one tool warning was about the size of the supply constant. It is just the 1e27 total and is harmless.

Not reported as defects, because the brief doesn't ask for them

• The dev vault's 80% isn't locked or released over time. The README already says this, so it's a trust point for buyers rather than a code defect.
• approve has the usual ERC-20 weakness when changing an existing allowance, the same as any standard token.

Not checked: there is no launch.json yet, so I couldn't review the manifest.

The review is complete and .imd-findings.json holds an empty findings list with a full coverage record. The git tree is clean apart from the gitignored findings file.

Result: no defects found in the Access Control, Trust Gap and Asymmetry areas for src/HamsterToken.sol.

What I checked:

• Permission model. The compiled ABI exposes only approve, transfer, transferFrom and views. There is no owner, modifier, initializer, receive, fallback, callback or external call, so no escalation chain, confused deputy or proxy path exists.
• Inherited code. The vendored OpenZeppelin ERC20 and Context are untampered v5.1.0. The sender is plain msg.sender, and _mint is reachable only from the constructor.
• Asymmetry. transfer and transferFrom share one _transfer path. The allowance set by approve is decremented by transferFrom in mirror. The only asymmetry is the standard EIP-20 approve race, which is inherent to the requested interface and not a defect.
• Launch flows. No fee, exemption list or hook exists, so the swarm share, pool seed and swaps all move exact amounts.
• Bytecode. An opcode scan of the runtime found no DELEGATECALL, CALLCODE or SELFDESTRUCT. Supply is the manifest's 1e27 minor units with 18 decimals.
• Tests. The project's 14 tests pass under forge 1.8.3 with solc 0.8.26.

Coverage rows mark all three entry points as holds, plus invariant rows for fixed supply, no privileged role, clean bytecode and the allowance pair. One row is marked unreached: the protected launch test could not run here because it imports v4-core and LaunchLiquidity, which are not in this tree. Its checks were traced by hand instead.

One trust assumption to pass to the requester: the dev vault address receives 80% of supply with no lock or vesting, exactly as the brief asked.

The findings file is in place and is intentionally excluded from git by the harness. The scratch test is removed and the tree is otherwise untouched. Review complete.

Result: no defects found. The findings file at the repository root holds an empty findings list and seven coverage rows, all holds.

What was reviewed. The token is a 20-line wrapper around the vendored OpenZeppelin v5.1.0 ERC20 with no constructor arguments, no owner, and no transfer hooks. I checked it against the Execution Trace, Periphery and First Principles guides, the Senior Auditor's Mindset, and the floor tests in the protected suite.

• Entry points. The compiled ABI exposes exactly the three state-changing functions listed by the verifier plus views. Every check, state change and failure path of approve, transfer and transferFrom was traced through the inherited code.
• Execution Trace. Zero-address sender and receiver paths, over-balance transfers, self transfers, zero-value transfers, infinite and finite allowance residuals, allowance granted before balance arrives, and the full launch flow with a pool-manager-style pull were all exercised in a scratch Foundry test. All 13 probes passed alongside the project's 14 tests.
• Periphery. The five inherited files were hashed against the upstream v5.1.0 release and match byte for byte. The sender context is plain msg.sender with no forwarder. The runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE2, and the contract has no receive or fallback.
• First Principles. The only writer of total supply is the constructor's mint. The supply is exactly one billion tokens at 18 decimals and stays conserved under fuzzed multi-party sequences.

Notes for the judge, not findings. The 80% "dev vault" share is the requester's remainderTo address with no lock or vesting contract, which the README states as an assumption. Standard ERC-20 approve front-running semantics apply, as with any OpenZeppelin token. Neither is a code defect with a failing input. Slither and Aderyn reported nothing above a stylistic numeric-literal note, which I confirmed is harmless.

The review is complete. The math audit of the Hamster token found no defects, and .imd-findings.json holds an empty findings list with a ten-row coverage record.

What I checked, against the Math Precision, Boundary and Numerical Gap guides

• Supply constant. The literal on line 14 of src/HamsterToken.sol is a compile-time exact 1e27, matching the manifest's minor units. The aderyn "large numeric literal" lead is stylistic only. No truncation, overflow or decimals mismatch exists.
• Inherited arithmetic. The three state-changing entry points are unmodified OpenZeppelin v5.1.0. I diffed the five vendored files the token compiles against and they are byte-identical to the upstream tag. Scratch probes covered zero amounts, self-transfer of the whole balance, full balance then one wei more, supply plus one, max uint, infinite versus finite allowance, and atomic revert when allowance suffices but balance does not. All behaved exactly, with correct revert data and no wrap.
• Launch split. Ten percent of 1e27 is exactly 1e26 with zero remainder, the dev vault gets exactly 8e26, and the intermediate product is far below the uint256 limit.
• Boundary surface. The token has no external calls, no payable function, no receive or fallback, no sentinel-address logic beyond OZ's zero-address reverts, and no bytes decoding. A fuzz over three holders kept the balance sum equal to the supply.
• Opening price. The 2,500 IMD cap over 1e27 tokens, both currency orderings, lands inside Uniswap v4's sqrt-price bounds with more than tenfold margin and fits uint160. This is deployer math, recorded as a boundary check rather than a token defect.
• Runtime bytecode. A push-aware opcode scan found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE or CREATE2, and decimals() returns 18.

Coverage. All three listed entry points are marked holds, plus rows for the constructor, the supply invariant, the split invariant, the price boundary, the boundary surface, dependency integrity and the opcode scan. Nothing in my area was unreached.

The scratch tests were removed and the working tree contains only .imd-findings.json as new content. One note for the judge outside my area: the 80% dev-vault allocation is an unlocked concentrated holding by design, documented in the README as a trust assumption rather than a defect.

Done. The suite builds and passes with the verifier's fuzz seed: 44 tests across three files, 0 failures. Only two new files under test/ were added. No config, lib or source files were touched, and there are no submodules.

What I added

• test/HamsterToken.invariant.t.sol: a handler-driven invariant suite over random call sequences. Seven actors (factory, distributor, pool manager, dev vault, three holders) start from the launched 10/10/80 state. The handler drives bounded transfer, approve and transferFrom calls plus failure paths checked for the exact OpenZeppelin error: over-balance transfers, over-allowance and over-balance transferFrom, zero-address receiver and spender, sixteen privileged selectors from every actor, and ETH sent to the token. It runs with fail-on-revert on, so the handler never reverts and any check inside it is a hard failure. Invariants: fixed total supply, sum of actor balances equals supply with nothing at the token, handler or zero address, balances and allowances match independent ghost bookkeeping, runtime code hash and metadata never change, round trips through the factory are lossless, and every expected failure was counted as failed.
• test/HamsterToken.edge.t.sol: edge cases the existing suite skipped. Zero-amount, one-wei, exact-balance and self-transfers. Infinite allowance never decremented while max minus one is. Approve overwrites rather than accumulates. Allowance does not conjure balance and survives a failed transferFrom. Owner spending via transferFrom still needs an allowance. A launch helper that deploys and pays out 10/10/80 in one transaction, plus a fuzzed split over any pool share that leaves no dust. Non-payable constructor, no fallback, ETH and unknown selectors rejected. The protected floor's full admin list from a stranger and from the deployer, after which the holder can still transfer. The same opcode scan the floor runs for DELEGATECALL, CALLCODE and SELFDESTRUCT.

Grounding The invariant harness was run in test/scratch/ against a mutant token that burns one wei per transfer. Both the supply and ghost-balance invariants failed on the first sequence, so the properties are not vacuous.

Findings None. The token is a plain OpenZeppelin v5 ERC-20 with no owner or admin path, and nothing I tried departed from standard ERC-20 behaviour. Tokens sent to the token's own address are stranded, which is ordinary ERC-20 behaviour and is pinned as a documented test rather than reported. No .imd-findings.json was written.

Review complete. The Hamster token audit stands: no defects, and I wrote .imd-findings.json with an empty findings list and a seven-row coverage record. Only that file was added to the tree.

What I checked

• Specialist findings. All five inputs (tests plus math, flow, permissions, economics) reported nothing, so there was nothing to reproduce or merge.
• The token itself. src/HamsterToken.sol is a 22-line wrapper over OpenZeppelin ERC20 with an argument-less constructor that mints the full supply to msg.sender. The ABI exposes only the three ERC-20 state changers plus view functions. No owner, mint, burn, pause, blocklist, fallback or receive exists.
• Dependency integrity. The five vendored OpenZeppelin files the token compiles against are byte-identical to upstream v5.1.0. A tampered library was the one realistic way a wrapper this thin could hide a defect.
• Bytecode. Creation code and runtime are well under the protocol limits. An opcode scan of the runtime found no CALL, DELEGATECALL, CALLCODE, CREATE, SELFDESTRUCT or STATICCALL.
• Manifest. launch.json uses only schema keys with correct types, lowercase addresses, an empty constructorArgs matching the constructor, and a totalSupply equal to the minted constant.
• Tests. Build, forge fmt --check, and all 44 project tests pass, including the invariant suite with fail-on-revert.

Coverage verdicts. All three entry points (approve, transfer, transferFrom) hold, with the OpenZeppelin failure paths traced. Four extra rows record the constructor, the no-privilege invariant, dependency integrity, and the manifest.

Leads dropped. The aderyn low on the large numeric literal is a style note, not a defect. The README's chain and pair-token statements are documentation outside the manifest and not verifiable from the tree, so they are not reported.