I couldn't commit: git has no author identity set, and setting one would mean writing to .git/, which is off limits. Everything is left as ordinary files in the working tree for the harness to collect, with forge-std copied in directly rather than as a submodule. forge build, forge test (32 passed, 0 failed) and forge fmt --check all pass on solc 0.8.26.

What's there

• foundry.toml: solc pinned to 0.8.26, bytecode_hash = "none", optimizer on, no ffi or filesystem access. forge-std v1.9.7 is in lib/forge-std, used only by tests.
• src/LaunchToken.sol: the token, named "The Comb" (COMB). It has 18 decimals and exactly 10^27 minor units minted to the deployer, with no mint, owner, pause, fee or upgrade functions. The brief asked for nothing the standard token can't do.
• src/CombWall.sol: the wall, with no constructor arguments, no owner or admin, no external calls and nothing that accepts ETH. It has claim, carve and release, the four views the brief named, and the Claimed, Carved and Released events. I added three views the brief didn't ask for:
  • hasCell(address), so you can tell whether a wallet holds a cell without the sentinel value.
  • nextCarveAt(uint16), the earliest time the holder can carve again.
  • cells(from, count), which reads a range of cells at once so the website can load the whole wall quickly.
• Tests cover:
  • one cell per wallet
  • taken and out-of-range cells
  • message length 0, 1, 64 and 65 bytes, and emoji (length counts bytes, not characters)
  • the 24h cooldown at its exact boundaries
  • release then reclaim
  • all 1,024 cells claimed
  • ETH being refused
  • no admin functions
  • a fuzz test that the claim count stays correct
• ABIs are in docs/abi/LaunchToken.json and docs/abi/CombWall.json.
• README.md covers the behaviour, assumptions, deployment parameters, "After launch" (nothing to set) and operational responsibilities.
• I wrote no launch.json, since the manifest step produces it.

I also ran the two supplied protected test files in scratch, with environment values I made up to stand in for the launch, and all 9 of their tests passed.

Design choices to review

• What cellOf returns for no cell: it returns 65535 (NO_CELL) when a wallet holds none, because 0 is a real cell.
• When the cooldown starts: the 24h cooldown starts at the claim, so the first carve is possible 24h after claiming.
• Ways around the limits: a holder can release and immediately reclaim a cell with a new message, risking someone else taking it in between. One cell per wallet is enforced per address only, so one person with many wallets can claim many cells.
• No content filtering: messages are stored as written, so the website must render them as plain text.

The README documents all of these. Passing tests aren't an audit; the independent review still needs to happen.

Done. I wrote launch.json for the accepted tree and verified it against the source, the ABI exports, and the build.

What the manifest contains

• Token: LaunchToken, name "The Comb", symbol "COMB", 18 decimals, matching src/LaunchToken.sol, which has no constructor arguments.
• Contracts: a single entry, CombWall, with an empty constructorArgs list. The accepted CombWall.sol declares no constructor, and docs/abi/CombWall.json confirms it has no constructor entry. It has no owner or admin, so no $owner reference applies.
• Pool: paired currency 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 (IMD), fee 12500, tickSpacing 60, initialPrice "79228162514264337593543950336", exactly as the This launch section gives them.
• Notes: a short description of the token and the CombWall behavior, well under the 4,000 character limit, with no supply, allocation, owner or chain fields.

Checks

• A scratch script confirmed the schema keys, unique valid contract names, reserved names absent, lowercase pair address, string initialPrice below 2^256, and notes length.
• forge build succeeded and forge test passed all 32 tests across both suites.
• Git status shows launch.json as the only new or changed file. No configuration file, lib/, or source was touched.

Review complete. No defects in the Math Precision, Boundary or Numerical Gap areas survived verification, and the findings file records an empty list with a full coverage record.

Scope

Files read: src/CombWall.sol (149 lines), src/LaunchToken.sol (66 lines), both test files, the protected floor tests, the workflow brief and the README. ABI exports under docs/abi/ match the compiled ABIs. The project suite passes with 32 tests. No launch.json exists in the tree, as the README states, so there was no manifest to inspect.

Severity counts: 0 Critical · 0 High · 0 Medium · 0 Low

What I checked and concluded

Each check was run as a throwaway Foundry probe under test/scratch/, since removed.

• Counter and index arithmetic. The unchecked ++_claimed and --_claimed are bounded by the empty-cell and held-cell guards. Filling all 1,024 cells, releasing them all, then refilling leaves the count, owners, messages and cooldowns consistent. Cell 1023 stores as 1024 in the uint16 holder map and reads back correctly.
• Timestamp math. The uint64 cast and the 24-hour addition cannot truncate or overflow. Carving still works when the clock is warped to the uint64 maximum. The Slither timestamp lead is immaterial at a 24-hour scale.
• Batch view boundary. A count of zero returns empty arrays, a count past the wall truncates to one entry, and reading the full wall with 64-byte messages costs about 11.2M gas, within usual eth_call limits.
• Calldata boundary. A string whose declared length exceeds the calldata is rejected by the ABI decoder with no state change. There are no external calls, payable paths, sentinel-token branches or bytes decoding.
• Token arithmetic. The unchecked balance add cannot overflow because balances always sum to the fixed supply. Self-transfer of the full balance, zero-value transfers, full-supply moves, infinite allowance and max-minus-one allowance all behave correctly. The Aderyn literal lead resolves to exactly 1e27.

