The CrawlHive token project is complete, verified, and committed on main as commit 0e68af9.

What was built

• src/CrawlHiveToken.sol is a plain OpenZeppelin ERC-20 named CrawlHive, symbol CRAWLHIVE, 18 decimals. The constructor takes no arguments and mints the whole 1,000,000,000 supply once to msg.sender, which on the launch is the factory. There is no owner, mint, pause, blocklist, fee, or upgrade path.
• test/CrawlHiveToken.t.sol holds 30 tests: metadata and supply, CREATE2 deployment from a factory stub, exact transfers and allowances, revert cases for balance, allowance, zero address and ether, the 10/88/2 launch flow and a claim, probes of every mint and freeze selector the floor tries, a runtime opcode scan, and three fuzz tests.
• script/DeployCrawlHive.s.sol is a local helper whose function the tests call directly. The README states it is not the launch path.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none" and disables cbor metadata, ffi and filesystem access.
• forge-std 1.17.0 and the five OpenZeppelin 5.4.0 files ERC20 needs are vendored as plain files with provenance notes. No submodules.
• README.md documents assumptions, the manifest values for the token, operational responsibilities, and an empty "After launch" section since nothing is owner-settable.

Verification

Check	Result
forge build (clean, empty env)	pass
forge test (clean, empty env)	30 passed
forge fmt --check	pass
Verifier's protected floor test, run in scratch against the built creation code	8 passed

For the protected test I assembled the factory's harness and a local v4-core copy in the scratch area, computed the CREATE2 token address, and seeded a single-sided pool against the IMD address. The seed and both swap directions succeeded. The scratch area was removed before the final clean rebuild.

No launch.json or blocked file was written. No open questions remain for the requester.

I found no defects in the economics area, so .imd-findings.json has an empty findings list plus a coverage row for each entry point and for the invariants I checked. The file is valid JSON, and no other file in the tree was changed.

What the code is: src/CrawlHiveToken.sol is a plain ERC-20 built on the project's vendored OpenZeppelin v5 ERC20. Its constructor mints 1,000,000,000 × 10^18 once to msg.sender, and decimals() returns 18. Nothing else is overridden: there is no _update override, owner, mint function, pause, blocklist, fee or burn.

How it measures against the three guides:

• Economic Security: the supply is fixed. _mint is called only in the constructor, and no privileged path can move, freeze or create tokens.
• Invariants: the total supply stays at exactly 1e27, and the decimals match the 18 the manifest will state.
• Flow Gap: there is no logic that runs on transfer. The factory sending the swarm's share to the distributor, seeding the pool, forwarding the remainder, distributor claims and buying from or selling into the PoolManager all move exactly the amount stated.

Coverage:

• approve, transfer and transferFrom are all marked holds; I traced them through OpenZeppelin's _approve, _spendAllowance and _update.
• approve has the usual ERC-20 risk where a spender can use the old allowance before a change lands. That applies to any ERC-20, not this token in particular, so it is not a finding.

Leads:

• The aderyn note (a large number written in the source at line 23) is only about how the number is written. The value is correct: 1,000,000,000 × 10^18.
• Slither reported nothing.

What I could not check: there is no launch.json yet, so I did not review the manifest. The project's own test suite passed 30 of 30. I did not run the separate launch test that is checked against (Token.protected.t.sol), because it imports pool-seeding code that isn't in this tree.

I wrote launch.json for the CrawlHive launch. It is the only changed file.

What the manifest says

• Kind is custom_token. The token contract is CrawlHiveToken, name CrawlHive, symbol CRAWLHIVE, 18 decimals.
• The constructor in src/CrawlHiveToken.sol takes no arguments, so constructorArgs is empty. It mints 1,000,000,000 tokens to msg.sender once, so totalSupply is 1e27 in minor units, matching the contract's TOTAL_SUPPLY constant.
• No application contracts exist in the accepted tree, so contracts is an empty list.
• Pool and economics are copied exactly as the launch gives them: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's verbatim economics object.
• Notes describe the token as a plain fixed-supply ERC-20 with no fees, exemptions, owner, mint, pause, blocklist or upgrade path, and state that no initialization calls are needed.

Verification

• A schema check confirmed only the allowed top-level keys, string uint256 and address values, lowercase addresses, a 32-character-safe contract name, and notes under 4000 characters.
• forge build compiled cleanly and forge test passed all 30 tests.
• git status shows launch.json as the sole new file. No configuration, lib, or test files were touched.

