Implemented the FROGS token, voting contract, four original frog illustrations, live-data website, wallet flows, tests, and documentation.

Verified:

• forge build, forge test — 45 passing — and forge fmt --check
• 22 website tests and 2 local chain integration tests

Deployment and hosting remain: configure the Sepolia address in web/config.js and publish web/. Instructions are in README.md.

Idle agents show “status unknown” because the API lacks individual online flags.

Created launch.json matching the accepted token and FrogOfTheWeek($token) constructor.

Schema, manifest constraints, metadata and compiled ABI checks passed. forge build succeeded with existing lint warnings; forge test passed all 45 tests.

Only launch.json is changed for submission.

The review is complete. The findings file is written and no source files were changed.

Result: no defects in the assigned area. .imd-findings.json holds an empty findings list and ten coverage rows, one for each of the six listed entry points plus four invariant and lead rows.

What I checked (Access Control, Trust Gap, Asymmetry):

• Permission map. There is no owner, role, initializer, proxy, receive or fallback. The constructor stores only the token address and start time, and moves no supply. The runtime has no delegatecall or selfdestruct.
• Confused deputy. vote always pulls from msg.sender, so a relay contract or another holder cannot spend someone else's approval. Probed with a relay: it reverts with TokenTransferFailed.
• Withdrawal ownership. withdraw pays only the caller's own locked[week][msg.sender] to the caller. Another address or a relay gets NothingToWithdraw.
• Asymmetry. Vote and withdraw are mirror writes on locked and totalLocked. Both check balances before and after the token call. Historic vote totals and winners stay untouched by withdrawals, as the brief requires. The cached leader matched a full-scan model with dense ties and lowest-id tie-break across 256 fuzz runs.
• Boundaries. finalize and withdraw reject at exactly one second before week end and succeed at week end. A second finalize for an unended week reverts.
• Slither leads. The reentrancy-balance reports are not findings. One guard covers all three entry points, state settles before the token call, and only the event follows it. The timestamp leads are the intended week clock.

Trust assumption recorded, not a defect. A vote cast one second before the week ends can be withdrawn one second later and re-voted in the next week, so late voters pay almost no capital cost. Same-transaction vote-then-withdraw is impossible. This follows from the requested refundable, token-weighted design and is documented in the README.

Outside the area. I read the website code for severe issues and found none worth reporting. The finalize backlog is handled with explicit "finalize oldest weeks first" copy, and the champion panel reads the last finalized week.

The scratch probes under test/scratch/ were removed after running, and the working tree is back to clean apart from the findings file.

Wrote .imd-findings.json: no substantiated defects, with all six entry points and eight invariants covered.

Passed 46 Foundry tests, 22 JavaScript tests, and additional arithmetic/boundary checks. Protected deployment checks were inspected but not executed.

The review is complete. The findings file is written and valid, and no tracked file was changed.

Outcome: no reproducible defects in the Economic Security, Invariant or Flow Gap areas. The findings list in .imd-findings.json is empty, with 11 coverage rows: one for each of the six listed entry points, plus the invariants and economic seams I checked.

What I verified, beyond reading the code against the three guides:

• A scratch differential model (256 fuzz runs, six weeks, all 2000 agent ids, 1-wei and whole-token votes, forced ties, interleaved refunds from earlier weeks, a finalization backlog, and direct token donations) confirmed conservation and that the cached leader always equals the lowest id holding the maximum. The shipped suite only models three agent ids and one week for the leader check, so this closes that gap.
• Withdraw-then-finalize and finalize-then-withdraw produce identical records, and the leader cache survives overtake and re-tie sequences.
• Every inflow and outflow is exact-delta checked, so the contract balance never falls below outstanding liabilities with the LaunchToken, and no voter's refund can be starved by another.
• The website flow re-reads the week before approving and before voting, approves the exact amount, and maps 1-based display weeks to 0-based contract weeks correctly for withdrawals and champion labels.

Static-analysis leads rejected: the slither reentrancy lines are guarded by a lock covering all three state-changing functions with effects before the token call; the LaunchToken has no callbacks; the aderyn unsafe-ERC20 line is handled by the custom return-value check.

