Implemented Keel: 1,000,000,000 KEEL, 18 decimals, minted once to the deployer, with no further minting or admin controls.

Included offline dependencies, deployment documentation, and success/failure tests.

Checks passed:

• forge build
• forge test: 30 tests passed using the required seed
• forge fmt --check

Done. I wrote launch.json for the Keel launch and verified the tree builds and tests pass.

What the manifest says

• Token contract Keel, name Keel, symbol KEEL, 18 decimals, no constructor arguments. This matches the accepted src/Keel.sol, whose constructor takes nothing and mints the whole supply to msg.sender.
• totalSupply is the constructor's mint, 10^27 minor units, written as a decimal string.
• No application contracts, since the accepted tree has none.
• pool and economics are copied exactly as the launch reference gives them: native ETH as the zero address, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's verbatim economics object.
• notes describe only the Keel contract and its fixed-supply, no-admin behavior, well under the 4000 character limit.

Checks run

• A schema sanity check on the JSON confirmed only the six schema keys are present, economics is byte-identical to the job's, and totalSupply is 10^27.
• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 30 tests across both suites.

Git status shows launch.json as the only new file. Nothing else was changed.

The review is complete and .imd-findings.json is written. The working tree is clean apart from the gitignored scratch test and the findings file.

Outcome. The Keel token's math holds across all three assigned guides. The contract is 17 lines on top of an unmodified OpenZeppelin v5 ERC20, with one compile-time constant and no division, fee, scale conversion, external call, payable path or bytes decoding. I found no defect in the assigned area. One low finding outside the area is recorded.

What I checked in my area

• Math Precision. The only arithmetic is the supply constant. It evaluates to exactly 1e27, fits below 2^96, and the 10% and 88% launch shares divide with zero remainder. Balance updates in the vendored ERC20 are guarded before their unchecked subtraction, and the recipient add cannot wrap because balances always sum to the supply.
• Boundary. Probed transfer values of 0, 1, supply, supply+1 and max uint, self-transfers, allowance at max, max minus one, exactly equal and above balance, zero owner and spender, and ETH sent to the contract. Every case reverts or succeeds as the ERC-20 contract and README describe, with state unchanged on revert.
• Numerical Gap. There is no seam to exploit: no formula pair, no accumulator, no truncated quantity, no edge fast path that skips an invariant. A seeded fuzz over three-holder splits confirmed conservation.

The one finding (low). The README documents sha256sum --check lib/SHA256SUMS as a project check, and THIRD_PARTY.md says the file records every vendored file unmodified. On the committed tree that command fails for seven forge-std files, including Vm.sol and StdAssertions.sol. All OpenZeppelin files match, so the deployed bytecode is unaffected. This is a provenance gap in the test harness only, with the exact command and hashes in the reproduction.

Coverage. All three ABI entry points are marked holds, plus rows for the supply, decimals, narrow-width, boundary-surface, vendored-library and aderyn-lead invariants. The aderyn large-literal lead is a readability note, not a defect. Nothing was left unreached.

The review is complete and written to .imd-findings.json. The working tree is otherwise untouched (git reports clean apart from the findings file, which is gitignored by the harness).

Outcome: the Keel token's permission model is sound. It is a plain OpenZeppelin v5.0.2 ERC20 with one constructor that mints the full supply to msg.sender. There are no roles, no owner, no initializer, no mint, burn, pause, blacklist or upgrade entry point, and the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT. The deployer becomes an ordinary holder and cannot move anyone else's balance without an allowance.

What I checked in my area (Access Control, Trust Gap, Asymmetry):

• Entry points. All three listed entry points (approve, transfer, transferFrom) trace to the unmodified OpenZeppelin implementation. Each writes only the caller's own balance or allowance row, rejects zero addresses, and cannot reach the mint branch.
• Library trust gap. I fetched the five OpenZeppelin files from the v5.0.2 tag and they are byte-identical to the vendored copies. Storage layout is the standard five-slot ERC20 layout and the source has no non-ASCII characters.
• Asymmetries. The approve-replace versus transferFrom-consume race and the infinite-allowance non-decrement are standard ERC20 behaviour of the agreed design and are documented in the README. I recorded them as trust assumptions, not defects.
• Launch floor. No fees, burns, hooks or exemption lists exist, so every launch flow moves exactly what it says. Constructor takes no arguments, matching the README.

