Implemented BloxIMD (BLOX) with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer.

Vendored dependencies and documented assumptions, deployment, and operational responsibilities.

Verified:

• forge build
• forge test: 26 passed, including 4,000 fuzz cases using the required seed
• forge fmt --check

Created launch.json matching BloxIMD’s constructor, exact supply, and required pool and economics.

forge build passed. All 26 tests passed with the supplied fuzz seed. Only launch.json is included for submission.

The review is complete. The findings file is written and the working tree is unchanged apart from it.

Result: no defects in the assigned area. BloxIMD is a two-line subclass of OpenZeppelin v5.1.0 ERC20 with one constructor mint, and every Math Precision, Boundary and Numerical Gap failure mode I checked holds.

What I verified

• Supply constant. The literal on line 10 evaluates to exactly 1e27 at compile time, equal to one billion whole tokens at 18 decimals. Operator precedence is correct and there is no overflow headroom concern.
• Arithmetic paths. The only arithmetic is inside OpenZeppelin's balance update and allowance spend. Both are guarded by an explicit comparison before the unchecked subtraction, so no underflow or wrap is reachable. Transfers of balance+1 and of 2^256-1 revert cleanly; self-transfer of the full balance preserves it.
• Allowance edges. The maximum value is treated as infinite, maximum-minus-one is finite and decrements exactly, and the allowance check runs before the balance check so failed calls revert atomically.
• Boundaries. No external calls, no payable or fallback path, no bytes decoding, no rounding or scaling anywhere. The only sentinel branches are the zero-address checks, which I traced on both sides.
• Library integrity. All five vendored OpenZeppelin files hash byte-for-byte to the upstream v5.1.0 tag.
• Static-analysis lead. The aderyn large-literal note is stylistic and the value is exact. Not a defect.

Evidence. The existing 26-test suite passes with the pinned fuzz seed. An 11-test scratch battery over zero, one-wei, full-balance, over-balance, maximum, self-transfer, odd-amount conservation and double-deployment inputs also passed. That scratch directory has been deleted.

Coverage record. The findings file holds eight rows marked holds: the three ABI entry points, the supply invariant, the conservation invariant, the external-boundary inventory, the vendored-library check and the static-analysis lead. Nothing was left unreached.

Out of my area, noted for the judge. No launch.json exists in the tree yet, which is expected before the manifest step runs. The token has no owner or privileged entry point, so there are no trust assumptions to document.

The review is complete and the findings file is in place. No defects were found in the assigned area.

Result: .imd-findings.json holds an empty findings list and 11 coverage rows. All three verifier-listed entry points are marked holds, with the remaining rows recording the invariants I checked.

What I traced (Execution Trace, Periphery, First Principles):

• approve, transfer and transferFrom through the vendored OpenZeppelin _approve, _transfer, _update and _spendAllowance paths, including zero-address, zero-value, full-supply, uint256.max and self-transfer boundaries, allowance residuals, and atomic failure.
• The constructor under CREATE2 from a factory-like contract: exactly 10^27 base units land at the factory address, decimals are 18.
• The launch flows in my scratch harness: distributor transfer, claim, pool seed, and a PoolManager-style balance-delta pull and take all arrive whole with supply unchanged.
• Periphery: the five vendored OpenZeppelin files are byte-identical to upstream v5.1.0, so no modified base contract hides behind the import.
• Runtime bytecode scanned with the protected test's exact loop plus cast disassemble: no DELEGATECALL, CALLCODE, SELFDESTRUCT, or any CALL/CREATE opcode. No receive or fallback, so the contract rejects ETH and unknown selectors.
• The aderyn large-literal lead evaluates to exactly 10^27 at compile time and is style only.

Checks run: forge build, the project suite with the README's fuzz seed (26 passed), forge fmt --check, and seven scratch trace tests (all passed, then removed). The protected Uniswap v4 harness could not be run locally since v4-core and its environment are not vendored, but its opcode and supply checks were replicated directly.

Documented trust assumptions, not defects: standard ERC-20 approval front-running and tokens sent to the token's own address being unrecoverable. Both are reproduced and already stated in the README as intended standard-token behaviour.

The review is complete and recorded in .imd-findings.json.

Outcome: no defect found in the Economic Security, Invariant or Flow Gap areas. The token is a verbatim OpenZeppelin 5.1.0 ERC-20 with one constructor mint of 10^27 base units to msg.sender and nothing else.

What I verified:

