Implemented LaunchToken and Graveyard, with vendored dependencies, ABI exports, operational documentation, and adversarial tests.

Verified with Solidity 0.8.26:

• forge build passes offline.
• forge test passes: 50 results, including two stateful invariants, using the supplied seed.
• forge fmt --check and ABI consistency checks pass.

After deployment, the owner must bind WAKE once, consecrate tokens, and fund rewards. Details are in README.md. Manifest generation and independent review remain separate stages.

I wrote launch.json and changed no other file. forge build succeeds, and forge test passes all 50 tests with the required fuzz seed. Nothing here checks the manifest against the schema, so I checked it by reading it against the rules.

What it contains:

• Token: LaunchToken, named "A Funeral For Every Dead Token", symbol WAKE, 18 decimals. The name and symbol match src/LaunchToken.sol.
• Contracts: only Graveyard, which is the one application contract in the tree. Its constructor takes a single argument, the owner, so the manifest passes "$owner". It doesn't take the token address: the owner sets that once after launch with setWakeToken, as the brief asks, so there's no $token argument.
• Pool: the IMD pair token (0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7), fee 12500, tick spacing 60, and the initial price as the launch section gives it.
• Notes: a 672-character summary of the owner's steps after launch (set the token, add buriable tokens, fund rewards), burial and rewards, and flowers.

The manifest has no supply, allocation or other fields outside the schema.

I found one math issue in the Graveyard contract, and it's low severity. The results are in .imd-findings.json with a coverage row for all 10 entry points. No repository files were changed: I deleted the scratch test after running it.

Finding 1 (low): splitting dust across wallets drains the reward vault (src/Graveyard.sol:208–210)

• Cause: every burial pays floor(V / 2000), where V is the WAKE in the vault, whatever amount is buried. The only lower bound is a balance above 0, so 1 wei of a dead token earns the same reward as a whole holding.
• Reproduction: the vault holds 1,000,000 WAKE and one holder has 1,000 wei of a consecrated token. They give 1 wei each to 1,000 new wallets, and each wallet buries it and forwards the WAKE. I ran this with forge: the holder collected 393,545 WAKE, about 39.35% of the vault, for 1,000 wei plus gas. That matches the formula V·(1 − (1999/2000)^N).
• Why only low: the brief only says "balance must be above 0", and the README (lines 133–134) and docs/SECURITY.md accept Sybil and dust splitting on purpose. The fix is a decision for the requester. Options include a minimum burial amount per token, or scaling or capping the reward per token. Both change the agreed design.

What holds:

• Reward cap: the reward formula can't overflow, and it can't empty a funded vault, because below 2,000 wei the reward rounds to 0.
• buryMany: it recomputes the reward from what is left in the vault before each entry.
• Exact amounts: burials, flowers and funding each check the actual balance change, so taxed or no-op tokens are rejected.
• Boundaries:
  • an epitaph of exactly 64 bytes is accepted;
  • buryMany takes 1 to 50 entries;
  • getTombstones caps a page at 100 entries and handles a start past the end.
• LaunchToken: it is an unmodified OpenZeppelin ERC-20 with a fixed supply of 10^27.

Static-analysis leads: I checked them and none is a defect. The "strict equality" at line 203 is the intended amount == 0 check. The reentrancy-balance reports cover functions that all share the reentrancy guard and check balances exactly. There is no launch.json in the tree yet, so I didn't review a manifest.

The review is complete and written to .imd-findings.json. No files in the tree were changed; the scratch tests I used were removed.

Outcome. The permission model of Graveyard and LaunchToken holds. I found no permission bypass, escalation path, confused deputy, or asymmetric write across the seven mutators or the token. Both findings are trust assumptions inherent to the brief's design, reported at low severity with concrete reproductions so the judge can decide whether they need a requester scope decision.

Findings

• Low, setWakeToken binds any contract with code, permanently. The setter is correctly guarded, but the only value check is code presence. The owner can bind a mintable token of their own and lock it, after which the real LaunchToken can never be attached and mourners burn dead tokens for worthless rewards. The launch handoff knows $token at deploy time, so a constructor argument would remove the gap. The brief asks for the setter, so this is a scope decision, not a blocking defect.
• Low, vault extraction through per-wallet gating. No withdraw function exists, which I confirmed, but anyone can split a dead-token balance across wallets and the owner can consecrate a token it mints. On a 1,000,000 WAKE vault one burial pays 500 WAKE, 100 split wallets collect 48,782 WAKE, and 1,386 owner dust wallets collect about half the vault, including third-party donations. SECURITY.md documents this; any mitigation changes the economic rules.

Coverage. All ten listed entry points have rows: eight hold, two carry the findings above. Three extra rows record invariants I checked, including owner provenance, msg.sender-only allowance use, and the shared reentrancy guard. The slither reentrancy and strict-equality leads were traced and not promoted. The vendored OpenZeppelin subset matches standard v5 code. The existing suite of 50 tests passes.

Not reached. There is no launch.json in the tree yet, so the manifest row is marked unreached. The README's "87% to the pool, 3% to the payer" split and the 2,500 IMD opening cap come from launch facts I was not given and were not verified.

The review is complete. The findings file is written and valid, the scratch directory is removed, and the working tree holds no stray files.

Outcome. The Graveyard contract holds up well against the Economic Security, Invariant and Flow Gap checklists. I found no fund-loss, accounting or reentrancy defect, so no finding carries a proof test. The three findings I report are economic properties of the agreed design, each with a reproduction I ran on this tree in a scratch test before deleting it.

Findings written to .imd-findings.json:

• Low: amount-independent reward. Any positive balance earns 0.05% of the vault, so one wallet holding 1 wei of each of 50 consecrated tokens takes 2.47% of the vault in one buryMany call, and 1000 dust wallets take 39.35%. This matches the brief's formula and is acknowledged in the README, so I framed it as a documented trust assumption whose fix needs a scope decision. At the 2,500 IMD opening cap the attack is unprofitable on mainnet gas, which I noted.
• Low: no minimum-reward argument. A mourner who previews 500 WAKE and is front-run by 50 dust burials receives 487.65 WAKE while their full token balance is already at the dead address. The README warns about this, but an optional minReward would preserve the design.
• Info: epitaph right decided by transaction ordering. A 1-wei burial mined ahead of the genuine first mourner permanently takes the epitaph.

Coverage. All ten listed entry points have rows. Seven Graveyard and three LaunchToken entries are either holds or tied to the findings above. I also recorded rows for the conservation, never-empties and exact-burn invariants, both medium-or-higher Slither leads, which I rejected after tracing the guards, and the manifest. No launch.json exists yet in the tree. The README's constructor description matches the code and the exported ABIs match the build.

Verification run. The existing 50 tests pass, including the two stateful invariant suites. I could not run the Python ABI check since Python is absent, so I compared the ABI JSON with node instead.

Added two test files under test/ covering failure paths, boundary values, fuzz properties, and stateful custody invariants.

Validation passed:

• forge build
• forge test with the required seed: 61 passed, 0 failed
• New invariant suite: 16,384 random calls

No reproducible defects found. Only test/ files were added.

The review is complete and .imd-findings.json is written and validated. Git status shows no tracked-file changes, so only the untracked findings file and my test/scratch/ reproduction exist.

Outcome: the Graveyard and LaunchToken code holds up under the Execution Trace, Periphery and First Principles guides. No critical, high or medium defect was found. Three low-or-informational findings are recorded, each with a reproducing Foundry test in test/scratch/Leads.t.sol.

Findings

• Low, dust front-run griefing. bury always moves the caller's entire balance, and the ABI docs recommend exact approvals. A third party holding one wei of a consecrated token can transfer it to the mourner before the burial lands, and the burial reverts with insufficient allowance. A fifty-token batch fails atomically.
• Low, WAKE binding is a post-launch owner setting. The launch rules want contracts fully configured in constructors when the value is launch-known, and the token address is available as $token. Instead the owner binds any contract with code after deployment. Until then every function reverts with no recovery if the owner key is lost, and the owner can bind a non-WAKE token. The brief asked for this flow, so it is a brief-versus-launch-rule conflict for the requester to decide.
• Info, Sybil dust drain. The reward ignores the buried amount, so one holder splitting 1,000 wei across 1,000 wallets takes about 39% of the vault. The README documents this as deliberate. It is recorded with numbers, not as a code defect.

Coverage has 16 rows: all 10 listed entry points plus the exact-burn invariant, reentrancy across all mutations, vendored library integrity, ABI exports, the protected floor, and the manifest. The manifest row is unreached because no launch.json exists in the tree yet. Vendored OpenZeppelin files were diffed against upstream v5.0.2 and differ only by formatter whitespace. ABI exports are byte-identical to the compiled artifacts.

Static-analysis leads were checked and dismissed: the reentrancy-balance lines are guarded by nonReentrant and the balance deltas are the intended check, the strict equality is a counter test, and the loop calls are bounded at 50 and user-chosen.

I found no high or critical defects. All 9 specialist findings reproduced against the code; after merging duplicates they become 4 low and 1 info finding. They are in .imd-findings.json, with a coverage row for all 10 entry points plus one for the manifest.

I reproduced each finding with a scratch Foundry test (forge test, 4 tests run). I then deleted the test, so the tree is unchanged apart from the findings file.

Findings

1. Low: dust split across many wallets drains the reward vault. Four specialists reported this one cause, so it is merged here (src/Graveyard.sol:207). The reward is 1/2000 of the vault whatever amount is buried, and any balance above zero qualifies. 1,000 wallets each burying 1 wei took 393,545 WAKE, 39.35% of a 1,000,000 WAKE vault. This is what the brief's formula says and the README documents it, so fixing it is the requester's call.
2. Low: the reward token is set by the owner after launch, not in the constructor. Two reports, merged (setWakeToken, line 90). The launch rules say the address should come in as $token. The setter accepts any contract with code and then locks it, so a wrong address is permanent. Until it is called, the contract does nothing: burials, consecrate, fund, layFlowers and nextReward all revert. The brief asks for the setter, so changing it needs the requester's decision.
3. Low: a 1-wei transfer can block a burial. Integrators are told to approve each token for its full balance. If anyone sends the user 1 more wei first, the burial reverts on allowance; in buryMany the whole batch fails.
4. Low: no minimum-reward argument. After 50 burials ahead of hers, a previewed 500 WAKE reward paid 487.65 WAKE, and her tokens were burned all the same.
5. Info: the epitaph right can be front-run. Whoever's burial is mined first becomes the first mourner, so a 1-wei burial included ahead of the real first burier takes the epitaph permanently.

Rest of the review

• Static-analysis leads checked:
  • The reentrancy-balance leads are covered by nonReentrant on every function that changes state.
  • The strict-equality lead is a correct exact-transfer check.
• No other gaps on my own pass: I found nothing beyond what the specialists covered.
  • consecrate, fund, layFlowers and the three LaunchToken functions hold.
  • launch.json is valid, and its single $owner argument matches the constructor.

Frontend, static export, and verified deployment manifest are ready.

• Build/typecheck passed.
• 17 tests, 12 browser scenarios, and 16 design checks passed.
• Prospective bundle: 1.64 MB, below 8 MiB.

Validation report · Design documentation

Live reads verified; owner WAKE setup remains pending. No live transactions were sent. Files remain uncommitted because .git is read-only.