One low finding. The README tells reviewers to run the vendored-dependency checksum gate, and it fails: seven forge-std files do not match lib/SHA256SUMS. I diffed them against the upstream v1.9.7 tarball (whose hash matches THIRD_PARTY.md) and the differences are whitespace only, so nothing is tampered and no deployed bytecode is affected. The stated integrity guarantee is still false, and a reviewer cannot tell this benign reformat from a real edit to Vm.sol without doing that work. Fix is to restore the upstream bytes or regenerate the manifest.

Coverage record: 8 rows, one per entry point plus the invariants above, all holds except the checksum row, which points to finding 1. Existing tests (30 unit, fuzz and invariant tests) build and pass under the pinned seed. No proof test was needed since nothing reached high severity.

Review complete. The findings file is written and validated, and the scratch test is removed so the tree holds only the review output.

Outcome: Keel holds on every check in my area. One low-severity defect is recorded, outside the economics area but concrete.

What I covered

• Economic Security: the token has no external dependencies, oracles, callbacks, fees, burns, rebases, blacklists, pause or owner. Every launch flow was traced to exact wei: the swarm share to the distributor, the pool seed through the PoolManager, a buy and a sell back, the remainder, and a claim. All arrive whole and return true.
• Invariant: supply is minted once to msg.sender under CREATE2, not tx.origin, and no selector can mint, burn or initialize afterwards. Sum of balances equals total supply under the project's 256x64 invariant run and my own 1024-run fuzz. Over-balance and over-allowance paths revert atomically.
• Flow Gap: with no periphery calls and no exemption lists, there is no seam between execution, external behavior and intent. Runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Static-analysis lead: the large-literal warning is a compile-time constant equal to exactly 10^27. Not a defect.
• Dependencies: the vendored OpenZeppelin v5.0.2 ERC20 files are byte-identical to upstream.

The one finding (low): the README instructs running the vendored-file checksum check, and THIRD_PARTY.md says upstream sources are unmodified. On the committed tree that check fails for seven forge-std files. The recorded digests are the genuine v1.9.7 digests. The committed copies differ only by line wrapping, consistent with the formatter having been run over lib. forge-std is test-only, so there is no on-chain effect. The fix is to restore the upstream bytes or regenerate the sums and correct the wording.

Not reported, by design: the inherent ERC-20 approve race, and tokens sent to the token's own address being stuck. Both are standard ERC-20 traits with no victim other than the sender.

Coverage record: all three entry points are marked holds, plus four invariant and flow rows and one finding row for dependency provenance.

The review is complete and the findings file is written and validated. Nothing further is needed from the tree.

Outcome: the Keel token holds in my area. Both findings are outside the token's control flow and neither touches src/Keel.sol.

What I covered

• Execution Trace: traced transfer, transferFrom and approve through the OZ _update, _spendAllowance and _approve paths. No external calls, no stale reads, atomic reverts, exact amounts moved. The launch flows the protected test exercises all move exactly what they say.
• Periphery: every vendored OpenZeppelin file is byte-identical to upstream v5.0.2. The seven forge-std files that fail the checksum manifest differ from v1.9.7 by whitespace only, which I confirmed by a whitespace-stripped comparison.
• First Principles: supply is minted once to msg.sender and no selector can grow it. No receive or fallback. Runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. The project's 30 tests pass with the documented seed, and my scratch test confirmed the behaviors I recorded.

Findings written to .imd-findings.json

1. Low. The README's documented check sha256sum --check lib/SHA256SUMS fails on the committed tree. Seven forge-std files were reformatted by forge fmt after the sums were taken from pristine v1.9.7. Semantics are unchanged, but the integrity manifest does not attest to the tree as shipped. Fix is to regenerate the sums or restore the pristine files.
2. Info. Standard ERC-20 allowance replacement is front-runnable and the token offers no increase/decrease helpers or permit. This is by design for a plain token and is recorded as a trust note for integrators, not a defect.

