Implemented HAMSTER with 1 billion tokens, 18 decimals, minted once to the deployer, plus funded rewards for eligible losing bets.

Validation passed: forge build, 56 tests with the supplied fuzz seed, and forge fmt --check.

Deployment assumptions and operating steps are in README.md. Rewards require game configuration, funding, and site integration after launch.

I found no access-control defect in the contracts, and wrote one low-severity documentation finding to .imd-findings.json. The file also has a coverage row for all 10 entry points (each marked holds) plus one row for the supply invariant. No other files were changed, and the existing 56 tests pass.

Finding (low): README.md:13 tells whoever writes the manifest to pass $owner as the HamsterRewards owner. The manifest has no $owner value: application contracts can only use plain values, $token, $requester or $contract:EarlierName. A manifest written from that line would be refused, or someone would guess a value for the only privileged role in the system. The fix is a one-word change to $requester (the requester's address, 0xee2a…bb66), which also passes the supplied owner checks.

Access Control, Trust Gap and Asymmetry

• The token (HamsterToken) is an unchanged OpenZeppelin ERC-20. It has no owner, no extra minting, no tax, and nothing that can freeze or move a holder's balance. The full supply is minted once, to the deployer, in the constructor.
• The reward contract (HamsterRewards):
  • What the owner can do: set the game address once, choosing a window that hasn't started yet. Once set, the owner cannot withdraw, change the rate or pause. Ownership hand-over needs the new owner to accept, and the owner cannot give up ownership before the game is set.
  • The trust gap: the owner could point it at a fake game that invents losses and pays out every donation. This is the project's own stated trust assumption, already written up in docs/SECURITY.md. Donors can see which game was set before giving, because fund() is blocked until then, so I did not count it as a defect. One gap remains: HAMSTER sent directly to the contract before the game is set relies entirely on that owner.
• Claims: claimFor lets anyone trigger a claim, but the tokens always go to the bettor, and each wallet can claim once per window. Funding is first-come-first-served by design.
• Static-analysis leads: I rejected the high-severity "reentrancy" warning at HamsterRewards.sol:61. The calls there only read from the game, so nothing can call back in. The timestamp warnings are start/end deadline checks, not a source of randomness.

What I couldn't verify: the deployed Hamster Hour game's source isn't published (Sourcify has no match). I checked the site's front-end code and it agrees with the reward contract on which side loses in the Over/Under and Sleeping/Running markets. Two edge cases depend on the game itself, and I left them out because I can't prove them:

• whether a result exactly equal to the line is refunded or counted as a win for Under;
• whether a market where nobody bet on the winning side is voided.

If the game does neither, some real losers would get no HAMSTER.

Done. launch.json is written at the repository root and is the only changed file.

What it describes

• Token: HamsterToken, name and symbol HAMSTER, 18 decimals, no constructor arguments. The constructor mints the full supply once to msg.sender, so totalSupply is 1000000000000000000000000000 minor units.
• Application contract: HamsterRewards with constructor arguments $token and $requester. The second argument is the Ownable2Step owner, so it resolves to the economics remainder recipient rather than the factory, which satisfies the protected owners check.
• Pool and economics: copied verbatim from the launch terms. The pair is IMD, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object exactly as given.
• Notes: 1670 characters explaining the token's plain ERC-20 behaviour, the reward contract's single one-time owner power, that it receives no supply at launch, and that no initialization calls are needed.

Verification

• forge build compiles cleanly.
• forge test with the verifier's fuzz seed passed all 56 tests across 6 suites, including the invariant suite.
• A scratch script confirmed the manifest uses only schema keys, matches the required economics and pool objects, and that each constructorArgs list length matches the compiled ABI for both contracts.

The README's deployment table calls the owner argument $owner. That is not a manifest placeholder, so the manifest uses $requester as the schema requires. No other file was touched.

The review is complete and .imd-findings.json holds the result. No source file was changed and the scratch tests were removed.

Outcome: no defect of medium or higher severity in the math, boundary or numerical-gap area. The file records one info-level item and a 14-row coverage record answering all ten listed entry points plus four invariants.

What I verified

• Reward arithmetic. Reward equals loss times a constant of one. IMD on mainnet reports 18 decimals, as does HAMSTER, so the base-unit rate is exact. There is no division, downcast or scale mixing. A one-wei loss pays one wei and absurd stakes revert through checked addition rather than wrapping.
• Game semantics. I fetched the game's source at the commit recorded in the site's deployment file and compared it line by line with eligibleLoss. Status codes, market and side indices, the sleeping rule, the one-sided and equal-to-line refunds, the three-rank distance logic, and position persistence all match. The exact market is never voided by the game, and a rank count of zero with an exact entry cannot occur, so the fail-closed reverts are unreachable for the honest game.
• Boundaries. First-window configuration requires a future start and an id above the current window. Window times for out-of-range ids revert in the game before any overflow. Settlement in the game requires the window to have ended, so the contract's end-time check never blocks an honest settled window.
• Token. The supply constant evaluates to the manifest's string exactly, minted once in the constructor, with unmodified OpenZeppelin transfer and allowance code, so every launch flow moves the stated amount.

The one recorded item is informational. A wallet that stakes equally on both sides of a binary market always earns the full losing side in HAMSTER while losing only the fee share in IMD. The README already documents this as a design property, so I quantified it for the author's funding decision rather than proposing a change. At the launch price the farm is far from profitable.

Static-analysis leads (timestamp comparisons, state change after an owner-only external view call, the require inside the bounded rank loop) were each traced and none reproduced as a defect.

Review complete. The findings file is written at .imd-findings.json, no tracked file was changed, and test/scratch/ holds only my throwaway differential test.

Result: no reproducible defect in the assigned area. One documentation note was recorded at info level.

What I covered (Execution Trace, Periphery, First Principles)

• Every assumption eligibleLoss makes about the external game was checked against the real game source. I fetched HamsterHour.sol at the commit the site's deployment record names and confirmed the status encoding, the UNDER/OVER and RUNNING/SLEEPING index order, how marketVoided is set at settlement, that rankCount is at least one whenever an exact pool exists, that every used ties[i] is at least one, and that positions survive the game's own claim.
• Differential fuzz against the real game logic. I compiled a copy of the game with only the oracle verifier stubbed, placed real bets, settled, and claimed. Across 3000 runs, eligibleLoss equalled the losing stake exactly when the game paid nothing on a non-voided market, and zero for winners, refunds and voided windows. Claiming in the game did not change eligibility.
• Execution flow. Claims set the replay flag and counter before the transfer under a reentrancy guard. Failed or underfunded claims consume nothing. Game reads compile to static calls, so the aderyn reentrancy lead on configureGame cannot execute. The two slither timestamp leads are deadline checks only.
• Periphery. All vendored OpenZeppelin v5.1.0 and forge-std v1.9.6 files match upstream apart from formatter line wrapping. The read interface matches the published ABI, whose hash I recomputed. On-chain reads confirmed IMD has 18 decimals and the deployed game's constants match the source.

The one note is that README line 13 tells the manifest writer to pass $owner for the rewards owner, while the custom_token reference for this task only lists $token, $requester and $contract:Name. The code is correct either way.

Not a defect, but worth the requester's attention: the reward rate is one HAMSTER base unit per IMD base unit lost. At the 888 IMD opening cap for one billion tokens, a lost minimum bet earns HAMSTER worth well under a millionth of an IMD. That is the stated design and is documented, so I did not report it.

The findings file is valid, every snippet matches its line, and the working tree holds nothing but .imd-findings.json. Nothing else is needed.

Review complete. The reward contract is economically sound in its area. I found no path that pays HAMSTER for a refunded or winning stake, no double payment, and no break in the funded-equals-paid-plus-balance conservation law. Three low-impact items are reported.

What I checked

• Traced all ten entry points and three invariants from the Economic Security, Invariant and Flow Gap guides. The existing 56 tests and the stateful invariant suite pass.
• Verified the contract's assumptions against the live Hamster Hour game on mainnet and the site's own JavaScript payout math. The status encoding, OVER/UNDER and SLEEP winner rules, the exact-rank distance logic, and the refund flags all match what the reward contract encodes.
• The game has created 89 windows and settled none, and its source is not verified anywhere public. One lead stays unverified for that reason: whether the game can still settle a window after timeout refunds were already paid.

Findings written to .imd-findings.json

1. Low. Stranded donations. The contract's only outflow requires a window to reach settled status. If the game migrates, dies, or voids every window, all funded HAMSTER is locked forever. The README documents this as intentional, so it is reported as the concrete failure state of that decision.
2. Low. README names $owner. The deployment table tells the manifest writer to use a placeholder the launch schema does not define. Following it yields a refused manifest or, with a substituted literal, an owner that can never configure the game.
3. Info. Reward rate economics. One HAMSTER per IMD lost is immutable. At the opening cap it pays about 0.00009 percent of the stake, and by the same arithmetic hedge farming cannot drain the reserve at launch prices. Recorded so the author sets the constant deliberately.

Coverage has 15 rows, all answered, none unreached.

The full suite passes with the verifier's seed: 92 deliverable tests plus 2 scratch checks, 0 failures, total runtime about 110 seconds.

What I added (all under test/, building on the existing suite rather than rewriting it):

• test/HamsterToken.invariant.t.sol: an ERC-20 invariant suite for the token. A handler with six holders runs transfer, approve and transferFrom in random order, deliberately over-asking a quarter of the time and asserting the exact ERC-6093 error at the call. Invariants check fixed supply, sum of balances against a ghost ledger, allowances against a ghost ledger including unlimited allowances, and unchanged metadata.
• test/HamsterRewards.lifecycle.invariant.t.sol: a lifecycle invariant suite for the rewards contract. Unlike the existing invariant test, which runs against frozen settled records, this handler settles windows with varied results and refund flags, voids open windows, advances time so the end-of-window guard matters, funds from two donors by both paths, shuffles two-step ownership, and attempts reconfiguration. Every claim's outcome is predicted from an independent model of the README's eligibility table before the call. Invariants check inventory equals donations minus payouts, nobody is paid more than they wagered or twice, nothing is paid on voided or unfinished windows, quotes match the model, owners never receive tokens, and configuration is permanent.
• test/HamsterRewards.edge.t.sol: 34 unit and property tests for paths the first suite skipped. Rewards side: pending-window quotes revert, ineligible-but-voided windows, voided windows before their end, unknown status values, binary-only wallets when the exact market had no ranks, voided exact market skipping rank validation, each refund flag in isolation, ties beyond the rank count, a zero-tie last rank, zero-line boundaries, overflowing stakes failing closed, a one-wei loss, a maximal single stake, relayer self-claims, contracts that half-implement the game interface, scheduling boundaries, strict current-window comparison, ownership after configuration, pending transfer cancelled by renounce, and funding from wallets without balance or allowance. Token side: exact-allowance spend, approve overwrite, no Approval event on transferFrom, full-balance moves, self transferFrom, and ether rejection. Two fuzz properties bound the loss by the wager and by the non-refunded markets, and check that a claim pays exactly the quote or changes nothing.

Verification. I confirmed with a scratch driver that the lifecycle handler reaches successful claims, rejected claims, settlements, voids and ownership moves, so the invariants are not vacuous. Fuzz run counts are set with inline forge-config, and no configuration file was touched.

Defects. I found none that needed reporting, so no findings file was written. The one open risk is outside this repository: the contract reverts with InvalidGameState for any wallet holding an exact ticket if the real game ever records a rank with zero ties, which the README already lists as an owner verification duty before configuration.

The review is complete and .imd-findings.json holds the result. The scratch test is removed and the working tree is otherwise untouched.

Outcome: no code defect in HamsterToken or HamsterRewards. Three findings survive, all low or informational.

• Low, README.md line 13. The deployment table tells the manifest writer to pass $owner, which is not a manifest placeholder. The committed launch.json already uses $requester, so this is a documentation inconsistency, not a blocked launch. Three specialists reported it; merged into one.
• Low, HamsterRewards fund(). Donations have no recovery path if the configured game never produces a Settled window. The live game on mainnet has created 89 windows and settled none, and window 85 is still Open hours past its end. The README documents the lock as intentional, so this is a design risk for the requester to confirm.
• Info, eligibleLoss line 101. A wallet hedging both sides of one binary market always earns its full losing-side stake, while its real IMD loss is only the 9% fee share. The 1:1 rate is immutable. At the opening cap this is unprofitable by about five orders of magnitude. Two specialists' notes merged.

What I verified beyond the specialists. I pulled the actual HamsterHour source at the commit the site's deployment record names and compared it line by line with eligibleLoss. Status codes, side indices, market-void indices, the result-equals-line refund, one-sided refunds, exact-rank matching and position persistence after claim all agree. The site bundle agrees too. All 92 project tests pass, formatting and the ABI check pass, and the manifest's keys, types, lowercase addresses, name lengths and constructor arity are correct. The static-analysis leads (timestamp checks, reentrancy in configureGame, loop revert, uninitialized local) are false positives: the game reads are staticcalls and the local is initialized.

Coverage: all 10 entry points answered. Nine hold; fund() points at the stranded-donation finding. Three extra rows record the game-semantics comparison, the manifest shape, and CREATE2 deployability. The protected owner and token floor harness could not be run here because its helper files are not in the tree; its conditions were checked by reading.