Implemented BIT with 100,000,000 tokens, 18 decimals, minted once to the deployer. Included vendored dependencies, deployment documentation, and security notes.

Passed forge build, seeded forge test, and forge fmt --check, including offline verification: 34 unit/fuzz tests and both invariants passed.

Protected platform integration checks remain for the network verifier.

I wrote launch.json for the BIT custom token launch. It is the only new file in the tree, and nothing else was changed.

What the manifest describes. The accepted tree contains one contract, BIT in src/BIT.sol, which is a plain OpenZeppelin v5 ERC-20. Its constructor takes no arguments and mints the whole supply once to msg.sender. There are no application contracts. The manifest reflects that exactly:

• kind is "custom_token", token.contract is BIT, name and symbol are BIT, decimals is 18.
• constructorArgs is empty, matching the argument-free constructor.
• totalSupply is the constructor's mint in minor units.
• contracts is an empty list.
• pool and economics are copied verbatim from the launch terms, with IMD as the paired currency, fee 12500, tick spacing 60 and the one-to-one provenance price.
• notes describe the token's behaviour in about 1,300 characters, well under the limit.

Value	Written
totalSupply	100000000000000000000000000
economics.poolBps	8800
economics.initialMarketCapWei	1000000000000000000000
economics.remainderTo	0x0007b73c85c6b6e8a05fb612df6550219acb6946

Checks run. A script parsed the file and asserted the exact key set, the supply arithmetic, the verbatim economics and pool objects, and the notes length. The build compiled cleanly. The full test suite with the verifier's fuzz seed passed all 35 tests. Git status shows launch.json as the only addition.

The review is complete. The findings file is written, the working tree is unchanged, and the scratch tests are removed.

Result: no defects found in the math, boundary or numerical-gap areas. .imd-findings.json holds an empty findings list and six coverage rows, all holds.

What I checked, against the Pashov Math Precision, Boundary and Numerical Gap guides:

• Math Precision. The token has no division, fee, fixed-point scale, cast, shift or mixed-decimal arithmetic. The only arithmetic is OpenZeppelin's balance and allowance updates. The checked fromBalance < value guard precedes the unchecked subtraction, and the unchecked recipient addition cannot wrap because the sum of balances is fixed at 1e26. The aderyn large-literal lead is a compile-time constant that equals exactly 1e26 and 100_000_000 ether, so it is not a defect.
• Boundary. No payable function, receive, fallback, external call, sentinel branch or bytes decoding exists. Sending ETH or an unknown selector reverts and the contract balance stays zero. Zero-address sender, receiver and spender are rejected even at zero value.
• Numerical Gap. The invariant totalSupply == sum(balances) holds exactly, with no rounding anywhere to drift it. Zero-amount transfers take the same path as nonzero ones and skip no state update. The launch split of 1000, 8800 and 200 basis points divides the supply with zero remainder.
• Dependency integrity. All five vendored OpenZeppelin files are byte-identical to upstream commit dbb6104 (v5.0.2), so the inherited arithmetic is the audited library code.

Verification run locally:

Suite	Result
Existing unit and invariant tests	35 passed, invariant 128 runs x 64 depth, 0 reverts
Scratch boundary probes (max uint, supply+1, max-1 allowance, 1 wei, zero value, split/merge fuzz)	11 passed

Not reached: nothing in the assigned area. The Uniswap v4 seed and swap flow from the protected test was not executed here because its v4-core dependency is not in this tree, but since the token applies no transfer tax, the amounts it moves are exact by construction.

The review is complete with no defects found. The findings file is written and the tree is otherwise unchanged.

Result: no findings. The token is a 15-line fixed-supply ERC-20 with no privileged role, so the Access Control, Trust Gap and Asymmetry guides have nothing to bite on. Every failure mode in those guides was checked against the code and none is reachable.

What I verified:

• Permission model. The compiled ABI has exactly three state-changing entry points, approve, transfer and transferFrom, all scoped to msg.sender. There is no owner, minter, pauser, blacklist, burn, upgrade, receive or fallback. Twenty probed admin selectors revert identically for the deployer and a stranger.
• Trust gap. The deployer holds the whole supply after construction, which is the factory under launchCustom. It has no power over any other holder: a transferFrom from the deployer with zero allowance reverts and the holder's balance is unchanged.
• Asymmetry. transfer and transferFrom write the same storage in mirror directions, move exactly the requested value, and share one revert path. Finite allowances decrement exactly and the max allowance is untouched.
• Supply. totalSupply is written only when from or to is the zero address, which the public transfer paths reject, so it is fixed after the constructor.
• Library provenance. All five vendored OpenZeppelin files are byte-identical to the pinned v5.0.2 commit in DEPENDENCIES.json.
• Tests. The full suite passes with the README seed, 34 unit and fuzz tests plus 2 invariants over 8,192 handler calls with zero reverts. My scratch test of the access surface passed 5 of 5 and was removed afterwards.

Static-analysis leads were both dead ends. Slither reported nothing. Aderyn's large-literal note at line 10 of the token is a style remark on an expression that evaluates to exactly the stated supply.

The findings file holds an empty findings list, nine coverage rows marked holds for the three entry points, the constructor and five invariants, and a notes field recording scope, methods and the one thing I could not check. That gap is launch.json, which does not exist yet in this tree, so manifest consistency was checked only against the README's stated values, all of which match the compiled artifact.

The review is complete and the findings file is written. The tree is otherwise untouched.

Outcome: no economic, invariant or flow-gap defects found. BIT is an unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint of 100,000,000 tokens at 18 decimals to the deployer. The file .imd-findings.json holds one informational note and nine coverage rows.

What I verified:

• Vendored library integrity. The five files under lib/openzeppelin-contracts were diffed byte-for-byte against the upstream commit pinned in DEPENDENCIES.json. They are identical, so there is no tampered accounting hidden in the dependency.
• Supply invariant. The only mint is in the constructor. The compiled ABI exposes only approve, transfer and transferFrom as state-changing entry points. Total supply cannot grow or shrink after deployment.
• Conservation. Every transfer debits and credits the same amount with no fee, burn or rebase. Transfers to the zero address revert, so no path reduces supply.
• Launch flows. The factory, distributor, claimant and Uniswap v4 PoolManager legs all move exactly the requested amount. No exemption list is needed because nothing is taxed.
• Manifest agreement. The constant equals the manifest supply in minor units, decimals are 18, and the constructor takes no arguments and makes no external calls.
• Build and tests. The project compiles and all 35 tests plus both stateful invariants pass with the documented seed.

The one informational item is the standard ERC-20 approve race, where a spender acting between two approve calls can move the old plus the new allowance. I confirmed it with a scratch test and recorded the exact call sequence. It is inherent to the standard, is already documented in the README, and is not a launch-floor blocker. The note suggests ERC-2612 permit as an optional design-preserving mitigation.

Coverage: all three listed entry points are marked holds, with six additional rows for the invariants, launch flows, dependency integrity and constructor parameters I checked. Nothing in my area was left unreached.

The review is complete. The findings file is in place, the working tree has no tracked changes, and the scratch tests are removed.

Outcome: no defects found in BIT. The token is a 15-line wrapper over an unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint of 1e26 base units to msg.sender, no constructor arguments, no admin, mint, burn, pause, fallback or receive paths.

What I checked, in my assigned area:

• Execution Trace. Traced approve, transfer and transferFrom from entry to storage. Zero-address sentinels revert, balances and allowances are checked before subtraction, self-transfers preserve balance, a failed delegated transfer reverts the allowance update, and no external call or callback exists. The one "approval residual" is the inherent ERC-20 approve ordering race, reported at info since the README already documents it and no code change is required for the agreed design.
• Periphery. All five vendored OpenZeppelin files hash byte-identical to the pinned upstream commit, so the base contract is untampered. Context returns plain msg.sender.
• First Principles. The constructor is non-payable, the creation code carries no arguments so a manifest constructorArgs of [] is correct, decimals are 18, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Verification run: forge build, the full 35-test suite with the README's seed, forge fmt --check, and six scratch probes covering the approve race, zero-value delegated transfers, raw CREATE with value, self-transferFrom at max allowance, and unknown selectors. All passed as the standard specifies.

Coverage record: all three listed entry points plus the constructor and four invariants are marked holds. The aderyn large-literal lead is the 1e26 constant and matches the spec exactly. Nothing in my area was left unreached. Launch-side items outside this repository, such as the manifest and chain selection, were not reviewable here because no launch.json exists yet.

Done. The full suite passes with the verifier's seed and without it, and no defect was found in the token, so there is no findings file to write.