Observations (non-blocking)

Neither contract has an owner, privileged role or constructor argument, so there is no beneficiary to review and $owner is not needed in the manifest. Release-then-reclaim resets the cooldown, which the README documents as intended.

The review is done and .imd-findings.json holds the result. No tracked file was changed, and the scratch tests were removed.

Outcome. The CombWall and LaunchToken contracts are sound in the control-flow area I was assigned. The build passes, all 32 project tests pass, the exported ABIs match the compiled ones, and both runtimes clear the launch floor checks for forbidden opcodes, size, and supply at the deployer.

Findings written:

• Low, cooldown bypass. The brief limits message rewrites to once per 24 hours, but a holder can call release() then claim() on the same cell to rewrite instantly. The README accepts this because someone could grab the cell in between. That mitigation is false for a contract wallet or batched caller, which does both calls in one transaction with no window for anyone else. I verified the atomic bypass with a scratch test that rewrote a cell twice in one block.
• Info, README gas figure. The README states claims cost roughly 70k to 120k gas. Measured costs ran from about 98k for a 1-byte message to about 143k for a 64-byte message, with the first claim about 17k higher.

Coverage. All six verifier-listed entry points have rows. Five hold and carve points to finding 1. Extra rows record the state-coupling invariant, the launch floor checks, the ABI match, and both static-analysis leads, which I confirmed are not defects. The manifest row is marked unreached because no launch.json exists yet in this tree.

The findings file is in place and no tracked file was changed. The harness ignores the findings file and the scratch directory at the git level, which is expected.

Review outcome: two low-severity findings, no privileged role or permission bypass found.

The assigned area was covered in full. CombWall has no owner, initializer, proxy, external call, payable path or fallback, so the Access Control map reduces to three msg.sender-keyed functions whose guards I traced end to end. The Trust Gap guide found nothing because there is no privileged actor and no economic value in the contract. The Asymmetry guide produced the one real defect.

Findings written to .imd-findings.json

• Low, cooldown bypass. The pair release() then claim() rewrites a held cell's message with no cooldown, while carve() enforces 24 hours for the same holder. Done from a contract the holder keeps the cell with certainty, so the README's "someone may take it in between" mitigation does not apply. The brief states "max once every 24 hours". Proof test under test/scratch/CooldownBypass.t.sol fails on the current code with three rewrites in one block.
• Low, outside my area. Messages are validated by byte length only, so a one-byte 0xff claim is stored in a string field. I verified ethers v6 throws a BAD_PREFIX error when that element is read from cells() or messageOf(), while viem substitutes a replacement character. The README already documents raw-byte storage, so this is reported to give the website stage a concrete failing input.

Coverage record. All six listed entry points have rows: carve and the three token functions hold, claim and release point to finding 1. Extra rows record that the ABI exports are identical to the compiled output, the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT, the cell and counter invariants hold under the existing fuzz test, and both static-analysis leads were checked and dismissed.

Not verified. No launch.json exists yet, which is correct for this stage. The README's pool currency, fee, tick spacing and launch owner could not be cross-checked because no "This launch" section or network.json was supplied.

The findings file is in place and the tree is otherwise unchanged. The scratch test directory is removed, the findings file is git-excluded by the harness as intended, and no source, config or test file was modified.

Result of the economics review of The Comb (CombWall + LaunchToken)

The code holds no value and makes no external calls, so the Economic Security, Invariant and Flow Gap checklists mostly collapse to one scarce resource, the 1,024 cells, and one timer. I found one low defect and one design-level trust assumption. Nothing critical or high.

• Low, finding 1: the 24-hour carve cooldown is bypassed by release() then claim(). The brief says a holder may rewrite their message at most once every 24 hours. The carve path enforces that, but release deletes the cell's lastWrite and claim restarts it, so the same wallet rewrites the same cell any number of times per block. A scratch test reproduced this: three rewrites of cell 7 within one second, all succeeding. The README calls this accepted, but it contradicts the brief's stated guarantee, so I reported it with a minimal fix that keeps the design (a per-address last-write timer) and flagged that the requester must choose between fixing it and amending the brief text.
• Info, finding 2: the per-address limit is Sybil-able. Claim costs about 97k gas median, so one actor can occupy all 1,024 cells for roughly 99M gas, about 0.1 ETH at 1 gwei, and hold them forever. The brief asks for no Sybil resistance and the README documents it, so this is recorded as the material economic risk of the agreed design, not as a code defect.

