The BloxImd token is complete and verified. The whole project lives at the repository root as a Foundry project.

What was built

• src/BloxImd.sol is the token: contract name BloxImd, name "BloxImd", symbol "BLOX", 18 decimals. The constructor takes no arguments, calls no other contract, and mints the entire supply of one billion tokens once to the deployer. It inherits OpenZeppelin v5 ERC-20 with no owner, minter, pause, blacklist, fee, burn or upgrade path.
• script/DeployBloxImd.s.sol is a reviewable deploy script. Its deploy() function is tested directly and reads no environment.
• test/BloxImd.t.sol holds 27 tests covering metadata, the single mint and its event, CREATE2 deployment from a factory contract (mirroring the launch), successful transfers and allowances, reverts for insufficient balance, insufficient allowance and zero addresses, the absence of any mint or privileged call that could grow supply or freeze a holder, rejection of ETH, a bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and three fuzz tests for supply conservation and allowance enforcement.
• README.md documents behaviour, assumptions, launch parameters (chain, IMD pair, fee, tick spacing, economics), the standalone deploy procedure, the "After launch" section (nothing to set) and operational responsibilities.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", disables ffi, and declares remappings inline. forge-std v1.9.7 and OpenZeppelin Contracts v5.1.0 are vendored under lib/ as plain files from release tarballs, with no nested git metadata and no .gitmodules.

Verification results

The protected launch test's requirements are all met by construction: the supply is minted to the CREATE2 deployer, transfers are exact for every address, nothing can mint, no privileged call exists, and the runtime contains no forbidden opcodes. I did not write a launch.json or commit anything, as the brief reserves both for later steps. One open item for the launch's deployer is explorer verification after deployment, noted in the README.

I found no defects in BloxImd's permissions, so .imd-findings.json holds an empty findings list and five coverage rows.

What I reviewed: src/BloxImd.sol and the OpenZeppelin ERC20 it inherits (version 5.1.0 per its package.json; its transfer and allowance code reads as stock). I also read the deploy script and the launch-floor test supplied with the task, and checked the token against the Access Control, Trust Gap and Asymmetry guides. The project's own suite of 27 tests passes.

• Access control: the token has no owner, no roles, no modifiers and no admin functions of its own. Its only code is a constructor that mints 1,000,000,000 × 10^18 to msg.sender (the factory) once, plus decimals() returning 18. It can't mint after deployment, and nothing can pause, blacklist, freeze, seize or burnFrom a holder.
• Trust gap: the factory gets the whole supply but no special power afterwards. transferFrom always checks the caller's allowance first, and no address is exempt, so neither the factory nor anyone else can move a holder's tokens without approval.
• Asymmetry: nothing treats one address differently. There is no fee, burn or exemption list, so the factory → distributor → claimant flow and the PoolManager seed and swaps move exactly the amounts they state. approve, transfer and transferFrom keep the standard ERC20 checks: zero addresses are rejected, balances and allowances are checked, and an unlimited allowance is not spent down.

Coverage rows (all holds): approve, transfer, transferFrom, plus two invariants — "no privileged role and no supply growth after deployment" and "decimals = 18, name BloxImd, symbol BLOX."

Static-analysis leads: Aderyn's large-number note at src/BloxImd.sol:21 points at 1_000_000_000 * 10 ** 18, which is correct, so I didn't report it. I also left out the usual front-running risk of changing an existing ERC20 allowance: it applies to every ERC20, not to this design.

I didn't run the supplied launch-floor test, because it needs launch environment values I don't have. My reading is that the token meets its conditions.

Review complete. No defects found in the Math Precision, Boundary or Numerical Gap areas, and the findings file records an empty list with full coverage.

What the token is. BloxImd is a 32-line wrapper over OpenZeppelin v5.1.0 ERC20 with a constant supply minted once in the constructor. The five vendored OpenZeppelin files hash identically to upstream v5.1.0, so the inherited arithmetic is the audited code, not a modified copy.

What I checked, and the result.

• Supply constant: the expression on line 21 evaluates with checked EXP and MUL to exactly 1e27, which is 90 bits and fits uint96, uint112 and int128. The aderyn "large numeric literal" lead is not a defect.
• Launch split: 10%, 80% and 10% of 1e27 divide with zero remainder, and the intermediate products stay far below 2^256. No fee or rounding exists, so every launch flow delivers exactly what the factory sends.
• Transfer boundaries: amounts of 0, the full supply, supply plus one, and uint256 max, plus self-transfers and transfers to the token contract itself, all behave as the OpenZeppelin spec states. Sum of balances equals total supply under a fuzzed sequence of transfers.
• Allowance boundaries: max allowance is not decremented, max minus one is, exact allowance drains to zero and one more unit reverts, and the allowance check runs before the balance check.
• Boundary enumeration: the contract has no external calls, no payable or fallback path, no sentinel branches beyond zero-address rejections, and decodes no bytes.
• Supply growth: the ABI exposes no mint or burn; stray selectors fail and leave supply untouched.

Coverage record. All three entry points (approve, transfer, transferFrom) are marked holds, plus six invariant rows. The one standard-inherent note, ERC-20 approve front-running, is recorded as a coverage note and not a finding because it is a property of the standard rather than of this code.

Tooling. The 27 project tests and 16 scratch tests in test/scratch/MathBoundary.t.sol pass. Scratch files are gitignored and nothing in the tree outside .imd-findings.json was changed.

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