What I found. The token in src/BIT.sol is an unmodified OpenZeppelin v5.0.2 ERC-20 with one constructor mint of 100,000,000 BIT to the deployer, no owner, and no mint, burn, pause or upgrade path. I read it adversarially and against the protected floor test. It meets every check the floor applies: manifest supply to the factory, 18 decimals, no privileged selector that grows supply or moves a holder, no DELEGATECALL, CALLCODE or SELFDESTRUCT. Nothing to report.

What I added, building on the existing unit and invariant files rather than rewriting them. All four files are under test/ only; no config, library or source file was touched and no dependency was installed.

• test/BIT.launchFloor.t.sol mirrors the protected floor locally. A probe etched at the factory address deploys the token through CREATE2 in one call, salted with the launch number, and checks the address prediction. It tries the floor's exact admin and privileged selector lists from both a stranger and the factory, and asserts each call reverts and moves nothing. It also covers the complete swarm, pool and remainder flow that empties the factory to zero, the factory failing to spend a holder's allowance it was not given, the constructor rejecting ether, the token rejecting ether and unknown selectors, a reused salt, a manifest supply that disagrees, and a scan for unlinked library placeholders.
• test/BIT.properties.t.sol holds 22 stateless fuzz properties at the edges: the supply mints to whoever deploys, round trips restore balances, split transfers equal one transfer, the boundary between an allowance of max minus one and max, exact allowance spends to zero and one wei further fails, last-write-wins approvals, and every failure path leaving balances and allowances untouched.
• test/BIT.adversarial.invariant.t.sol is a second invariant suite that mixes valid operations with attacks in random order: overdrawn transfers, spends past an allowance, transfers to and from the zero address, 22 privileged selectors from the deployer and strangers, and ether sends. Every rejected call is checked for its exact ERC-6093 error and for unchanged state. Recipients include fresh fuzzed addresses and the token contract itself as a sink. Six invariants compare the whole touched ledger and allowances against the chain after every call.
• test/helpers/LaunchProbe.sol is the factory stand-in those tests drive.

Verification. 72 tests pass across 5 suites, including 8 invariants over 24,576 handler calls with zero reverts. The new files pass forge fmt --check. In scratch I pointed the adversarial handler at two mutant copies of the token, one with a one percent burn on transfer and one with a public mint, and the invariants failed on both within the first run, so the properties are not vacuous. The one failure during development was my own oracle: with a zero amount, OpenZeppelin rejects spending from the zero address with ERC20InvalidApprover rather than ERC20InvalidSender. I corrected the expected error, since the behaviour is correct.

The new files are left uncommitted in the working tree for the submission step to pick up.

The review is complete and the findings file is written. The tree is otherwise unchanged (git status is clean apart from the ignored findings file; the scratch test was removed after running).

Outcome: no blocking defects. The token is an unmodified OpenZeppelin v5.0.2 fixed-supply ERC-20, and the one specialist lead reduces to a documented standard-ERC-20 property.

What I verified

• Code and library. All five vendored OpenZeppelin files diff byte-identical to upstream commit dbb6104 (v5.0.2). The constructor mints 1e26 units once to msg.sender, and the ABI exposes only approve, transfer and transferFrom as state-changing, with no receive, fallback, owner, mint or burn paths.
• Tests. The project suite passes with the pinned seed (72 tests, including ledger invariants with zero handler reverts).
• Deployability. Creation code is 2,614 bytes and runtime 1,751 bytes. The runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE opcodes, and metadata is limited to the solc version tag.
• Manifest. launch.json uses only schema keys, empty constructorArgs matching the argument-less constructor, the exact minted supply, 18 decimals, lowercase addresses, and the pool and economics values given for this launch.
• Static-analysis leads. Slither reported nothing. The aderyn large-literal note is a style lint on a compile-time constant and was dropped.

Findings reported

1. Info, merged from audit_flow and audit_economics: the inherited approve ordering race. I reproduced it with a scratch Foundry test: after approve(50e18), a front-running transferFrom, approve(7e18) and a second transferFrom, the spender holds 57e18. This is standard ERC-20 behaviour, already documented in the README with the approve-to-zero-first mitigation, so it is recorded as a trust assumption and does not open a revision.

Coverage record: all three entry points answered, plus rows for the constructor and supply, privileged entry points, bytecode floor, dependency integrity, the manifest and the static-analysis leads.