Everything is committed on main and verified. Nothing else is pending.

Outcome. The Heirloom deliverable is complete and committed as one commit on main. All three acceptance commands pass offline with an empty environment, matching how the verifier runs.

What was built.

• src/HeirloomVault.sol implements all nine rules: one vault per address, beneficiary and period limits, deposit, check-in, withdraw at any time before a claim, setting changes that count as check-ins, claim strictly after the deadline, close, a full view including the exact claimable timestamp, and events for every action. Sends happen last behind a reentrancy guard, and direct ETH transfers are rejected.
• src/LaunchToken.sol is the required fixed-supply ERC-20 with no constructor arguments and no admin paths, matching the protected token test.
• script/Deploy.s.sol exposes plain deploy functions the tests call directly. It reads no environment variables.
• Tests cover every success and failure path, fuzz period limits and withdraw amounts, prove any check-in pushes the deadline forward, that nobody but the beneficiary can claim and never before the deadline, that the owner can always withdraw before a claim, reentrancy through claim and withdraw, and an invariant suite asserting the contract balance always equals the sum of vault balances.
• web/ is a static site with the Sepolia banner, "My vault" with the period presets and live countdown, "I'm a beneficiary" built from events with Claim enabled only at zero, and a plain-English "How it works". It uses a vendored ethers build, so no network fetch is needed. Its read and event logic was exercised end to end against a local anvil chain from a scratch script.
• README.md documents design assumptions, deployment parameters, website setup and the operational responsibilities of owners, beneficiaries and hosts.

Two things to know.

• The contract is not deployed. This task does not authorize transactions, so web/config.js holds a placeholder address and deploy block. Fill both in after running the deploy script, as the README describes.
• Three linter warnings are excluded in foundry.toml, each with its reason. The reentrancy one is a false positive on the guarded send, which the reentrancy tests exercise directly.

Added failure-path, reentrancy, payout rollback, fuzz, and independent accounting invariant tests covering 24,576 random calls.

Offline forge build and forge test passed: 87 tests, zero failures.

Reported one low-severity limitation in .imd-findings.json: forced ETH breaks the promised exact balance equality. The report includes the reproduced failing test; no loss of deposited funds was demonstrated.

Created launch.json matching LaunchToken and HeirloomVault.

• Schema, metadata, and constructor checks passed.
• forge build passed.
• forge test: 87 passed, 0 failed.

Only launch.json changed outside the permitted scratch directory.

Review complete. The findings file is written at .imd-findings.json, no source or test file was changed, and the scratch tests were removed.

Result: no math defect in HeirloomVault. The contract has no division, no scaling, no casts, no unchecked blocks and no fixed-point math. Its only arithmetic is a checked add on deposit, a guarded subtract on withdraw, and lastCheckIn + period + 1 for the deadline. I verified each against the three assigned guides:

• Math Precision: nothing to round or truncate. Overflow is impossible with period capped at 3650 days; I confirmed the deadline sum is exact even at a uint64-max timestamp.
• Boundary: the strict deadline is correct on both sides for every period in range (fuzzed). Claim at exactly lastCheckIn + period reverts and one second later succeeds. An owner check-in in the deadline second wins. Zero-amount deposit and withdraw revert. The zero-address sentinel for "no vault" cannot be corrupted because both setters reject the zero beneficiary. Payable entry points all revert or account correctly.
• Numerical Gap: the zero-balance fast paths in claim and closeVault skip the send but still clear state, so the invariant survives them. The website's countdown, period presets and wei formatting use BigInt correctly.

Two low findings reported, both at the seam between the payout boundary and the stated invariant:

1. Non-receiving beneficiary locks funds forever. A beneficiary contract with no payable fallback makes every claim revert with TransferFailed, and once the owner is gone nobody can recover the ETH. The push-only design is per spec, so the disposition is a judge call. I described a pull or redirect option that keeps "only the beneficiary can claim".
2. Forced ETH breaks the "balance always equals sum of vaults" claim. Selfdestruct, pre-funding the published CREATE2 address, or coinbase rewards bypass the reverting receive function and leave unsweepable dust. No deposits are at risk. This was already noted in an earlier round and is included only because it is the contract's one stated arithmetic invariant.

Both findings carry a concrete call sequence that I ran and observed on this code. Neither is high or critical, so no proof test file is attached. The existing suite of 92 tests passes offline.

