Committed on main with a clean working tree. The staking vault and launch token are implemented, tested, and documented.

What was delivered

• src/LaunchToken.sol: fixed-supply ERC-20 "Stake Launch Token" (STK), 18 decimals, 10^27 minor units minted to the deployer, no constructor arguments, no mint, owner, pause, blocklist, fee or upgrade functions.
• src/StakingVault.sol: ownerless vault. Stakers lock their whole position for 7 days from their latest stake. Anyone can fund rewards in the token. Rewards stream per second pro rata to stake using a Synthetix-style accumulator with the rate scaled by 1e18. Rewards streamed while nothing is staked are kept and re-streamed on the next funding. A mid-period top-up must not lower the current rate, which blocks dust-funding griefing. Deposits credit the amount actually received. Every external function is non-reentrant and follows checks-effects-interactions.
• Tests: 56 in total. Unit and fuzz tests cover lock boundaries, pro-rata and per-second accrual, late joiners, funding rules, claim and exit, principal safety against non-stakers and admin-style selectors, direct transfers, and a fee-on-transfer mock. A handler-driven invariant suite over four actors checks that the vault balance always covers principal plus owed rewards plus the unstreamed remainder, that stakes sum to the total, that principal is conserved, and that claims never exceed funding.
• script/Deploy.s.sol with a config-taking deploy function that the tests call directly.
• README.md documents behaviour, assumptions, the one deployment parameter (rewardsDuration, 604800 at launch, with constructor arguments ["$token", "604800"]), and operational responsibilities.
• lib/ vendors forge-std 1.16.2 and only the OpenZeppelin 5.7.0 files the contracts import, as ordinary files with no submodules.

Verification

From a clean build with an empty environment and --offline, forge build, forge test and forge fmt --check all pass. A scratch replica of the protected floor confirmed both runtimes deploy from a CREATE2 probe without moving the supply, stay under the size limit, and contain no DELEGATECALL, CALLCODE or SELFDESTRUCT. A longer invariant campaign of 256 runs at depth 100 also passed. Slither and Mythril are not available here and were not run.

Design choices to be aware of

• Each new stake resets the 7-day lock on the whole position. Rewards themselves are never locked.
• Tokens sent to the vault by plain transfer are stranded by design, since there is no sweep role.
• The commit uses your email for the author identity because the repository had none configured.

Done. The manifest is written at launch.json and is the only file I changed.

What it declares

• Token: LaunchToken, "Stake Launch Token" / "STK", 18 decimals, matching the name and symbol set in the source file.
• One application contract: StakingVault with constructorArgs ["$token", "604800"]. The source constructor is (address token_, uint256 rewardsDuration_), and the README fixes the launch reward period at 7 days. There is no owner argument because the vault has no privileged role.
• Pool: native ETH as the paired currency, fee 3000, tickSpacing 60, the default sqrtPriceX96.
• Notes describe the constructor, the no-owner design, the staking, lock, funding and claim behaviour, and that the factory supplies the LP, MerkleDistributor and guard.

Verification

• A schema check in Node confirmed all fields, patterns, limits, unique identifiers and backward references.
• A scratch test deployed StakingVault with exactly the manifest's ABI encoding and confirmed the token wiring, the 7-day duration, the token metadata and that the constructor leaves the deployer's supply untouched.
• Offline build and full test run passed: 57 tests, 0 failures.

The untracked dotfiles shown by git are sandbox device nodes, not edits. The scratch test lives under test/scratch and is discarded before submission.

Saved .imd-findings.json with no substantiated findings and coverage for all 8 entry points.

Offline Foundry checks passed: 56 tests, including 8 invariants across 3,072 handler calls.

The protected launch harness was reviewed but not executed; deployment inputs were unavailable.

Wrote .imd-findings.json with no substantiated defects and coverage for all 8 entry points.

Existing unit/fuzz tests, all 8 invariants, and 7 additional permission checks passed. Source and configuration remained unchanged. Deployment-specific protected tests were inspected but not executed.

Recorded no substantiated defects in .imd-findings.json, with coverage for all eight entry points.

Existing and supplemental unit, fuzz, and invariant checks passed. Deployment-specific protected tests lacked required inputs and were not run. Production files remain unchanged.

The review is complete. The findings file is written at .imd-findings.json, the snippets match the tree, and the scratch tests are removed (git status is clean apart from the gitignored findings file).

Outcome: the vault's math holds up. I found two low-severity defects and no medium or higher issues in the Math Precision, Boundary and Numerical Gap areas.

Findings

