The HAMSTER token is built, tested, documented and committed on main as commit 9594349.

What was delivered

• src/HamsterToken.sol: contract HamsterToken, a self-contained fixed-supply ERC-20. Name and symbol are HAMSTER, 18 decimals, and the constructor mints the full 1,000,000,000 tokens to msg.sender once. It takes no constructor arguments, calls no other contract, and has no owner, mint, burn, pause, blocklist, fee or exemption list. Transfers and approvals to the zero address revert, and an unlimited allowance is not decremented.
• src/interfaces/IERC20.sol: the interface it implements, so no external library is vendored into the attested bytecode.
• script/DeployHamsterToken.s.sol: a local deploy script whose deploy() function reads no environment and is called directly by a test.
• Tests in test/: 37 tests across three suites. They cover metadata, the single mint, every transfer and approval success and failure path, custom error payloads, deployment through a CREATE2 factory probe, bare creation code with no arguments, the same admin and freeze selector sweeps the protected floor runs, an opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, EIP-170 size, fuzz tests, and handler-based invariants that the supply never changes and balances always sum to it.
• README.md: assumptions, deployment parameters including the launch economics as given, the supply flow at launch, operational responsibilities, security notes and how to run the checks.
• foundry.toml pins solc 0.8.26 with bytecode_hash = "none", optimizer on, no ffi and no filesystem permissions. The runtime bytecode tail confirms only the solc version marker is appended.
• lib/forge-std is forge-std v1.11.0 copied in as plain files with no git metadata, so the offline verifier can build it.

Verification results

Slither and Mythril were not available on this machine and did not run. No launch.json was written, and nothing was deployed or signed. There are no owner settings to configure after launch, so the README's "After launch" section states that explicitly.

The math audit of src/HamsterToken.sol found no math defects that need fixing. It found one boundary issue at info severity. The results are in .imd-findings.json, which parses as valid JSON with 1 finding and 4 coverage rows. No tracked files were changed: I deleted my scratch tests after running them.

Finding 1 (info), src/HamsterToken.sol:130: transferFrom accepts address(0) as the sender when the amount is 0.

• What happens: anyone calling transferFrom(address(0), to, 0) gets true back, and the token emits Approval(0x0, caller, 0) and Transfer(0x0, to, 0).
• Why it matters: the interface treats a Transfer from address(0) as a mint, so this looks like a mint even though the token says it never mints after deployment. No balance or supply changes; some explorers and indexers may list it as a mint.
• Reproduction: a scratch Foundry test confirmed it.
• Fix: add a check that reverts when from == address(0) in _transfer, as OpenZeppelin's ERC-20 does.

Coverage by entry point:

What I checked against the three guides:

• Precision: there is nothing to round; the contract has no division or scaling.
• Supply constant: the aderyn lead at line 40 is a false alarm. The constant evaluates to exactly 1e27.
• Unchecked addition: it cannot overflow, because all balances together always add up to 1e27.
• Transfer edge cases:
  • Sending to yourself keeps your balance (fuzzed for 256 runs).
  • Sending the full supply succeeds.
  • Sending one unit more than the supply, or the uint256 maximum, reverts.
  • Sending to address(0) reverts.
• Allowance edge cases:
  • An unlimited (maximum) allowance is never reduced, and maximum minus one is reduced correctly.
  • Spending more than the allowance reverts.
  • Spending exactly the allowance leaves zero, with no off-by-one.
• Boundary guide: the contract makes no external calls and has no payable functions or decoded byte inputs, so most of its steps don't apply.

The project's own test suite passed (41 tests). Nothing in my area was left unchecked.

The manifest is written and verified.

What I wrote: launch.json at the repository root, the only file changed.

• Token: contract HamsterToken, name HAMSTER, symbol HAMSTER, 18 decimals. The accepted constructor takes no parameters, so constructorArgs is an empty list. totalSupply is the 1,000,000,000 × 10^18 the constructor mints to msg.sender, written as a decimal string in minor units.
• Contracts: none. The accepted tree contains only the token and its IERC20 interface, so no application contracts are named.
• Pool and economics: copied verbatim from the launch reference, with the IMD pair address, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.
• Notes: a 1,306-character description of the token's behavior and the launch terms, well under the 4,000 limit.

Checks run:

• A script confirmed the manifest has exactly the schema's top-level keys, the correct kind, the exact supply and economics, a valid contract name, and lowercase addresses.
• forge build succeeded with solc 0.8.26.
• forge test with the verifier's fuzz seed passed all 37 tests across 3 suites.
• git status shows launch.json as the only new file, with nothing else modified.

