Implemented the ownerless vault with independent 1–365-day locks, exact repayments, reentrancy protection, and no early exit. Added tests, vendored dependencies, deployment script, and README.

Checks passed: forge build, all 45 tests, and forge fmt --check.

The canonical mainnet IMD address was not supplied and remains an explicit, unverified deployment parameter. No transactions were broadcast.

Created launch.json using the existing mainnet token address from IMD’s official page.

Passed schema and constructor ABI checks, offline build, all 45 tests, a second fuzz seed with 1,024 runs, protected deployment rehearsal, and formatting checks.

Only launch.json changed. Live-token compatibility was not tested.

Done. The findings file is valid JSON, the quoted snippet matches lines 93–96 of the source, and the working tree shows no tracked changes (only the required .imd-findings.json and the gitignored scratch test were added).

Result: no math, boundary, or numerical-gap defects found in SitOnHands. The contract has no division, scaling, or rounding at all, so the precision and seam failure modes in the assigned guides have nothing to attach to. Every edge I traced holds:

• Duration bounds are inclusive at 86,400 and 31,536,000 seconds. The off-by-one values on both sides revert, matching the brief's 1-day minimum and 365-day maximum.
• Time gate flips exactly at unlockTime, so a position is held for precisely the requested number of seconds.
• Arithmetic cannot overflow or underflow. The unlock time sum is bounded by the 365-day cap, and both subtractions on balance deltas are short-circuited by an explicit less-than guard. An amount one below the uint256 maximum locks and withdraws exactly.
• Accounting is only exact additions and subtractions of the transferred amount, and the strict both-side balance checks reject fee, no-op, false-return, and self-credit transfers. Reentrancy from token hooks into either entry point is blocked by the guard, and the mid-hook view state looks like a donation, so nothing observes a harmful inconsistency.
• Static-analysis leads did not reproduce: the reentrancy lines are covered by the guard, the ETH-send line has no ETH path, and the timestamp lines are the intended gate.

