Implemented Coinbase (COINBASE): 1,000,000,000 tokens, 18 decimals, minted once to the deployer.

Included vendored dependencies, success/failure tests, accounting invariants, and deployment documentation.

Passed forge build, forge test, and forge fmt --check. A clean offline build and parallel tests also passed with an empty environment.

Created launch.json matching the accepted Coinbase constructor, exact supply, pool settings, and economics. Only the manifest changed.

Offline build and all 32 tests passed, including a second fuzz seed. Slither reported no medium/high findings. Manifest fields and constructor ABI checks passed.

Git staging was unavailable because .git is read-only; the file remains ready for collection.

The review is complete and the findings file is written. Nothing else is pending.

Outcome. The Coinbase token is a plain 17-line OpenZeppelin ERC-20 with no admin surface, and all three state-changing entry points hold. I found one low-severity defect, outside the token code itself, in the project's release checklist.

What I checked, by area

• Execution Trace. Traced approve, transfer and transferFrom through the vendored ERC-20 base to every revert path and storage write. Zero-address checks, atomic rollback on insufficient balance or allowance, unlimited-allowance handling and self-transfer all behave as the README states. Launch flows move exact amounts, so the factory, distributor and PoolManager transfers arrive whole.
• Periphery. Downloaded the upstream OpenZeppelin v5.0.2 and forge-std v1.9.7 archives into a scratch directory outside the repo. The archive hashes match the dependency notes. All six OpenZeppelin files are byte-identical to upstream. Seven forge-std files differ from upstream in whitespace only, which I confirmed by diffing each one.
• First Principles. The constructor mints exactly 10^27 units to the immediate deployer, which the launch harness requires to be the factory. The compiled ABI exposes only the three listed functions plus views and events. No receive, fallback, mint, burn, pause, blacklist or owner path exists. The existing suite of 32 unit, fuzz and invariant tests passes, and the format check passes.

The one finding (low). The README tells the launch operator to run the dependency integrity check, and the dependency notes claim the vendored files are unmodified. Running that command on the committed tree fails with seven mismatches, because the recorded hashes describe the pristine upstream forge-std files while the vendored copies were reformatted. The reproduction and the exact command, hashes and file list are in the finding. The fix is to regenerate the checksum file from the committed tree or restore the seven files from the upstream archive.

Leads I dismissed. Aderyn's large-literal lead at the supply constant is correct arithmetic and already asserted by a test. The slither run reported nothing.

Coverage. Seven rows: all three entry points and the constructor hold, the fixed-supply and no-privileged-path invariant holds, the OpenZeppelin periphery holds, and the forge-std periphery row points at the finding. No files were changed other than .imd-findings.json, and the scratch download was removed.

The review is complete and the findings file is written. No source file was changed.

Outcome. The token's economics hold. One low-severity defect is reported, outside the economic area.

What was checked, in the assigned area:

• The token is a bare OpenZeppelin v5.0.2 ERC20 with a single constructor mint of 10^27 units to the deployer. I fetched the tagged upstream files and confirmed every vendored OpenZeppelin file the token inherits is byte-identical.
• Economic Security: there are no external dependencies, oracles, fee or tax formulas, callbacks, or sentinel-address branches, so none of the guide's extraction or dependency-failure modes have a surface.
• Invariants: balance conservation, fixed supply, and holder-only balance mutation hold. The only writer of total supply is the constructor, and the ABI exposes only approve, transfer and transferFrom as state changers.
• Flow Gap: I modelled the launch flows in a scratch test under test/scratch (10% to the distributor, 88% to the pool, 2% remainder, a full claim, and pool-style pulls with finite and unlimited allowances). Every flow arrives whole, the basis-point split leaves no dust, and the 88% share fits Uniswap v4's int128 deltas. The existing 32-test suite and the 128-run invariant suite also pass.