• Low, rate floor rounding. The mid-period top-up check rebuilds the period total from floor-divided pieces, so a top-up of exactly the streamed amount lands one wei short and reverts with RewardRateTooLow. The README tells funders that exact amount is enough. Concrete input: stake 100 ether, fund 1000 ether, wait 3 days, fund 428571428571428571428. One wei more succeeds. The rounding only ever lowers the proposed rate, so the dangerous direction (dust slowing the stream) is still blocked. The suite misses this because its reward amount gives an exact 1e36 rate.
• Low, unbounded reward duration. The constructor rejects zero but no upper bound. A duration of 1e40 makes every funding round to a zero rate and strands the tokens permanently, since there is no sweep. A duration near 2^256 makes funding revert forever. The launch value of 604800 is safe, so this is a deployment-input hazard.

What I verified as sound

• No overflow in any product: a 1-wei sole staker across nine maximal fundings keeps the accumulator near 1e45, and a later whale's earned stays far below 2^256.
• Precision loss from per-block global checkpoints is dust: about 1e11 wei over 4,000 blocks on a 101M-token stake, and it stays in the vault.
• Zero-rounding of per-second accrual needs sub-gwei fundings against the whole supply, so it is not material.
• Period-end and lock-end comparisons are consistent at the exact boundary second.
• The solvency invariant holds because every liability term rounds down and funding totals are bounded by what the vault received.

Coverage: all 8 listed entry points have rows, plus the constructor and five invariant or boundary rows. Nothing was left unreached.

Done. The suite passes from a clean offline build with no environment variables: 88 tests across 6 suites, 0 failures. The working tree is clean apart from the findings file, which the network's own exclude list keeps out of git by design.

What I added, on top of the existing 56 tests

• test/StakingVault.edge.t.sol holds 30 adversarial unit and fuzz tests (1000 fuzz runs via inline config). They cover rate-floor rounding at the boundary, funding one second before and exactly at period end, lock resets to the second, claims and partial withdrawals not touching the lock, a full unstake freezing rewards, whole-supply and one-wei positions, fifty consecutive top-ups, stake-and-exit round trips that must never profit, a 100% fee token, event amounts under a fee token, re-entrancy through sender and recipient token hooks on every entry point, twelve admin-style selectors that must not exist, ETH rejection, and donations never being paid to anyone.
• test/StakingVault.lifecycle.invariant.t.sol is a second invariant harness with fail_on_revert on, 128 runs of depth 64. Six actors range from whales to a 500-wei account. The handler lands warps exactly on unlock times and period ends, performs full-balance operations, and makes adversarial calls that must revert. Twelve invariants check solvency, a bound on stranded dust, per-actor principal and token-balance accounting, lock enforcement, accumulator and clock monotonicity, the rate floor, and payout-equals-view. A fuzzed liveness test replays random sequences and then has everyone exit with exactly their principal.
• test/mocks/ReentrantToken.sol is a hook-calling token for the re-entrancy tests.

Findings reported in .imd-findings.json

• Low, with a proof test: a vault built with a very large rewardsDuration accepts a funding whose scaled rate truncates to zero. The tokens are pulled in, nothing is streamed or parked, and no one can ever recover them. The launch value of 7 days cannot trigger this, and the suite pins that as safe rather than asserting the stranding is correct.
• Info: a mid-period top-up of exactly the streamed amount can revert by rounding when the rate is not a whole multiple. Two extra wei always clear the floor, which the README should state.

Harness issues I caught and corrected before trusting results were a prank consumed by a view call, a funder running out of balance in a fuzz, and a liabilities view that missed rewards streamed while nobody was staked before the next checkpoint. None turned out to be contract defects.

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

Outcome: the vault is sound on every fund-safety axis. All four specialist leads reproduce and collapse into two low findings, and my own pass found nothing beyond them.

Findings kept (both low):

• Double-floor rate check in fundRewards. A mid-period top-up of exactly the streamed amount, which the README names as the minimum, reverts with RewardRateTooLow by one rate unit. A zero-amount restart mid-period with nobody staked hits the same seam. Reproduced with the exact values the audit_math specialist gave (rate 1653439153439153439153439153439153, top-up of 428571428571428571428 reverts, plus 1 wei succeeds). No funds at risk. Merged from audit_math and write_foundry_tests.
• Unbounded rewardsDuration. A duration above amount times 1e18 lets fundRewards pull tokens at a zero rate and strand them with no recovery path. A duration near 2^256 overflows periodFinish and bricks funding. The launch value of 604800 is safe, so this is a deployment-input hazard. The specialist's proof fails on current code for the stated reason and is attached. Merged from audit_math and write_foundry_tests.

Dropped or recalibrated: nothing dropped. The write_foundry_tests "info" rating on the rounding issue is raised to low to match its duplicate.

Coverage: all 8 entry points answered. Seven hold. fundRewards carries both findings. Three invariant rows added for balance backing, rate monotonicity, and principal custody.

Verification run: the full suite passes with 88 tests. Both invariant suites and the edge suite already exercise non-round rates, so the test gap the audit_math specialist described is closed by the current tree.

Note for the fix: the edge test that pins the exact-streamed-amount revert will need updating once finding 1 is resolved.