The work is complete and committed. A clean clone of the commit builds, passes all tests with the verifier's fuzz seed, and passes the format check, all offline.

One deviation to flag first. The brief says to add the pool to the existing Foundry project and to integrate with the real OGClubFarmVault. The workspace was empty and the vault source is not published anywhere I could find. I built a fresh Foundry project at the root, and the integration test runs against a reconstruction of the vault's season interface in test/support/OGClubFarmVault.sol. It is test support only, nothing in src depends on it, and the README explains how to swap in the real vault with a single import change.

What was delivered

• src/OGClubCreatorPool.sol: the contract as specified. Ownable2Step, ReentrancyGuard, SafeERC20, MerkleProof, custom errors, immutable token, 3-day delay and 90-day claim window, YYYYMM month validation, exact balance checks on fund and claim, sweep back to free. No withdraw, no payout override by owner, no ETH, no proxy. The constructor makes no external call.
• Tests, 68 in total across five files: unit tests for every listed rule and revert, fuzz tests including paid-per-month ≤ total, four invariants under a handler, the vault integration flow, and direct calls of both deploy functions.
• script/DeployCreatorPool.s.sol for mainnet from env OG_TOKEN and OWNER, listing no games. script/DeployCreatorPoolSepolia.s.sol deploys a mock $OG and lists test games from a JSON string. Both print the address and ABI-encoded constructor args.
• README.md with behaviour, trust assumptions, invariants, deployment parameters, and an "Operations" section describing the monthly owner workflow.
• OpenZeppelin 5.4.0 and forge-std 1.11.0 vendored under lib as plain files. The index holds no gitlinks.

Check	Result
forge build (solc 0.8.26)	success, lint warnings only
forge test with the verifier's seed	68 passed, 0 failed
forge fmt --check	clean
Pool runtime size	about 14 KB

Decisions you may want to review

• "No self payout" was read two ways and both are enforced: a payout cannot be the pool contract, and a payout wallet cannot set itself again.
• The Sepolia script takes the games JSON as text through the GAMES_JSON variable rather than reading a file, so no filesystem permission is enabled. The example JSON file has placeholder text, not addresses, so it must be filled in before use.
• Slither was not available here. The code avoids the six outright-reject detectors by construction, which the README states.

Next steps for the requester

• Put the real OGClubFarmVault, OGClubStaking and OGClubClubs sources in the repository and point the integration test at the real vault.
• Supply the live $OG token address for the manifest. The owner argument is $owner.
• Arrange an independent adversarial review before release, as the contract will hold developers' $OG.

I found one medium, two low and one info finding. They are written to .imd-findings.json along with a coverage row for each of the 12 entry points and the three requested invariants. The existing suite (68 tests) passes. My proof test fails on the current code for the reason given in finding 1. I then deleted the scratch test and changed no project files.

Findings

1. Medium: the owner can still redirect money owed to an open month (src/OGClubCreatorPool.sol:242). claim() only checks that the game has a payout wallet at claim time, and listGame() works at any time. So if a month's Merkle root contains a game id that isn't listed yet, the owner can wait for the month to open (when cancelMonth stops working), list that id with their own wallet, and the claim pays them.
   • Reproduction: propose 202611 with a single leaf of 1000 OG for gameId("new-game"), wait 3 days, call listGame(id, owner), then claim(...). The owner's balance goes from 0 to 1000e18.
   • What it breaks: the rule that the owner can't touch a month's money after its 3-day window, and the invariant that the owner's $OG never rises. The invariant test only passes because its handler never lists an owner wallet.
   • Fix: store a listedAt time for each game and have claim require listedAt < opensAt.
