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

Vendored dependencies and documented deployment parameters, assumptions, and operational responsibilities in README.md.

Verified:

• forge build
• forge test: 33 passed, including fuzzing and invariants with the supplied seed
• forge fmt --check

Created launch.json matching CoinbaseToken’s constructor, exact supply, and required pool and economics.

forge build passed. All 33 tests passed with the specified fuzz seed. Only launch.json changed.

The review is complete and the findings file is written and valid. The working tree shows no tracked changes; .imd-findings.json and test/scratch/ are gitignored.

Result: the token's arithmetic holds. CoinbaseToken is a bare OpenZeppelin v5.0.2 ERC20 with one constant mint, and the vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 archive. I traced every path in my area:

• Math Precision: the only arithmetic the contract adds is the compile-time constant, which evaluates to exactly 10^27 and divides by 10^18 with zero remainder. Inside the library, every unchecked subtraction is preceded by a bounds check and every unchecked addition is bounded by total supply. There is no division, fee, scale conversion or downcast anywhere.
• Boundary: no external calls, no payable or fallback path, no bytes decoding. The only sentinel branches are the zero-address checks, and both sides of each were walked. Max-uint transfers, allowance equal to amount, max-minus-one versus max allowance, and unlimited allowance against an overdrawn balance all behave as the standard requires. I confirmed these with six scratch tests, all passing.
• Numerical Gap: the sum-of-balances invariant holds exactly because integer arithmetic equals real arithmetic here. The launch split percentages of 10^27 produce no remainder.

One low finding, outside the contract itself. DEPENDENCIES.md tells the reader to verify the vendored libraries with the checksum file, but that command fails on seven forge-std files. Diffing against the upstream v1.9.7 tarball shows they were only reformatted by forge fmt, with no semantic change, so tests and the production contract are unaffected. The judge gets the exact command, its output, and the cross-check in the finding. The aderyn large-literal lead was checked and is not a defect.

The coverage record answers all three entry points as holds plus four invariant and lead rows. Nothing in my area was left unreached.

The review is complete and the findings file is written at .imd-findings.json. The token itself has no economic defects.

What I checked

• src/CoinbaseToken.sol is a 17-line contract: it inherits OpenZeppelin ERC-20 unchanged and mints 10^27 units to msg.sender in the constructor. The constant evaluates to exactly 1,000,000,000 × 10^18.
• The five vendored OpenZeppelin files are byte-identical to upstream v5.0.2, so transfer, transferFrom and approve carry no fee, exemption, callback or external call.
• The compiled ABI exposes only those three state-changing functions. There is no mint, burn, pause, owner or upgrade path, so the supply cannot grow or shrink after deployment.
• Against the Economic Security, Invariant and Flow Gap guides: no external dependencies to break, conservation of balances holds, launch flows to the distributor, PoolManager and requester move exact amounts, and the protected floor's swap and claim flows are satisfied by a plain ERC-20.
• The existing suite passes with the documented seed. The three entry points each get a holds coverage row with reasons.

One low finding

Running sha256sum -c DEPENDENCIES.sha256, which DEPENDENCIES.md and the README name as the integrity check, fails for seven forge-std files. The recorded digests are the real upstream v1.9.7 digests. The committed files were reformatted afterwards and are identical to upstream once whitespace is stripped. No behaviour changed and the production dependency closure verifies, but the documented check is broken and the "Sources are unmodified" claim is false. The fix is to restore the upstream bytes or regenerate the checksum file.

Not reachable from this tree

No launch manifest exists yet. The README's claim of an 80 percent pool and 10 percent requester split comes from the job's economics, not this code, so I recorded it as unreached rather than verified. The token name "COINBASE" is the requester's stated choice and I did not treat it as a code defect.

The review is complete and .imd-findings.json holds one finding plus nine coverage rows.

Outcome. The token itself is clean in my area. CoinbaseToken is a 17-line contract over a byte-identical OpenZeppelin v5.0.2 ERC-20, and all three state-changing entry points behave as the README states.

What I verified

• Execution trace. Traced approve, transfer and transferFrom through the inherited OpenZeppelin code with concrete inputs: zero address, zero amount, self-transfer, max allowance, insufficient balance and allowance. Every failure path reverts atomically and every success path moves exactly the stated amount.
• Launch flows. A scratch test deployed the token by CREATE2 from an address standing in for the factory, then ran the swarm share, claim, pool pull and pay, and remainder transfers. All amounts arrived whole, supply stayed at 10^27, and the factory could not pull a holder's balance without approval.
• First principles. The constructor mints exactly 1,000,000,000 × 10^18 to msg.sender, takes no arguments, links no libraries, and leaves no owner, mint, burn, pause or freeze path. The compiled ABI exposes no receive, fallback or other non-view function.
• Periphery. Downloaded the upstream archives named in DEPENDENCIES.md. Their hashes match the file's claims, and all six vendored OpenZeppelin files are byte-identical to upstream.

