The Hamster Hive (HAMSTER) token is built, tested and committed on main. All checks pass: forge build, forge test with the verifier's fuzz seed, and forge fmt --check.

What was delivered

• src/HamsterHive.sol is a fixed-supply ERC-20 on OpenZeppelin v5.1.0. The zero-argument constructor mints the whole supply once to the deployer. No owner, mint, burn, pause, blocklist, fee or upgrade path exists. decimals() returns 18.
• foundry.toml at the repository root pins solc 0.8.26, sets bytecode_hash = "none" and cbor_metadata = false, and declares remappings. ffi and filesystem access are off.
• forge-std v1.9.7 and OpenZeppelin Contracts v5.1.0 are vendored under lib/ as ordinary files. There are no git submodules.
• script/DeployHamsterHive.s.sol exposes a deploy() function that the tests call directly; run() only wraps it in a broadcast.
• README.md documents behaviour, assumptions, the pinned build parameters, the manifest values the manifest step will record, post-launch configuration (none), operational responsibilities and the security checklist items.

Test results

Check	Result
Unit and fuzz tests	27 passed, 0 failed
Fuzz seed	verifier's seed used
forge fmt --check	clean

Tests cover success paths (metadata, mint to EOA, to a contract deployer and via the script, transfers, approvals, infinite allowance), failure paths (balance and allowance overflows, zero addresses, 22 common admin selectors from deployer and stranger, ETH sent to the token) and properties (supply conservation under fuzzing, runtime free of DELEGATECALL, CALLCODE and SELFDESTRUCT). I also confirmed in scratch tests that the constructor-event assertion fails on wrong values and that a CREATE2 deployment from a probe contract leaves the whole supply with the deployer, matching the protected floor test.

Not run: Slither and Mythril are not available on this machine. Explorer verification after launch belongs to the network's deployer.

I found no defects in HamsterHive, so .imd-findings.json has an empty findings list and five coverage rows. I read the code only: I didn't compile it or run any tests, including the protected floor tests.

src/HamsterHive.sol is a plain OpenZeppelin ERC-20 with nothing changed except decimals(). It mints a fixed 1,000,000,000 × 10¹⁸ to msg.sender once, in the constructor. It has no owner or other privileged role, no mint or burn after deployment, and no fee, burn or hook on transfer.

Against the three economics guides (Economic Security, Invariant and Flow Gap):

• Launch flows: every transfer moves exactly the amount given. The factory's transfer to the distributor, the pool seed through the PoolManager, distributor claims and trader swaps all arrive in full.
• Supply: the total supply cannot grow or shrink after deployment, because no function other than the constructor calls _mint, and nothing burns.
• Privileged calls: there are none, so nobody can freeze or move a holder's balance.

Coverage rows:

• HamsterHive.approve(address,uint256) — holds.
• HamsterHive.transfer(address,uint256) — holds.
• HamsterHive.transferFrom(address,address,uint256) — holds.
• Fixed total supply minted to the deployer — holds.
• decimals() returns 18 — holds.

The aderyn "large numeric literal" warning at line 18 is the supply constant (1_000_000_000 * 10 ** 18), so I left it out.

I wrote nothing except .imd-findings.json.

Created launch.json matching HamsterHive’s constructor, exact supply, and required pool/economics values.

forge build succeeded. All 27 tests passed with the supplied fuzz seed. Manifest and compiled constructor ABI checks passed.

Only launch.json is changed for submission.

The review is complete. The findings file holds an empty list and eight coverage rows, and the working tree is otherwise untouched.

Result: no defects in the Math Precision, Boundary or Numerical Gap areas. Hamster Hive is OpenZeppelin v5.1.0 ERC20 with one compile-time constant and no arithmetic, external calls, payable paths or hooks of its own, so each failure mode in the three guides was checked and ruled out against concrete inputs rather than assumed away.

What I verified:

• Supply constant. The expression on line 18 evaluates exactly to 10^27, matching the manifest supply. It fits below 2^96 and int128.max, so Uniswap v4 deltas and liquidity cannot truncate it. The aderyn large-literal lead is not a defect.
• Transfer math. The insufficient-balance check precedes OpenZeppelin's unchecked subtraction, and the unchecked addition cannot overflow because balances sum to the fixed supply and no mint path exists after the constructor. Exact balance, balance plus one, zero, max uint256 and full self-transfer all behave as intended.
• Allowance math. The allowance check precedes the unchecked decrement. Allowance equal to the amount reaches zero, max minus one decrements, and only exact max is treated as infinite. The balance check still binds when allowance exceeds balance.
• Launch splits. The ten percent swarm share, its two and eight percent parts, the eighty percent pool share and the ten percent remainder all divide 10^27 with zero remainder and recompose to the full supply.
• Sum invariant. A 256-run four-party fuzz of chained transfers and the project's own fuzz suite conserve the supply exactly.
• Boundaries. No external calls, no payable functions, no receive or fallback, no bytes decoding. The only sentinel checks are the inherited zero-address reverts.
• Dependency integrity. All five OpenZeppelin files the token compiles against are byte-identical to the published v5.1.0 npm package.

The scratch test under test/scratch/ was run, passed, and removed. The existing 27 project tests also pass. Nothing in my area was left unreached.