The review is complete. No defects were found in the Math Precision, Boundary or Numerical Gap area, and the report is written to .imd-findings.json with an empty findings list and eight coverage rows.

What the code is. CrawlHiveToken is an unmodified OpenZeppelin 5.4.0 ERC20 with a compile-time constant supply minted once in the constructor. It adds no arithmetic of its own beyond the supply constant, no external calls, no payable path, no fees, no burns and no owner.

What I checked and how.

• Diffed all five vendored OpenZeppelin files against the pinned upstream commit. All are byte-identical, so the inherited transfer and allowance math is the audited library code.
• Verified the supply constant is exactly 1e27 with no overflow, and that it agrees with the brief, the README and the declared decimals. The aderyn "large numeric literal" lead is a compile-time constant and not a defect.
• Wrote and ran a scratch Foundry suite covering zero, one wei, exact-balance, balance-plus-one, max uint256, self-transfer, zero-address, infinite allowance, max-minus-one allowance, exact and over-allowance transferFrom, and allowance preservation when a balance check reverts. Two fuzz properties ran over 2,000 cases each: balance conservation summing to the supply, and allowance decrement equal to the spent value. All 14 tests passed.
• The existing project suite also passes with 30 tests.

Coverage. All three listed entry points are marked holds, with five additional invariant rows for the supply constant, decimals, supply immutability, the absence of external boundaries, and the numerical-gap seams. Nothing was left unreached. The scratch test directory was removed, so the tree is unchanged apart from the findings file.

The review is complete and the findings file is written. The git status check fails only because the sandbox blocks reading the global gitconfig; it does not affect the deliverable.

Outcome: no defects found in CrawlHiveToken. The findings file holds one info-level note and ten coverage rows, all holds.

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

• approve, transfer, transferFrom through the inherited OpenZeppelin ERC20 to _approve, _spendAllowance, _transfer and _update. Every revert path, state write and event behaves as the standard specifies. No external calls, no fee, no hook, no reentrancy window.
• Constructor takes no arguments, makes no external calls, and mints exactly 1e27 once to the caller. Under CREATE2 from a factory stub the factory receives the whole supply, which is what the protected launch test requires.
• Periphery: the vendored OpenZeppelin files are byte-identical in code to the pristine mirror, differing only in header comments and import order. forge-std 1.17.0 only affects tests. The deploy script reads no keys and is not the launch path.
• Floor invariants: no mint, owner, pause, blocklist, freeze, seize or burnFrom entry point exists. The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT and is well within size limits. Slither run locally reported zero results at low impact or above, matching the verifier's output. The aderyn large-literal lead is the readable supply constant and not a defect.

The one info note records the standard ERC-20 approval overwrite race, reproduced in a scratch test (approve 100, spend 100, approve 50, spend 50 moves 150). It is inherent to the standard, already documented in the README, and I recommend no change, since non-standard approve semantics would break wallet and PoolManager integrations.

The scratch test directory was removed, so the tree is unchanged apart from .imd-findings.json.

The review is complete and the findings file is written and validated.

Outcome: no blocking defects in the assigned area. The token is an unmodified OpenZeppelin 5.4.0 ERC-20 with a single constructor mint, and its permission model is exactly the standard one. Both findings I recorded are informational and describe inherent ERC-20 behavior, not defects in this code.

What I checked:

• Access Control. Mapped every writer of the three storage variables. Balances move only by the holder (transfer) or by a spender within allowance (transferFrom). Allowances are written only by their owner, or decremented symmetrically on spend. Supply is written only in the constructor. There is no owner, role, initializer, proxy, receive or fallback, and the compiled ABI confirms only the three listed state-changing selectors.
• Asymmetry. Compared approve against transferFrom, transfer against transferFrom, and the mint and burn branches of the internal update. Only the external paths that reject the zero address are reachable. Self-transfer nets to zero.
• Trust Gap. No privileged actor and no economic formula exist inside the token, so no seam between lenses is present. The factory holding the full supply at deployment is the launch design and is recorded as a trust assumption.
• Dependency integrity. All five vendored OpenZeppelin files are byte-identical to upstream at the pinned commit, fetched during this review.
• Static-analysis lead. The large-literal lead at line 23 evaluates to the manifest supply and is style only.

Findings recorded as info, each with a reproduction run in a scratch test:

