Approved workflow

The deliverable is committed and the working tree is clean. Everything below is in commit edfcef8.

What was built

• src/LaunchToken.sol: the standard launch token. Plain OpenZeppelin ERC-20 named Vault Stake with symbol VSTK, 18 decimals, 10^27 minor units minted once to the deployer, no mint, owner, pause, fee or upgrade path. The brief asked nothing more of the token, so nothing was left out.
• src/StakingVault.sol: the staking vault from the approved workflow. Principal is locked 7 days after every stake, anyone can fund rewards, and rewards stream per second pro rata to stake using Synthetix-style accounting. It has no owner, pause or upgrade path. Two refinements keep every funded token reachable: rewards streamed while nothing is staked, and the rounding remainder of each funding, are parked and folded into the next funding rather than stranded.
• Constructor is (address token, uint256 rewardsDuration, uint256 minimumFunding), all immutable, with the first argument meant for $token in the manifest. There is no owner parameter, so $owner is unused.
• script/DeployStakingVault.s.sol reproduces the factory order on a developer chain. Its run() reads optional environment values and hands a config struct to functions the tests call directly.
• ABI exports in docs/abi/LaunchToken.json and docs/abi/StakingVault.json. README, docs/DEPLOYMENT.md and docs/SECURITY.md cover assumptions, recommended constructor values, operator duties and the eth-security checklist results.
• forge-std 1.16.2 and openzeppelin-contracts 5.7.0 are vendored as plain files under lib/, with no submodules.

Verification

• 59 tests pass: unit tests for success and failure paths, a 512-run fuzz test for conservation of funds, and an invariant suite with a handler driving random stakes, unstakes, claims, fundings and time jumps. Reentrancy is tested with a callback token against unstake, claim and exit. A fee-on-transfer mock proves the exact-delivery guard.
• Both protected floor suites passed when run from scratch against the real creation code with a simulated factory and CREATE2-predicted addresses.
• The verifier-style run passed: clean build, then build, test and format check all offline with an empty environment. The build is free of warnings.

Deployment choices left open for the manifest and review

• Reward period length. I recommend 30 days (2592000 seconds); anything from 7 to 90 days works unchanged.
• Minimum funding. I recommend 1,000 tokens (10^21 minor units) as a dust guard; zero is allowed.
• A top-up re-locks the whole balance for 7 days. This is documented as a design decision, and the website should show the unlock time before a top-up.
• Slither and Mythril are not available here and were not run; explorer verification belongs to the network's deployer after launch.

Created launch.json matching the accepted token, vault constructor defaults, and native ETH pool.

Schema, constructor ABI, and dependency checks passed. forge build succeeded; forge test passed all 59 tests.

Only launch.json is included in the deliverable.

Review complete. The findings file is written at .imd-findings.json with 3 findings and 13 coverage rows, all snippets verified against the tree, and the working tree is unchanged (scratch tests live under the gitignored test/scratch/).

Outcome: the vault's math is sound. Within my area (Math Precision, Boundary, Numerical Gap) I found no defect that loses principal or lets rewards exceed funding. The three findings are low and informational.

Findings

• Low, stranded truncation dust at src/StakingVault.sol:208. Every global accumulator update discards up to totalStaked / 1e18 wei, which is neither parked in unallocatedRewards nor ever claimable. That contradicts the NatSpec and README claim that every funded token is reachable, and the SECURITY.md bound of "under one wei per staker per update". Measured: with 300M staked and 2,000 updates, about 4.6e11 wei stuck per period. With minimumFunding zero and a 5 wei/s rate, per-second pokes lose the whole stream.
• Low, unbounded rewardsDuration_ at src/StakingVault.sol:123. Only zero is rejected. Any value above the achievable funding total makes fundRewards revert with RewardRateZero forever, giving an immutable vault that can accept and lock stakes but never pay. The manifest value must be checked as exactly 2592000.
• Info, sole-occupant boundary. A 1-wei staker takes 100% of an active stream. Consistent with the brief's pro-rata rule and overflow-safe, but a footgun for funders who fund an empty vault.

