Implemented Hamster Oracle with scoring, streaks, history, round counts, and a top-50 leaderboard. Deployment and operations are documented in README.md.

Passed:

• forge build and forge fmt --check
• 31 local tests, including fixed-seed fuzzing and invariants
• 4 live Sepolia fork tests

No deployment performed. Independent adversarial review remains required before deployment.

Done. The manifest is written and verified.

What launch.json declares

• One contract, HamsterOracle, with a single constructor argument of 100 for the immutable uint64 threshold_. That matches the accepted source and the brief's default threshold.
• No $owner entry. The contract has no owner, admin, oracle key, or upgrade path, and its constructor takes no address, so there is no privileged argument to fill.
• The SqueekCore proxy, genesis timestamp, and round duration are compile-time constants in the source, not constructor inputs.
• Notes explain the threshold meaning, the absence of privileged roles, and that no token, pool, ETH, or initialization call is involved.

Verification

• The manifest has exactly the keys kind, contracts, and notes. The notes are well under the 4000-character limit.
• forge build succeeds. forge test with the verifier's fuzz seed passes all 31 tests across 7 suites, including the deployment test that asserts a threshold of 100.
• git status shows launch.json as the only new or changed file.

I found no defects in the economics area I could back with a reproduction, so .imd-findings.json holds an empty findings list. Its coverage record answers all three entry points as holds, plus rows for the invariants I checked. No files in the repository were changed. The 31 tests outside the fork suite all pass; I did not run the fork suite.

What I checked, against the Economic Security, Invariant and Flow Gap guides and the Mindset:

• The live SqueekCore (economic security). I downloaded the verified implementation source from Blockscout (0x2847…6889), outside the repo. Its batch validation refuses any record with work == 0 and only lets the settled round advance to a round that has already ended (genesis + N*600 <= now). So the game's two key assumptions hold against the real contract:

  • a zero-work round has no record and counts as NAP inside a certified page;
  • the round numbering and closing time match the game's currentRound.

  Reading the work as the change in cumulative work, with the consistency checks in _readWork, also matches.

• Farming points or the streak bonus. None of these let anyone gain points they didn't earn:

  • Scoring order. A round can be scored only once it has ended, and any new prediction must be for a round after the current one. Scoring is therefore always in round order, whoever calls checkpoint and whatever batch size they use. The pending list always takes the earliest round first.
  • Point values. A correct pick earns 1 (or 3 for SPRINT) plus a streak bonus of the run length minus 1, capped at 5, so at most 8 per round.
  • No double scoring. Each prediction is removed from the pending list before it is scored, so it cannot be scored twice.
  • Escaping a loss. Picks cannot be changed or cancelled, so a wrong pick always breaks the streak.

• Invariants.

  • Points only go up.
  • Each prediction is scored exactly once.
  • A saved round result never changes, and the roundWork view computes the same value settle stores.
  • Every player outside the top-50 ranks below its last entry, because removal only drops the lowest entry and members only move up.

• Flow gaps. Calls to SqueekCore are read-only and cannot call back into the game to change it. A bad response reverts the whole transaction, so nothing is half-saved. Nobody can block another player's checkpoint; only bad data from SqueekCore can.

Risks I judged inherent to the design, not defects (the builder documents them in docs/SECURITY_REVIEW.md):

• One person can use several wallets to cover every outcome.
• Players can pick wallet addresses that win leaderboard ties.
• An upgrade by SqueekCore's own admin that changes its settings would stop any round not yet settled from scoring. Rounds already settled keep their results.
• If one checkpoint reaches an unsettled round while SqueekCore is down or changed, the whole call reverts. That includes rounds earlier in the same call that already have saved results; a smaller maxRounds gets around it.

Not covered: I did not run the fork tests against live Sepolia. The other eight guides (math, permissions, control flow) belong to the other three reviewers, so I only touched them where they overlapped with economics.

I found no defects I could back with a failing input, so .imd-findings.json has an empty findings list. It also has a coverage row for each of the three entry points (all holds) plus three rows for invariants I checked. The working tree is otherwise unchanged; I deleted my scratch test afterwards.

How I checked