1. A zero-value transferFrom succeeds with no allowance and emits a Transfer event from an arbitrary address. This is the ERC-20 zero-value rule and no change is recommended.
2. The approve/transferFrom front-running race applies, as to every ERC-20. The README already documents it.

Coverage has 11 rows: the three entry points, the constructor, four invariants, dependency integrity and the trust-gap seams all hold. One row is unreached: the protected pool-seed and swap test cannot run here because Uniswap v4 core is not in the tree, though by inspection the untaxed token reduces those flows to plain transfers.

The scratch test lives under test/scratch/ and is gitignored. No tracked file was changed.

Everything passes and only files under test/ changed. No defects were found in the token, so no findings file was written.

What I added

• test/CrawlHiveToken.invariant.t.sol: a handler with the deployer plus five holders that drives transfer, approve and transferFrom with bounded inputs, and nine explicit failure handlers. These cover over-balance, over-allowance, the infinite allowance against an empty balance, the zero address as receiver, spender and sender, 22 would-be admin selectors from every actor, the deployer pulling without allowance, and ether sends. Each failure handler expects the exact ERC-6093 error. The handler keeps a ghost ledger of balances and allowances. Invariants check the supply is fixed, the actors' balances sum to the supply with nothing at the zero address or the contract, balances and allowances equal the ledger, metadata is immutable, and the token holds no ether. The run ends by checking both success and failure paths were exercised. Inline config sets 256 runs at depth 64 with fail-on-revert on.
• test/CrawlHiveToken.edges.t.sol: 24 unit tests and 6 fuzz tests at 1000 runs for inputs the existing suite skipped. These include the supply literal, independent double deployment, deploying from the zero address, one wei above balance and allowance, the maximum amount, the same transfer twice, tokens stranded at the contract, zero-amount transferFrom without allowance, the allowance-before-balance check order, self-pulls, max-minus-one allowances, overwrite rather than accumulate approvals, directional allowances, the missing Approval event on transferFrom, and a fuzz over unknown selectors.

Results

Suite	Tests	Result
Existing unit and fuzz	30	pass
Edge cases	30	pass
Invariants, 256 runs × 64 calls	1	pass, 0 reverts, stable across two seeds

One harness correction worth knowing. A transferFrom from the zero address with a zero amount reverts with ERC20InvalidApprover rather than ERC20InvalidSender, because OpenZeppelin updates the allowance before the sender check. That is a refusal either way and is pinned as such in both new files.

Assessment of the implementation. The token is unmodified OpenZeppelin 5.4 ERC20 with a constructor mint and a pure decimals override. The vendored library matches upstream, there is no privileged surface, and no property failed, so there is nothing to report.

The review is complete and .imd-findings.json is written at the repository root with two info-level findings and a nine-row coverage record. Git status shows only the findings file and the scratch test as untracked, both of which are expected outputs. No repository file was modified.

Outcome: no blocking defects. CrawlHiveToken is a plain OpenZeppelin 5.4.0 ERC-20 with a fixed supply minted to the deployer and no custom logic beyond a constant decimals() override.

Specialist findings, judged

• Approve race (reported by audit_permissions and audit_flow): same root cause, merged into one finding at info. Reproduced in a scratch test: a spender takes 50e18, the owner lowers the allowance to 20e18, the spender takes 20e18 more, ending with 70e18. This is the ERC-20 standard's own semantics, documented in the README. No change recommended.
• Zero-value transferFrom without allowance (audit_permissions): reproduced. It emits a zero-value Transfer event and moves nothing. Any value of 1 or more reverts with the expected allowance error. Kept at info, standard behaviour.
• audit_economics, audit_math, write_foundry_tests reported nothing, which matches my own tracing.

My own checks, all holding

• All five vendored OpenZeppelin files are byte-identical to the 5.4.0 npm package.
• Constructor takes no arguments and mints exactly the manifest supply to msg.sender, verified via a CREATE2 factory stub.
• Creation and runtime bytecode are well under the protocol size limits, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The ABI exposes only approve, transfer and transferFrom as state-changing entry points, so no mint, owner, pause or rescue path exists.
• The manifest uses only schema keys, with lowercase addresses, string uint256 values, and a supply string equal to the constant.
• The aderyn large-literal lint is style only. The constant evaluates to exactly 1e27.
• The existing 61 repository tests pass, as does my 4-test scratch probe.

One documentation nit I did not file as a finding: the README says launch.json is intentionally not included, but the manifest step has since added it. That is a stale sentence, not a code defect.