Finding reported (low): the integrity check the README instructs, sha256sum --check DEPENDENCIES.sha256, fails on 7 forge-std files. The recorded hashes are upstream v1.9.7's, but the vendored copies were reformatted, so the "unmodified" claim in DEPENDENCIES.md is inaccurate. The differences are whitespace only, forge-std is test-only, and token bytecode is unaffected.

Coverage: all three listed entry points are recorded as holds, with six additional invariant and launch-flow rows. One limit is stated in the record: the protected Uniswap v4 harness could not run here because v4-core and the launch liquidity library are not in this tree, so pool behaviour was verified by hook absence and numeric bounds rather than by executing a seed and swap.

Review complete. The findings file is written and no tracked file was changed.

Outcome. The Coinbase token's permission model is clean in my area. It has no privileged actor, so there is nothing for the Access Control, Trust Gap or Asymmetry checklists to break. I report one low defect outside my area.

What I verified

• Access control. The compiled ABI exposes only the constructor, eight ERC-20 views and the three entry points. There is no owner, minter, pauser, blacklist, initializer, receive or fallback. Each entry point writes only the caller's own balance or allowance row. A scratch test confirmed the factory cannot pull a holder's balance without approval and that tx.origin receives nothing at deployment.
• Trust gap. The deployer has exactly the rights of every other holder. The only trust assumption is outside the token: the factory holds the whole supply after construction and performs the distribution.
• Asymmetry. Finite allowances decrease exactly, the max allowance never decreases, zero-owner transferFrom reverts on both the zero and non-zero value paths, and transfer to the zero address reverts so no burn path exists.
• Runtime. An opcode scan of the deployed bytecode found no CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE, SELFDESTRUCT or ORIGIN. The vendored OpenZeppelin files are byte-identical to upstream v5.0.2.
• Existing checks. The project's 32 unit, fuzz and invariant tests pass, and forge fmt --check is clean.

Finding (low). The README tells the verifier to run the shipped integrity check, and it fails: seven forge-std files under lib/ do not match DEPENDENCIES.sha256. I diffed each against the pinned v1.9.7 tag and the differences are whitespace only, so behaviour is unaffected. The fix is to regenerate the hash file or restore the upstream bytes.

Not reached. The protected launch harness could not be run here because it imports Uniswap v4 sources absent from this tree. I traced its expectations by reading and see no way a plain fixed-supply ERC-20 fails them. One non-code point for the requester, not recorded as a finding: a mainnet token named "Coinbase" with symbol COINBASE carries obvious trademark and impersonation exposure.

The review is complete and the findings file is written.

Result for the assigned area (Math Precision, Boundary, Numerical Gap): no defects. The token at src/Coinbase.sol is an unmodified OpenZeppelin v5.0.2 ERC-20 with one compile-time constant and one constructor mint. There is no fixed-point math, division, scale conversion, downcast, signed arithmetic, fee, burn or cap anywhere in the token. I verified the vendored OpenZeppelin files are byte-identical to upstream, then exercised every math boundary with a scratch Foundry suite that has since been removed:

• Supply constant evaluates to exactly 1e27 and divides to one billion whole tokens with zero remainder. No runtime path can change it.
• transfer behaves correctly at 0, 1 wei, exact balance, balance plus one, supply plus one, max uint, and self-transfer of the whole supply. Fuzzed sums are conserved. The unchecked balance add in OpenZeppelin cannot wrap because the supply is fixed far below 2^256.
• transferFrom and approve handle max uint as infinite, decrement max minus one, consume an exact allowance to zero, revert atomically when one wei short, need no allowance for zero amounts, and leave the allowance intact when the receiver is the zero address.
• Launch flows move exactly the stated amount, so the protected whole-arrival, seed and swap checks cannot come up short.

The slither lead was empty. The aderyn lead on the large literal is the compile-time supply constant, confirmed exact on chain.

One low finding outside my area. The README and DEPENDENCIES.md tell reviewers to run sha256sum --check DEPENDENCIES.sha256 as an integrity check and claim the vendored files are unmodified. That check fails on the committed tree for seven forge-std files, which were reformatted relative to the upstream v1.9.7 archive while the hash file still records the upstream hashes. The differences are whitespace only and forge-std is a test-only dependency, so no token bytecode is affected. The fix is to restore the upstream bytes or regenerate the hash file.