• Live SqueekCore source. I downloaded the verified V3 implementation source from Blockscout and compared its settlement and roundPage code against _readWork and _coreState:
  • Both contracts number rounds the same way: round N ends at genesis + N*600. A round becomes scoreable at exactly the moment the core is allowed to record it.
  • Every round the core records has work of at least 1 and a nonzero data hash, and rounds with no record are 0. So the check that a 0-work page has no record never rejects valid data.
  • Asking for one round with a one-record budget can't be cut short, so end − start cumulative work is exactly that round's work.
  • The core can never report a recorded frontier at or beyond the current round, so the IncompatibleCore check never fires against real data.
• Boundary math. Work equal to the threshold counts as SPRINT, threshold − 1 as JOG, 0 as NAP. Predicting at roundStart(r) − 1 is accepted and at roundStart(r) it reverts. The streak bonus is min(run − 1, 5), so one prediction earns at most 8 points and the conversion to a small integer is safe. Every counter is far too large to overflow.
• Ordering. Each player's pending heap always scores the oldest round first. A new prediction is always for a later round than anything already scored, so the streak can't be gamed by order. The top-50 leaderboard stays correctly sorted, including when someone is evicted, because scores only go up.
• Tests. The existing suite passed (31 tests, fork tests excluded). A scratch test of my own also passed: 8 straight correct SPRINTs at exactly the threshold, then a correct JOG at 99, then a correct NAP at 0. It scored 61 points with a streak of 10, as expected.
• Static-analysis leads. The "strict equality" warning is the intended exact match on the core's settings. The "uninitialized local" warning is a false positive: the variable is always set before it's used. The loop and timestamp warnings are all bounded or intended.

Design choices, not defects

• A round with no prediction breaks a streak.
• A run's first correct pick gets no bonus.
• The stored streak can be out of date and points show only after checkpoint runs.

The README and security notes already state all three, so I didn't report them.

What I didn't cover: I didn't run the Sepolia fork tests. Outside the math area, I didn't review upgrades of SqueekCore itself.

I found nothing in the permissions area that blocks deployment. There is one low-severity finding, and it is in .imd-findings.json with a coverage row for each of the three entry points.

Finding 1 (low), src/HamsterOracle.sol:144: settle(roundId) saves the round's result but gives no one any points. Points, streaks and the leaderboard only change when someone calls checkpoint(player, …) for each wallet, up to 16 rounds per call. The brief reads as if settling a round scores it. Here, who shows up on the top-50 board depends on who has paid gas to credit them.

• Reproduction: Alice predicts SPRINT for round 2, SqueekCore records work 500 for that round, and anyone calls settle(2). Afterwards points(alice) is still 0 and leaderboard() is empty. Only an extra checkpoint(alice, 1) gives her the 3 points.
• Check: I confirmed this with a throwaway Foundry test, then deleted it.
• Severity: It is low because nobody can redirect or forge points. The builder's security doc already describes this "credit later" design. Changing it would need a decision about scope, so the finding suggests two options and doesn't push a redesign.

What I checked and found sound:

• Access control: there is no owner, admin, setup function, upgrade path, delegatecall or payable function. The constructor only sets the fixed threshold and refuses any chain but Sepolia, so the launch factory ends up with no role. predict only ever writes the caller's own entries. Anyone may call checkpoint for anyone, but it only scores that player's own predictions, oldest first. It gives the same result whoever calls it and however the batches are split.
• Asymmetry: settle and checkpoint apply the same checks before saving a result: the round must be over and recorded by SqueekCore. Where one reverts the other stops, and both write the same storage. Every stored variable's writers have matching guards.
• Trust gap: all calls to SqueekCore are read-only, so it can't make the game act on its behalf. SqueekCore's ABI has no way to roll back a recorded round, so whoever settles first cannot lock in a value that later changes. SqueekCore's own upgrade, guardian and reporter powers are outside the game, and the brief accepts them.
• Live data: against the live Sepolia proxy, rounds are numbered from 1 and the paged round lookup matches what the contract expects (rounds 1, 44, 45 and 57). The reporter had recorded round 546 within 144 seconds of it closing.
• Tests: the full suite passes (31 tests). I didn't run the fork suite.

Static-analysis leads: I looked at each and none is a defect here. The "dangerous strict equality" is a deliberate config check that fails safely. The "uninitialized" coreState is filled in before it is used. The external calls inside the loop are capped at 16 rounds. The timestamp comparisons only set round boundaries.

