Implemented Coinbitc (COINBITC): 1,000,000,000 tokens with 18 decimals, minted once to the deployer.

• forge build, forge test, and forge fmt --check pass.
• 28 unit/fuzz tests and both invariants pass.
• Clean offline verification reproduces identical bytecode.
• Dependencies are vendored; README documents assumptions, deployment, and operational responsibilities.

Done. The manifest is written and verified against the accepted tree.

What I wrote: launch.json at the repository root, the only file changed. It describes the single accepted contract, Coinbitc, as a custom_token launch:

• Token: contract Coinbitc, name Coinbitc, symbol COINBITC, 18 decimals, empty constructorArgs, totalSupply of 10^27 minor units. This matches the source, which mints one billion tokens with 18 decimals to msg.sender in a no-argument constructor. The compiled ABI confirms the constructor has no inputs.
• Contracts: an empty list. The accepted tree has no application contracts.
• Pool and economics: copied verbatim from the launch reference. Native ETH pair, fee 12500, tick spacing 60, the one-to-one sqrtPriceX96, and the requester's economics object with poolBps 8800, a 10 ETH opening cap, and the lowercase remainder address.
• Notes: a short description of the token's fixed supply, lack of privileged functions, and the factory's handling of the swarm share, pool seed and remainder. It is 807 characters, under the 4000 limit.

Checks run:

• forge build compiled cleanly with Solidity 0.8.26.
• forge test passed all 29 tests across both suites, including the 128-run invariant suite.
• A scratch script validated the manifest's key set, types, lowercase addresses, supply string, verbatim economics and notes length.
• git status shows launch.json as the only new or changed path.

The protected harness itself was not run locally because it depends on the network's Uniswap v4 and launch sources, which are not in this tree. Its requirements are satisfied by construction: the supply is exactly the manifest's, minted to the deployer, with no exemptions needed since every transfer is exact.

I found no defects in Coinbitc. .imd-findings.json holds an empty findings list and a coverage record; I changed no other files.

What I reviewed: src/Coinbitc.sol is 14 lines. It inherits the vendored OpenZeppelin v5.0.2 ERC20, which DEPENDENCIES.md says is unchanged; I read its code and saw no edits. The only thing Coinbitc adds is a constructor that mints 1_000_000_000 * 10 ** 18 (exactly 1e27, which matches the brief) to msg.sender. Against the Execution Trace, Periphery and First Principles guides:

• approve, transfer, transferFrom all hold:
  • The exact amount moves.
  • Calls revert on a zero address, a short balance or a short allowance, and a revert undoes everything.
  • An unlimited (max) allowance is not reduced on use.
  • There is no fee, burn or hook, so the transfers from the factory to the distributor, from the distributor to claimants, and the pool seed and swaps through the pool manager all arrive in full.
• Supply, roles and opcodes:
  • Nothing can mint after deployment.
  • There is no owner, pause, blacklist, freeze or burnFrom.
  • There is no assembly or external call, so no DELEGATECALL, CALLCODE or SELFDESTRUCT.
  • decimals() returns 18, and the name and symbol match the brief.
• Static analysis lead: aderyn's "large numeric literal" warning at src/Coinbitc.sol:12 is a false positive. The literal is written with underscores and works out to exactly 1e27.
• Existing tests: forge test passes all 29 tests, including the invariant suite (8,192 calls, no reverts).

The coverage record answers all three entry points (all holds) plus two invariant rows: fixed supply, and no forbidden opcodes with 18 decimals.

Not covered:

• There is no launch.json yet, so I checked no manifest.
• I didn't run the protected floor test here. It imports src/LaunchLiquidity.sol, PoolInitializationGuard.sol, HookFlags.sol and v4-core, and none of these are in this tree, so I assume the verifier supplies them.

I found no defects that I can back with a reproduction. .imd-findings.json is written with "findings": [] and a coverage record that answers all three entry points.