The coverage record has nine rows. All three ABI entry points hold, five invariant rows hold, and the forge-std integrity row points to the finding. The working tree is clean apart from the findings file.

Done. The full suite passes: 62 tests across 5 files, with no changes outside test/ other than the findings file the brief asks for.

What I found about the token. src/Coinbase.sol is a plain OpenZeppelin v5.0.2 fixed-supply ERC-20 and has no defect. I confirmed the five vendored OpenZeppelin files are byte-identical to upstream, so nothing is hidden in the library. The constructor mints exactly 10^27 units once to its immediate deployer, there are no admin entry points, and the runtime has no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE or CREATE2.

What I added, building on the existing unit and invariant files rather than rewriting them:

• test/Coinbase.launch.t.sol mirrors the protected launch floor without the Uniswap v4 stack. It deploys through raw CREATE2 with the attested creation code and checks address prediction, the single mint event, the full swarm, pool and remainder flows arriving whole, 20 uneven claims draining the distributor to exact dust, pool-manager settle and take, CREATE2 salt collision, independent supplies across deployments, ether rejection, unknown selectors, stuck tokens at the token address, and the protected harness's complete lists of 10 supply-growing and 12 holder-freezing signatures from both a stranger and the factory.
• test/Coinbase.fuzz.t.sol has 13 property tests at 1000 runs each over arbitrary accounts: three-party conservation, round trips, exactly one Transfer event per transfer, split sums, and failure paths with exact custom errors for zero receiver, zero spender, strangers pulling without approval, over-allowance and over-balance pulls, the unlimited-allowance boundary, random unknown selectors, and ether.
• test/Coinbase.adversarial.invariant.t.sol is a second invariant suite at 256 runs by depth 64 with an open cast: the deployer, the token address as a sink, five funded holders, two strangers and newcomers who join mid-sequence. Fourteen handler actions include ten that must be refused, asserted with their exact revert data at the point of call so fail_on_revert stays meaningful. Invariants hold supply fixed, balances and allowances equal to the ghost model, the cast summing to the supply, and no ether at the token.

Grounding. I ran all three new files against a mutant with a 1% transfer fee and a deployer-only mint. Seven launch tests, ten fuzz tests and all four invariants failed on the mutant, so none of the properties are vacuous.

One finding, severity info, written to .imd-findings.json. The README's documented integrity check fails: seven forge-std files no longer match DEPENDENCIES.sha256 because they were reformatted. The differences are whitespace only and do not affect the token, but an operator following the README gets a failure.

I did not commit; the working tree holds the three new test files and the findings file.

The review is complete and the findings file is written. No tracked files were changed.

Outcome. The Coinbase token has no code defect. The five specialists all reported the same single issue, which I reproduced and merged into one low finding.

What I verified

• src/Coinbase.sol is a 17-line OpenZeppelin v5.0.2 ERC20 with an argument-free constructor minting exactly 10^27 units to msg.sender. The five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 archive.
• Build, the 62-test suite, and forge fmt --check all pass. The runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT or CALL opcodes, and the sizes are far below the deployment limits.
• All three entry points (approve, transfer, transferFrom) are stock ERC20 and marked holds in the coverage record, plus a row for the constructor and supply invariant.
• launch.json agrees with the contract: empty constructorArgs, supply string, decimals 18, lowercase addresses, no extra keys.

Findings written to .imd-findings.json

1. Low, merged from all five specialists. sha256sum --check DEPENDENCIES.sha256 fails for seven forge-std files. I fetched the upstream v1.9.7 archive and confirmed the recorded hashes are upstream's and the committed copies differ only in whitespace. Test-only dependency, no effect on the token. Fix is to regenerate the hash file or restore the upstream bytes.
2. Info. README line 87 says the repository provides no launch manifest, but launch.json is committed.

No critical or high finding exists, so no proof test was needed.