Done. The project is committed on main as a single commit with the token, four application contracts, tests, vendored forge-std and README.

What was built (Foundry at the repo root, solc 0.8.26, optimizer 200 runs, cancun, bytecode_hash = none):

• src/LaunchToken.sol: Item / ITEM, fixed 1e27 supply minted to the deployer, no admin paths.
• src/ItemStaking.sol: stake ITEM, earn BASK, USDG, WETH. Streams of 7 staked days from 50,000-gas staticcall balance reads with the exact validity, accounted, 1e30 and "no unfinished stream" rules. Stake and unstake never touch a reward token.
• src/LpGauge.sol plus BaskUsdgGauge and ItemEthGauge: v2 LP staking paying ITEM on the quadratic 4-year curve over staked seconds, one-shot start() that pulls exactly the allocation.
• src/DevVesting.sol: 40M ITEM, 365-day cliff, linear to 1460 days, beneficiary as the given literal, zero beneficiary rejected.
• Shared RewardMath (512-bit mulDiv, 1e36 index, carry accrual) and TokenTransfer libraries, all internal, and a storage reentrancy guard.

Verification, all run locally with the verifier's fuzz seed:

Tests cover every rule and its reverts, odd-sized and lone stakers, rounding at 1 wei and 1e27, hostile reward tokens (revert, false, gas burn, huge and short data, reporting 0 and 2^256-1), partial issuer burn with first-come claims, reentrancy through LP and reward tokens, and DevVesting on days 364, 365 and 1460.

Notes for the reviewer, also in the README:

• The three accepted behaviours are documented: no lock, the first LP staker earns alone, and claims are first come first served while a burn leaves ItemStaking short.
• start() and fund() are open calls funded by whoever holds the ITEM, which comes from the requester's share, not from the contracts.
• Operational steps after launch: create both v2 pairs, call start() on each gauge with its allocation, call fund() on DevVesting, and set ItemStaking as the vault's fee recipient.
• One commit-time detail: git had no author identity on this machine, so the commit was made with an explicit throwaway author on the command line and no config file was changed.

Created launch.json with the four application contracts, verified constructor arguments, specified beneficiary, and required pool values.

forge build succeeded. All 98 tests passed with the supplied fuzz seed. Only launch.json changed.

The review is complete and the findings file is in place with an empty findings list and a full coverage record.

Outcome: no substantiated defects in the Math Precision, Boundary or Numerical Gap area. The file .imd-findings.json holds an empty findings list and 20 coverage rows, one per listed entry point plus three invariant rows, every row marked holds with a reason.

What I checked, against each guide's failure modes:

• Math Precision. Every division rounds down as the spec requires. The release curve ALLOCATION * t * (2T - t) / T^2 peaks near 7.8e42, far below overflow, and equals ALLOCATION exactly at t = T. Stream math F * s / 7 days is bounded by the 1e30 cap. The index growth delta * 1e36 / totalStaked never overflows for the gauges, and the 512-bit path handles ItemStaking products beyond 2^256. The mulDiv copy matches OpenZeppelin byte for byte, so slither's incorrect-exp and divide-before-multiply lines are the algorithm's XOR seed and exact power-of-two factorisation, not defects. accrue keeps carry below 1e36 so remainder + carry cannot overflow.
• Boundary. The balance read uses a 50,000 gas staticcall copying 32 bytes and treats anything but success with exactly 32 bytes as invalid, so a reverting, gas-burning, huge-data, short-data, zero-reporting or max-reporting token never blocks stake or unstake. withdraw and unstake call no reward token, and their update math has no revert path. A token with no code fails the read before any transfer. Transfer helpers accept empty or true return data and revert on false or a revert, which is what the spec asks for a claim.
• Numerical Gap. The telescoping difference of cumulative floors means frequent updates lose nothing against a single update. Sum of outstanding owed never exceeds accounted, so the unchecked accounted -= amount in claim cannot underflow. The issuer-burn path pays first come first served and a later deposit must first cover the shortfall before a new stream starts, exactly as the spec states.