What the code is: src/Coinbitc.sol is a plain OpenZeppelin ERC-20. Its constructor mints 1,000,000,000 × 10^18 to msg.sender (the factory), and nothing else is added. The vendored OpenZeppelin files are unmodified v5.0.2: I downloaded the upstream archive, its SHA-256 matches DEPENDENCIES.md, and all six vendored files are identical to upstream. There are no fees, hooks, owner, mint, burn or exemption logic, and no external calls. forge test passes all 29 tests, including the stateful invariants.

Economic Security guide:

• Token misbehaviour: none. Transfers move exactly the stated amount, so these launch flows all arrive whole:
  • the 10% swarm share to the distributor and its claims;
  • the 88% pool seed;
  • the 2% remainder to the requester;
  • buys and sells settled through the PoolManager.
• ERC-20 compliance: holds. The function returns true, errors are custom errors, and type(uint256).max works as an unlimited allowance.
• Value extraction: none possible, since there are no owner or admin powers and nothing depends on a price.
• Allowance race: the standard approve race is documented in the README and is not a defect.

Invariant guide:

• The sum of balances equals totalSupply, which equals 10^27.
• The only mint is in the constructor, so the supply cannot grow.
• The unchecked blocks in _update are bounded by the balance check and the supply cap.

Flow Gap guide: I found no seams. There are no callbacks, no periphery calls and no address-dependent branches.

Static analysis lead: Aderyn's large-numeric-literal at src/Coinbitc.sol:12 is only about style; the value is correct.

Not covered:

• I could not run the protected launch harness (Token.protected.t.sol). It imports src/LaunchLiquidity.sol, src/PoolInitializationGuard.sol and src/HookFlags.sol, which aren't in this tree, plus launch environment variables, so the network's verifier runs it.
• There is no launch.json yet, so I couldn't check a manifest.

I changed no files apart from .imd-findings.json. Untracked entries like .bashrc and .gitmodules now show up in git status. They are character-device files mounted by the sandbox (the same device type as /dev/null), not real files and not something I created.

Review complete. The math audit of Coinbitc found no defects, and the findings file records an empty list with full coverage.

What was checked

• Source is a 14-line contract inheriting the unmodified OpenZeppelin v5.0.2 ERC20 and minting once in the constructor. The vendored library files are plain tracked files, not a submodule.
• Math Precision guide. The supply literal is a compile-time constant equal to exactly 10^27 base units, matching the README digits. The single checked supply increment cannot overflow. Balance updates run unchecked but are bounded by the supply, so no wrap is reachable. Decimals are fixed at 18 and match the scale of the literal. No division, downcast, or scale mixing exists in the token.
• Boundary guide. The token has no external calls, no payable or fallback paths, no bytes decoding, and no sentinel branches beyond the zero-address reverts. I probed 1 wei, full balance, balance plus one, self-transfer, max allowance, max-minus-one allowance, allowance equal to amount, and allowance above balance. All behave as the README documents.
• Numerical Gap guide. The launch split of 10, 88 and 2 percent of 1e27 divides with zero remainder, sums back to the supply, and every intermediate product fits comfortably in 256 bits. Transfers are exact, so the protected harness flows arrive whole.
• Static analysis lead. The aderyn large-literal note reproduces as an exact value, not a defect.

Verification run

• Existing suite: 29 tests passed, including 128 invariant sequences of 64 calls.
• Scratch probes: 11 additional boundary tests passed, then removed as instructed.
• Format check passed.

Coverage. All three entry points, approve, transfer and transferFrom, are marked holds with reasons, plus five invariant rows. Nothing was left unreached. The findings file is valid JSON at the repository root and no project file was modified.

The review is complete and found no defects. The findings file at the repository root holds an empty findings list and a seven-row coverage record. No project file was changed, and the scratch test directory was removed.

What I checked, from the Access Control, Asymmetry and Trust Gap guides

