The work is complete and committed on main as 6da5643. Build, all 34 tests, and forge fmt --check pass with the pinned solc 0.8.26.

What was built

• src/TestIMD.sol: OpenZeppelin ERC20 "Test IMD" / tIMD, 18 decimals, no premint, no owner. faucet() mints 10,000 tIMD once per 24h per address and reverts with FaucetCooldown(nextAt) otherwise.
• src/TestSIMD.sol: fork of the mainnet POOL4 StakedIMD. I pulled the source from its Sourcify exact match and vendored the five solady files it compiles against. Only name and symbol changed; the owner's pause and rescue powers stay as requested.
• src/Stacker.sol: immutable, ownerless, no fee. The constructor requires sIMD.asset() == IMD and approves the vault once. credit pulls IMD from the caller, deposits with the trader as share recipient, updates all six totals, and emits Stacked. Zero trader reverts, zero amount returns 0 with no event, and all vault and token errors bubble up unchanged for try/catch integrators.
• site/: dependency-free static page using public Sepolia RPCs. It shows your stack split per project, points, tsIMD held and its IMD value, leaderboards from chunked Stacked logs, an empty projects.json, faucet and "stack to myself" tools, and explorer links. Addresses live in site/config.json.
• README.md: deployment order and constructor arguments, owner duties, after-launch checklist, assumptions, test coverage, and the build-settings rationale.

One thing worth knowing

The launch probe scans runtime bytecode linearly for forbidden opcodes. At 200 optimizer runs solc places the solady Transfer event hash in a data section, and one of its bytes reads as CALLCODE to that scanner. The mainnet vault bytecode has the same artefact. I set optimizer_runs = 10_000, which inlines the constant, and test/Deployment.t.sol reproduces the probe's size and opcode checks on every run so this cannot regress silently.

Not done, and why

• The three Sepolia addresses in the README are marked as pending the launch handoff. I cannot deploy and must not invent addresses. After the handoff, paste them into the README table and site/config.json, then pin site/ to IPFS under imd-acc-test.
• Slither and Mythril were not available here and did not run. Tests passing are not an audit; the mainnet IMD path needs an independent adversarial review.

Build and all 34 tests pass. The only change in the working tree is the new launch.json.

Result: launch.json is written as an evm_contracts manifest naming the three accepted contracts in constructor dependency order.

• TestIMD takes no constructor arguments.
• TestSIMD takes the TestIMD reference as its asset and the owner address stated in the brief, written as the static address 0x4b91078b2374c956A65F7Af0999CaE0a935E6821 so the vault owner is that wallet rather than the factory or the payer. This matches the README's deployment table from the earlier accepted work.
• Stacker takes the TestIMD and TestSIMD references, and its constructor checks that the vault's asset equals the token.

The notes field describes each contract, the owner's retained pause and rescue powers, the Stacker's ownerless and feeless design, and the absence of ETH funding or initialization calls. I checked the manifest shape locally: only the three schema keys, unique identifiers under 32 characters, string arguments, and backward-pointing contract references. No file other than launch.json was created or modified.

The review is complete. The findings file is written and validated, the scratch tests are removed, and the tree is unchanged apart from the findings file.

Outcome: the math in the three contracts is sound in its core. Share rounding directions, overflow safety, faucet boundaries, accumulator conservation and the withdraw(maxWithdraw) path all hold, the last one confirmed by a 2,000-run fuzz with donations. I found three low-severity defects, each reproduced in a Foundry scratch test with exact numbers, and no critical or high issue, so no proof files were attached.

Findings written to .imd-findings.json:

• One-wei hold-stamp grief (TestSIMD, low). The vault says a third party must not stamp a hold on someone else for free, but only the zero-amount case is excluded. A mint(1, victim) costs 1 wei of IMD, and credit(victim, 1) from any address does the same. Either one resets the victim's one-block hold, so their redeem reverts for that block. Repeated per block it is a cheap, temporary withdrawal denial. Production logic is unchanged by design, so I flagged it as a scope decision rather than a silent fix.
• Unbounded rounding loss after a donation (Stacker, low). One faucet grant sent straight to the empty vault prices one share at 0.01 tIMD. Every cashback below that reverts with ZeroShares, and a credit of 1.99e16 wei mints one share worth 1.00e16, losing 49.7 percent. The event and all totals still record the full amount, so points overstate value delivered. Nobody profits, so it is griefing and accounting drift.
• credit accepts the Stacker's own address as trader (Stacker, low). Shares are minted to the Stacker, which has no sweep and never redeems. This permanently breaks the "holds 0 sIMD" invariant the brief requires, and the invariant suite cannot catch it because its handler uses fixed trader addresses. Self-harm only, but a one-line check prevents it.