2. Low: one far-future month id locks the pool for good (:205). lastMonth never goes back down, and any year up to 9999 is accepted. Once 999912 is proposed and opens, every later proposeMonth reverts with MonthNotAfterLast. There is no withdrawal, so the free balance and all later vault payments are stuck. Fix: cap the month id relative to the current date, or have cancelMonth restore the previous lastMonth.
3. Low: renounceOwnership() is inherited and not blocked (:24). After renouncing, nobody can propose a month, so all free and future $OG is stuck forever. Fix: override it to revert.
4. Info: the integration test doesn't use the real OGClubFarmVault. It runs against test/support/OGClubFarmVault.sol, a stand-in written from the brief because the real vault source isn't in this repository. Its header says so.

Checked and found sound: the claim window boundaries, cancel only before a month opens, once-per-game claims, the amount <= remaining cap, the exact balance checks on fund and claim (a fee-on-transfer token reverts), sweep timing, overwriting a cancelled month (no leftover claim flags), and how reserved is kept. Balance ≥ reserved and reserved = sum of open months' remaining both hold. The slither timestamp warnings are only the intended day-scale windows, so I didn't report them.

Not covered in depth: the deploy scripts outside their economic effect.

I found one medium and three low defects in OGClubCreatorPool, plus one test gap. Each of the four defects has a Foundry test that fails on the current code for the stated reason. The existing suite (68 tests) passes. Results are in .imd-findings.json with 5 findings and 14 coverage rows, which cover all 12 entry points and 2 invariants. I changed no files: the scratch tests were deleted after their source was copied into the findings, and the tree is clean.

Findings

1. Medium: cancelling a mistyped month id doesn't undo it (src/OGClubCreatorPool.sol:205).
   • proposeMonth advances lastMonth, and cancelMonth never puts it back.
   • Reproduction: proposeMonth(999912, r, 100e18), then cancelMonth(999912), then proposeMonth(202611, …). The last call reverts with MonthNotAfterLast for every id below 999912, permanently.
   • After 999912 is used once more, no month can ever be proposed. All free $OG, including later farm-vault payouts, is then locked for good.
   • Fix: restore the previous lastMonth when the last month is cancelled, or cap month ids near the current date.
2. Low: renounceOwnership is inherited unchanged.
   • One owner call means proposeMonth can never run again. The free balance and every later vault inflow can then never leave the pool.
   • Fix: override renounceOwnership to revert.
3. Low: the owner can be a game's payout wallet (_checkPayout, line 314).
   • Reproduction: listGame(g, owner), propose a month that gives g all of the free balance, wait 3 days, then claim. The owner's balance goes from 0 to 1000 $OG. This breaks the brief's rule that the owner's $OG never rises through this contract.
   • The invariant test misses this because its handler skips any payout change to the owner.
   • Fix: reject the owner as a payout in listGame and changePayout.
4. Low: claim's exact-balance check only measures the pool's side (line 251).
   • With a standard fee-on-transfer token (the recipient gets less), funds that arrive by plain transfer can still be claimed. The claim succeeds and the game receives 99 instead of 100.
   • The existing test only covers a token that charges the sender, so this path is untested.
   • Fix: also check that the payout wallet's balance rises by exactly amount.
5. Info: the integration test uses a rebuilt vault. It runs against a copy of OGClubFarmVault that the builder reconstructed, not the real contract the brief names. The builder disclosed this; the real vault source isn't in the repo.

Coverage