I recorded one informational item rather than a defect. The strict equality check that protects exactness also means that if the live IMD token ever stops transferring exact amounts (a fee switch, upgrade, blacklist, or pause by the token's own administrator), every matured withdrawal reverts and the ownerless vault has no recovery path. That actor is external and privileged, the README already documents it, and the judge should confirm the real IMD implementation's admin powers before release.

Coverage has six rows: both listed entry points, the constructor, the views, and two invariants, all marked holds except withdraw, which carries the informational reference.

The review is complete. Findings and coverage are written to .imd-findings.json. No files in src/, test/ (outside test/scratch/), or configuration were changed.

Outcome: no exploitable defect in the Access Control, Trust Gap or Asymmetry areas. Both state-changing entry points hold.

What I checked

• Access control. Only two state-changing functions exist. lock pulls tokens solely from msg.sender, so nobody can force-lock a third party or use the vault as a confused deputy for approvals. withdraw is gated on the stored depositor, maturity, and a one-shot withdrawn flag. There is no owner, pause, initializer, proxy, receive or fallback, and the constructor ignores msg.sender, so factory deployment traps no control.
• Asymmetry. The lock and withdraw writers mirror each other on all three counters (positions, lockedBalance, totalLocked). canWithdraw uses the same predicates as withdraw. The repo's invariant suite already enforces conservation.
• Trust gap. The only external privileged actor is the IMD token owner. I read the live mainnet token over RPC. It is a non-proxy LayerZero OFT with standard OpenZeppelin transfers; its owner can only set peers, name, symbol and delegate. No path lets that owner create an asymmetry against depositors.
• Static-analysis leads. All reentrancy lines are covered by nonReentrant plus checks-effects-interactions, and five existing tests assert re-entry is blocked. The aderyn ETH-send lead is a false positive. These are recorded as checked in the coverage rows.

Two informational notes were recorded, neither blocking:

1. The post-transfer exact-balance check in withdraw cannot protect the vault, since accounting is already settled, and would turn any token-side shortfall into a permanent zero payout. I reproduced this in test/scratch/StrictWithdrawCheck.t.sol, but it is not reachable against the verified live token, so it is reported as info.
2. The deploy script authenticates the token only by symbol(), which is owner-mutable on the live IMD contract, and no canonical address is pinned in the repository. The launch manifest step must carry the authenticated static address.

Live token facts I verified on mainnet: address 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, symbol "IMD", empty EIP-1967 implementation slot, owner 0x047f606fd5b2baa5f5c6c4ab8958e45cb6b054b7. Its canonical status still needs confirmation from the project's deployment record.

Sources: DropsTab IMD listing

The review is complete and the findings file is written at .imd-findings.json. The working tree shows no modified tracked files; only the ignored test/scratch/ directory and the findings file were created.

Outcome: no critical, high, or medium defects in the two entry points. Both lock and withdraw hold under the Execution Trace, Periphery, and First Principles checks. The build compiles and all 45 existing tests pass, including the fuzz and stateful invariant suites.

What I verified in depth:

• lock: zero-amount and out-of-bounds duration rejection, inclusive 1-day to 365-day bounds, pull-only-from-caller semantics so residual allowances cannot be spent by others, both-sided balance delta checks that reject fee, no-op, and false-returning tokens with full rollback, and reentrancy blocking across both entry points via token hooks.
• withdraw: depositor-only access, inclusive time gate checked at unlock minus one second and at unlock for both 1-day and 365-day locks, double-withdraw and unknown-id rejection, checks-effects-interactions ordering with the reentrancy guard, and full rollback on transfer failure so retry remains possible.
• Conservation invariant: vault balance is at least totalLocked, which equals the sum of per-depositor balances and the sum of unwithdrawn position amounts. Only lock and withdraw touch all three, in lockstep.
• No escape paths: the ABI exposes only the two mutators and views. There is no owner, pause, upgrade, sweep, receive, or fallback.
• Vendored library integrity: hashed every OpenZeppelin file against upstream v5.0.2.

Three findings, none blocking:

1. Low. The strict depositor-side balance equality in withdraw means that if the live IMD token's transfer accounting ever changes after locks exist, such as a token admin enabling a transfer tax, every pre-existing position becomes permanently unwithdrawable. There is no fallback, partial-delivery, or owner path by design. I reproduced this with a scratch test. The trigger requires third-party token-admin action, so it is a trust assumption the author should decide on consciously, not an attacker path. The proposed fix relaxes the "exact amount" guarantee, so it needs a scope decision.
2. Info. The deploy script's symbol check reverts with empty return data rather than its named error for a token whose symbol() returns bytes32, because ABI decoding failures escape try/catch. Script only, no fund impact.
3. Info. DEPENDENCIES.md states the vendored OpenZeppelin files are unmodified, but Address.sol and IERC20Permit.sol differ from upstream. The diff is whitespace and line wrapping only, with identical semantics, but a hash comparison will fail.

The coverage record has seven rows: both listed entry points plus the conservation invariant, the no-escape-path invariant, library integrity, the deploy script, and the absent launch manifest. One open deployment item remains outside the code: the live IMD address is not in the tree or in any network file, so token identity must be confirmed at the manifest step.

Review complete. The findings file is valid JSON, the quoted snippet matches lines 93 to 96 of the contract exactly, the scratch test is removed, and the working tree has no tracked changes.

Outcome. The vault is sound in my area. I found no defect at medium or above and recorded one low-severity trust assumption.

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

• Conservation. Only lock and withdraw write the coupled terms, and each updates position, per-user balance and total together. The existing stateful invariant suite passes, including donations.
• Round trip. A deposit of X returns exactly X with an exact-transfer token. There is no fee, division, loop, shared cap or queue, so no rounding farming, griefing or blocking of other depositors is possible.
• Access and privilege. No owner, pause, sweep, fallback, delegatecall or selfdestruct exists. Positions are written once and never transferred or shortened.
• Time boundary. Withdrawal succeeds at exactly the unlock timestamp and fails one second earlier, matching the brief.
• Static-analysis leads. The Slither and Aderyn reentrancy and ETH-send lines are false positives. Both entry points are guarded and no ETH moves.
• Dependency integrity. Vendored OpenZeppelin and forge-std files match their upstream tags byte for byte, or differ only by formatter whitespace. There are no submodules.

The one finding (low). The withdraw function demands the vault balance fall by exactly the amount and the depositor balance rise by exactly the amount. If the live IMD token ever applies any deduction on transfers, whether a fee, reflection, or a later upgrade, every position becomes permanently unwithdrawable with no recovery path. A scratch test reproduced this: two depositors, a 0.01% fee switched on after locking, and both withdrawals revert forever while the vault keeps the full principal. This is a design trade-off against the brief's exact-principal promise rather than a logic bug, and the README partly warns about it. The author should either verify on-chain that canonical IMD is a plain non-upgradeable ERC-20, or accept a relaxed recipient-side check so a token fee degrades to partial loss instead of total loss.

Open item, not a defect. The canonical mainnet IMD address is still unknown to the repository, so the constructor argument for the launch manifest remains an input the deployer must supply and verify.

Added boundary, failure-path, and three-actor invariant tests exclusively under test/.

Offline forge build and forge test pass: 59 tests, including 4,000 new fuzz cases and 24,576 new invariant calls.

No defect reproduced. Live IMD compatibility remains unverified because no canonical token address was supplied.

I found no defects that need fixing, so .imd-findings.json has an empty findings list. Its coverage record marks both entry points as holds, plus two checks I added: no admin path to user funds, and the launch constructor input. The full suite passes (59/59). No repository files were changed; the only file written is .imd-findings.json.

Both entry points behave as the brief asks:

• lock has a reentrancy guard and rejects a zero amount or a duration outside 1–365 days (both ends allowed). It takes only the caller's own IMD, checks that both balances moved by exactly the amount, and opens a new position each time. Position IDs are never reused.
• withdraw checks the position exists, that the caller deposited it, that it hasn't been paid out, and that block.timestamp >= unlockTime. It marks the position paid before sending back the exact amount, and a failed transfer rolls everything back so it can be retried.
• The vault has no owner, fee, pause, sweep, upgrade or other way out.

Why I dropped every specialist finding:

• Withdrawals stuck if IMD later adds a transfer fee (math, permissions, economics and flow all reported this; I treated it as one issue). It doesn't apply to the real token. I checked the IMD address in launch.json (0xD34a…63B7) on mainnet: symbol() returns "IMD", it is not a proxy, and it has no fee, pause or blacklist functions. Its owner can only change peers, name, symbol and delegate. So an exact-amount transfer can't start failing after a deposit.
• Deploy script only checks the symbol: launch.json already fixes the token address, so the symbol check doesn't decide which token the vault uses.
• Deploy script gives an unclear error for tokens whose symbol() returns bytes32: the real IMD returns a normal string, so this never happens with it.
• lib/DEPENDENCIES.md says the vendored OpenZeppelin files are unmodified, but two are reformatted: the specialist's diff shows only whitespace changes. That's a documentation note, not a contract defect.
• Static-analysis warnings: the reentrancy warnings are covered by the reentrancy guards and the fixed, trusted token. The "ETH sent without address check" warning is wrong, because the contract never sends ETH. The timestamp warnings are just the intended unlock-time check.