Accepted design points I did not report as defects, since the brief and README state them: tokens voted in the last second of a week are refundable one second later and can vote again immediately, so the lock imposes near-zero cost on last-block voters; direct donations are stranded; one withdraw call is needed per deposited week and one finalize call per backlog week.

The review is complete. The findings file is written and validated, the scratch tests are removed, and the working tree is otherwise untouched.

Outcome: no safety defect found in the Solidity control flow. The only entry in .imd-findings.json is one info-level note. All six listed entry points have coverage rows, plus five rows for invariants, deployment, periphery and the website flow.

What I checked, against the Execution Trace, Periphery and First Principles guides:

• vote: all three inputs traced. Week must match, agent bounded below the sentinel, zero amount rejected. Every storage effect precedes the token call and reverts with it. The incremental leader cache was fuzzed against a full 2000-slot tally with forced ties and matched every run.
• finalize: no inputs, no external calls, cannot get stuck. Votes for an ended week are frozen because only the current week accepts votes, so a late or backlogged finalize records the same winner.
• withdraw: caller-only ledger, liability cleared before transfer, both-side balance checks, failed transfers stay claimable, no expiry.
• Periphery: the raw-call helper rejects false, short and malformed returns and accepts empty returns. The reentrancy flag is restored on every path. The token has no hooks, fees, mint or selfdestruct, so the Slither reentrancy and Aderyn unsafe-ERC20 leads do not reach a defect.
• Deployment: the constructor grants no roles and moves no supply, matching the protected floor test.
• Website: the live /swarm response matches the adapter's expected shape. Unit tests and the Anvil integration test pass locally.

The one info finding is a usability gap, not a loss. Refunds are keyed per week, so a voter with deposits in two ended weeks needs two withdraw calls, and the site only shows the balance for one typed week. Funds are never at risk and the README documents the behaviour. I included it because the brief says voters "withdraw all their locked FROGS", and the reproduction gives the exact state where that reading diverges.

Not reached: nothing in scope was left unexamined. I did not run Slither or Mythril, since neither is provided here.

Added 26 tests covering failure paths, boundaries, rollback, and reentrancy. Strengthened custody invariants across 16,384 randomized calls.

Offline forge build and forge test passed: 71 tests, zero failures.

Changes are confined to test/. No confirmed contract defects found.

The review is complete. The findings file is in place at the repository root and no other tracked or untracked path was changed.

Outcome: no safety defect found. The contract and token hold on every entry point, and the two items I kept are informational wording gaps against the brief, not loss-of-funds or breakage.

What I verified

• Full Foundry suite from a clean offline build: 71 tests green, including the 256-run stateful invariant campaign that checks custody equals liabilities plus donations.
• Each of the six listed entry points traced for guards, effects ordering, failure paths and reentrancy. Effects precede the token call on both deposit and refund paths, both are behind a guard, and exact balance deltas are checked. The leader cache is a correct argmax with lowest-id tie-break.
• Slither's reentrancy leads do not reproduce: the token is the plain immutable LaunchToken, state is settled before the call, and the guard covers all three functions. Aderyn's unsafe-ERC20 lead is handled by the low-level call wrapper that accepts empty or true returns only.
• Manifest and constructor: $token fills the only address argument, the constructor grants no role and moves no supply, pool fields are the required defaults.
• Website: all 17 ABI selectors match cast sig, the live swarm API shape matches the normaliser, and the 22 node tests pass.

Findings kept (both info)

1. Per-week withdrawals. The audit_flow finding reproduced exactly as stated: a voter with deposits in two ended weeks gets only one week back per call, and the site inspects one typed week. Funds are never lost.
2. Sequential finalization. After idle weeks, one press of "Crown the winner" records an empty older week, and the contested week needs further calls. This is documented, but it diverges from the brief's literal wording and the site's success message does not say which week settled.

Both were reproduced with a scratch Foundry test whose exact inputs and expected-versus-actual values are in the reproduction fields. The coverage record answers all six entry points plus three invariant rows.