The review is complete and the findings file is written and validated. No tracked file was changed. The only writes are the ignored .imd-findings.json and my scratch trace under test/scratch/.

Result: no defects found in the token. The Execution Trace, Periphery and First Principles passes all come back clean, and one informational note is recorded.

What I covered:

• Execution trace. The constructor mints exactly 1e27 to the deployer through one checked _update call, with no arguments and no external calls. The three entry points resolve to the unmodified OpenZeppelin paths. Each guard, state write and revert path was traced, and the project's 27 tests plus my scratch traces all pass.
• Periphery. The vendored OpenZeppelin tree was diffed against the published npm 5.1.0 tarball and is byte-identical in content. The base contract the token trusts is therefore exactly what the README claims.
• First principles. No owner, hooks, fee, pause, fallback or receive exist. The compiled ABI exposes only the three state-changing ERC-20 functions, so the launch flows move exact amounts and the protected floor's privileged-selector probes all revert without state change.
• Static analysis lead. The aderyn large-literal note was checked and the literal evaluates correctly to the stated supply.

What I recorded:

• One info finding. The inherent ERC-20 approve overwrite race, executed as a scratch test showing a spender pulling 150 on a 100-then-50 approval. It is standard behaviour and a trust assumption for integrators, not a blocking defect.
• Coverage. All three listed entry points are marked holds, with additional rows for the constructor, supply and decimals invariants, library provenance, launch flows and bytecode properties.

Not reached: the launch's chain id and pair-token address in the README could not be checked, since no network file was supplied in the reads. That is documentation, not token code, so it does not affect the verdict.

The review is complete. The file .imd-findings.json holds an empty findings list and seven coverage rows, and the scratch test is removed so the tree is unchanged apart from the report.

Result: no defects found in the Access Control, Trust Gap or Asymmetry areas. Hamster Hive is a 31-line wrapper over OpenZeppelin v5.1.0 ERC20 with a no-argument constructor that mints the whole supply once to the deployer. It has no owner, roles, hooks, fee branches, pause, blocklist, upgrade path, or receive/fallback.

What I verified, and how:

• Permission model. The compiled ABI exposes exactly the eleven standard ERC-20 and metadata selectors plus two constant getters. A fuzzed sweep of every other selector reverts from both the factory and a stranger, with supply and balances untouched. The deployer or factory cannot pull a holder's balance without an allowance.
• Trust gap on the dependency. I read the vendored ERC20, Context and interface sources line by line against upstream v5.1.0. No added writers, exemptions or hooks, and no shadowing copy of ERC20.sol anywhere the remapping could resolve to.
• Asymmetry. transfer and transferFrom share one _update path. A fuzz test confirmed mirrored balance writes and allowance arithmetic, including the infinite-allowance case. Storage has only the five OZ slots, each written and read as expected.
• Launch shape. A CREATE2 deployment from a factory contract lands the full supply on the factory, and transfers move exact amounts, so the protected floor's distributor, claim and seed flows receive what they send.
• Static leads. Slither reported nothing. Aderyn's large-numeric-literal note on line 18 is style only and the constant evaluates to the manifest supply, so it is not a finding.

The existing 27-test suite passes with the verifier's fuzz seed. Items I deliberately left out as not defects: the inherent ERC-20 approve front-running race, and the deploy script's broadcaster receiving the supply, which the README documents and the launch does not use.

Added failure-path tests, boundary fuzz tests, and five-actor invariants for balances, supply, allowances, and transfer liveness.

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

No defects found. Only files under test/ were added.

The review is complete and the findings file is written. The working tree is clean apart from the ignored findings file and the pinned reads.

Outcome: The token is a clean, argument-free wrapper over OpenZeppelin v5.1.0 ERC20, and no blocking defect exists. The findings file holds one info-level finding and a six-row coverage record.

What I verified against the code:

• Vendored library is genuine. ERC20.sol, Context.sol, IERC20.sol, IERC20Metadata.sol and draft-IERC6093.sol are byte-identical to the npm 5.1.0 package, confirmed by diff.
• Deployment model holds. A CREATE2 deploy from a factory probe minted the whole supply to the factory, decimals read 18, and the creation and runtime sizes sit far under the limits. The runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE or CALL opcodes.
• Launch flows move exact amounts. The factory-to-distributor and distributor-to-claimant transfers arrive whole and leave the supply unchanged. There is no fee, hook or admin surface, and common admin selectors revert from the factory.
• All three entry points traced. approve, transfer and transferFrom are the unmodified OpenZeppelin paths with the expected zero-address, balance and allowance reverts, and infinite allowance is preserved.
• Manifest is consistent. launch.json uses only schema keys, lowercase addresses, an empty constructorArgs for the zero-parameter constructor, and the exact minted supply.
• Project tests pass. The existing 52 unit, fuzz and invariant tests all pass, and the static-analysis lead about a large numeric literal is a style note with no behavioural effect.

Specialist findings settled: The single specialist finding, the inherited ERC-20 approve race reported by the flow audit, reproduced exactly as described in a scratch test: a spender who front-runs an allowance reduction from 100e18 to 50e18 ends with 150e18. I kept it at info severity, citing the unconditional allowance write at lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol:287, as a documented standard trust assumption that requires no change and does not block the launch. The other four areas reported nothing, and my own pass with the Pashov and Trail of Bits checklists found nothing they missed.