Zero To One (ZTO) is implemented and committed on main; forge build, forge test (27 tests, all passing) and forge fmt --check pass with solc 0.8.26. I could not run the protected launch test here, because it needs the network's own harness contracts, v4-core and environment values that this repository does not have.

• Token (src/ZeroToOne.sol): a self-contained ERC-20 with no constructor arguments that mints 1,000,000,000 × 10^18 to the deployer once. It has no owner, mint, burn, fee, pause, blocklist or external calls.
• Tests (test/): they cover success and failure paths for transfers and allowances, the absence of any admin or mint surface, a runtime opcode scan, fuzzed conservation, and an invariant that balances always sum to the fixed supply.
• Configuration: foundry.toml pins solc 0.8.26 with bytecode_hash = "none" and ffi off. forge-std v1.9.7 is vendored as ordinary files under lib/forge-std, with no submodule.
• Documentation (README.md): behaviour, launch parameters, assumptions and operational responsibilities.

The launch parameters documented are:

Share	Amount (ZTO)	Goes to
Swarm, 10% (fixed by the network)	100,000,000	the launch's distributor
Pool, 88% (poolBps 8800)	880,000,000	the single-sided pool
Remainder, 2%	20,000,000	0x7B8C742F2e1eEB3fB2C10d72967Fa6d4a22f0479

The starting market cap is recorded as 2500000000000000000000, which assumes IMD has 18 decimals. If it does not, that figure must be restated.

Choices and open items:

• Zero-address guards: transfers and approvals to the zero address revert. This is the usual ERC-20 convention rather than a transfer rule, but it means there is no way to burn.
• Unlimited allowance: an allowance of type(uint256).max is treated as unlimited and is not decreased.
• Left to the network's deployer: the IMD address, pool fee, tick spacing and sqrtPriceX96 are not fixed in this repository.
• No audit: no static analyser was run, and an independent review is still advisable before release.

Created launch.json with the exact token supply, constructor arguments, requested economics, and IMD pair.

Validation passed: supplied schema and ABI checks, offline build, all 27 tests, a second fuzz run with 1,024 cases, and formatting check.

Only launch.json is included in the deliverable changes.

Recorded no substantiated defects in .imd-findings.json, with all three entry points covered.

Offline build, formatting check, and both test runs passed, including 2,048 fuzz cases per fuzz test on the second run.

Full launch integration remains unverified because the manifest, service code, and protected-harness dependencies are absent. Source files were unchanged.

No substantiated defects found. Recorded all 3 entry points as holds in .imd-findings.json.

Offline build, formatting check, and tests passed, including a second seed with 4,096 fuzz runs per test. Source files remain unchanged.

Protected launch integration remains unverified because required contracts and launch inputs are absent; this limitation is recorded.

Recorded no substantiated defects in .imd-findings.json, with all three entry points covered.

Offline build, formatting, and both test runs passed, including expanded fuzz and invariant checks. Protected launch integration remains unverified because its dependencies and launch inputs are absent. Reviewed files remain unchanged.

Recorded no substantiated defects in .imd-findings.json. All three entry points are covered.

Offline build, formatting, and tests passed with two fuzz seeds. Full launch integration remained unverified because service dependencies and deployment inputs are absent.

Source, tests, and configuration were unchanged.

The review is complete. The findings file is written at the repository root, the scratch test directory is removed, and no tracked file changed.

Outcome: the ZeroToOne token has no defect that affects funds, supply, or the launch flows. All four specialists and the independent tester reported nothing, and I confirmed that by tracing the three entry points myself rather than relying on their verdicts. I kept one informational item that no specialist raised.

What I verified against the code

• approve rejects the zero spender, overwrites the allowance and emits. The overwrite race is standard ERC-20 and documented by the author as deliberate.
• transfer rejects the zero receiver and reverts on insufficient balance. The unchecked debit and credit cannot wrap because the sum of balances is the constant supply, and a self-transfer re-reads the debited slot.
• transferFrom checks allowance before balance, treats max as unlimited, and a revert inside the inner transfer rolls the allowance decrement back.
• The constructor mints exactly the manifest supply to the deployer, confirmed with a contract deployer standing in for the factory.
• An opcode scan of the compiled runtime and creation code found no DELEGATECALL, CALLCODE, SELFDESTRUCT or any external call.
• The manifest's economics copy the job, and the provenance sqrt price recomputes exactly. The paired currency address could not be checked because no network configuration was supplied, so that row is marked unreached.
• The existing 45 tests pass. The aderyn large-literal lead is a constant that folds to the correct supply.

The one finding, severity info: any caller can run transferFrom(address(0), to, 0) and the token emits a Transfer event from the zero address with value zero. Explorers that treat that shape as a mint will show spurious zero-value mints on a token that promises no minting. No balance or supply changes, and a non-zero amount from the zero address reverts on the allowance check, so this is cosmetic and does not need to block the launch. A one-line sender check in the private transfer helper closes it if the author wants parity with OpenZeppelin.