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

Added vendored dependencies, deployment documentation, and success/failure tests.

All local checks pass with Solidity 0.8.26:

• forge build
• forge test: 30 unit/fuzz tests and two invariants
• forge fmt --check

Offline build and tests also pass with an empty environment.

The review is complete. The findings file is written with an empty findings list and six coverage rows, and the working tree holds no other changes.

Result: no defects in the assigned area. The token at src/CoinbaseToken.sol is a plain OpenZeppelin v5.4.0 ERC-20 whose constructor mints the whole supply once to the deployer. The vendored library files match the SHA-256 hashes pinned in the dependency record. The compiled ABI exposes exactly the three listed state-changing entry points plus the standard view functions, with no owner, minter, pauser, initializer, proxy, delegatecall or receive path.

What I checked against the three guides:

• Access Control. The only guards are the holder's own msg.sender and the allowance row it granted. A stranger's approve cannot touch another holder's allowance, and a one-wei delegated transfer by that stranger reverts. The factory holds no power over holders after paying out. Fourteen admin-style selectors revert from both the factory and a stranger. The CREATE2 factory, not the EOA driving it, receives the supply.
• Asymmetry. The transfer and delegated-transfer pair move identical amounts, both reject the zero receiver, and a fuzzed round trip over 512 runs restores balances exactly. The maximum allowance is not decremented, and a zero-value delegated transfer without allowance moves nothing. Storage writers and readers for balances, allowances and supply are symmetric.
• Trust Gap. There is no setter, fee, price, hook or callback, so no seam exists where a permitted actor extracts value. The standard ERC-20 approve race is the only residual, it is inherent to the standard and documented in the README, so I did not report it.

The protected launch harness expectations also hold on this code: supply is fixed, the deployer receives it, runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT, and the existing 31 unit, fuzz and invariant tests pass. The aderyn large-literal lead is a style note about the supply constant and has no defect behind it. The scratch test used for verification was removed, leaving only the findings file as new content.

The review is complete. The findings file is at the repository root and the git exclusion of it and the scratch folder is the harness's own setup.

Result: no math, boundary or numerical-gap defect in the token. The contract in src/CoinbaseToken.sol is an unmodified OpenZeppelin v5.4.0 ERC-20 with a single constructor mint, and the six vendored OpenZeppelin files hash exactly to their pinned upstream versions. There is no division, scaling, casting, fee, hook or payable path anywhere in it, so the Math Precision guide's failure modes have nothing to attach to.

What I verified, with the existing suite plus a scratch test of my own that runs eight cases including a 512-run fuzz:

• Supply scale. The literal flagged by aderyn evaluates to exactly 10^27, which is one billion whole tokens at 18 decimals. The lead is closed.
• Transfer boundaries. One wei, the full balance, balance plus one, the maximum uint256, zero from an empty account, a self-transfer of the whole supply, and a transfer to the token's own address all behave exactly as the standard specifies. The sum of balances stays at 10^27 under fuzzing.
• Allowance boundaries. An allowance spent exactly to zero, one unit over, the maximum value treated as unlimited, maximum minus one treated as finite, and a revert on insufficient balance that rolls back the allowance decrement all hold.
• Zero-address paths. Transfers to zero, approvals of a zero spender and transfers from zero revert on both the zero-value and nonzero-value paths.
• Launch flows. The ten percent and eighty-eight percent shares of 10^27 divide exactly, and with no transfer hook every launch transfer delivers the full amount.

One informational note is recorded. Seven vendored forge-std files do not match the SHA-256 hashes in dependencies.json. I diffed each against the pinned upstream commit and the only change is line wrapping from the repository's formatter. After stripping whitespace, local and upstream contents are identical, and forge-std is test-only, so there is no effect on the token. The author should either restore the upstream bytes or re-record the hashes so the provenance claim in the README is accurate.

The coverage record answers all three listed entry points as holding, plus three invariant rows. No finding carries a proof file, since nothing rose to high or critical.

The findings file is in place at the repository root (git excludes it by design, as it does the .imd/ inputs), the scratch tests are removed, and no tracked file changed.

Result: no defects found. .imd-findings.json holds an empty findings list and seven coverage rows, all holds.

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• Supply conservation. The only mint is in the constructor and equals 10^27 (1 billion times 10^18). There is no public mint, burn, or _update override, and transfers to the zero address revert, so the supply can neither grow nor shrink. The stateful invariant suite and my own scratch probe confirm this.
• Constructor and recipient. No parameters, nonpayable, mints everything to msg.sender. A CREATE2 deployment from a factory credits the factory and not its caller. Decimals are the OpenZeppelin default of 18. The identifier CoinbaseToken is 13 characters.
• Launch flows. No tax, exemption list, blacklist, or pause exists, so the swarm, pool, and remainder legs move exactly what they say. The 10/88/2 split of 10^27 produces exact integers with no rounding dust. A trader can send tokens into and out of the pool manager address at face value.
• Entry points. approve, transfer, and transferFrom are the unmodified OpenZeppelin v5.4.0 implementations. A zero-address sender through transferFrom reverts on every path, so no route reaches a mint. The max-uint allowance stays infinite as documented.
• Dependency integrity. All five vendored OpenZeppelin files are byte-identical to upstream commit c64a1edb, verified by SHA-256 against both dependencies.json and the fetched upstream source. No submodules exist. The build compiles cleanly and all 31 existing tests pass.
• Privileged surface and opcodes. The ABI exposes only ERC-20 functions plus one constant view. No owner or role storage exists. No DELEGATECALL, CALLCODE, or SELFDESTRUCT appears in the sources or runtime.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note on line 10 is a style remark on 1_000_000_000 * 10 ** 18, which evaluates to exactly 10^27. It is not a defect.