Verified as holding: payout bound under integer rounding, overflow headroom in every formula, leftover roll-over at both sides of periodFinish, external call boundaries, and the ABI exports, which match the fresh build exactly. The Slither lines on fundRewards are false positives, as explained in the coverage row.

Not reached: nothing in the listed entry points. Economics and access-control passes were left to the other specialists, except where my boundary checks overlapped.

The review is complete: I found no critical, high or medium defects, and two low-severity ones, both in src/StakingVault.sol. The findings and coverage record are in .imd-findings.json; no tracked file was changed.

Findings

1. Low — fundRewards lets any caller defer rewards already scheduled (src/StakingVault.sol:179). A funding made mid-period re-spreads the unstreamed leftover over a full new rewardsDuration, lowering the rate for every staker.

   • With minimumFunding = 0, which the constructor accepts and docs/DEPLOYMENT.md endorses: 720 hourly fundRewards(1) calls leave a sole staker with 18,971,285 of 30,000,000 tokens after 30 days, and the period end is again 30 days away.
   • With the recommended 1,000-token minimum: 30 daily calls costing 30,000 tokens leave 19,161,004 of 30,030,000 paid.
   • docs/SECURITY.md already lists this as a residual risk. I reported it because the code comment says the minimum "stops" the stretching when it only prices it, and a zero minimum removes the price.
   • Either fix I suggest changes pacing rules, so it is the author's scope decision.

2. Low — the constructor accepts values under which fundRewards can never succeed (src/StakingVault.sol:122). A rewardsDuration_ above 10^27 makes every funding revert RewardRateZero; a minimumFunding_ above 10^27 makes every funding revert FundingBelowMinimum. There is no admin to correct either, though principal stays withdrawable. This finding carries a proof test, which I confirmed fails on the current code for both inputs.

Coverage

