Implemented Simdlaunch (SIMD): 1 billion tokens, 18 decimals, minted once to the deployer.

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

Verified with Solidity 0.8.26:

• forge build, including an offline rebuild
• forge test: 34 passed with the supplied seed
• forge fmt --check

Protected network integration tests remain for the verifier’s harness.

I found no defects in the permissions area (Access Control, Trust Gap and Asymmetry). .imd-findings.json holds {"findings":[]} and a coverage record with a row for each of the 3 entry points, all holds. It also has rows for the constructor and three invariants I checked. No tracked files were changed.

What I reviewed

• src/Simdlaunch.sol is 17 lines. It inherits OpenZeppelin v5.1.0 ERC20, and its constructor mints 1_000_000_000 * 10 ** 18 once to msg.sender.
• There's no owner, role, modifier, override, fee, exemption list or callback hook.
• I read the vendored ERC20.sol and Context.sol directly: approve, transfer, transferFrom, _update, _approve and _spendAllowance. All six vendored files match the digests in the library's own SHA256SUMS. That file is vendored too, so this only shows the files are internally consistent. I also read the code against upstream v5.1 logic.
• There's no delegatecall, selfdestruct or assembly anywhere in src/ or the vendored files.

Access Control

• Every state-changing path acts only on the caller's own balance or allowance (msg.sender).
• transferFrom spends the allowance before moving tokens, and the whole call reverts if either step fails.
• Nothing can mint after the constructor, and nothing can pause, blacklist, freeze or seize a balance.

Trust Gap

• No role survives deployment. The factory receives the full supply and gets no other power.
• The launch flows (factory to distributor, factory to PoolManager, trades) move exactly the stated amount.

Asymmetry

• transfer and transferFrom share one _update path with the same checks.
• Zero-address rules are the standard ones: no sending or approving to address zero.
• The only infinite allowance is type(uint256).max, as documented.

Leads I checked and dropped

• aderyn large-numeric-literal at line 12: this is the intended supply constant, 1e27. Not a defect.
• slither: reported nothing.
• Approve front-running race: standard ERC-20 behaviour, not a defect in this code, so I didn't report it.

Not covered: there's no launch.json in the tree yet, so the manifest wasn't reviewed. The protected floor tests import files that aren't in this tree (the floor checks, LaunchLiquidity, v4-core), so I couldn't run them here. The project's own 34 tests pass.

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

Verified manifest fields and compiled constructor ABI. forge build succeeded; forge test passed all 34 tests with the supplied fuzz seed.

The math review of Simdlaunch found no defects. The findings file is written with an empty list and six coverage rows.

What the token is. One constant and a constructor over an unmodified OpenZeppelin v5.1.0 ERC-20. I confirmed all five vendored OZ files are byte-identical to the upstream v5.1.0 release by SHA-256, so the arithmetic under review is OZ's _update, _mint, _approve and _spendAllowance.

Math Precision pass. The supply constant 1_000_000_000 * 10 ** 18 folds to exactly 10^27, checked with node. The only arithmetic is OZ's checked balance guard followed by unchecked subtract and add, both bounded by a total supply that is about 10^50 times below the uint256 limit. There are no divisions, casts, scale conversions or fees, so no rounding or truncation surface exists. The aderyn large-literal lead is this exact constant and is not a defect.

Boundary pass. Scratch tests exercised the edges and all behaved as intended:

• Transfer of balance plus one and of max uint revert with the correct insufficient-balance error.
• Self-transfer of the full balance by both transfer and transferFrom preserves the balance.
• Allowance exactly equal spends to zero. Allowance one short reverts. Max allowance is the infinite sentinel and is not decremented. Max minus one is decremented normally.
• An allowance larger than the balance is still bounded by the balance check.
• Zero-value transfers succeed. Zero-address sender, receiver and spender all revert.

Numerical Gap pass. Supply conservation held under fuzzing and under the project's own stateful invariant suite over 8,192 calls. The 10 percent and 70 percent launch allocations divide 10^27 exactly, and with no fee or hook every launch flow moves exactly what is sent.

Coverage. All three listed entry points are marked holds, with three extra rows for the constructor constant, the supply invariant and the launch-flow exactness. Nothing in the assigned area was left unreached. The scratch test directory was removed and the working tree is unchanged apart from the findings file.

The review is complete and written to .imd-findings.json. No files in the repository were changed, and the working tree is still clean apart from the findings file.

Outcome: no defects in the token. The contract is a 17-line wrapper over an unmodified OpenZeppelin v5.1.0 ERC-20 that mints 10^27 units to the deployer once. All three listed entry points hold, and the one finding is an info-level provenance note.

What I checked in my area:

• Execution Trace. Traced approve, transfer and transferFrom through the OpenZeppelin code to their storage writes and revert paths. No external calls, no callbacks, no sentinel path other than the documented unlimited-allowance case, and failed transferFrom calls roll back the allowance write.
• Periphery. Verified the six vendored OpenZeppelin files byte for byte against the upstream v5.1.0 archive, whose hash matches the one documented. Context uses plain msg.sender.
• First Principles. Constructor takes no arguments and mints to the immediate deployer, so the factory receives the whole supply under CREATE2. The ABI exposes no mint, burn, owner, pause or upgrade functions. The runtime bytecode has no reachable DELEGATECALL, CALLCODE, SELFDESTRUCT or any CALL-family opcode.
• Launch flows. Factory to distributor, claims, pool seeding and swaps are plain transfers that arrive whole, so the protected floor's transfer and supply checks are satisfied by construction.

The build and the project's 34 tests pass under the documented seed.

One finding, severity info. The vendored forge-std checksum file does not match seven of its files. I diffed them against the upstream v1.9.7 archive and every difference is whitespace only, consistent with the formatter having been run over the library directory. This is test tooling with no effect on the token, but the README and DEPENDENCIES.md claim the checksums were verified, and that claim fails as shipped. The fix is to regenerate the checksum file or exclude lib from the formatter.

Coverage has eight rows: the three entry points plus the constructor and four invariants, all holds except the forge-std row, which points at the info finding. No proof test was written since nothing reached high severity.

The review is complete. The findings file is written, the scratch test is removed, and no repository file was changed.

Result: no defects found in the economics area. The file .imd-findings.json holds an empty findings list and seven coverage rows, all holds.

What the token is. One contract, a stock OpenZeppelin v5.1.0 ERC-20 with a single constructor mint of one billion tokens at 18 decimals to the deployer. It adds no overrides, no owner, no hooks and no extra entry points. I confirmed the six vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 tag, and the compiled ABI exposes only approve, transfer and transferFrom as state-changing functions.

What I checked against the three guides.

• Economic Security. No external dependency, oracle or callback exists. Operations at reported maxima succeed, overdrafts and zero-address sentinels revert atomically, and no selector can grow or shrink supply. The 10/70/20 launch split divides the supply with no remainder.
• Invariant. Sum of balances equals total supply after randomized transfer sequences, in both the project's stateful suite and my own independent fuzz check. Finite allowances decrement exactly and the unlimited allowance is untouched.
• Flow Gap. A delta-measured settlement, as the Uniswap v4 PoolManager performs it, receives exactly the nominal amount in both directions, so the distributor transfer, pool seed, claims and swaps arrive whole. The reachable-opcode scan from the protected floor passes and the token rejects ETH.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note is a style remark on a compile-time constant that evaluates to exactly 10^27, not a defect.

Not covered. The protected integration test needs the network's v4 harness, which is not vendored here, so I did not execute a real PoolManager seed and swap. The ERC-20 approve race is standard behavior already documented in the README and was not reported as a finding.

Completed under test/ only. Added 18 boundary/fuzz tests and expanded invariants covering allowance transitions, failure rollback, and supply conservation.

Validation passed with the required seed:

• forge build
• 51 unit/fuzz tests
• 32,768 invariant handler calls

No implementation defects were reproduced.

Review complete. The findings file is written at the repository root and the tree is otherwise unchanged.

Outcome: the token is clean. The only finding kept is the one audit_flow reported, at info severity. The other three specialists and the test writer reported nothing, and my own pass found nothing to add.

What I reproduced:

• The forge-std checksum mismatch holds. Running the checksum file in lib/forge-std reports seven files FAILED. I downloaded the upstream v1.9.7 archive, confirmed its hash matches DEPENDENCIES.md, and showed that each of the seven files is identical to upstream once whitespace is stripped. The OpenZeppelin tree is byte-identical to the upstream v5.1.0 archive. Impact on the deployed token is none, since forge-std is test-only, so it stays info.
• The aderyn large-numeric-literal lead is the readable supply constant and is not a defect. Dropped.

My own pass: the contract is an unmodified OpenZeppelin ERC20 with one fixed mint to msg.sender in an argument-free constructor. No owner, mint, burn, pause or blacklist exists. The compiled runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT, has no link references, and is far under the size limits. The manifest matches the code on contract name, metadata, empty constructor arguments and supply. The repository suite of 52 tests, including the invariant suite with revert failure enabled, passes. The protected tests could not compile here because they need the service's Uniswap v4 harness, so I checked their conditions by hand instead.

Coverage: all three entry points answered as holds, plus rows for the constructor, manifest, deployability and the static-analysis leads.