I added two test files. The full suite now has 57 tests, and all of them pass with forge test under the verifier's fuzz seed. I found no defects, so there is no .imd-findings.json.

The HAMSTER token has a fixed supply of 1,000,000,000 × 10¹⁸, all of it minted to the deployer. It has no owner, no mint, no pause and no transfer tax. Transfers or approvals to the zero address revert, and an allowance set to the maximum value counts as unlimited and is never reduced. The earlier contributor's tests (HamsterToken.t.sol, HamsterToken.invariant.t.sol, DeployHamsterToken.t.sol) are unchanged and still pass.

test/HamsterToken.model.t.sol is a stronger invariant suite set to 256 runs × 64 calls in the file itself. It makes random sequences of transfer, approve and transferFrom calls between six actors: the deployer, four others, and the token contract itself. About one target in eight is the zero address, and the amounts lean towards the edges: 0, exactly the balance or allowance, one more than that, and the maximum. It keeps its own record of what every balance and allowance should be, and checks that each call succeeds or reverts exactly when the token standard says it should. After every sequence it checks that:

• every outcome matched the expected result;
• every balance and allowance matches the record;
• the total supply never changes, and the actors' balances add up to it;
• the zero address never holds tokens or receives an allowance;
• the address recorded as the first holder never changes.

I also ran a throwaway check that the handler really hits both succeeding and reverting calls, so the invariants aren't passing on empty runs.

test/HamsterToken.edges.t.sol pins cases the existing tests didn't cover:

• Largest amounts: transfers of the maximum value or one wei over the supply revert, and moving the whole supply through an allowance works.
• Allowance edges: an allowance one below the maximum is reduced normally, an unlimited one emits no Approval event when spent, and zero-amount transferFrom behaves correctly with no allowance or to the zero address.
• Ownership edges: self-allowances, transfers back to the owner, allowances that can't be spent against a different owner, and calls made from the zero address.
• Launch: deploying the token and paying out the 10% swarm share, the pool seed and the rest in a single transaction delivers exact amounts and leaves the factory empty. The distributor can pay every claim in full, and the original holder has no special power afterwards.
• Fuzz tests (1000 runs each): a failed transferFrom changes nothing, an unlimited allowance never goes down, and transfers between holders keep the supply whole.

The review is complete. The findings file is written with an empty findings list and seven coverage rows, and my scratch tests are removed so the tree is unchanged apart from the findings file.

Outcome: no defects found in the economics area. HamsterToken is a self-contained fixed-supply ERC-20 with no owner, no external call, no fee, and no privileged function, so most failure modes in the Economic Security, Invariant and Flow Gap guides have no surface to attach to. What I checked against each guide:

• Economic Security. No oracle, token or cross-contract dependency exists. The token never returns false, takes no fee, does not rebase or blacklist, and rejects ether and unknown calldata. Sentinel inputs behave sanely: zero recipient and zero spender revert, zero-value transfers succeed and emit per EIP-20.
• Invariant. The conservation law "sum of balances equals the constant supply" holds across every writer. Self-transfers re-read storage so they conserve, the unchecked addition is bounded by the constant supply, and a failed transfer reverts the allowance spend atomically. The project's handler invariants and my scratch fuzz confirmed this.
• Flow Gap. I modelled the launch flows end to end with a factory deploying through CREATE2, a distributor claim, and a PoolManager-style sync, transfer, settle and take sequence. Every leg moved exactly the stated amount and a buy and sell round trip left no shortfall.

Verification run. The project builds, its 37 tests pass with the verifier's fuzz seed, the formatter check passes on tracked files, and my five scratch probes passed. The static analysis lead about the large numeric literal is a compile-time constant that evaluates to the manifest's supply, so it is not a defect.

Trust notes, not defects. Tokens sent to the token contract itself or to any wrong address are unrecoverable, and the classic approve race is inherent to EIP-20. Both are documented in the README. The protected token test could not be executed locally because it imports Uniswap v4 core, which is not vendored here.

Review complete. The findings file is written and the tree is otherwise unchanged.

Outcome: The HAMSTER token has no permission defects that move or freeze funds. One low-severity asymmetry was found and reproduced.