• Vendored dependency integrity. All five OpenZeppelin files were diffed against the cached upstream copy. They are byte-identical apart from version headers and one 5.2.0 gas tweak with identical semantics. No non-ASCII or hidden characters in source or library.
• Supply invariants. The literal evaluates to exactly 1e27. The constructor is the only supply writer, the compiled ABI exposes only approve, transfer and transferFrom as state changers, and a CREATE2 deploy from a factory stand-in holds the whole supply.
• Conservation. A 1000-run fuzz of 24-step mixed transfer, approve and transferFrom sequences kept the sum of balances equal to totalSupply after every step, with no allowance residuals.
• Launch flows. Swarm share, pool seed, remainder forwarding, claims, and PoolManager pay and pull all move exact amounts. The 10/80/10 split of 1e27 produces zero rounding dust.
• Floor checks. Runtime bytecode has no DELEGATECALL, CALLCODE or SELFDESTRUCT and is under the EIP-170 limit. Decimals return 18. The existing 26-test suite and build pass cleanly.

The one recorded item is info severity: the inherent ERC-20 approve-replacement race, with a concrete reproduction showing a front-running spender collecting old plus new allowance. It is standard behaviour, already documented in the README with the revoke-first mitigation, and needs no code change.

Coverage has nine rows. All three entry points and five invariants hold. The launch manifest row is marked unreached because no launch.json exists yet in this tree. When it is written it needs empty constructorArgs, decimals 18, contract name BloxIMD and the exact 10^27 totalSupply.

The scratch test directory was removed, so the working tree is unchanged apart from the findings file.

Review complete. The findings file is written and the tree holds no changes of mine beyond it.

Result: no defects found in the assigned area. .imd-findings.json contains two informational notes and ten coverage rows. All three verifier entry points are marked holds.

What I checked

• Access control: the token inherits only OpenZeppelin ERC20 and Context. The compiled ABI exposes exactly approve, transfer and transferFrom as state-changing functions. There is no owner, initializer, mint, burn, pause, blacklist, receive or fallback. The deployer has ordinary holder rights only after construction.
• Trust gap: the five vendored OpenZeppelin files are byte-identical to upstream v5.1.0, so the base the token trusts is untampered. _msgSender returns msg.sender, so no meta-transaction impersonation path exists. The constructor mints the full supply once to msg.sender, which is the factory in the launch flow.
• Asymmetry: transfer and transferFrom share one _update path with no fee, exemption or branch that treats one caller class differently. Allowance has one writer that sets and one that only decreases.
• Bytecode: an opcode scan of the compiled runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE or CALL-family instructions.
• Tests: the existing 26-test suite passes offline from a clean build. The aderyn large-literal lead is a compile-time constant equal to 1e27 and is not a defect.

Informational notes recorded

• The ERC-20 approve race when lowering a non-zero allowance. This is inherent to the standard and the README already documents the revoke-first mitigation.
• Zero-value transferFrom succeeds from any caller without allowance and emits a Transfer event. This is required by ERC-20 and moves nothing.

Both were confirmed with a scratch Foundry test that was deleted afterwards. No finding is high or critical, so no proof file was attached.

Added failure-path, boundary, and fuzz tests plus three stateful invariants under test/.

forge build and forge test pass offline with the required seed. Invariants passed 256 sequences totaling 32,768 calls.

No defects found. Existing implementation and configuration remain unchanged.

The review is complete and written to .imd-findings.json. The tree is otherwise unchanged (git status is clean apart from the findings file, which is ignored by the repo's gitignore).

Outcome: no defects. BloxIMD is a fixed-supply ERC-20 that inherits OpenZeppelin v5.1.0 unchanged and adds only a constant and a constructor mint of 10^27 units to the deployer. Everything I checked holds:

• Vendored library is genuine. I diffed all five files under lib/openzeppelin-contracts byte-for-byte against upstream v5.1.0. They are identical.
• Build and tests pass. The project's 49 tests, including invariants and seeded fuzz runs, pass. Formatting check passes.
• No privileged or dangerous surface. The ABI exposes only the ERC-20 functions plus the supply constant. The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, STATICCALL or SELFDESTRUCT. No receive or fallback.
• Launch flows are exact. No fee, tax or callback, so factory, distributor, pool seed and swaps move exactly what they say. Creation code is 2636 bytes, far under the limits.
• Manifest is consistent. Only schema keys, empty constructorArgs matching the parameterless constructor, supply and decimals matching the mint, lowercase addresses, notes under the limit.

Specialist findings. All three were informational and all reproduced as standard ERC-20 behaviour rather than defects. I merged the two approve-race reports from audit_permissions and audit_economics into one info finding and kept the zero-value transferFrom report as a second info finding, each with the exact reproduction I ran in a scratch Foundry test. Neither should reopen the author's work. The aderyn large-literal lead is a compile-time constant that evaluates to exactly 10^27, confirmed by test, so it was dropped.

Coverage. All three listed entry points are marked holds, with additional rows for the constructor, the fixed-supply invariant and manifest deployability. No proof files were needed since nothing reached high or critical severity.