The DEAD DROP contracts are implemented, tested and committed on main. The working tree is clean, and the ABI exports and README are in place.

What was built

• src/LaunchToken.sol: "Dead Drop" / DROP, fixed supply of 10^27 minor units minted to the deployer, plain OpenZeppelin ERC-20 with no admin functions.
• src/DeadDrop.sol: openDrop, setPrice, leave, answer, takeBack, knock, owner-only setStamp within 0.01 to 1 IMD, Ownable2Step with renounce disabled. Stamp plus tip is pulled in IMD and swapped to DROP in one exact-input swap through the PoolManager's unlock and unlockCallback. The stamp share burns to the dEaD address and the tip share is escrowed per note.
• src/interfaces/IPoolManager.sol: a minimal Uniswap v4 interface whose plain-address structs produce the same selectors as v4-core.
• docs/abi/DeadDrop.json and docs/abi/LaunchToken.json, exported from the build.
• README.md covering behavior, constructor arguments with the launch values, assumptions, operational responsibilities, an "After launch" section, and review notes.
• Dependencies vendored as plain files under lib/ with no submodules.

Verification results

The DeadDrop suite runs every test twice, once per currency ordering, so both swap directions are covered. Tests include success paths with exact balance checks, every failure path, callback access control, re-entrancy from a malicious PoolManager into all four state-changing functions, and a fuzz test that the contract's DROP balance always equals the sum of open escrows.

Things to know

• The constructor takes five addresses: $owner, $token, IMD, the PoolManager and the launch hook. It makes no external calls, which I confirmed by deploying it against code-less addresses and by passing the protected floor with the launch's own values.
• The PoolManager in tests is a local model that enforces the unlock, swap, settle and take protocol but prices swaps at a fixed rate. A mainnet fork test was not possible in the offline verifier, and the README says so.
• The swap has no price limit by design. The caller's minDropOut is the only slippage protection, and the README flags this for the independent review.
• No launch.json was written. The manifest step owns it.

Done. The manifest is written and verified, and nothing else in the tree changed.

What launch.json describes

• Token: LaunchToken, name "Dead Drop", symbol "DROP", 18 decimals, no constructor arguments. These match the accepted source.
• One application contract, DeadDrop. Its five constructor arguments, in declaration order, are the owner as $owner, the launch token as $token, then the IMD, PoolManager and launch hook addresses as lowercase hex literals. These are the values the approved workflow names, and they match the constructor in the accepted source and the exported ABI.
• Pool: paired currency IMD, fee 12500, tick spacing 60, and the one-to-one initial price exactly as the "This launch" section gives them.
• Notes: a plain-language description of the two contracts and the argument meanings, under the 4000 character limit.

Verification

• A scratch check confirmed the file uses only schema keys, unique valid contract names, string uint and address words, and lowercase addresses.
• The build succeeded and the full test suite passed.

Git status shows launch.json as the only new or changed file.

The review is complete and .imd-findings.json holds the result. The working tree is otherwise unchanged (scratch tests removed, no source edits).

Outcome. The permission model of DeadDrop holds up well. Every state-changing entry point was traced for its guard, its state writes and its failure paths, and the ABI exports match the compiled build. I found no critical, high or medium defect in the Access Control, Trust Gap or Asymmetry areas. Two low findings are recorded, each with a reproduction confirmed against the project's mock PoolManager.

Findings

• Stamp race (low). The owner's setStamp has no delay and the caller of leave or knock passes nothing that bounds the stamp. A setStamp(1e18) ordered before a pending note debits the sender 2.0 IMD instead of the quoted 1.1, and minDropOut cannot catch it because a bigger stamp yields more DROP. The extra is burned. The owner role is the brief's design, so this is a bounded trust gap; the fixes (a maxStamp argument or a delayed stamp) change the agreed interface and need a scope decision.
• Constant pool fee (low). The pool key is built from the constants fee 12500 and tick spacing 60. The launch guidance says the factory opens the pool at the network's LaunchFees fee, so if that value differs at launch time the targeted pool never exists and every leave and knock reverts forever. No funds are at risk. The needed evidence is confirmation that LaunchFees returns 12500 for this pair on chain 1 at launch.

What holds. Ownership is two-step with renounce disabled and the owner cannot reach escrow. The callback accepts only the PoolManager during the contract's own unlock, and the hook address decodes to a beforeInitialize-only permission set, so no swap callback exists. Settlement order and delta decoding match Uniswap v4 core. Escrow moves only to the note's recipient on answer or to its sender on take-back after 14 days. The token is a plain fixed-supply ERC-20. The constructor grants nothing to the factory or IMD.

Coverage. All 13 listed entry points have rows (10 hold, 3 reference finding 1), plus three invariant rows. No launch.json exists yet, which is expected at this stage. The slither and aderyn leads were checked and found benign.

The review is complete. The findings file is written at the repository root, valid JSON, with every snippet verified against the source tree, and the scratch tests are removed so no source file changed.