Coverage record: all three listed entry points marked holds, plus four invariant rows. One row (vendored forge-std) references finding 1. No proof tests were attached since nothing reached high or critical severity.

Done. The suite is complete and verified.

Outcome. The full Foundry suite passes with the verifier's fuzz seed, and only files under test/ were added. No defect was found in the Keel token itself. It is a plain fixed-supply OpenZeppelin ERC-20 with no mint, burn, or admin surface.

Check	Result
forge build	clean
forge test with the verifier seed	56 passed, 0 failed, 0 skipped
forge fmt --check test/	clean
Paths changed	test/KeelProperties.t.sol, test/KeelFailurePaths.invariant.t.sol

What I added on top of the earlier contributor's 30 tests, which I left untouched:

• test/KeelProperties.t.sol holds 25 property and edge tests. They cover raw creation-code deployment through CREATE2 in one call with address prediction and the initiator receiving nothing, a factory claiming the wrong supply, salt reuse, arbitrary deployers, independent deployments, net-zero round trips, repeated transfers until the balance runs out, up to 48 holders conserving the supply, transfers to inert contracts and to the token itself, exact event counts, approve overwrite and idempotence, allowance exactly consumed, the one-below-max allowance boundary, the re-approval race, allowance checked before balance and before the zero-receiver check, a holder needing its own allowance, transfers from the zero owner, and that no caller can alter another owner's allowance.
• test/KeelFailurePaths.invariant.t.sol is a second invariant suite that mixes valid and deliberately invalid calls in random order across six unevenly funded actors. Each invalid call must revert with the exact ERC-6093 error and leave a state fingerprint unchanged. Invariants check the ledger, fixed supply fully held by the actors, immutable metadata and code hash, and a ghost-volume bound. The run table shows all 14 entry points exercised over a thousand times each with zero unexpected reverts.

One finding reported, severity info, in .imd-findings.json. The README instructs reviewers to run sha256sum --check lib/SHA256SUMS, but seven forge-std files no longer match their recorded digests. All seven are already formatter-clean, so the digests were most likely recorded before a reformat. The OpenZeppelin files the token compiles against all match, and nothing in the token or tests is affected. It is outside my allowed paths, so it is reported rather than fixed.

Findings file is written and the scratch tests are removed. Final check of the tree state and the findings file is done.

Outcome: the Keel token holds on every floor check. The only substantiated defect is a documentation and provenance drift, kept at low severity. The findings are in .imd-findings.json.

What I reproduced

• Checksum gate fails (low, merged from five specialists). Running the README's sha256sum --check lib/SHA256SUMS reports seven forge-std files as FAILED. I fetched the seven files from upstream forge-std v1.9.7 and confirmed each upstream file hashes to exactly the recorded digest, while the vendored copies differ only in whitespace. So the drift is a forge fmt pass over lib/, not tampering. The five OpenZeppelin v5.0.2 files are byte-identical to upstream. Nothing that reaches deployed bytecode is affected, but the documented integrity check and the "unmodified" claim in THIRD_PARTY.md are false as shipped.
• Allowance replacement race (info). The standard ERC-20 approve race reproduces in a scratch test. It is inherited OpenZeppelin behaviour under the agreed design, so it is recorded as a trust note, not a defect.

My own review of the token

• Fixed supply of 1e27 minted once to msg.sender via CREATE2, decimals 18, name and symbol match launch.json.
• No mint, owner, pause, blacklist, burnFrom or initializer exists. All 22 admin-style selectors revert from a stranger and from the deployer, with supply and holder balances unchanged.
• Runtime code contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, and both creation and runtime sizes are far under the limits.
• Transfers move exactly the requested amount, so the distributor share, pool seed and swaps arrive whole.
• launch.json uses only schema keys, an empty constructorArgs list matching the zero-parameter constructor, the exact minted supply, and lowercase addresses.
• The project's own 56 tests pass with the README's fuzz seed, and forge fmt --check passes.

Coverage: all three entry points answered as holds, plus five invariant rows, one of which points at the checksum finding.

Not verifiable here: the protected floor tests import v4-core and launch helper sources that are not in this repository, so I could not run them directly. I replicated their supply, decimals, admin-call and opcode checks in a scratch test, which passed.