Coverage: all 21 listed entry points have a row, plus three invariant rows. Static-analysis leads were checked and rejected: the strict equalities are correct sentinel and block comparisons, the reentrancy ordering is on trusted immutables with no callback, and the "locks ether" lead is wrong because rescueETH exists.

Not reached in depth: the page's JavaScript was read for BigInt and decimals handling and looked correct, but I did not execute it. Ownership handover and permit paths were covered only as Solady defaults, since they fall outside the math area.

The review is complete. The findings file is at the repository root, excluded from git by the harness's own rule, and the tree is otherwise untouched.

What I audited. I traced Stacker.credit, every TestSIMD funnel and owner function, and the TestIMD faucet through their guards, state writes and revert paths, following the Execution Trace, Periphery and First Principles guides. For the periphery I pulled the mainnet StakedIMD exact match from Sourcify and diffed it: the fork differs only in pragma, comments, contract name and the name and symbol strings, and all five solady files plus the thirteen vendored OpenZeppelin files are byte-identical to upstream. The page's thirteen selectors and the Stacked topic match cast sig. All 34 project tests pass. Every slither and aderyn lead was checked and rejected with a reason.

Findings written to .imd-findings.json (3 findings, 26 coverage rows, 21 of them the listed entry points):

• Medium, one-block hold is third-party stampable. Any positive mint or transfer re-stamps the recipient's lastDepositBlock, so a stranger calling credit(victim, 1) for one wei of free faucet tIMD sets the victim's maxRedeem to 0 and makes their whole-position redeem revert that block. Repeated front-running keeps them locked. The code's own comment claims this grief is prevented. The logic is the mainnet vault's, so the fix is a design decision; a failing proof test is attached.
• Low, credit accepts the Stacker or the vault as trader. Only the zero address is rejected, so credit(address(stacker), 1e18) mints shares nobody can ever move and breaks the brief's required "Stacker holds 0 sIMD" invariant. The invariant handler never generates this case. Failing proof attached.
• Info, Permit2 infinite allowance. The vendored solady ERC20 gives the canonical Permit2 address an unrevocable infinite allowance over every tsIMD holder. Standard and inherited, but undocumented in the README's integrator list.

Not reached. I did not run the page in a browser or against live RPCs; its logic was reviewed by reading. No other gaps in the assigned area.

The review is complete. The findings file holds five findings and coverage rows for all 21 entry points plus four invariant rows. No source, test or configuration file in the tree was changed; the only new files are the ignored findings file and my scratch tests.

What I checked. I read the Senior Auditor's Mindset and the Access Control, Trust Gap and Asymmetry guides, mapped every entry point and the roles the constructors hand out, and traced each path with Foundry. I also fetched the verified mainnet StakedIMD source from Sourcify and diffed it: the fork differs only in pragma, title comment, name and symbol, and all five vendored solady files are identical, so the "logic unchanged" claim holds. The existing 34 tests pass.

Findings, most severe first.