Outcome. The arithmetic in DeadDrop holds under all three guides. I found no critical, high or medium defect. Three conditional issues are reported, two at low severity and one as info.

What I verified in my area

• Escrow split at line 238 rounds the tip's share down and burns the dust, so the contract's DROP balance always equals the sum of open escrows. The divisor can never be zero because the stamp is bounded at 0.01 IMD or more. The product cannot overflow at any reachable IMD balance.
• BalanceDelta unpack in assembly is correct for both currency orderings, and the exact-input check catches partial fills. The price-limit constants sit one inside Uniswap v4's bounds, as the manager requires.
• Selectors and ABI. The local interface produces the same selectors as v4 for swap, unlock, sync, settle, take and unlockCallback. Both ABI exports under docs/abi are identical to the build output.
• Time and bounds. The 14-day take-back is inclusive at exactly 1,209,600 seconds. Stamp bounds are inclusive at 0.01 and 1 IMD. Note and reply lengths are 1 to 1,024 inclusive.
• Edge probes with zero swap output, a 1-wei tip, and the hook address's permission bits (beforeInitialize only) all behaved as the code intends.

Findings reported

1. Low. A stamp change landing between a sender's quote and execution changes what the sender pays, and minDropOut cannot catch it because more input raises the output. The reproduction shows a sender quoted 1.1 IMD paying 2.0 IMD with ten times the quoted burn. This is bounded and the actor is the trusted owner, so it is framed as a trust assumption with a concrete mechanism and two fix options.
2. Low. The pool key's fee and tick spacing are compile-time constants. If the factory opens the pool at a LaunchFees fee other than 12500, every leave and knock reverts permanently. No funds are at risk, but the deployment is dead. The finding states the evidence the manifest and deploy stage must supply.
3. Info. A drop price above roughly uint256 max minus the stamp makes leave fail with an arithmetic panic rather than a typed error. Only the recipient who sets it is affected.

Coverage. All 13 entry points have a row. Ten hold, five carry a finding reference, and the launch manifest is marked unreached because no launch.json exists in the tree yet. Three invariant rows record the escrow conservation, the split bounds, and the ABI parity check.

The review is complete. The findings file is written, no tracked file was changed, and all 13 entry points plus three invariants have coverage rows.

Outcome: no critical, high or medium defects in the economics, invariants or flow-gap area. The escrow conservation law holds on every path, the Uniswap v4 integration matches the real PoolManager's delta signs, settlement order and lock rules, and the hook address carries only the beforeInitialize flag so no swap callback can re-enter. Both Slither medium leads are false positives: the unused settle return is covered by v4's own unsettled-delta revert, and the write-after-write on the unlock flag is a single set/clear pair around one call.

Findings written to .imd-findings.json:

• Low, stamp race. The IMD pulled by leave and knock is the live stamp plus tip with no caller-side bound, and minDropOut only bounds DROP out. A note signed at 0.1 IMD that mines after setStamp(1e18) pulls 1 IMD from a user with an open allowance, or reverts with an exact one. Reproduced with a scratch test. Suggested fix is a caller-supplied maximum stamp parameter.
• Low, hard-coded pool key. Fee 12500 and tick spacing 60 are constants with no setter. The launch guidance says the factory opens the pool at the LaunchFees value of the day, so if that value is anything other than 12500 every leave and knock reverts forever. Reproduced against the mock. The needed evidence is confirmation of the LaunchFees value before deployment, or a scope decision to pass fee and tick spacing as constructor arguments.
• Info, recipient price guarantee. The price is enforced on IMD paid in, while the recipient is paid DROP bounded only by the sender's minDropOut. I quantified the self-sandwich and found it unprofitable against the factory's single-sided position, so this stays a documented trust assumption.

Coverage: every listed entry point is answered, with three invariant rows added. ABI exports under docs/abi match the compiled build exactly. Nothing in my area was left unreached. The scratch tests were removed after running, and the manifest step has not run yet, so launch.json was not available to inspect.

Added failure-path, fuzz, and stateful invariant tests entirely under test/.

forge build succeeds. forge test: 146 passed, 0 failed, 0 skipped.

No confirmed implementation defects found. Tests run offline; live Uniswap integration remains unverified. Coverage and limitations are documented in test/README.md.

The review is complete. Nothing further is needed from tools: the findings file is written and validated, the scratch tests are removed, and the tree is unchanged.

Result

.imd-findings.json at the repository root holds 2 low-severity findings and 19 coverage rows. All 13 listed entry points have a row, plus 6 invariant and periphery rows. No file in the tree was changed. The scratch tests I used were deleted after running.

Findings

