Created launch.json with ITEM, all four contracts, the literal vesting beneficiary, and required pool settings. Only the manifest is a submission change.

Verified constructor ABI matches, successful forge build, and all 79 tests passing with the supplied fuzz seed.

I found no real defects in the economics. The review file .imd-findings.json has one info-level note and needs no fix, so there are no proof tests (those are only for critical or high findings).

The full suite (79 tests) passes. I also traced every entry point against the Economic Security, Invariant and Flow Gap guides and ran two throwaway probe tests, which I've since deleted. The tree is unchanged.

The note (info): this is what the brief specifies, not a bug. In ItemStaking, if anyone donates more than 1e30 raw units of a reward token on top of what's already accounted for (src/ItemStaking.sol:118), that token never streams again. Nothing in the contract ever brings the surplus back under the limit, so every later fee in that token sits in the contract for good. Streams already running and amounts already owed still pay out. I confirmed it with a probe: after a donation of 1e30+1 BASK, 1,000 BASK of fees and 30 days, the staker has earned 0. The attack needs 1e12 BASK or WETH, or 1e24 USDG, so it's out of reach for WETH and USDG and depends on BASK's supply. Changing it would mean changing the brief, so it's the requester's call.

What holds:

• Gauges: total paid never exceeds what has been released, which never exceeds the allocation. A stake added and removed in the same block earns nothing. withdraw only moves LP tokens, so it can't be blocked.
• ItemStaking: for each reward token, accounted only grows when a stream starts and only falls by what is actually paid. So payouts can't be counted again as new fees and never exceed what came in. No reward-token behaviour can make stake or unstake revert, including reverting, returning false, burning gas, returning huge data, or reporting 0 or 2^256-1. Numbers can't overflow even with a 1-wei total stake and a stream at the 1e30 limit.
• DevVesting: it releases nothing before day 365, then vests on the deployment clock up to the full allocation at day 1,460.

Static-analysis leads: none of them holds up.

• Aderyn's shift-order warning is a false positive: the instruction's arguments are in the correct order.
• Aderyn's reentrancy warning on start() doesn't apply: the only call before the state change is to the fixed factory address, and start() is guarded against reentry.
• Slither's strict-equality warning flags the "previous stream has finished" check, which is meant to be exact.

Not checked: the protected deployment tests need the launch environment's variables and wouldn't run here. Something can also be done on purpose, by design: right after a stream finishes, anyone can start a dust-sized one, which makes the next large fee wait up to 7 more staked days. It only delays rewards and takes no value, so I left it out of the findings.

The coverage record answers all 17 entry points: 16 hold, and ItemStaking.sync is marked against the note. It also has rows for the two accounting invariants and the shift-order lead.

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

Outcome: no substantiated defects in the Execution Trace, Periphery or First Principles areas. One info note was recorded, and all 17 entry points plus five checked invariants have coverage rows.

What I traced

• LpGauge control flow. The global index is advanced from differences of the cumulative release curve, then the caller's account, before any stake change. A same-timestamp stake-and-claim earns nothing. The clock only runs while totalStaked is nonzero and clamps at T, so emission never exceeds the allocation. withdraw never touches ITEM and its update path has no revert branch, so an LP exit always works.
• ItemStaking control flow. Streams advance by floor(F·s/D) differences, wall time always checkpoints while staked time only passes with stakers present. A new stream starts only on a valid read, balance at or above accounted, fresh in (0, 1e30], and no unfinished stream. Claims pay min(accrued, balance read) and decrement accounted by exactly that amount. Nothing in stake or unstake can be made to revert by any reward-token behaviour. A scratch run confirmed a stream ending exactly as the last staker exits, an idle-period deposit, and burn deficits being repaired before new streams.
• Periphery. The TokenCalls selector shift is the correct Yul operand order, calldata is 36 bytes, the staticcall is gas and copy bounded, and a 0-byte transfer return is accepted only if the token has code. RewardIndex computes the carry formula exactly without a 256-bit product overflow, and the index is monotone.
• DevVesting. Cliff and linear formula match the brief at days 364, 365 and 1,460. Funding is once-only and the release path is effects-before-transfer.

Static-analysis leads were all false positives after inspection and are recorded as such in the coverage rows.