What was checked (Access Control, Asymmetry and Trust Gap guides, plus the Senior Auditor's Mindset):

• Permission map. The contract has no owner, minter, pauser, blocklist, initializer or proxy. The ABI holds only the ERC-20 functions and constants. I scanned the compiled runtime and found no CALL, DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE opcodes, and there is no receive or fallback.
• Constructor. It mints exactly one billion tokens with 18 decimals to msg.sender and makes no external call. The factory holding the whole supply at launch is a trust assumption by design, not a defect.
• Allowance path. The deployer cannot pull from a holder without an approval. Max allowance is not decremented, finite ones are, and the project's own 37 tests pass with the pinned fuzz seed.
• Launch flows. Transfers carry no tax, burn or exemption list, so every flow delivers exactly what it says.

Finding 1 (low), src/HamsterToken.sol:131. The transfer path rejects a zero recipient but has no mirror check for a zero sender, and a zero amount needs no allowance. Any caller can therefore run the following and get events the token should never emit after deployment:

transferFrom(address(0), attacker, 0)   // emits Approval(0x0, attacker, 0) and Transfer(0x0, attacker, 0), a fake mint row
transferFrom(victim, attacker, 0)       // emits Approval(victim, attacker, 0) and Transfer(victim, attacker, 0) with no approval

No balance or supply changes, so the impact is confined to indexers and explorers. The suggested fix is a sender zero-address check at the top of the internal transfer, matching OpenZeppelin v5.

Coverage. All three listed entry points have rows: approve and transfer hold, transferFrom carries finding 1. Four extra invariant rows record the constructor, the access surface, the trust-gap seam and the launch flows. The protected floor tests could not be executed here because v4-core and the launch environment variables are not supplied, but each property they assert was traced in source.

Review complete. The findings file at .imd-findings.json holds one low-severity finding and seven coverage rows, and the tree has no changes outside that file and test/scratch/.

What I checked. The token is a self-contained ERC-20 with three state-changing entry points and no external calls, payable paths, callbacks, owner or initializer. I traced each entry point against the Execution Trace, Periphery and First Principles guides, re-ran the existing 37 tests with the verifier's fuzz seed, and added scratch tests for self-transfer via transferFrom, unlimited self-allowance, the raw-call return shape the Uniswap v4 PoolManager checks, and balance conservation. The aderyn "large numeric literal" lead is a compile-time constant that the tests confirm equals 1e27, so it is not a defect.

Finding 1, low. _transfer rejects a zero recipient but never rejects a zero sender. Because the zero address has a balance and allowance of exactly 0, any caller can run the following and have it succeed:

token.transferFrom(address(0), victim, 0)

It returns true and emits Approval(address(0), caller, 0) and Transfer(address(0), victim, 0), a mint-shaped event from a token that documents one mint only. No balance or supply changes, so the harm is confined to explorers, indexers and alerting that treat zero-sender transfers as mints. The proof test fails on the current code and passes against a copy with a one-line from != address(0) check, which keeps all intended behaviour.

Coverage. approve and transfer hold. transferFrom carries finding 1; its allowance-spend and transfer paths otherwise hold. Supply constancy, exact launch flows, the constructor's single mint to the factory, and the absence of any periphery surface all hold. Nothing in my area was left unreached.

I've written the review to .imd-findings.json. It holds one low-severity finding and a coverage row for all 3 entry points; no tracked files were changed.

The finding: the three specialist reports on the zero-address sender all describe the same cause, so I merged them into one (src/HamsterToken.sol:131). _transfer checks that the recipient isn't the zero address but never checks the sender. As a result, anyone can call transferFrom(address(0), victim, 0) and it succeeds instead of reverting. It emits Approval(0x0, caller, 0) and Transfer(0x0, victim, 0), which looks like a new mint to explorers and indexers, even though the token says it mints only once, at deployment.

• Reproduction: I ran the specialist's proof (test_transferFromZeroSenderMustRevert) and it fails on the current code for the stated reason.
• Severity: low. No balance, allowance or supply changes, so the only harm is misleading event logs.
• Related, same function: transferFrom(holder, caller, 0) with no allowance emits an Approval the holder never made. That's also harmless, and I noted it under the same finding.
• Fix: add a check that rejects a zero-address sender at the top of _transfer.

Coverage:

• approve holds.
• transfer holds: the exact amount moves, and the unchecked arithmetic can't overflow because the supply is fixed.
• transferFrom is marked as the finding.
• I also checked one invariant and it holds: the supply is a constant 1e27, minted to the factory by a constructor with no arguments, which matches launch.json.

Dismissed leads: the aderyn "large numeric literal" warning on line 40 is just the supply constant, not a defect. Slither reported nothing. The token has no fees or exemptions, so the launch transfers, the pool seed and swaps all move exact amounts.

Tests: all 57 of the project's tests pass. I couldn't run the protected launch tests because they need files (src/LaunchLiquidity.sol, src/HookFlags.sol and others) and v4-core, none of which are in this tree. I read them instead. I deleted my scratch test files afterwards.