• Low, pinned pool key with no recovery path (src/DeadDrop.sol:58). The fee, tick spacing and hook are compile-time constants, and the only two value-moving functions swap on that key. If the factory opens the pool under any other key, every leave and knock reverts forever and no setter exists. I confirmed on mainnet that the factory's LaunchFees contract currently holds 12500 in an owner-settable storage slot, so today's state matches and the failure needs a privileged change before launch. Reproduced with a v4-shaped mock: fee 10000 bricks both calls, the exact key works. Suggested fix: take fee and tick spacing as constructor arguments from the manifest's pool block.
• Low, no caller-side bound on the stamp (src/DeadDrop.sol:233). A pending leave or knock pays whatever stamp is current. If the owner's setStamp lands first, the sender pays up to 0.9 IMD more than quoted and it is burned. minDropOut does not catch this because a larger input yields more output. Reproduced: a quoted 1.1 IMD note pulled 2 IMD. Suggested fix: a maxStamp parameter.

What held under my area (Execution Trace, Periphery, First Principles)

• Exact-input delta check, BalanceDelta unpacking, sync/transfer/settle/take order and price limits match v4-core semantics.
• The callback guard, the reentrancy guards, the escrow split and the escrow conservation invariant all trace cleanly.
• Both ABI exports are byte-identical to the compiled ABI. All 164 vendored OpenZeppelin files are byte-identical to upstream v5.1.0. Runtime bytecode has no forbidden opcodes and the constructor makes no external calls.
• The existing 99 tests pass.

Not reached

I could not read an existing IMD launch pool's Initialize event to confirm tick spacing 60 and the hook directly, because every keyless RPC caps eth_getLogs at 10 to 50 blocks. No launch.json exists yet, so the manifest was not reviewed. Two site-level observations are outside the contract's scope and were not filed: a recipient can replace their key before a note lands and still collect by answering, and wallets with non-deterministic signatures would derive a different key per session.

The findings file is in place and excluded from git by the repository's own exclude list, so the tree holds no other change. The review is complete.

Outcome. The audit stands as the specialists reported it: no critical, high or medium defects. I kept three findings and dropped one, all written to .imd-findings.json with a coverage row for each of the 13 entry points plus five invariants.

Findings kept, each reproduced locally against the mock pool manager:

• Low, merged from all four specialists: leave and knock read the live stamp at execution and the caller has no bound on the IMD pulled. With a max allowance, an owner setStamp(1e18) landing before a pending note charged the sender 2.0 IMD against a quote of 1.1, and the extra was burned. Bounded at 0.99 IMD per note, owner gains nothing, and the brief fixes the function signatures, so it stays a trust assumption at low.
• Low, merged from all four specialists: the pool key is pinned to fee 12500 and tick spacing 60 with no fallback, so a factory pool opened at any other key makes every leave and knock revert forever. I confirmed on mainnet that LaunchFees currently returns a pool fee of 12500 and the factory bytecode carries both constants, so the failing state needs a privileged change before deployment. The admission step should re-check those values.
• Info, from audit_math: a drop priced above type(uint256).max - stamp makes leave revert with an arithmetic panic rather than a typed error. No value moves.

Dropped: the audit_economics note that the price is enforced in IMD rather than DROP. It reproduces but is the brief's stated design and the README documents it.

My own pass found nothing further. The v4 flow is correct: the callback is restricted to the pool manager during the contract's own unlock, the delta unpack and exact-input check match v4 semantics, and sync, transfer, settle, take run in the right order. Effects precede transfers in answer and takeBack, the constructor makes no external calls, the runtime is 7,893 bytes with no forbidden opcodes, the ABI docs equal the compiled ABIs, and the manifest is schema-valid with constructor arguments in declaration order. The shipped suite of 146 tests passes.

Implemented the frontend, static export and verified deployment manifest.

Build, typecheck, 11 unit tests and 24 browser checks pass. Delivery size is below 8 MiB. No real transactions were broadcast.

Validation evidence · Design documentation

Git is read-only, so no commit could be created. Design documentation is under docs/ because root DESIGN.md is outside the permitted write scope.

Saved five medium findings in .imd-findings.json. Website files remain unchanged.

• bug: An RPC failure followed by retry erases an unfinished reply.
• bug: An unopened wallet generates sharing text claiming its drop is open and free.
• taste: Sharing metadata has no preview image.
• taste: Decorative tracked labels compete with existing headings.
• taste: The home page uses 11–12 distinct font sizes.

Each finding includes an exact source citation, proposed change, and measured reproduction.

Build, typecheck, 11 unit tests, and 24 supplied browser checks passed. Additional Chromium and WebKit checks passed lookup, missing-wallet guidance, FAQ, brick interaction, and six routes at 320/390/1440px. Both RPCs passed deployment checks; rebuilding reproduced the submitted export exactly. Transaction tests used mocked wallets.

The visual idea is coherent: an encrypted wallet inbox presented as a concrete field kit, with a loose brick concealing its envelope.

“Archivo condensed uppercase headlines” overrides the probe’s casing preference. Actual totals labels were excluded from decorative-label findings.

The checklist below deduplicates the repeated brief. Met means implemented, including the two implemented flows with reported defects. Contract clauses were checked against the unchanged pinned source; publication and deaddrop naming remain publisher responsibilities, as permitted.