The one finding, severity low. DEPENDENCIES.md tells the reader to verify the vendored libraries with sha256sum -c DEPENDENCIES.sha256, and that command fails on seven forge-std files. The recorded hashes are the genuine upstream v1.9.7 hashes. The files in the tree differ only by whitespace, so the token is unaffected, but the "Sources are unmodified" claim is false and any provenance gate running the documented command rejects the tree. The fix is to restore the upstream bytes or regenerate the checksum file.

Static analysis leads. Slither reported nothing. Aderyn's large-literal note on line 10 is the supply constant, which evaluates to exactly 10^27, so it is not a defect.

Not reached. The protected launch test needs Uniswap v4 core and the harness's LaunchLiquidity library, which are not in this tree, so I approximated the pool manager with transfer and transferFrom rather than running a real swap. The scratch test directory was removed after use.

Added 9 tests and expanded randomized invariants to cover failure rollback, allowance boundaries, authorization isolation, and holder transferability.

forge build and forge test pass with the required seed: 42 tests passed, including 16,384 invariant calls.

Only test/ changed. No implementation defects found.

The review is complete and the findings file is valid. Nothing more to request.

Outcome: the COINBASE token holds under the Access Control, Trust Gap and Asymmetry guides. One low-severity provenance defect is reported in .imd-findings.json, with coverage rows for all three entry points.

What I checked in the assigned area

• Access control. The contract inherits unmodified OpenZeppelin v5.0.2 ERC-20 and adds only a constructor. The compiled ABI has exactly three nonpayable functions and seven views, with no owner, minter, pauser, initializer, receive or fallback. A fuzzed sweep of non-ABI selectors from arbitrary callers reverts with no state change. The deployer keeps no residual power after moving the supply out and cannot pull a holder's balance.
• Asymmetry. transfer and self-approved transferFrom reach identical end states for the same inputs. Every revert path in transferFrom leaves allowance and balances untouched. Allowance writes only touch the caller's own row.
• Trust gap. No caller class is exempt or taxed. Factory, distributor, pool manager and trader paths all move exact amounts, so the launch flows the floor test requires arrive whole. I byte-compared the vendored OpenZeppelin files against the upstream v5.0.2 archive. All six plus the license are identical.
• Static-analysis lead. The aderyn large-literal warning is a constant that folds to the manifest supply exactly. Dismissed.

The one finding (low). The README and DEPENDENCIES.md tell readers to verify vendored sources with a checksum file, and that check fails on a clean checkout. Seven forge-std files differ from both upstream v1.9.7 and the committed record. The difference is whitespace-only reformatting, so there is no on-chain or semantic impact, but the repository's stated provenance guarantee is false as committed. The fix is to regenerate the record or restore the byte-exact upstream files and exclude the library from formatting.

Not substantiated, left out. The README hardcodes an 80/10/10 split and names Ethereum chain ID 1 as the target. I have no job economics or chain table to check these against, so they are not reported.

Scratch tests live under test/scratch/, which is ignored and not kept. No repository file was modified.

The review is complete and written to .imd-findings.json. No repository file was changed, and the working tree stays clean apart from the findings file the task asks for.

Outcome. The token holds. Both findings are documentation defects, with no effect on the deployed contract.

Specialist findings. All four specialists reported one and the same issue, so I merged them into a single low finding:

• DEPENDENCIES.sha256 fails the documented check. I reproduced it on the clean HEAD: the documented sha256sum -c command reports seven forge-std files as FAILED. I downloaded both upstream archives named in DEPENDENCIES.md, confirmed their archive digests match, and compared all 36 vendored files. The seven recorded digests are the genuine upstream ones, the committed copies differ only by whitespace from a forge fmt pass, and every OpenZeppelin file the token compiles against is byte-identical to upstream. Severity stays low: forge-std is test-only, so the only harm is a false provenance statement.

My own pass found one more item, reported as info. README line 47 says the repository contains no launch manifest, but launch.json is committed at the root. The manifest itself is consistent with the code and the schema.

What I verified about the token itself. It is an unmodified OpenZeppelin v5.0.2 ERC-20 with a no-argument constructor minting exactly the manifest supply to msg.sender. The ABI exposes no mint, burn, owner, or pause function. The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE opcodes. Creation and runtime sizes are far under the deployment limits. The full local suite of 42 tests, including the 256-run invariant suite, passes with the README's seed, and forge fmt --check is clean. The aderyn large-literal line is the underscore-formatted supply constant and is not a defect.

Coverage record. All three listed entry points are marked holds with reasons, plus three invariant rows covering fixed supply, factory deployability, and manifest consistency.