What holds. The coupling between the cell map and the reverse address map, the _claimed counter, the 1..64-byte message bound, and the view/write consistency of nextCarveAt versus carve all hold under tracing and the existing fuzz test. LaunchToken is the plain fixed-supply token the launch requires: immutable supply of 10^27 minted to the deployer, no mint or burn path, exact transfers, and no DELEGATECALL, CALLCODE or SELFDESTRUCT in either runtime. Both ABI exports match forge inspect output exactly. There is no launch.json yet, which is correct for this stage, and neither contract takes constructor arguments, so there is no owner or beneficiary to review.

Static-analysis leads. The Slither timestamp warning on carve is a seconds-scale drift against a 24-hour window with no value attached, and the Aderyn literal warning is style. Neither is a finding.

Coverage. All six listed entry points have rows: three on CombWall (two marked finding for finding 1, carve holds), three on LaunchToken (all hold), plus eight invariant and lead rows. No entry point is unreached.

All done. The suite is green and only files under test/ were added; the findings file sits at the repository root as the brief requires, and the harness's own exclude rule keeps it out of git.

What I found in the implementation

Both contracts are sound. CombWall is a 1,024-cell message wall with no owner, no ETH path and no external calls. LaunchToken is the standard fixed-supply ERC-20 minting the whole supply to its deployer. The exported ABI files in docs/abi/ match the compiled ABIs. I found no critical or high defect, so no proof files were needed. Two low-severity observations went into .imd-findings.json rather than being asserted as correct:

• Cooldown bypass by release and reclaim. A holder can call release() then claim() on the same cell in one block and rewrite the message with no 24-hour wait. The README documents this as accepted, so it is reported as a spec deviation for the reviewer.
• Mint-shaped zero-value event. Anyone can call transferFrom(address(0), anyone, 0). Balances and supply are untouched, but it emits a Transfer from the zero address, which indexers read as a mint. Informational only.

What I added (four files, 62 new tests on top of the existing 32)

• test/CombWall.invariant.t.sol: a handler with 8 actors driving claim, carve, release, time warps, ETH sends and a cooldown-edge stress handler against a ghost model that predicts every success and exact revert selector. Invariants check the count against the model, every touched cell against ghost owner, raw message bytes and cooldown, the reverse lookup for every actor, one cell per wallet, untouched cells staying empty, and zero ETH held.
• test/LaunchToken.invariant.t.sol: a handler with 7 holders driving transfer, approve and transferFrom in modes that deliberately hit the failure paths (over balance, over allowance, zero address, exact and infinite allowance) plus admin-selector and ETH probes. Invariants: supply fixed and equal to the sum of balances, every balance and allowance equal to the ghost ledger, no ETH.
• test/CombWallEdge.t.sol and test/LaunchTokenEdge.t.sol: boundary and failure-path unit and fuzz tests, including batch-view edges, error precedence, failed calls leaving no trace, raw-byte messages, fuzzed cooldown offsets, reverted transfers keeping allowances, runtime opcode scans and the full-wall saturation path.

Verification

Check	Result
forge build	clean
forge test	94 passed, 0 failed, about 21 s
Mutation checks in scratch	all three deliberate model mutations caused failures

The mutation checks matter: an earlier version of the random campaign did not reliably reach the exact cooldown second, so I added the edge-stress handler and re-verified that a wrong cooldown model, a wrong one-cell rule and a wrong allowance rule are each caught.

The review is complete. The findings file at the repository root holds six findings and a ten-row coverage record, and no source file was changed.

What I did

• Built the tree and ran the existing suite (93 tests pass).
• Ran both specialist proofs against the code. Both fail for the stated reason.
• Wrote scratch tests for every other lead and reproduced each one. Scratch files were removed afterwards.
• Installed ethers 6.17.0 in a temporary directory to confirm the decoding claim, then deleted it.
• Diffed the exported ABIs against the compiled ones. Both match.
• Checked launch.json field by field against the schema rules. It is valid and agrees with the source.

Findings kept, after merging and recalibration

1. Low. release() deletes lastWrite, so a holder rewrites a cell's message at will with release() then claim(), with certainty when done atomically. Four specialists reported this; it is now one finding carrying a proof that fails on this tree. It stays low because no funds are held, no privileged actor exists, and the README documents the behaviour. The requester must either add a per-address timer or amend the brief's wording.
2. Low. The message check validates only byte length, so a one-byte 0xff message is stored in a string field. ethers v6 throws when decoding it from messageOf, cells or the events, which can break the frontend's wall view.
3. Info. transferFrom from the zero address with value zero succeeds and emits a mint-shaped Transfer event.
4. Info. The README gas range for claim is below measured cost. A 64-byte claim costs about 143k gas.
5. Info. The README says the repository contains no launch.json, but the manifest step added one.
6. Info. Trust assumption: one cell per address only, so one actor can hold all 1,024 cells for roughly 100M gas. Documented design, recorded for acceptance.

Dropped or downgraded

• The slither timestamp lead is the intended 24 hour comparison and is not a defect.
• The aderyn large-literal lead is the fixed supply constant and is correct.

Coverage

All six listed entry points are answered. Carve, approve and transfer hold. Claim, release and transferFrom point at findings 2, 1 and 3. Four extra rows record the counter invariant, the fixed-supply invariant, factory deployability and the manifest check, all holding.