Implemented SPAD with the exact requested name, 18 decimals, and 1,000,000,000 tokens minted once to the deployer. Dependencies are vendored; deployment parameters, assumptions, and operational responsibilities are documented.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed: 31 tests, including fuzz and invariant coverage.
• forge fmt --check passed.

Protected launch integration remains for the network’s configured harness.

Created launch.json with exact SPAD metadata, supply and economics, no application contracts, and a 0.3% pool fee.

Schema and constructor ABI checks passed. forge build succeeded; all 31 local tests passed. Only launch.json is a submission change.

The review is complete. The findings file is written with an empty findings list and full coverage.

Result: no defects found. The token is a 16-line wrapper over OpenZeppelin v5.0.2 ERC20 with no overrides, so every arithmetic path the Math Precision, Boundary and Numerical Gap guides target either does not exist or is the library's own checked code.

What I verified

• Vendored library is genuine. I re-downloaded the v5.0.2 archive. Its SHA-256 matches DEPENDENCIES.md and all six vendored files are byte-identical to upstream.
• Supply constant. The literal evaluates at compile time to exactly 10^27, fits uint256 and uint128, and is divisible by 10,000 so every basis-point split in the launch is integral. The aderyn large-literal lead is stylistic only.
• Transfer and transferFrom arithmetic. The checked balance and allowance guards precede the unchecked subtractions, and the unchecked recipient add is bounded by total supply. I exercised 1 wei, the full supply, supply plus one, max uint, max-minus-one allowance, self-transfers, zero amounts and a pranked zero address in a scratch suite. All nine tests passed, and the scratch directory is removed.
• Fixed supply and whole launch flows. Mint happens once to msg.sender, there is no burn or admin path, and transfers to the zero address revert. The existing invariant run and a three-way fuzz confirm balances always sum to the supply.
• Boundary enumeration. The token has no external calls, payable functions, sentinel branches or bytes decoding, so the Boundary guide's steps 2 through 5 have no call sites to apply to.

Coverage record has seven rows: the three ABI entry points plus four invariant and boundary rows, all holds. The existing suite of 31 tests passes and the shipped source and tests pass the format check.

The review is complete and the findings file is written. No tracked file was changed; the scratch test lives under the gitignored test/scratch directory.

Outcome: no economic, invariant or flow-gap defect in SPAD. One info-level provenance note was recorded.

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

• Token source. SPAD is the unmodified OpenZeppelin v5.0.2 ERC20 plus one constant and a constructor that mints the whole supply to the caller. The six vendored OpenZeppelin files are byte-identical to the upstream archive, whose hash matches the one recorded in the repo.
• Supply invariant. The constant folds to exactly 10^27, which matches the brief. Mint and burn are unreachable after construction, and the ABI exposes only approve, transfer and transferFrom as state changers. The delivered stateful invariant suite and my scratch tests confirm balances always sum to total supply.
• Launch flows. With no taxes, hooks, exemptions or external calls, the factory to distributor, pool and remainder transfers, distributor claims, and trader buy and sell round trips all move exact amounts. I fuzzed the pool share across the full allowed range of basis points.
• Allowance economics. Finite allowances decrement, the max allowance is sticky, and failed pulls roll back atomically. Neither the factory nor the deployer can move a holder's balance without approval.
• Other leads. The aderyn large-literal warning is not a defect. The token accepts no ether and has no forbidden opcodes. Formatting check and all 31 delivered tests pass.

The one finding, severity info. The dependencies document says vendored sources are unmodified, but seven forge-std files were reformatted with whitespace-only changes against the v1.9.7 archive. The code is semantically identical and forge-std is test-only, so this has no effect on the token. It is recorded with the exact comparison steps so the author can either restore upstream bytes or reword the sentence.

The coverage record answers all three listed entry points as holds, plus rows for the supply invariant, constructor minting, launch-flow exemptions, dependency integrity, and the static-analysis lead.

The review is complete and .imd-findings.json is written. No tracked files were changed.

Outcome: the SPAD permission model holds. The token is an unmodified OpenZeppelin v5.0.2 ERC20 plus one constructor mint. There is no owner, initializer, pause, blocklist, seize, burn, permit, receive or fallback path. The only state-changing entry points are the three ERC-20 ones, each scoped to the caller or to an allowance the holder set.

What I checked in my area, each against the Access Control, Trust Gap and Asymmetry guides:

• Access control. Enumerated every ABI function. The constructor hands out no roles and mints the full supply to the deployer, which is the factory under CREATE2. The deployer cannot pull a single wei from a holder without approval. Unknown selectors and any ETH value revert.
• Trust gap. No privileged actor exists, so no access-times-economics seam exists. The one trust assumption is by design: the factory holds the whole supply after construction and the launch economics are enforced by the factory, not the token.
• Asymmetry. Compared transfer against transferFrom and approve against spend. Validation, writes and revert rollback mirror correctly. The known approve-overwrite race remains, which I recorded as an info item since it is standard behaviour and the README already documents the mitigation.
• Supply chain. All five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag. No submodules. Build, the 31 existing tests and format check pass.
• Static analysis lead. The aderyn large-literal note resolves to exactly 10^27, matching the brief.

The findings file holds one info-level item with its reproduction and eight coverage rows covering all three listed entry points plus the constructor and the invariants above. My scratch probes live under test/scratch and are ignored by git.

Review complete. The findings file is written with an empty findings list and a full coverage record. No tracked file changed.

Result: no defects found in the Execution Trace, Periphery or First Principles areas for src/SPAD.sol. The token is a 16-line subclass of the vendored OpenZeppelin ERC20 that adds one constant and one constructor mint. Every state-changing path is inherited, unmodified, and I traced each to its final state.

What I checked and how

• Execution trace of all three entry points. Approve, transfer and transferFrom each enforce their zero-address guards, do the balance or allowance check before the unchecked subtraction, and move exactly the requested amount. A revert after the allowance write in transferFrom rolls it back atomically. No external calls, callbacks, fees, hooks or stale reads exist on any path.
• Constructor. The supply constant equals ten to the twenty-seventh and is minted once to the immediate caller. A scratch test deploys it through CREATE2 from a factory contract with a launch-number salt, confirms the predicted address, and confirms the factory holds the whole supply with nothing to the origin.
• Periphery. I downloaded upstream OpenZeppelin v5.0.2 into a fresh temp directory and compared every vendored file byte for byte. All five sources and the licence are identical, and the archive hash matches DEPENDENCIES.md. No git submodules are present.
• Compiled artifact. The ABI exposes only the three listed state changers. A disassembly of the deployed runtime contains no CALL, CREATE, DELEGATECALL, CALLCODE or SELFDESTRUCT. Plain ETH, value-bearing calls and unknown selectors all revert.
• Suites. The project's 30 unit and fuzz tests plus the stateful invariant pass. My five scratch probes under test/scratch pass. Formatting passes.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note is a style lead only; the literal evaluates to the correct supply, so I did not report it.

One assumption recorded, not a defect. The pinned Cancun target emits a single MCOPY opcode, so the launch chain must be post-Cancun. All current mainstream targets are. It is noted in the coverage record for whoever selects the chain.

Coverage rows answer all three listed entry points plus the constructor, four invariants and the vendored base, each with a verdict of holds.

Added 14 edge-case and fuzz tests, plus stronger invariants tracking balances, allowances, and failed-call rollback.

forge build and forge test pass: 45 tests, including 256 invariant sequences and 16,384 handler calls.

Only test/ changed. No implementation defects found.

The findings file is in place and excluded by the harness's own git exclude rule, as expected. The review is complete and no repository files were changed.

Verdict: no blocking defects. SPAD is a plain OpenZeppelin v5.0.2 ERC20 with a fixed supply of one billion tokens at 18 decimals, minted once to the deployer, with no owner, mint, burn, pause, blacklist, fee or initializer. Both specialist findings reproduced and are kept at info severity. Nothing new surfaced in my own pass.

What I verified

• Build and tests: the project compiles on Solidity 0.8.26 and all 45 tests pass, including the stateful invariants with zero reverts. The formatter check also passes.
• Entry points: approve, transfer and transferFrom all trace to unmodified OZ code with the expected revert paths and exact-amount movement. All three marked holds.
• Floor checks: the runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT or any CALL-family opcode. Supply cannot grow after construction.
• Manifest: name, symbol, decimals, empty constructor arguments and total supply match the compiled contract. The recorded initialPrice equals the stated formula exactly.
• Vendored dependencies: I downloaded both upstream archives. Their hashes match DEPENDENCIES.md. All six OpenZeppelin files are byte-identical. Seven forge-std files differ by whitespace only.

Findings kept, both info

1. DEPENDENCIES.md says vendored sources are unmodified, but seven forge-std files were reformatted. No effect on the token or tests. Fix the bytes or the sentence.
2. The approve/transferFrom allowance race is standard ERC-20 behaviour inherited unchanged. I reproduced it in a scratch test where a spender moved 150 tokens against an intended cap of 100. The README already documents the revoke-to-zero mitigation. No code change recommended.

Dropped: the aderyn large-numeric-literal lead, since the constant is the readable one-billion-times-ten-to-the-eighteen expression. Slither reported nothing.

The coverage record answers all three listed entry points plus four invariant rows.