Not covered. The real Uniswap v4 seed and swap run only in the protected launch harness, which needs environment variables and v4-core sources this tree does not carry. I traced the token's side of those flows by hand and with plain transfers. The ERC-20 approve front-running race is inherent to the standard, is documented in the README, and is not reported as a defect.

The findings file is in place at the repository root, excluded from git by the harness's own exclude rule, and the working tree is otherwise untouched. Review complete.

Result

The token is a plain OpenZeppelin v5.4.0 ERC-20 with a fixed one-billion supply minted once to the deployer. I found no defect in the token itself. One low-severity provenance defect in the vendored test dependency is recorded in .imd-findings.json, together with a coverage row for every listed entry point.

What I checked, in my area (Execution Trace, Periphery, First Principles):

• Execution trace. Each of approve, transfer and transferFrom was traced through the inherited OpenZeppelin code to its guards and state writes. Zero-address sentinels revert, insufficient balance or allowance reverts, exact amounts move, the maximum allowance is treated as unlimited, and there is no fee, hook, callback, external call or partial-update window. Factory, distributor and PoolManager flows therefore move exactly what they say, which is what the protected launch harness requires.
• Periphery. All six vendored OpenZeppelin files are byte-identical to upstream commit c64a1edb and match their recorded hashes. There is no submodule and no untracked file under lib. The compiled ABI exposes only the ERC-20 surface plus the supply constant. Runtime and creation bytecode contain no DELEGATECALL, CALLCODE, SELFDESTRUCT or any CALL-family or CREATE opcode.
• First principles. The constructor takes no arguments, is non-payable, makes no external calls and mints a compile-time constant equal to the manifest supply at 18 decimals to msg.sender, which under CREATE2 from the factory is the factory. Nothing can grow the supply or move a holder's balance without that holder's approval after deployment.
• Build and tests. The project compiles with Solidity 0.8.26, all 31 existing tests including 4 fuzz properties and 2 invariants pass, and formatting is clean.

The one finding (low). dependencies.json claims a SHA-256 hash for every vendored file, but 7 forge-std files were reformatted after vendoring and no longer match. The recorded hashes are those of the pristine pinned commit, and the differences are whitespace only. This is a false integrity record for a test-only dependency, not a token defect. The fix is to restore the 7 pristine files or recompute their hashes.

Not covered. No launch.json exists yet, so there was no manifest to check. The protected harness itself depends on v4-core and launch helpers that are not in this tree, so I verified the token against its assertions by reading rather than by running it. Outside my area, I note for the judge that the token name and symbol reuse the Coinbase brand, which is a branding and legal question rather than a code defect, so I did not record it as a finding.

Added 17 unit/fuzz tests covering failure paths and boundary values, and strengthened invariants with independent balance and allowance tracking.

Validation passed: forge build and offline forge test—48 reported tests, including 24,576 randomized calls.

Only test/ changed. No confirmed defects found.

Done. I wrote launch.json for the Coinbase (COINBASE) custom token launch and it is the only file changed.

What the manifest says

• Kind is custom_token, token contract is CoinbaseToken with name Coinbase, symbol COINBASE, 18 decimals.
• constructorArgs is empty, matching the compiled ABI, whose constructor takes no inputs.
• totalSupply is 1000000000000000000000000000, the exact amount the constructor mints to msg.sender.
• contracts is empty because the accepted tree has no application contracts.
• pool and economics are copied verbatim from the launch reference: native ETH pairing, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.
• notes describe only the token present in the tree and stay well under the length limit.

Checks run

• A script confirmed the manifest's keys, supply, pool and economics match the schema and the job's values.
• forge build compiled cleanly and forge test passed all 31 tests.
• git status shows launch.json as the only new file. No configuration, lib, or workflow files were touched.

The review is complete. The findings file is valid JSON, and the working tree is clean apart from the findings file itself (build output is gitignored).

Outcome. The token is a plain, pristine OpenZeppelin v5.4.0 ERC-20 with no added logic, and I found no defect in it. One low finding survives from the specialists, merged from two duplicate reports.

What I verified

• Build and the project's full suite pass: 48 tests across unit, fuzz and invariant files, with no reverts in 24,576 invariant handler calls.
• All six vendored OpenZeppelin files are byte-identical to upstream commit c64a1edb at v5.4.0 and match their recorded hashes, so the production dependency is sound.
• The compiled runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT or any external call opcode. Creation code is 2642 bytes and runtime 1753 bytes, far under the deployment limits.
• The constructor takes no arguments and mints exactly 10^27 units to msg.sender, so the factory's CREATE2 deployment credits the factory with the manifest's supply.
• The manifest in launch.json uses only schema keys, with correct types, lowercase addresses, an empty constructorArgs matching the constructor, and a totalSupply equal to what is minted.

Specialist findings

• audit_flow (low) and audit_math (info) both reported the same root cause: seven forge-std files under lib/forge-std/src do not match the SHA-256 hashes in dependencies.json. I reproduced it, fetched the pinned upstream commit, and confirmed by a comment-stripped token-level comparison that every one of the seven differs only in line wrapping. Kept as one low finding, since the README's integrity claim is false for a test-only dependency but nothing in the production token or launch flows is affected.
• audit_permissions, audit_economics and the test writer reported nothing, and my own pass agrees.

Coverage. All three entry points (approve, transfer, transferFrom) hold, with the constructor, the fixed-supply and exact-flow invariants, the opcode restriction and the manifest also recorded as holding. The provenance row points at the one finding. No proof test was written because nothing reached high or critical severity.