Implemented BLOXToken.sol: BLOX IMD (BLOX), 18 decimals, exactly 1 billion tokens minted once to the deployer.

Dependencies are vendored. Tests and deployment/operations documentation are included.

Passed with Solidity 0.8.26:

• forge build
• forge test: 28 passed using the requested fuzz seed
• forge fmt --check
• Clean offline build and parallel tests

I found no economic defects in BLOX, so .imd-findings.json has an empty findings list plus coverage rows. I read the code and checked the JSON parses; I didn't run Foundry or the protected test harness.

src/BLOXToken.sol is a standard, unmodified OpenZeppelin ERC20. Its constructor mints exactly 1,000,000,000 × 10^18 (the 1e27 cap) once to msg.sender, which is the factory in the launch flow. Beyond that it adds nothing: no fee, burn, mint, admin or upgrade paths.

Coverage (all three entry points, plus one supply invariant):

• transfer: holds. It moves the exact amount with no fee or burn. So the launch flows arrive in full: the factory's transfer to the distributor, the pool seed through the PoolManager, distributor claims, and trader swaps.
• transferFrom: holds. It checks and reduces the allowance, then makes the same exact transfer. An unlimited allowance is not reduced, which is standard ERC20 behaviour.
• approve: holds. It changes no balances and has no economic side effects.
• Supply invariant: holds. Total supply stays at 1e27 and equals the sum of all balances, because no function can mint or burn after deployment.

The economic security, invariant and flow-gap guides found nothing to report. With no fees or exemptions, there is nothing that could make a launch flow arrive short. Aderyn's "large numeric literal" warning on line 12 points at the supply constant, which is the intended value, so it isn't a defect.

Created launch.json matching BLOXToken, its constructor and supply, with the exact required pool and economics values.

forge build succeeded; all 28 tests passed using the supplied fuzz seed. Only launch.json is changed outside scratch artifacts.

The review is complete and .imd-findings.json holds an empty findings list with a coverage record. The working tree is otherwise unchanged. The scratch tests I used were deleted.

Result: no defects found. The token is a 17-line fixed-supply ERC-20 on an unmodified OpenZeppelin base, and every path I traced in my area behaves as intended.

What I checked, by guide

• Execution trace. Traced approve, transfer, transferFrom and the constructor through the vendored base to the final storage write. Sentinel inputs behave correctly: zero sender, zero receiver, zero spender and zero-address from all revert, including at value zero, so no phantom mint from the zero address exists. Max allowance is not decremented and max minus one is, both as documented. transferFrom spends allowance and moves balance in one frame, so a failed transfer rolls the allowance back. The mint goes to msg.sender, not tx.origin, verified under CREATE2 from a factory-like contract.
• Periphery. All six vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 archive, whose hash matches the one recorded in the vendored README. The forge-std archive hash also matches, and its seven differing files differ only in whitespace. The compiled runtime has no receive or fallback, and no CALL, CREATE, DELEGATECALL, CALLCODE or SELFDESTRUCT opcodes outside push data. There are no immutables or link references.
• First principles. Name, symbol, 18 decimals and the one-time mint of exactly one billion tokens match the job and the manifest supply the launch requires. The contract identifier fits the 32-character limit, and an empty constructor argument list is correct. Nothing can grow or freeze the supply after deployment. The static-analysis lead about a large numeric literal is a compile-time constant evaluated exactly.

Verification run. The project's own 28 tests, including the 128-run stateful invariant suite, pass with the README's fuzz seed, and forge fmt --check is clean. My scratch probes for the boundary cases above also passed.

Coverage. All three listed entry points are marked holds, plus rows for the constructor, the constant-supply invariant, the opcode and fallback invariant, library integrity, and metadata conformance. Nothing in my area was left unreached. The protected launch-flow tests that need the Uniswap v4 harness were read, not executed, since that harness is not in the tree.

Review complete. No defects found in the assigned area; the findings file holds an empty list with full coverage.

What was reviewed. The token at src/BLOXToken.sol is a bare OpenZeppelin v5.4.0 ERC20 whose constructor mints the fixed supply once to the deployer. The three listed entry points, the constructor, and the inherited library were traced against the Access Control, Trust Gap and Asymmetry guides.

Why nothing was reported.

• No permission model exists to bypass. There are no roles, setters, initializers, hooks, proxies, fees or exemption lists. The ABI exposes only approve, transfer and transferFrom as state-changing functions, and plain or value-bearing calls to unknown selectors revert.
• Deployer holds no privilege beyond its balance. A scratch test confirmed the factory cannot pull a holder's tokens without an allowance.
• Vendored library is byte-identical to upstream v5.4.0 for all five files, so the sender context cannot be spoofed by a forwarder.
• Runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL, CREATE or ORIGIN opcodes. The supply cannot grow after deployment.
• Static analysis leads were checked. Slither reported nothing. Aderyn's large-literal line evaluates to exactly 1e27, which the repo test asserts.