forge build succeeded; all 27 tests passed. Only launch.json is included in the deliverable.

The review is complete and the findings file is written. The working tree is unchanged apart from the ignored scratch directory and the findings file.

Outcome: no defects in the Economic Security, Invariant or Flow Gap areas. The token is a thin wrapper over OpenZeppelin v5.1.0 ERC-20 with one constructor mint, no owner, no fee, no hooks and no external calls.

What I verified

• Supply invariant. The constant at src/BloxImd.sol:21 evaluates to exactly the manifest supply. The constructor is the only mint path, and no burn selector is exposed. A CREATE2 deployment from a factory contract mints to that contract.
• Conservation. Sum of balances equals total supply across fuzzed transfer and transferFrom sequences, 2000 runs. Boundaries at 0, 1 wei and the whole supply behave as intended.
• Launch flows. The 10/80/10 split, the distributor claim, a balance-delta settle modelled on the v4 PoolManager, and a trader buy-and-sell all move exact amounts. The real PoolManager was not run here because v4-core is not vendored. The protected test covers it.
• Supply chain. The five library files the token compiles are byte-identical to the upstream v5.1.0 tag. The other differences in the vendored tree are formatting only.
• Static analysis lead. The aderyn large-literal note is the supply constant and is correct.

Reported: one informational entry for the standard ERC-20 allowance race, with a concrete sequence showing a spender taking 150 after allowances of 100 then 50. It is a property of the standard the brief asked for, so no change is recommended.

Coverage: all three entry points marked holds, plus seven invariant and flow rows. Nothing in my area was left unreached.

Done. forge build and forge test both pass with 63 tests across three suites, and no defects were found in the token, so no findings file was written.

What was already there. The accepted implementation is a minimal OpenZeppelin v5 ERC-20 with the supply minted once in the constructor and no privileged functions. The existing test/BloxImd.t.sol already covered metadata, the CREATE2 factory path, basic reverts and three stateless fuzz tests. I built on it rather than rewriting it.

What I added, in two new files under test/:

• test/BloxImd.invariant.t.sol is the handler-driven invariant suite the criteria required. A handler drives six actors, including the deployer, through transfers, self-transfers, approvals and transferFrom with bounded inputs, and keeps ghost books of every balance, every allowance, and per-actor sent and received totals. The failure paths are driven too: over-balance, over-allowance, zero receiver by both paths, zero spender, 23 privileged selectors from every actor, and ETH with random calldata. Each probe asserts the exact ERC-6093 revert in place and counts the attempt. Seven invariants check after every call: fixed supply, actor balances summing to the supply with nothing parked at the zero or token address, balances equal to the ghost flows, nobody spending more than received, allowances equal to the ghost book with the infinite sentinel never decremented, no privileged call or ETH ever accepted, and immutable metadata. Inline config sets 256 runs at depth 64 with fail-on-revert on. A scripted unit test walks every handler path once so the random campaign is known to be non-vacuous.
• test/BloxImd.edges.t.sol pins the edge inputs the original suite skipped: one wei, balance plus one, max uint, the same call twice, approve overwriting rather than adding, the owner needing a self-allowance for transferFrom, a reverted transferFrom leaving the allowance intact, transfers to contracts and to the token itself arriving whole, and the exact ten percent swarm share. Nine property tests at 1000 runs cover round trips, additivity, three-way conservation, exact delivery to any receiver, allowance arithmetic, atomicity of reverts, and unknown selectors never changing supply.

Grounding. Before trusting the invariants I ran the same handler in scratch against two mutants, a one percent burn-on-transfer token and a token with a public mint. The sum-of-balances and supply invariants caught the first, and the privileged-probe invariant caught the second. That scratch file is removed.

Nothing to report. No input I tried produced behaviour that differs from a plain fixed-supply ERC-20, so there is nothing for a findings file. Tokens sent to the token contract itself are stuck, but the README documents that as intended and it is standard ERC-20 behaviour, so I tested it as the behaviour it is rather than reporting it.

The review is done and found no defects. I wrote .imd-findings.json with an empty findings list and a coverage row for each of the three entry points, plus one for the fixed-supply invariant. I traced the code by reading it; I didn't run forge test, because no finding needed a proof.

• The code: src/BloxImd.sol is OpenZeppelin v5's ERC20 with nothing changed except a fixed decimals() of 18. The only mint is in the constructor: exactly 1e27 (1,000,000,000 × 10^18) to msg.sender. Nothing can mint afterwards, and there's no owner, fee, pause or transfer hook.
• Coverage: approve, transfer and transferFrom all hold. With no fee or hook, the factory's payouts, the pool seed and swaps move exactly the amounts they state.
• Specialist findings: only one came in, and I dropped it. The economics specialist flagged the allowance race (changing a non-zero allowance lets a spender spend the old amount and then the new one). That is how every standard ERC-20 behaves, not a defect in this code. The other specialists, the test writer and slither reported nothing, so there was nothing to merge.
• aderyn's lead: the "large numeric literal" warning at line 21 is the supply constant, written as 1_000_000_000 * 10 ** uint256(DECIMALS). It equals 1e27 and isn't a bug.
• Manifest: launch.json matches the token: contract name, empty constructor arguments, 18 decimals, total supply of 1e27, and no application contracts.