• Medium, with proof. Anyone can re-stamp another holder's one-block hold for 1 wei. The vault stamps lastDepositBlock[to] on every positive mint, and the depositor picks to. So deposit(1, victim) or credit(victim, 1) from any address sets the victim's hold to the current block, and the victim's redeem in that block reverts. The in-code comment claims a third party cannot stamp a hold. The proof test fails on the current tree and passes once a third-party dust deposit either reverts or leaves the hold untouched. This logic is also on mainnet, so fixing it is a scope decision.
• Low. The renounce-while-paused guard is not mirrored on transferOwnership or completeOwnershipHandover. The owner can still leave the vault paused with no live owner, the exact state the guard exists to prevent. Owner footgun only.
• Low. credit rejects a zero trader but accepts the Stacker or the vault itself as trader. Shares minted to the Stacker are unrecoverable and break the stated "Stacker holds 0 sIMD" invariant. The loss falls on the caller.
• Info. Test gaps in this area: the invariant handler never targets the Stacker as trader, and no test covers third-party stamping, ownership transfer or handover, withdraw, mint, permit or rescueETH. My scratch tests cover these and pass where the code is correct.
• Info. Trust assumption record: the vault owner can sweep all staked IMD and freeze every exit, as the brief intends. No unprivileged amplifier exists. The Stacker's unlimited allowance cannot be spent by the owner or anyone other than the vault acting for the Stacker.

Coverage. Every listed entry point has a row. Four rows point at findings, the rest hold after tracing. I also recorded rows for the mainnet-fork diff, the deployment roles and the site's listed-project filtering, all of which hold.

The review is complete. The findings file is written and validated, every cited snippet matches the tree, all 21 entry points have coverage rows, the original 34 tests still pass, and the five scratch proof tests fail on the current code as the findings state.

Outcome: 5 findings written to .imd-findings.json (2 medium, 1 low, 2 info), 26 coverage rows, 3 with Foundry proofs that fail today.

Findings in my area (Economic Security, Invariant, Flow Gap):

1. Medium, hold-stamp griefing. The vault's one-block hold is keyed on the recipient address, not on the shares received. Anyone can reset a victim's hold with Stacker.credit(victim, 1), deposit(1, victim), mint(1, victim) or a 1-share transfer, for 1 wei plus gas per block. The victim's long-held shares then revert on redeem in that block. The contract's own comment says a third party "must not be able to stamp a hold for free"; only the zero-amount case is excluded. Proof file has three failing tests, one per route.

2. Medium, rescue-then-refund race. An asset rescue on an open vault zeroes assets while supply stays. The next 1-wei deposit mints roughly the whole existing supply again. With 1,000 IMD staked, rescued and refunded, the 1-wei depositor ends up able to withdraw 500 IMD and the original staker loses half. The documented hatch and the README checklist never require pausing first. The proof is written to pass under a fix that forces the asset rescue to happen paused.

3. Low, shares stranded in the Stacker. credit(address(stacker), x) succeeds and parks the sIMD in a contract with no way to move it, breaking the documented "holds 0 sIMD" invariant. Self-inflicted, but permanent and a one-line guard.

4. Info, brick-guard gap. The renounce-while-paused guard does not cover ownership transfer or handover completion, so a paused vault can be handed to a dead address. Owner-only, reported as a trust assumption.

5. Info, test coverage. The invariant handler rolls the block before every redeem and no test deposits for a third party, exercises rescue then deposit then refund, or credits the Stacker itself, so none of the above is reachable by the suite.

Scope notes for the judge: findings 1, 2 and 4 live in logic the brief says is forked unchanged from the mainnet vault, so each fix is a scope decision and I said so in the descriptions. I covered the ERC-4626 max/preview versus execution checks, round-trips, conservation, the Stacker's unlimited approval, fee-on-transfer and zero-share edges, and the page's points filtering; all hold. I did not run Slither or Mythril, and the page JavaScript got only a read for points integrity, not a UI review.

The findings file is in place at the repository root, excluded from git by the harness's own exclude rules as expected. The work is complete.

Recap

Delivered: four new Foundry test files under test/, building on the existing 34-test suite rather than rewriting it. The full suite is now 76 tests across 9 suites and passes on two fuzz seeds, with forge fmt --check clean on my files.