Checks run. Build, the repo's 28-test unit, fuzz and invariant suite with the README seed, and format check all pass. Scratch probes for selector surface, deployer privilege, transfer symmetry and supply constancy passed and were deleted, leaving the tree clean.

Not covered. The owners floor test and the Uniswap v4 seed and swap integration need the network's harness and were not executed locally. The coverage record in the findings file states this.

Added 17 adversarial tests and expanded stateful invariants for failure paths, allowance rollback, supply conservation, and transfer availability.

Verified offline with the supplied seed: forge build and forge test pass—45 tests, 32,768 invariant calls, zero failures.

Only test/ changed. No implementation defects found.

The review is complete. .imd-findings.json is in place at the repository root with an empty findings list and a 14-row coverage record. No tracked file was changed. The scratch test lives under the gitignored test/scratch/ directory.

Outcome: no defects found in the assigned area. BLOX IMD is a 17-line OpenZeppelin v5.4.0 ERC-20 whose only arithmetic is the supply constant and the inherited balance and allowance updates. Every failure mode in the Math Precision, Boundary and Numerical Gap guides was checked against it with concrete inputs, and all of them hold.

What was verified, with evidence

• Supply constant. The literal product evaluates to exactly 10^27 and equals one billion times ten to the inherited 18 decimals. The README and reference manifest string has 28 digits, so it is the same value. The aderyn large-numeric-literal lead is a style lint, not a defect.
• Transfer and allowance edges. Zero value, exact full balance, balance plus one, uint256 max, self-transfer of the full balance, max allowance and max-minus-one allowance, zero-address sender and receiver, and zero-value transferFrom without an allowance all behave per ERC-20 and per the project's own documented intent.
• Overflow and rounding. There is no division, fee, scaling or downcast anywhere. The unchecked arithmetic in the vendored _update rests on the invariant that balances sum to the supply, which fuzzing and the project's stateful invariant suite confirm.
• Launch splits. The 10 percent, 88 percent and 2 percent shares of the supply divide with zero remainder and sum back to the supply exactly.
• Boundary enumeration. The token has no external calls, payable functions, receive or fallback, sentinel branches reachable from its entry points, or bytes decoding. ETH sends and unknown selectors revert.
• Protected floor. The opcode scan from the protected test finds no DELEGATECALL, CALLCODE or SELFDESTRUCT in the compiled runtime. Privileged selectors revert and the deployer cannot move a holder's balance.
• Existing tests. All 28 project tests pass with the pinned fuzz seed. My 8 scratch checks pass.

Coverage record. All three entry points are marked holds. Two rows are marked unreached because they are not in the tree: the launch.json manifest, which the manifest step has not written yet, and the deployer-side price and liquidity derivation, which lives in the network's deployer. For the latter I only sanity-checked that the opening price implied by 2,500 IMD against the supply sits well inside Uniswap v4's tick and sqrt-price range.

The review is complete. The findings file is valid JSON and the working tree shows only the untracked findings file, with the scratch test ignored by git.

Outcome: no defects found. The findings file holds an empty list and a coverage record of ten rows, all holds.

What the token is. src/BLOXToken.sol is a 17-line contract inheriting unmodified OpenZeppelin v5.4.0 ERC20. Its constructor mints exactly 10^27 units to its creator and it adds no other code.

What I verified.

• Reproduced the behaviour of the three entry points by tracing the inherited ERC20 code and by running the project's 45 existing tests plus a scratch replay of the protected floor's token-side checks. CREATE2 deployment at the launch salt, whole-supply mint to the creator, exact swarm, pool and remainder transfers, a pool-manager round trip, 22 privileged selectors from a stranger and the deployer, and refused ETH all behaved as intended.
• Confirmed deployability under the factory model: zero constructor parameters match the empty constructorArgs, no libraries or immutables, creation and runtime sizes are well under the limits, and the opcode scan found no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE.
• Downloaded the upstream OpenZeppelin v5.4.0 and forge-std v1.9.7 archives. Their hashes match the vendored manifest, every OpenZeppelin file is byte-identical, and the forge-std differences are whitespace only.
• Checked launch.json against the schema rules: names, types, lowercase addresses, supply equal to the mint, and economics matching the README's assigned values.

Specialist findings. All four specialists and the test writer reported nothing, so there was nothing to reproduce or merge. The static-analysis lead about the large numeric literal is a readability lint; the constant evaluates to exactly 10^27.

One limit to note. The real Uniswap v4 seed and swap through a PoolManager was not executed locally because the protected harness's v4 dependencies are not in the tree. I replayed only plain transfers to and from a pool-manager address, which is all a hook-free, fee-free ERC20 does in that flow.