The info note is that start() on either gauge pulls the entire allocation in one call, and the default launch split leaves the requester 100M ITEM against 490M and 210M needed. The README already discloses the 740M requirement and the constants come from the brief, so this is a funding-inventory note for the judge, not a code defect.

The review is complete. The findings file is valid JSON, both snippets match the tree exactly, and every one of the 17 listed entry points has a coverage row.

Outcome: no exploitable defect in the Access Control, Trust Gap or Asymmetry area. The permission model is empty by design: no roles, owners, initializers, proxies or sweeps exist, and every state-changing function is nonReentrant and keyed to msg.sender. Paired surfaces (stake/withdraw, stake/unstake, sync/claim, fund/release) write mirrored state in mirrored order, with the global index and caller account checkpointed before every stake change.

What I checked, beyond reading:

• Ran the existing suite (79 tests pass) and six scratch probes of my own under test/scratch/, covering dust-stream griefing, burn-to-zero then partial repayment, odd stake sizes with repeated claims and exits, a lone 7-wei gauge staker across a 1000-day idle gap plus a same-block flash stake, hostile WETH during principal moves, and the 1e30 fresh cap with a late 1e27 joiner. All pass with at most 2 raw units of dust.
• Checked the Slither and Aderyn leads: the "incorrect shift order" and "state change after external call" lines are false positives (Yul shl argument order is correct; start() is guarded and the factory address is a constant).

Two notes recorded, both at info severity:

1. Anyone can send 1 wei of a reward token and call sync to make it the live stream, delaying real fees by up to 7 staked days per cycle. This follows the assignment's "later amounts wait" rule exactly, so it is flagged for the judge as accepted behavior rather than a defect.
2. Starting both gauges and funding vesting needs 740M ITEM from single callers, while the requester holds 100M after a default 80% pool split. The README already states the requirement. It is a launch-policy gap, not a code defect.

Nothing was left unreached. The launch manifest does not exist yet, which is expected at this stage.

I added invariant tests for every contract that holds value, plus edge-case and event tests. The full suite passes with the verifier's fuzz seed: 92 tests, 0 failed, and forge build is clean. I found no defect in the contracts, so I didn't write .imd-findings.json. I changed none of the existing files; everything new is under test/.

Invariant tests (in test/invariant/). Each uses a handler that calls the contract in random order with several actors. Run counts are set in the files themselves.

• Both gauges (128 runs × 80 calls each; an earlier run at 256 runs × 500 calls also passed):
  • Staked LP held equals totalStaked and the sum of all stakes.
  • ITEM is conserved: what the gauge holds plus what was paid equals the allocation plus any ITEM sent to it.
  • Paid plus still-owed never exceeds released, and falls short of it by at most 3 wei (one per actor).
  • stakedSeconds only counts time while something is staked, and released, rate and remaining match their formulas exactly.
  • withdraw never fails, even while ITEM transfers revert, return false or return oversized data.
  • A failed claim leaves the debt unchanged.
• ItemStaking (128 × 80): the handler mixes stake, unstake, claim, sync, fee deposits, issuer burns, time jumps and hostile reward tokens (all balance-read failure modes, plus transfers that revert, return false or return oversized data).
  • ITEM held equals totalStaked and the sum of stakes.
  • For each reward token, what it holds plus paid plus burned equals what it received.
  • Paid plus owed never exceeds what it received, and it can pay everything owed whenever there was no burn.
  • stake/unstake never fail, and a claim of a well-behaved token never fails.
  • A claim never pays more than was owed, and whatever it doesn't pay stays owed.
• DevVesting (128 × 40):
  • vested matches its formula exactly.
  • released ≤ vested ≤ the allocation, and released never goes down.
  • The beneficiary's balance equals released, and nothing leaves the contract except to the beneficiary.
  • fund can't succeed twice, and release never fails once funded.

Other new tests:

• test/ItemStakingReadEdges.t.sol, using a new mock test/mocks/OddReadToken.sol:
  • A balance read returning 33 or 64 bytes, or needing about 60k gas even when plenty is supplied, counts as invalid: no stream starts, stake and unstake still work, and the claim reverts with BalanceReadFailed.
  • A read needing about 30k gas is valid.
  • A top-up waits until the live stream reaches exactly 7 days, then starts from that moment.
  • A 1-wei reward split between a 1-wei staker and a 1e27 staker rounds down and carries the fraction over to the next stream.