• Permission model. The token is a 14-line subclass of the vendored OpenZeppelin v5.0.2 ERC20 with a constructor mint. The ABI exposes only the constructor, three ERC-20 writers and six views. There is no owner, initializer, proxy, pause, blacklist, mint or burn entry point, and no payable path. All five vendored OpenZeppelin files hash identically to the upstream v5.0.2 tag.
• Inconsistent guards. Balances are written only by the internal update function and allowances only by the internal approve function, so there is no weaker parallel writer to exploit. The mint path is reachable only from the constructor, and the burn path is unreachable because transfers reject the zero receiver.
• Confused deputy. The factory holds the whole supply after construction but cannot pull from any holder without that holder's allowance. I verified the exact call the protected harness makes from the factory address reverts and leaves the holder's balance intact.
• Asymmetry. The approve and spend-allowance pair write the same slot with the same validation. The transfer and transferFrom pair share one internal path. The one documented difference, no Approval event on transferFrom, is upstream OpenZeppelin v5 behavior and the README states it.
• Trust gap seams. The token has no setter, oracle, fee recipient or pricing formula, so none of the four seams exists. The only trust assumption is that the factory distributes the ten, eighty-eight and two percent split outside the token, which is the network's design.
• Bytecode and launch floor. Creation and runtime code contain no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE. Transfers move exactly the requested amount, so the swarm share, claims, seed and swaps arrive whole. Decimals are 18, the contract name is 8 characters, and the constructor takes no arguments.

Extra checks beyond the existing suite. The project's 29 tests pass, including two stateful invariants. I added a scratch fuzz that sends random selectors and calldata from random callers for 2000 runs and asserts supply and a holder's balance never change, plus checks that ETH is refused and that transferFrom from the zero address reverts. All passed.

Static-analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note points at the compile-time constant that equals exactly ten to the twenty-seventh, confirmed by the tests. It is not a defect.

Not reported, by the guides' do-not-report rules. The standard ERC-20 approve race, a zero-value transferFrom needing no allowance, and tokens sent to the contract being unrecoverable are all documented in the README and carry no loss path.

Added 18 adversarial and fuzz tests, and expanded the suite to five stateful invariants covering balances, allowances, supply, and failure atomicity.

forge build and forge test pass: 47 tests, including 32,768 randomized invariant calls.

Only test/ files changed. No implementation defects found.

The review is complete. No defects were found, and the findings file records that with full coverage.

Outcome: .imd-findings.json holds an empty findings list and six coverage rows, all holds. The working tree is otherwise unchanged (the scratch test lives in the gitignored test/scratch directory).

What I verified

• Specialist input. All four specialists and the independent tester reported nothing, so there was nothing to reproduce or merge. I did my own pass instead.
• Source. The token is a plain OpenZeppelin v5 ERC-20 with a no-argument constructor minting one billion tokens with 18 decimals to the deployer. No owner, mint, burn, pause, blacklist, fee or hook path exists. The ABI exposes only approve, transfer and transferFrom as state-changing entry points.
• Entry points. For each of the three I traced the checks, state changes and revert paths in the vendored ERC20 and reproduced them in a scratch Foundry test: zero-address and insufficient-balance reverts, allowance spend and infinite-allowance behaviour, exact-amount transfers through a factory-to-distributor-to-claimant flow and a pool-manager-style pull of the pool share. The accepted suite of 47 tests, including invariants, also passes.
• Deployability. The manifest's empty constructorArgs match the constructor. CREATE2 deployment from a factory probe mints exactly the manifest's totalSupply to the deployer. Creation and runtime code are well under the size limits, and an opcode scan found no DELEGATECALL, CALLCODE or SELFDESTRUCT. Name, symbol, decimals and contract identifier match launch.json.
• Dependencies. The vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 archive, whose checksum matches DEPENDENCIES.md. The vendored forge-std differs from v1.9.7 only in whitespace, and it is test-only.
• Static analysis leads. Slither reported nothing. Aderyn's large-literal note points at the supply expression, which evaluates to the manifest value, so it is not a defect.

Not a finding, noted only: the pool's initialPrice is the sqrt price for 1.0 rather than one derived from the 10 ETH cap, but the launch rules state that field is provenance only and the deployer derives the real price, and the reference example uses the same value.