Not covered in depth: math precision and economics belong to the other reviewers. I left out wallets farming the leaderboard (the builder already documents that wallets aren't unique people) and the streak rule that a skipped round breaks the streak. Both are design readings of the brief rather than defects I can reproduce.

No repository files were changed.

I found no critical, high or medium defects in my area (Execution Trace, Periphery, First Principles). I reported two minor issues, one low and one info. The results and coverage rows are in .imd-findings.json, and no project files were changed: I deleted the scratch tests after running them.

Findings

1. Low: settle(roundId) gives no one points (src/HamsterOracle.sol:147). It only saves the round's result. Points, streaks and the top-50 change only when someone calls checkpoint(player) for each wallet. The brief describes settling as what awards points. To reproduce: alice picks SPRINT for round 5, the mock records work 500, then settle(5) runs. Afterwards points(alice) is 0 and the leaderboard is empty until checkpoint(alice,1) runs. The builder documented this as a deliberate choice to keep gas bounded. The requester should confirm the two-step flow is acceptable, or have predict credit the caller's finished rounds first.
2. Info: predict keeps accepting picks after SqueekCore stops matching (src/HamsterOracle.sol:255). If an upstream upgrade changes the genesis time, round length or work cap, settle and checkpoint correctly refuse to read it. But predict still accepts new picks that can never score, and nothing tells the player.

Both reproductions ran in scratch Foundry tests and behaved as described.

Coverage

• predict: finding 2. The round, duplicate and closing-time checks are correct, including the exact moment a round starts.
• settle: finding 1. Reading a round's work matches the real contract's logic.
• checkpoint: holds. Rounds are always scored in order, a failure undoes the whole call, and a third party calling it can't change anyone's result.
• Also checked and holding:
  • the queue library (RoundHeap)
  • the leaderboard's top-50 rule
  • the interface's field layout against the verified SqueekCore source on Blockscout (its implementation is still the live one on Sepolia today)
  • SqueekCore never reporting a round that hasn't ended

Tool leads I rejected

• The strict-equality warning is an intentional configuration check.
• The coreState local is only read after it has been loaded.
• The loop calls are capped at 16 rounds, and the timestamp comparisons are the intended round boundaries.

Checks run: the offline suite passed (31 tests), and the fork suite against the live Sepolia proxy passed (4 tests). I didn't attach failing-test proofs, since the task only asks for them on critical or high findings.

Added adversarial tests, 1,000-run fuzz properties, populated-leaderboard invariants, and fork tests pinned to Sepolia block 12025524.

• forge build passed.
• Full suite: 52 passed, 0 failed, including five live fork tests.
• Invariants: 40,960 calls, no unexpected reverts.
• Missing-RPC skip behavior verified.

No contract defects reproduced. All changes are under test/; production code and configuration remain unchanged.

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

Outcome. The contract holds up. Both specialists reported the same root cause, which I merged into one low finding, and I kept one informational lead. I found nothing new in my own pass.

What I verified.

• The full default suite passes (47 tests, 5 fork tests skipped without an RPC), and the live Sepolia fork suite passes against the pinned block when given the Tenderly endpoint.
• I pulled the verified SqueekCore implementation source from Blockscout. Rounds are 1-based with the same window formula the game uses, the frontier can only advance to an ended round, and a one-record page for a single round certifies exactly that round. The game's _readWork checks match those semantics, so the oracle read path is sound.
• The live proxy's configuration matches the game's constants. The manifest has only the schema keys, one string argument for the single constructor parameter, and notes under the limit.
• Streak reset on a skipped round and on a wrong pick, chronological heap processing, and stopping at an unrecorded round all behaved as documented in scratch tests.

Findings kept.

1. Low, merged. settle only caches a round's result. Points, streak and the top-50 board update only through a per-wallet checkpoint, so the views the brief requires show stale results until someone pays gas per player. Reproduced: alice predicts SPRINT for round 5, round records work 500, settle(5) returns SPRINT, yet points are 0 and the leaderboard is empty until checkpoint(alice, 1). No forging or redirection is possible, so this is a spec deviation rather than a safety defect. Suggested minimal fix is to credit the caller's matured predictions inside predict.
2. Info. predict never consults SqueekCore, so after an upstream configuration change it keeps accepting picks that can never settle and that block the wallet's queue.

Coverage. All three entry points are answered. settle points to finding 1. predict and checkpoint hold. Two invariant rows record the verified SqueekCore integration and the absence of privileged roles.