• test/StackerEdges.t.sol: the same call twice with the allowance or balance consumed to the wei, a project paying itself, one wei, maximum uint (reverts cleanly in vault math, nothing moves), a quintillion IMD, guard ordering under pause, stray IMD never spent by credit, re-entry from a hostile vault blocked by the guard, event data equal to balance delta at a non-unit price. Fuzz at 1000 runs: paused always reverts and moves nothing, short balance always reverts, the zero-share guard tracks the vault's own preview, a trader's value is within one share of what the project paid, credit-then-redeem never profits, and repeated cycles extract no dust.
• test/TestSIMDProperties.t.sol: ERC-4626 preview equals minted, conversion round trip never gains, monotonic conversions, deposit/withdraw and two-staker redeem round trips, pause flag versus every max view and every funnel, the hold's zero-amount grief guard, owner rescue and renounce consequences, two-step handover.
• test/TestIMDEdges.t.sol: exact 24h boundary, failed call leaves no trace, contract callers, many addresses, per-address independence, faucet is the only mint path.
• test/StackerInvariantExtended.t.sol: a handler funded only through the faucet (no deal), with projects whose allowance and balance run short, a self-paying project, direct vault deposits, share transfers, withdraws, donations, owner pause, rescue and renounce. Six invariants at 128 runs × 48 depth: Stacker holds nothing, totals agree from every angle, full tIMD supply conservation, vault share and asset conservation, solvency, and the pause/ownership state machine. A fixed-sequence test proves every credit outcome the handler classifies is reachable.

Findings written to .imd-findings.json:

• Low, with proof: credit(address(stacker), x) mints tsIMD to the Stacker itself and locks it forever, so any caller can break the brief's "Stacker holds 0 sIMD" invariant. The proof test fails on the current code and passes once credit rejects its own address.
• Info: a 1-wei credit re-stamps a trader's one-block hold, so their redeem can be blocked every block at near-zero cost. This is the mainnet vault's logic which the brief keeps unchanged, so it is reported for integrators and the page, with a verified reproduction.
• Info: TestSIMD matches the mainnet source exactly per Sourcify, but the mainnet artifact was compiled with solc 0.8.30, via-IR, osaka and 200 runs, so the README's "byte-for-byte" wording is accurate only at source level.

I also verified the site's hardcoded selectors and event topic against the compiled ABI and found no mismatch.

The review is done: the specialists' reports merge into four findings, and the most serious is low severity. They are written to .imd-findings.json, with a coverage row for all 21 entry points plus the "Stacker holds 0 IMD and 0 sIMD" invariant. I ran every specialist proof and my own test against the current code, and all of them failed the way their findings say. I changed no files; I deleted the scratch tests afterwards. git status refused to run because of a directory-ownership setting, so I couldn't double-check that through git.

1. Low – credit() accepts the Stacker or the vault as the trader (src/Stacker.sol:83). Five specialists reported this one cause. Calling credit(address(stacker), 1e18) mints 1e24 sIMD to the Stacker, which has no way to ever move it, so the brief's invariant breaks. Naming the vault as trader leaves shares only the owner can rescue. The caller loses only their own IMD, but the loss is permanent. The fix is to also reject address(this) and address(SIMD). My test that fails today is attached as the proof.
2. Low – anyone can block a holder's withdrawals for a block for 1 wei (src/TestSIMD.sol:122). Also reported by all five specialists, three of them at medium. A 1-wei deposit, mint, transfer or credit to someone else blocks that holder's entire withdraw/redeem for that block. An attacker can repeat it every block, paying only 1 wei plus gas each time. No funds are lost, and this is the mainnet vault's logic, which the brief says must stay unchanged. So the required fix is documentation: README lines 69–70 and the page should say this, including that every credit blocks that trader's redeem in the same block.
3. Info – owner rescue race (src/TestSIMD.sol:161). If the owner rescues the staked IMD while the vault is unpaused, a 1-wei depositor gets about half of whatever the owner later puts back. A specialist called this medium. I treat it as a trust assumption, because it needs the owner's own power and that power can already take all staked IMD. The owner checklist should say to pause before rescuing.
4. Info – the pause guard only covers renouncing (src/TestSIMD.sol:175). transferOwnership and completeOwnershipHandover still work while paused, so the owner could hand a paused vault to an unreachable address and freeze it for good. This is an owner footgun inherited from mainnet, not an exploit.

Dropped as not defects in this code:

• Rounding loss after a donation: this is how any ERC-4626 vault behaves, and the recorded IMD totals are correct.
• Permit2's infinite allowance: this is a standard default of the token library (solady) the vault is built on.
• README's "byte-for-byte" wording: a doc nit, not a defect.

launch.json matches the schema: dependencies are in order, and the brief's owner address is written as a static address.