Committed. The vendored library is tracked as 30 regular files, with no submodule entries.

Delivered a Foundry project implementing the brief, committed as ca31a9b.

• src/OneEthCap.sol: accepts ETH through receive() or deposit(), keeps a lifetime totalAccepted counter, and reverts any deposit that would push it past exactly 1 ether. Zero-value deposits and any call with unknown calldata revert. No NFT or ERC-777 receiver hooks exist, so those transfers fail at the token. A permissionless sweep() pushes the balance to an immutable beneficiary, with state updated before the external call.
• src/LaunchToken.sol: the required fixed-supply ERC-20, name OneEthCap, symbol ONECAP, 10^27 units minted to the deployer, no admin surface.
• Tests: 33 tests pass, covering exact cap, cumulative cap, crossing the cap, one wei past full, lifetime behavior after sweep, unknown calldata, ERC-721/1155/777 hooks, rejecting beneficiary, reentrancy during sweep, forced ETH via selfdestruct, two fuzz tests, and an invariant suite checking the cap and conservation of funds. No test reads environment variables.
• Verification: forge build, forge test, and forge fmt --check pass with the pinned solc 0.8.26, including from an empty environment. I also ran both protected floor tests from scratch against the real creation code, and all 8 passed.
• README documents assumptions, the single deployment parameter (beneficiary, to be filled with $owner), operational responsibilities, and what the cap cannot cover.

Two design decisions to flag. The cap is interpreted as a lifetime total rather than a balance cap, so sweeping does not reopen room. The brief did not name a recipient for accepted ETH, so I added an immutable beneficiary with a permissionless sweep rather than locking funds forever. Forced ETH and plain ERC-20 transfers cannot be refused by any contract. The README states this and the independent adversarial review remains an open item.

Review complete. The findings file is written and the scratch test directory is removed, so the tree holds no source changes.

Result: no defect in the assigned area. The math, boundary and numerical-gap guides were applied to every line of src/OneEthCap.sol and the token, and nothing fails.

• Math Precision: the cap contract has no division, multiplication, scaling, narrowing cast or unchecked block. The two subtractions CAP - totalAccepted cannot underflow because the only write to totalAccepted enforces totalAccepted <= CAP. The totalSwept accumulator cannot overflow in practice, confirmed with a forced balance of 2^128 - 1. The token's two unchecked blocks are each guarded by the check immediately before them.
• Boundary: short calldata, unknown selectors, hook selectors and view calls with value all revert without accepting ETH. A deposit of exactly the remaining room is accepted and one wei more is refused with the exact CapExceeded(room, requested) values, including at type(uint128).max. A beneficiary that deposits and re-sweeps during the callback leaves balance + totalSwept == totalAccepted exact.
• Numerical Gap: the cap check and remaining() read the same storage value at the same scale, and the zero-value path reverts instead of skipping state, so no seam exists.
• Static-analysis leads: the slither strict-equality line on sweep() is a false lead since balance == 0 is the correct emptiness test. The aderyn unchecked-address line is covered by the constructor's zero check.

One info entry records the deployment-input trust assumption: the beneficiary is immutable and push-only, so if the policy's $owner resolves to a contract that cannot receive ETH, every sweep reverts and deposits are locked forever. This is documented in the README and tested, so it is flagged for the manifest review rather than as a code defect.

Coverage: all seven listed entry points have rows, six holds and sweep() pointing at the info entry, plus three invariant rows. Build, the 33 existing tests and 8 scratch edge tests all pass offline.

Saved .imd-findings.json.

No substantiated permission defects. All seven entry points reviewed; 33 Foundry tests passed. Deployment beneficiary verification remains open because no manifest was supplied.

The findings file is in place and ignored by git as intended, the scratch test is removed, and the tree is otherwise clean. Review complete.

Outcome: .imd-findings.json holds 2 findings and 10 coverage rows covering all 7 listed entry points plus 3 invariants. No source file was changed. The existing suite passes offline (33 tests, including 3 invariants at 64 runs x depth 32).