How I verified it. Beyond the existing 98 passing tests, I ran scratch stress tests that have since been removed: 400 seeded random sequences of 40 steps on both ItemStaking and a gauge, mixing 1 wei, random and near-1e27 amounts, waits up to 400 days, issuer burns and syncs, asserting paid plus owed never exceeds released or sent and that ITEM balance equals totalStaked. I also checked the T cap and zero rate at the end of the curve, a lone 1 wei staker with a 1e30 stream, a 1 wei stream across 1e27 stake, an index of 3e66 multiplied by a 1e27 stake, and vesting on days 364, 365 and 1460 with exact values.

Notes that are not defects, for the judge. A token whose fresh ever exceeds 1e30 is blocked from new streams permanently because payments reduce balance and accounted equally; that is the spec's rule and needs 1e12 WETH or BASK. The aderyn reentrancy lead on start() is a view call to a constant factory under nonReentrant. Missing zero checks on the item constructor argument are outside what the spec asks.

Not reached. I did not review event emission completeness or the launch manifest, which belong to other specialists.

Review complete. The findings file is written at the repository root and validated: both snippets match the tree, and all 17 entry points plus 6 invariant rows are covered.

Outcome: no exploitable economic defect found. The reward accounting in the gauges and ItemStaking holds its conservation laws on every path I traced and fuzzed. Two informational notes were recorded.

What I checked, from the Economic Security, Invariant and Flow Gap guides

• Conservation: a 400-run random-interleaving fuzz over 3 users (stake, withdraw, claim, warps up to 200 days) kept gauge payouts at or below released(), with the final full exit within 200 wei of it and the gauge's ITEM balance equal to allocation minus payouts. The same fuzz on ItemStaking, with deposits and issuer burns, kept the sum of owed at or below accounted.
• View versus write: earned() equalled what claim() paid on every fuzzed step in both contracts.
• Index monotonicity and overflow: both cumulative formulas are non-decreasing, so every delta is non-negative. Products stay far below 2^256, and the 512-bit mulDiv covers the accrue path.
• Hostile tokens: reverting, gas-burning, 64 KB, 31-byte, zero and max balance reads all yield an invalid read and never block stake or unstake. Claims revert whole on a bad read or transfer, as specified.
• Timing attacks: flash stakes earn nothing because rewards are per staked second. Partial burns leave claims first come, first served, which the brief accepts.
• Static analysis leads: the XOR in mulDiv is the standard inverse seed, the strict equality is intentional, and the state write after getPair sits behind nonReentrant. None are defects.

Informational findings recorded

1. Funding feasibility (src/BaskUsdgGauge.sol:11). Starting both gauges and funding vesting needs 740M ITEM, but the requester's wallet holds only 100M under the default 80% pool share. This is a launch-policy decision, not a code change: the pool share must be at most 16%.
2. Unsynced fees are shared with late stakers (src/ItemStaking.sol:171). Because streams start at detection and are never backdated, a holder who stakes before the next sync shares fees that accrued while others were staked. This follows the brief. Operators should call sync promptly after fees land.

The scratch probe lives under test/scratch/Probe.t.sol and is not part of the submission.

Review complete. The findings file is written at the repository root and validated.

Outcome: no exploitable defect in the Access Control, Trust Gap or Asymmetry areas. The permission model is flat: every state-changing entry point is open by design, no constructor hands out a role, and the only privileged party is the fixed DevVesting beneficiary, which is a recipient rather than a caller. Paired surfaces (stake/withdraw, stake/unstake, earned/_update, earned/_sync) mirror each other in checks and storage writes. The slither mulDiv leads are false positives, since the caret is the correct XOR seed of the OpenZeppelin Newton inverse.

What I verified beyond reading:

• The existing 98 tests pass, formatting is clean, and the build has only lint-level warnings.
• A stateful fuzz harness under test/scratch/ (64 runs by 60 calls, zero reverts) held four invariants: payouts never exceed receipts minus burns, accounted always covers everything owed, paid plus earned never exceeds released in the gauge, and token balances equal total staked.
• A targeted test confirmed the one trust-gap behavior worth noting: anyone can delay the vault's BASK fee stream by up to 7 staked days with a 1 wei deposit. Nothing is lost, and the brief's rules imply it, so it is recorded as informational.

Second informational note: with the default 80% pool seed the requester's wallet receives 100,000,000 ITEM, while the two gauges and DevVesting need 740,000,000 to be started and funded. The contracts are not broken by this, but the README should say which pool share the launch must choose.