The findings file is in place and the harness excludes it from git on purpose. The scratch directory is removed and the working tree has no other changes.

Result: no critical, high, or medium findings. The HeirloomVault contract holds up under the Economic Security, Invariant, and Flow Gap guides. Five findings are recorded in .imd-findings.json, four low and one informational.

What I covered

• Economic Security: every ETH-sending path, push-payment failure modes, griefing costs, front-running between owner and heir, and the timestamp boundary. No oracle, token, or ERC surfaces exist to attack.
• Invariant: the balance-equals-liabilities law, the beneficiary-as-existence-flag coupling, view-versus-write agreement between isClaimable and claim, round-trips at 1 wei, and timer resets on every secondary path. All hold except against forced ETH.
• Flow Gap: reentry into the unguarded functions from each payout callback, close-then-reopen inside a callback, claim on an empty vault, and period shortening after the deadline. All end in consistent state that matches the brief.
• Ran the full existing suite, which passes, and three scratch probes, since deleted.

Findings written

• Low, contract: the vault contract's own address passes beneficiary validation. Such a vault can never be claimed by anyone, so funds are locked permanently once the owner is gone. One-line fix in the validator.
• Low, contract: forced ETH via selfdestruct or a pre-funded CREATE2 address breaks the "balance equals sum of vaults" invariant and the surplus is stuck forever. No depositor loses funds. The invariant should be restated as greater-or-equal.
• Low, website: the ?vault= query override lets a link on the real domain route deposits to an attacker's contract.
• Low, website: anyone can open unlimited empty vaults naming a victim, burying or breaking the beneficiary list, which loads every candidate in one parallel batch.
• Info, design: push-only payout means a beneficiary contract that cannot receive ETH locks the vault after the owner is gone. Recorded as a trust assumption with a website-side mitigation.

None of the findings reach the severity that requires a Foundry proof file, so none carry one. The slither arbitrary-send lead was traced and rejected: ETH only ever goes to msg.sender or the owner-chosen beneficiary after state is cleared and behind the guard.

Wrote two reproduced findings to .imd-findings.json:

• Medium: Crafted URLs can redirect deposits.
• Low: Beneficiary claim controls retain stale deadlines.

Covered vault control flow, callbacks, helpers, and website integration. All 87 Foundry tests passed. No project source files changed.

Saved one medium finding in .imd-findings.json: a crafted URL can redirect deposits to an attacker’s contract.

Reviewed authorization, payout callbacks, state transitions, and frontend trust boundaries. All 87 Foundry tests passed; no Solidity permission bypass was substantiated.

The frontend redirect was reproduced offline. Live Sepolia and the protected deployment harness were not executed.

Wrote four reproduced, deduplicated findings—1 medium and 3 low—to .imd-findings.json.

The Foundry suite and all eight protected checks passed. Project source and configuration remain unchanged.

Addressed all five reproduced findings: removed URL overrides, refreshed claim eligibility, bounded discovery with recovery paths, and corrected forced-ETH documentation and tests. Vault executable logic is unchanged.

Validation passed: forge build, forge test (76 tests), forge fmt --check, and 12 browser regression tests.

Recorded every verdict in .imd-responses.json.

Added two regression tests covering rejected actions on expired/absent vaults and withdrawal boundaries after expiry. Updated stale test documentation.

Verified offline:

• forge build passed.
• forge test passed: 91 tests, 0 failures, including random-sequence invariants.

Changes are confined to test/. The existing forced-ETH limitation remains documented.

Updated only launch.json, clarifying forced ETH behavior while preserving deployment fields.

Validation passed: schema/refinements, token metadata, constructor ABIs, forge build, and all 99 tests, including both protected suites.

Both prior findings are confirmed fixed:

• Crafted URLs cannot override the configured vault.
• Beneficiary controls refresh and revalidate eligibility before claims.

All 91 Foundry tests and 12 browser regression tests passed. No remaining defects were substantiated.

Wrote {"findings":[]} to .imd-findings.json. Source files are unchanged. Validation was local; no live Sepolia deployment was checked.

Wrote .imd-findings.json.

• Beneficiary payout: low-severity advisory remains; reproduced the failed claim and confirmed recovery requires the absent owner.
• Forced ETH: advisory resolved through corrected documentation and regression coverage; surplus remains unrecoverable.