Findings

• Low, receive() at src/OneEthCap.sol:54. The accept path does a cold storage read, a storage write and an event, so it cannot run inside the 2300-gas stipend. A contract that pushes ETH with transfer() reverts and one using send() gets false, even with room under the cap. No ETH is lost and the cap is not weakened, but the README's "plain transfer" wording promises a path that fails for that class of senders. Confirmed with a scratch test in both cold and warm storage states.
• Info, trust assumption at src/OneEthCap.sol:79. sweep() is a push to an immutable beneficiary with no pull or fallback path. If the policy $owner address cannot receive ETH, every deposit is locked forever. Reachable only through deployment configuration, already documented and tested by the author, so recorded for the judge and manifest reviewer rather than as a defect.

What holds (traced, not just read)

• The lifetime cap has exactly one incrementing path, guarded in _accept(). Value sent to any non-payable selector or unknown calldata is refused, so nothing bypasses the counter except forced ETH, which is documented.
• Conservation balance + totalSwept == totalAccepted survives reentrant sweep, a beneficiary that re-deposits and re-sweeps mid-callback, and a reverting beneficiary.
• The slither strict-equality and aderyn unchecked-address leads are benign: the equality is an emptiness check and the beneficiary is non-zero by constructor.
• No depositor claim exists, so there is no round-trip, sandwich, or griefing path that extracts value. Filling the cap costs the full 1 ETH and only enriches the beneficiary.

Not reached: nothing within the assigned area. The LaunchToken rows were traced briefly as out-of-area and hold.

Wrote .imd-findings.json with no substantiated defects and coverage for all seven entry points.

Validation: 33 project tests and eight protected checks passed. Protected checks used synthetic deployment inputs. Source and configuration files remain unchanged.

Created launch.json matching the accepted contracts: LaunchToken metadata, OneEthCap with $owner, and the native ETH pool.

Schema and constructor ABI checks passed. forge build succeeded; forge test passed all 33 tests. Only launch.json is changed.

Added failure-path, boundary, callback rollback, and fuzz tests, plus stronger ETH and token invariants.

Offline verification passed: 53 tests, 0 failures. Both invariant suites completed 256 sequences of 64 calls.

Only test/ files changed. No reproducible implementation defects found.

Review complete. The findings file is written, every snippet and line checks out against the tree, and the scratch tests are removed so the working tree is clean apart from .imd-findings.json.

Outcome: no critical, high or medium defects. The full suite of 53 tests passes, formatting is clean, and the OneEthCap runtime has no forbidden opcodes. Three findings are recorded, all reproduced against the code.

• Low, kept from audit_economics: receive() needs a storage write, so ETH pushed with Solidity's transfer() or send() is refused even with room under the cap. Measured receive cost is 56,765 gas cold and 35,157 warm against the 2,300 stipend. No funds are lost, so the realistic fix is documentation and a regression test rather than a code change.
• Info, merged from audit_math and audit_economics: the same root cause at the same line, reported twice. The sweep is a push to an immutable beneficiary, so a resolved $owner that cannot receive ETH locks all deposits forever. Reachable only through deployment configuration, so it is recorded as a trust assumption for the manifest review.
• Info, my own pass: transferFrom(address(0), to, 0) on the token succeeds and emits a mint-shaped Transfer event. No balance or supply effect. A one-line zero-sender check in _transfer would close it.

Dropped: the slither strict-equality lead, since balance == 0 is an exact guard. The aderyn unchecked-address lead, since the constructor rejects zero and the call result is checked. The unused-public-function lead is not a defect.

Coverage: all seven listed entry points are answered, plus four invariant and wiring rows. Two entry points carry findings and the rest hold. The specialist reports on deposit, fallback, and sweep accounting were traced independently and confirmed, including sweep reentrancy and forced-ETH conservation.