• Hold: acceptOwnership, transferOwnership, delistGame, relistGame, fund, sweep, and both invariants (balance ≥ reserved; reserved equals the sum of what open months still owe).
• Have findings: proposeMonth and cancelMonth (#1), renounceOwnership (#2), listGame and changePayout (#3), claim (#4).
• I covered all three assigned guides: Execution Trace, Periphery and First Principles.
• I read the deploy scripts but checked them only briefly and found nothing to report.
• I left out the five Slither timestamp warnings: each comparison is a deliberate window check, and I found no boundary errors at the edges.

The findings file is valid, both snippets match the source exactly, and the coverage record answers all 12 entry points plus five invariant/lead rows. The scratch test lives under test/scratch/ and is not part of the submission.

Result: the arithmetic and boundaries of OGClubCreatorPool hold. Two low-impact items were substantiated, nothing critical or high.

What I checked in my area (Math Precision, Boundary, Numerical Gap):

• No division, scaling or downcast risk. The only division is in the month-id validator, and the one narrowing cast is of a timestamp into uint64, which cannot truncate.
• Reservation accounting is exact. Every change to reserved is paired with an equal change to exactly one month's remaining, so balance ≥ reserved and reserved = Σ remaining hold by construction for a plain ERC-20. The existing invariant and fuzz suites confirm this and pass with all 68 tests.
• Time edges are consistent. Claim, cancel and sweep use complementary comparisons at opensAt and opensAt + 90 days, so there is no gap or overlap. I reproduced this at the exact boundaries in a scratch test. The Slither timestamp leads are intended behaviour.
• Cancel-and-repropose is safe. A cancelled month can only be overwritten before it opened, so the claimed map for it is guaranteed empty.

Findings written to the file:

1. Low. The claim path's exact-balance check only measures the pool's own balance. With the common fee-on-transfer shape, where the recipient receives less, the claim succeeds, the month records the full amount as paid, and the game receives 99% of it. The README's statement that claim reverts on fee-on-transfer tokens is only true for the inverted, sender-charged shape that the test mock implements. This does not trigger with a plain $OG token.
2. Info, trust assumption. The owner can list a game whose payout is the owner's own address and route a whole month to it after the 3-day delay. The "owner's $OG never rises" invariant passes only because the test handler never does this. This is the agreed design's reliance on an honest owner, not a bypass.

Not covered: the real OGClubFarmVault, whose source is absent from the repository, so the integration test runs against a reconstruction. That is outside my area and noted in the README by the author.

The review is complete and .imd-findings.json holds four findings and fifteen coverage rows. The existing suite of 68 tests passes, and my scratch tests under test/scratch/ reproduce every finding.

Findings

• Medium, owner self-payout. The brief says the owner can never withdraw and that the owner's $OG never rises through the pool. Nothing enforces it: _checkPayout at src/OGClubCreatorPool.sol:315 only refuses the zero address and the pool, so the owner can list a game paying itself, propose a single-leaf month for the whole free balance, and claim it after three days. The invariant handler never generates this case, which is why the suite passes. A proof test fails on the current code and passes once owner and pending owner are refused as payouts. The complete guarantee cannot be enforced on-chain while the owner picks roots, so the natspec should state the real safeguard: the delay plus published lists.
• Low, late listing into an open month. claim reads the payout at claim time and only needs it nonzero. The owner can propose a root with a leaf for an unlisted id, wait past opensAt, then list that id with any wallet and decide the recipient after the window where the owner is supposed to have no influence. Fix by recording a listing time and requiring it to precede the month's proposal.
• Low, renounce strands funds. The inherited one-step renounceOwnership leaves no owner, and proposing months is the only way tokens ever leave. All free balance, including future vault payouts, is locked forever. Override it to revert.
• Info, cancelled typo month. A cancelled month still raises lastMonth, so a mistyped future id permanently blocks the calendar months before it. This matches the brief, so it is recorded as a consequence, not a violation.

Coverage

All twelve entry points have a row. Ownership handover, cancel, changePayout, delist, relist, fund, proposeMonth and sweep hold under the Access Control, Trust Gap and Asymmetry checks. The reserved accounting invariant holds. Slither's timestamp leads are inherent to the window design and were not promoted. Reentrancy, math and token-behaviour passes outside my area were only sampled.

I added two new test files alongside the existing suite and found no high or critical defects. I did find three low-severity design problems, which I reported rather than writing tests that treat them as correct. With the verifier's seed, forge build succeeds and forge test passes all 100 tests (68 existing plus 32 new). I did not change anything in src/ and did not commit.

test/OGClubCreatorPool.adversarial.t.sol (31 tests) covers what the existing suite left open:

• Exact time limits: claims one second before opening, at opening, one second before closing, and at closing; cancelling one second before opening and at opening; sweeping before and at closing; sweeping twice; and sweeping or cancelling a month that was already cancelled.
• Cancel and re-propose: the old Merkle root stops working and the new one works, the 3-day delay restarts, and the new version can reserve more. A month id can't be reused without a cancel, and an older cancelled month can't come back once a newer one exists. Also covered: December to January rollover and invalid month ids.
• Replayed or forged claims: a proof can't be reused in another month, even when the owner gives both months the same root, and can't be moved to another game or amount. Also covered: an empty or padded proof, a zero-amount leaf, and a leaf for a game that was never listed.
• Who gets paid: a game's payout wallet that moved twice; the old wallet losing control; changing the payout after a claim doesn't allow a second claim; relisting keeps the current wallet; and several months open at once without affecting each other.
• Large trees: months of 33, 64 and 65 games pay out exactly.
• Ownership handover: a pending owner has no powers, and the old owner loses them after the handover. Months already proposed still pay and sweep after the owner renounces.
• Re-entering the pool: a payout wallet that tries to call back into the pool while being paid is blocked.
• Unusual tokens: a token that returns false is refused and nothing changes; a token that returns nothing works.

test/OGClubCreatorPool.actors.invariant.t.sol drives the pool with the owner, three relayers and the game wallets. It also tries things that must fail: forged claims, owner-only calls from other accounts, the owner changing a payout, cancelling a month after it opened, sweeping too early, and invalid proposals. Each attempt is checked against an independent model of what the pool should accept. After every step it checks:

• the balance covers what is reserved, and the balance equals what came in minus what was paid out;
• the reserved amount equals the sum of what open months still owe;
• no month pays more than its total;
• only game payout wallets ever receive $OG, never the owner or the account making the claim.

To check these tests can actually fail, I temporarily broke src in two ways (cancel allowed after opening; a month allowed to overpay), confirmed both were caught, then restored it with git. In 30 simulated runs, 68 claims and 33 sweeps succeeded, so the tests are exercising real payouts.

Findings in .imd-findings.json (each low one has a proof test that fails on the current code):

1. Low: listGame accepts the owner's own wallet as a payout. The owner can then propose a month paying that game the whole free balance and collect it 3 days later. This breaks the brief's rule that the owner's $OG never rises through this contract.
2. Low: the inherited renounceOwnership isn't disabled. If the owner renounces, the free balance and all future vault payments are locked in the pool permanently.
3. Low: a mistyped month id far in the future, such as 207206 for 202706, becomes lastMonth. Cancelling it during the 3-day review doesn't undo that, so every real month below it can never be proposed.
4. Info: the integration test runs against a stand-in vault the builder wrote in test/support/, not the real OGClubFarmVault. That sourc

Review complete. The findings file is written and the tree is otherwise unchanged (git status is clean apart from the untracked findings file, and the scratch tests are removed).

Outcome. Every specialist finding reproduced; the 15 specialist reports collapse into 6 findings, with four attached proofs that all fail on the current code for the stated reasons. The project's own 100 tests pass. The manifest's $OG address was checked against mainnet: symbol OG, 18 decimals, and it is the live farm vault's token.

Findings kept, by severity:

1. Medium: late listing redirects an open month. The owner can propose a root containing a leaf for an unlisted game id, wait past the 3-day window, then list that id with any wallet and claim. This contradicts the README's "a leaf for an unknown game is unclaimable" and the post-window guarantee. Merged from economics and permissions.
2. Medium: cancel cannot undo a mistyped month id. lastMonth is never lowered, so a typo like 999912 locks every future proposal and the whole free balance permanently, since there is no withdraw path. Merged from all four areas and the test writer.
3. Low: owner may be a payout wallet. Only zero and the pool itself are refused, so the "owner never gains $OG" invariant is enforced only by the test handler, which skips that case. Rated low because a second wallet is unstoppable on chain anyway and the delay is the real safeguard.
4. Low: inherited renounceOwnership strands all funds.
5. Low: claim's balance check is pool-side only. A recipient-side fee token passes and the game gets less than its leaf. Harmless with the real $OG but the README and the fee test overclaim.
6. Info: the integration test uses a reconstructed vault, not the real OGClubFarmVault.

Coverage. All 12 entry points answered, plus rows for the three brief invariants and the manifest. Eight entry points hold; claim, listGame, proposeMonth and renounceOwnership point at findings 1, 1, 2 and 4.

Nothing new beyond the specialists. My own pass over Merkle domain separation, reserved accounting across cancel and re-propose, claim and sweep boundaries, reentrancy, the deploy scripts and the launch manifest found no additional defect.

Both reproducible findings are fixed and their proofs pass, the three advisory findings reproduced on the original code and are fixed too, and all five are answered in .imd-responses.json.

What I verified first

• The two proofs failed on the starting tree exactly as reported. Both pass on the fixed contract.
• The three advisory findings also reproduced on the original source with a scratch test. The same scratch test passes on the fixed source.

Contract changes in src/OGClubCreatorPool.sol

• Late listing records a listedAt timestamp per game. A claim reverts when the game was listed after the month was proposed, so a month's recipients are fixed when its review starts. Same-block listing and cancel-then-re-propose still work.
• Mistyped month id is undone by cancel. Proposing stores the previous lastMonth, and cancelling the highest month walks back to the highest live month. The rule "month > lastMonth, or equal if cancelled" is unchanged.
• Owner as payout is refused on list and on payout change, for the owner and the pending owner. A claim also refuses a payout wallet that has since become the owner.
• renounceOwnership always reverts, since no owner would mean no way to schedule the free balance.
• Recipient-side balance check in claim, so a fee-on-transfer token now reverts in both shapes.

Tests and docs

• Added unit tests for every change, replaced the one test that encoded the old lastMonth behaviour, and added two invariants plus a handler action that tries the owner as payout.
• README natspec and trust statements reworded to match what the contract enforces, with new operational notes on listing order and on checking month ids within the three days.

Checks run

forge build          ok (only pre-existing lint warnings)
forge fmt --check    ok
forge test           84 passed, 0 failed (verifier seed), proofs included

The responses file is excluded from git by the harness's own exclude rule, which is how it was set up, so nothing further is needed there. Month-id validation still accepts any year up to 9999. A typo not cancelled within three days remains permanent, which the README now states.

The manifest is complete and launch.json is the only changed file.

Outcome. The earlier rejection asked for the mainnet $OG token address. It did not need the requester: the address in the accepted manifest is the requester's own live token, and I confirmed that on chain today rather than guessing.

• Token argument verified on Ethereum mainnet. A public RPC read of the token at the manifest's address returned name OG, symbol OG, 18 decimals and a total supply of one billion tokens. The live OG Club farm vault returned that same address from its token() getter, and its owner() is this launch's $owner wallet.
• Constructor match. OGClubCreatorPool's constructor takes an ERC-20 token and an owner, in that order, and only stores the token after a nonzero check. The manifest passes the static token address and $owner, so the empty-chain rehearsal cannot revert on a missing contract.
• Change made. Constructor arguments are unchanged from the accepted round. Only the notes were rewritten to record the on-chain evidence and the date it was gathered, so a reviewer can see the address is not a stand-in. Notes are under the 4,000 character limit and the manifest has exactly the kind, contracts and notes keys.
• Checks. The project builds, and the full suite passes with the verifier's fuzz seed.

Suite	Result
All 5 Foundry suites	79 passed, 0 failed

No .imd-blocked.json was written, since the missing value turned out to be resolvable from the requester's deployed contracts. Nothing outside launch.json was touched.

The reviewer's finding was correct and is now fixed. The integration test runs against the real OGClubFarmVault bytecode instead of the copy the previous round wrote from the brief. forge build and forge test both pass: 112 tests, run with the verifier's fuzz seed, including both invariant suites.

The vault finding (e94d3298…): fixed

• The live vault at 0x60401e74…0B80 has no verified source on Sourcify or Blockscout. Blockscout does have the transaction data that created it, though.
• test/support/OGClubFarmVaultBytecode.sol now holds that creation code and the live contract's code. A new test, test_vaultBytecodeIsTheLiveContract, deploys it with the mainnet constructor arguments and checks the result matches the mainnet code byte for byte.
• The integration tests deploy the same bytes with a mock $OG. They call it through an interface built from the function signatures in its code. With the real vault:
  • the claim format is the one assumed: season, account, amount;
  • a vault season can pay the pool's address, and the $OG shows up in the pool's free();
  • vault claims fail before its 3-day delay.
• I deleted the old copy, test/support/OGClubFarmVault.sol. It got three things wrong about the real vault, none of which affects the pool:
  • the vault numbers seasons itself (proposeSeason(root, total); there is no openSeason);
  • a season can take at most half the vault's free balance;
  • proposals must be at least 7 days apart.

Two of my earlier tests were failing, now fixed. Another contributor changed the contract after my last round, and two of my tests no longer matched it:

• cancelMonth now moves lastMonth back to the highest month that is still live. The invariant handler re-proposes the same month after cancelling the highest one. It now asserts lastMonth equals the highest live month, and no longer that every proposed month is at or below it.
• renounceOwnership is now disabled. The test that renounced and then claimed now expects RenounceDisabled, and checks that a two-step ownership handover leaves a proposed month claimable.

Reported in .imd-findings.json (both info, no money at risk):

• lastMonth steps back on cancel. The brief only allows re-proposing the cancelled month itself. The contract now also accepts lower months, as long as they are above the previous live one: for example, 202611 after cancelling 202612. This is documented as a way to undo a mistyped month and moves no money, but the requester should confirm they want it.
• The README is out of date. It still describes the deleted copy of the vault. It's outside the files I'm allowed to change, so I left it alone.

My answer to the reviewer is in .imd-responses.json. I haven't committed anything.

Review complete. The findings file is written at .imd-findings.json with one info-level note and an 18-row coverage record.

Earlier findings, all confirmed fixed. I copied the six attached proofs under test/scratch and ran them against the revised code. Every one passes now, and the full suite of 112 tests passes with them.

• Late listing redirecting an open month's leaf is closed. The contract records when a game was listed and claim refuses a game listed after the month was proposed.
• Cancel not undoing a mistyped month id is closed. Cancelling the highest month walks lastMonth back to the highest live month. I traced nested and repeated cancel sequences and found no way for it to land on a cancelled month or below an open one.
• Owner as payout wallet is closed. Listing and payout changes refuse the owner and pending owner, and claim re-checks the current owner.
• renounceOwnership now reverts.
• Recipient-side fee-on-transfer is closed. Claim checks the payout wallet's balance rose by exactly the amount.
• Integration against the real vault is closed in code. I fetched the live vault's runtime from mainnet and its keccak matches the constant the test asserts against byte for byte, so the test really drives the deployed vault's bytecode.

One item kept, as info. The README section about the vault in the integration test still describes the deleted reconstruction file and an openSeason function the live vault does not have. The author said README was outside their writable paths last round. Documentation only, no code impact.

Dropped. The test writer's note that the lastMonth walk-back departs from the brief's literal rule is the fix I asked for, and the brief's rule still holds with lastMonth defined as the highest live month. The static-analysis timestamp and literal leads are intended behaviour.

Also checked. The manifest has only the three schema keys, two string constructor arguments, and the live $OG address. Runtime size is 7,870 bytes and the constructor makes no external call, so the CREATE2 rehearsal deploys. Nothing in the tree was modified. The scratch copies were removed.