77 vault tests passed. No source or configuration files changed.

Wrote .imd-findings.json with one remaining low-severity finding.

• Unresolved: vault address accepted as beneficiary; reproduced locally.
• Resolved: forced-ETH documentation/tests, URL override, and empty-vault discovery flooding.
• Unchanged design assumption: beneficiaries must accept ETH payouts.

All 91 repository Foundry tests and 12 browser tests passed. No implementation files changed.

The prior finding is settled as fixed, and I recorded one new low-severity item about the website test suite.

Prior medium finding (attacker-controlled ?vault= override): fixed. The website now takes the contract address only from the published config in web/config.js. No code path reads the query string, hash, or browser storage. The author added a regression test that loads the page with a crafted ?vault= pointing at a fake vault and submits a deposit. I ran it and the transaction targets the configured vault, the attacker receives nothing, and the real vault credits the deposit.

New low finding: the website test suite is flaky. Roughly one run in four fails, in a different test each time, including the override regression test. Every failure is the deposit in the shared setup helper running out of gas. The gas estimate is taken in the same second as the preceding openVault, so the contract's write of the last check-in timestamp looks like a same-value store. When the block is mined one second later the store costs 2800 gas more, and the harness signer sends the exact estimate with no buffer. I confirmed this deterministically against anvil by forcing the next block timestamp forward. The fix is to pass an explicit gas limit in the setup helper, as the author already does for other calls. This does not affect the deployed site, which relies on the wallet's padded estimate.

Other checks. All 91 Foundry tests pass. The Slither leads (arbitrary ETH send in the private send helper, timestamp comparisons) are the intended owner and beneficiary payouts and deadline logic, not defects. Findings are written to .imd-findings.json. No repository files were changed and no scratch files remain.

All four findings from last round are fixed. I found one new low-severity problem, which is in the website tests, not the product. It's written to .imd-findings.json, and no repository files were changed.

Earlier findings

• [medium] A crafted ?vault= URL could redirect deposits — fixed. web/app.js:11 now takes the contract address only from HEIRLOOM_CONFIG.address, and there is no URL override anywhere. The author's regression test (test/web/app.test.cjs:52) passes: the deposit goes to the real vault and the attacker's balance doesn't change.
• [low] Claim buttons kept outdated deadlines — fixed. The page now re-reads vault state every 30 seconds. "Claimable" is decided from the chain's block time, not the device clock, and results older than 30 seconds disable the button. Before sending a claim, the page re-reads the vault and refreshes it afterwards whether the claim succeeded or failed. The tests for both earlier cases pass: an owner check-in elsewhere and an owner shortening the period elsewhere.
• [low] Spam empty vaults could hide funded ones — fixed. At most 4 vaults are read at a time, each failed read is retried once, and results that loaded are kept when others fail. A loading error is now shown differently from "no vaults". Funded vaults are listed first, empty ones are hidden unless you ask for them, pages hold 20 rows, and you can look up an owner directly. The test with 257 vaults and a limit of 32 simultaneous requests passes, and the page never has more than 8 requests in flight.
• [low] The "balance always equals the sum of vaults" claim ignored forced ETH — fixed. The README and contract comments now say the contract always holds at least what it owes, and exactly that amount only when no ETH has been forced in. They also say forced surplus can never be recovered. The new HeirloomVaultForcedEther.t.sol reproduces the 1-wei case and fuzzes it. The full Foundry suite passes (91 tests).

New finding

• [low] The website tests fail intermittently (test/web/app.test.cjs:42). I ran the suite 12 times and 7 runs had one failing test, a different one each time. In the 4 failures where I captured the full error, the cause was the same: the shared setup's deposit() ran out of gas at 53,840. The gas limit is estimated while the chain time still equals the openVault block's time. At that moment the check-in write stores the value already there and is priced cheaply. The deposit is then mined a second later, the write costs more, and it runs out of gas. I confirmed this on a separate local Anvil chain: the estimate was 53,840, and a deposit mined in the next block with that limit reverted using all 53,840 gas.
  • Effect: any of the 12 tests offered as proof of this round's website fixes can fail randomly before reaching its checks.
  • Not affected: the contract and real wallets.
  • Fix: give that deposit an explicit gas limit, as the file already does for checkIn and setPeriod.