• test/Events.t.sol: every state-changing function emits its event with the amount actually moved.

Notes, not defects:

• The invariant tests don't check how small the final ItemStaking rounding dust is; the existing fuzz tests already check that the last claimer is paid in full.
• A transfer that burns all its gas is left out of the random sequences because it only slows them down; the unit tests already cover it.
• Because of how the EVM forwards gas, a caller who sends very little gas can make the 50k-gas balance read fail. That only delays new fee streams during stake/unstake, and only reverts the caller's own claim, so it does no harm.
• The accepted behaviours (no staking lock, the first LP staker earning alone, claims being first come first served after an issuer burn) are already written up in REVIEW.md.

The review is complete and the findings file is written. The math area came back clean.

Result: no defects found in the Math Precision, Boundary, or Numerical Gap areas. The findings file at .imd-findings.json holds an empty findings list and 21 coverage rows: all 17 listed entry points marked holds, plus four invariant rows. The working tree is clean (scratch tests removed, nothing else touched).

What I verified, beyond reading the code:

• Built the project and ran the existing 79 tests, all passing.
• Wrote scratch probes for the edges the guides target: a 1-wei staker next to a 1e27 whale entering mid-stream with hourly sync spam, a 1-wei stream against the full ITEM supply, 70 consecutive one-wei streams over stakes of 1/2/4, the gauge at the exact T boundary with a late entrant, pre-start claim and withdraw calls, a stream finishing while idle, a deliberately low-gas stake that invalidates the balance reads, and a weekly vesting walk from day 364 to 1470.
• Every probe held the spec's invariants. Paid never exceeded released or receipts, dust stayed at a few wei, and the vesting cliff and endpoint are exact. The only surprises were my own assertion mistakes and the expected round-down dust, which the rules mandate.

Static-analysis leads checked and dismissed: the Yul shift operand order is correct, the strict equality on stream time is reached exactly because of the min cap, and the external view call before state in start() is a guarded view read.

Notes for the judge, not defects: index rounding can push a user whose exact share is an integer just below it, so 70 one-wei streams pay 9/19/39 instead of 10/20/40 and leave 3 wei in the contract. This is the specified round-down behavior and the spec's "paid less dust" acceptance covers it.

Review complete. The findings file is written and validated, and the scratch tests are removed so the tree holds only .imd-findings.json.

Outcome: no contract defects. All three specialist findings reproduce, but each is behaviour the brief itself mandates, so they stay as info notes rather than defects to fix. The full suite of 95 tests passes, and my own adversarial scratch tests also passed before I removed them.

Findings kept, all info:

• Dust stream delays fees. A 1 wei reward deposit synced right after a stream ends becomes the next 7-staked-day stream, so real vault fees wait one window. Reproduced exactly as the brief's "later amounts wait" rule prescribes.
• Surplus above 1e30 stops streams for good. Once an unaccounted surplus of a reward token exceeds 1e30 raw units, no later receipt of that token streams. Reproduced, and it is the brief's own cap.
• Funding size is operational. Starting both gauges and funding vesting needs 740,000,000 ITEM from single callers, more than the default launch split leaves the requester. The two specialists' duplicate notes are merged into one. The README already discloses it.

What I verified myself:

• Every one of the 17 entry points traced and marked holds, with reasons, plus rows for the two conservation invariants, the static-analysis leads and the manifest.
• Pre-start calls on a gauge do not backdate its clock, the schedule ends cleanly at four years, and withdraw never touches ITEM.
• A lying reward token that reports 1e30, then 0, then the maximum value, then turns honest never underflows accounting, never blocks unstake, and only ever blocks its own claim.
• The static-analysis leads do not hold: the Yul shift order is correct, the factory read is a staticcall to a constant address under the reentrancy guard, and the strict equality against the 7-day cap is reached exactly because elapsed is capped.

Nothing is outstanding for the author. The one open item for the requester is operational: arranging the 740,000,000 ITEM needed to start the gauges and fund vesting.