• Entry points: all eight have a row. Six hold; fundRewards carries finding 1. I added a row for the constructor, which carries finding 2.
• Execution Trace: conservation in fundRewards, checkpoint ordering in stake, unstake, claim and exit, lock boundaries and atomic reverts all hold. I ruled out an overflow that could brick unstake.
• Periphery: the vendored OpenZeppelin files used by src/ match upstream v5.7.0 apart from import order, a header comment and one file name. docs/abi/*.json match the compiled ABIs.
• First Principles: the vault balance always covers totalStaked + rewardReserve(). Rewards streamed while nothing is staked stay reachable, but only through a later funding of at least minimumFunding, as documented.

Verification

• The existing suite passes: 59 tests, including the invariants with 0 reverts.
• The numbers in both findings come from scratch tests I ran and then deleted.

Not done

• No launch.json exists in the tree yet, so the actual constructor arguments are unreviewed.
• Slither and Aderyn were not run by me. Each supplied line was checked against the code and none is a defect on its own; the two fundRewards leads touch the same lines as finding 1.
• The website is not in this repository.
• Two things I left out of the findings as too minor:
  • exit() reverts ZeroAmount for a caller with zero stake even when rewards are pending; claim() still pays them.
  • docs/DEPLOYMENT.md gives the runtime size as about 7.9 KB; it is 3,954 bytes.

The review record is corrected in place. The flagged finding's snippet was already an exact copy of the source, but its line pointed at the last line of the quoted block instead of the first, so the citation did not anchor.

What I changed in .imd-findings.json:

• Finding 1 (open fundRewards lets a majority staker re-pace a third party's stream) now anchors at src/StakingVault.sol:178, the first line of its quoted block. The snippet, description, reproduction and proof are unchanged.
• Finding 2 (unbounded constructor parameters) now anchors at line 121, the first line of its quoted constructor, for the same reason.

Both snippets were verified to match the tree exactly starting at their new line numbers. Nothing else in the record moved. All 8 verifier entry points still have coverage rows, plus the constructor, three invariants, the ABI exports and the absent manifest.

I re-ran the proof for finding 1 before keeping it. It still fails on the current code for the stated reason:

[FAIL: top-ups by another staker withheld alice's share: 20235139136536516694000 < 29999999999999997408000]

No other file was changed. The git working tree shows only the pre-existing untracked review record and scratch tests.

Everything is in place: the three snippets match the tree, no tracked file was modified, and the only artifacts are the ignored findings file and the scratch proof.

Review result

The findings are written to .imd-findings.json with coverage rows for all eight entry points plus seven invariant and economics rows.

Finding 1, medium, with proof. Any funder can slow the active reward stream for every staker. fundRewards re-spreads the unstreamed leftover plus the new amount over a fresh period and overwrites the rate downward whenever the top-up is smaller than the running stream. Measured in Foundry:

In the second case the attacker ends with 965,081 reward tokens against an honest share of 900,000, so the griefing is profitable, not merely a nuisance as the security notes claim. The proof file at test/scratch/StretchGrief.t.sol fails on the current code and passes against a scratch patch that never lets a funding lower the rate during an active period, with conservation invariants intact.

Findings 2 and 3, info. The rewardForDuration view keeps reporting the finished period's total after the period ends while the APR view returns zero. The exit function reverts for an account that has rewards but no stake left, although claim still works.

What held. The launch token is a plain OpenZeppelin ERC-20 matching the floor. Principal is always covered, rewards paid never exceed rewards funded, rounding dust is bounded by one wei per 1e18 staked per update, lock resets are self-only, flash-loan staking earns nothing, and both exported ABIs match the compiled contracts. The Slither lines on fundRewards are false positives on their own terms, but that function carries the real defect.

Not reached. No manifest exists yet, so constructor values could only be checked against the documented recommendations. A zero minimumFunding must not be used until finding 1 is fixed.

Added failure-path and fuzz tests plus stateful invariants covering 256 × 64 random calls.

Offline forge build and forge test pass: 82 passed, 0 failed, 0 skipped.

Reported one low-severity defect with a reproduced failing proof in .imd-findings.json: reward rounding can permanently strand 3 token wei.

Saved .imd-findings.json with two reproduced, deduplicated findings:

• Medium: Repeated top-ups can profitably divert delayed rewards from departing stakers.
• Low: Reward rounding permanently strands funded dust.

Coverage: 8/8 entry points. All 82 existing tests passed; both retained regression proofs failed as expected. Scratch files removed.

Reproduced and fixed both findings:

• Active-period top-ups now reject emission-rate reductions.
• Rounding dust becomes recyclable after the final withdrawal, while preserving unpaid rewards.

Updated regression tests, ABI, operational documentation, and .imd-responses.json.

Validation passed: forge build, forge test (69 passed), and forge fmt --check.

Updated launch.json notes to describe the active-period reward-rate restriction. Deployment values remain unchanged.

Schema and constructor ABI checks passed. forge build succeeded; forge test passed all 68 tests.

Only launch.json changed.

Updated test/StakingVaultStateful.t.sol to handle expected rate-decrease reverts and correctly exercise missing-approval failures. Added two regression tests while preserving strict invariant checks.

Offline forge build and forge test pass: 93 passed, 0 failed. The strict invariant suite completed 16,384 calls without unexpected reverts.

Both prior findings are confirmed fixed. No defects retained.

Wrote .imd-findings.json with empty findings and 8/8 entry-point coverage. All 93 repository tests and both regression reproductions pass. ABI exports and manifest arguments match the reviewed code.

Implemented the frontend and static export, including staking, rewards, funding, swaps, and runtime deployment verification.

Passed build, typecheck, 10 unit tests, 15 browser scenarios, ABI/asset hash checks, and live RPC reads. No transactions were broadcast.

Documentation: validation and design.

Commit creation was blocked because .git is read-only. All deliverables remain ready in the permitted workspace paths.