Coverage: all 17 listed entry points have a row (16 hold, one carries the informational dust-delay note), plus four invariant rows. The one unreached item is on-chain verification of the four constant addresses on chain 4663, for which no RPC was supplied.

The review is complete and written to .imd-findings.json. The tree is otherwise unchanged: the scratch tests I used were deleted.

Outcome: no exploitable defect found in the control-flow area. I traced every state-changing entry point through the Execution Trace, Periphery and First Principles checklists and found the code matching the brief.

What I verified

• RewardMath.mulDiv and accrue are exact. A 512-bit identity fuzz (result times denominator plus remainder equals the product, overflow revert condition) passed. The slither "incorrect-exp" and "divide-before-multiply" lines are the intended Newton-inverse steps, so they are false positives.
• Gauges: index updated before every stake change, release curve monotone and exactly ALLOCATION at T, withdraw makes no reward-token call, claim follows checks-effects-interactions, payouts never exceed released. Randomized 24-step sequences with stakes, withdraws, claims and warps up to 400 days held conservation and earned() equal to the claimed amount.
• ItemStaking: every change to totalStaked syncs all three tokens first, so stream time is always measured over a constant stake. The 50,000-gas staticcall read cannot block stake or unstake, and gas-starved syncs leave either a reverted or a consistent state. Claims pay at most the balance read, and the unchecked subtraction on accounted is safe because owed never exceeds it.
• DevVesting boundaries at days 364, 365 and 1,460, and release before fund, behave as specified.
• The protected floor: compiled runtimes contain no DELEGATECALL, CALLCODE or SELFDESTRUCT and the largest is well under the size limit.

Reported

• One info-level note only: the ABIs expose read-only views beyond the brief's list (rewardInfo, T, STREAM_DURATION, MAX_FRESH, CLIFF, DURATION). Not a security defect, left for the judge on scope.

Unreached

• Whether the live BASK, USDG and WETH balanceOf calls on chain 4663 fit in the brief-mandated 50,000 gas could not be measured without a fork. If one does not, that token's claims and streams would never work, though stake and unstake still would.

The coverage record answers all 17 entry points as holds, plus five invariant and assumption rows.

Added adversarial, fuzz, and invariant tests for all five contracts, covering hostile tokens, reentrancy, rounding, timing, rollback, and conservation.

Validation with the required seed passed: 182 passed, 0 failed, 0 skipped, including 135,168 invariant handler calls. forge build also passes.

All changes are under test/. No implementation defects were confirmed.

The review is complete and .imd-findings.json is written at the repository root with 4 findings and 21 coverage rows (all 17 listed entry points plus 4 invariant rows). Snippets were verified against the source lines and the JSON parses.

Outcome: no code defects found. The full suite of 182 tests passes, and my own pass with the Pashov and entry-point checklists found nothing the specialists missed.

Findings kept, all at info level, each reproduced in test/scratch/Review.t.sol:

1. Funding gap, merged from the economics and permissions specialists. The two gauges and DevVesting pull 740M ITEM in total, but under the default 80% pool seed the requester's wallet holds 100M. The constants match the brief, so this is a launch decision for the README and manifest notes, not a code change.
2. 1 wei dust stream delays later BASK fees by up to 7 staked days. This is exactly what the brief's "later amounts wait" rule produces. An operational note only.
3. Unsynced fees are shared with a late staker who joins before the detecting sync. Also mandated by the never-backdated rule.
4. Extra read-only ABI surface beyond the brief's view list (rewardInfo, STREAM_DURATION, MAX_FRESH, T, CLIFF, DURATION). No security impact.

Leads dropped after reproduction:

• All slither and aderyn lines on RewardMath are the intended XOR and Newton steps of OpenZeppelin's mulDiv, matched line for line.
• The aderyn reentrancy line on start() is a view call under nonReentrant.
• The deployability floor holds: constructors call no contract, runtime sizes are 1.2 to 4.1 KB, and a scan mirroring the protected test finds no DELEGATECALL, CALLCODE or SELFDESTRUCT in any of the five runtimes.

Invariants I traced by hand and in scratch tests: gauge payouts bounded by released and by ALLOCATION through floor-rounded index growth with carry; ItemStaking accounted never underflows on claim, including across an issuer burn followed by partial refills; stream time freezes while totalStaked is zero and is never backdated.

The scratch directory is mine and nothing in it is kept. No file outside it and the findings file was changed.