Implemented Loom (LOOM): 1 billion tokens with 18 decimals, minted once to the deployer. No further minting or administrative powers.

Vendored dependencies and documented deployment parameters, assumptions, and operational responsibilities in README.md.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed: 28 tests, including fuzz tests and 8,192 invariant calls.
• forge fmt --check passed.

Created launch.json matching Loom’s constructor, supply, and required pool/economics values.

forge build succeeded; all 28 local tests passed. Only launch.json is changed for submission.

The review is complete. The findings file is valid JSON, the scratch directory is removed, and the working tree reports no changes outside the findings file.

Result: no defects found in the math, boundary, or numerical-gap area. The token is a 15-line fixed-supply ERC-20 inheriting OpenZeppelin v5.0.2 without overrides, so there is no division, scaling, downcast, external call, or payable path to break. The findings file holds an empty list and seven coverage rows.

What I verified, with concrete inputs:

• Supply constant. The literal flagged by aderyn evaluates to exactly 1e27, the figure the README and manifest use. It fits in uint96 and uint128, and the launch shares of 10%, 2%, 8% and 80% are exact multiples of 1e25 with no dust. The constructor mint is the only path that increases total supply, and no mint or burn entry point exists afterwards.
• transfer. Tested amount equal to balance, balance plus one, uint256 max, full-balance self-transfer, and zero amount. The checked underflow guard fires before the unchecked subtraction, and conservation held under a 256-run fuzz plus the project's 128-run invariant suite.
• transferFrom and approve. Tested max allowance staying sticky, max minus one decrementing by exactly the value, allowance one wei short reverting, allowance equal to balance equal to amount succeeding, and a zero-amount call with no allowance being a no-op. A zero-address owner reverts in the approval path.
• Library integrity. All five vendored OpenZeppelin files diffed byte-identical against the upstream v5.0.2 tag, so no modified arithmetic is inherited.

All three listed entry points carry a holds row. The remaining rows record the invariants and the library check. Nothing in my area was left unreached.

The review is complete and the findings file is written. Nothing else is needed.

Result: no defects found in the Economic Security, Invariant or Flow Gap areas. The findings file holds an empty list and eight coverage rows, one for each of the three entry points plus five invariant and area rows, all holds.

What the code is. src/Loom.sol is a 15-line contract inheriting OpenZeppelin ERC20 with a single constructor mint of 1,000,000,000e18 to msg.sender. It has no constructor parameters, roles, hooks, external calls or admin entry points.

What I verified.

• The five vendored OpenZeppelin files were fetched from the upstream v5.0.2 tag and diffed. All are byte-identical, so the inherited transfer, approve and allowance logic is the audited library code.
• The repository suite passes: 27 unit and fuzz tests and the 128-run stateful invariant with 8,192 calls and zero reverts. The formatter check also passes.
• A scratch test I wrote and then deleted confirmed the launch flow as the protected harness exercises it: CREATE2 deployment from a factory-like contract mints the whole supply to that contract rather than the transaction origin, the 10% / 80% / 10% split divides exactly, a transfer-then-balance-delta settlement in the PoolManager style receives exactly what was sent, distributor claims leave it whole, no mint-like selector changes supply, and a mixed transfer/transferFrom fuzz conserves balances.

Guides covered. All items in Economic Security (dependencies, token misbehaviour, atomic extraction, ERC compliance, sentinels, shared capacity), Invariant (conservation, couplings, caps, boundaries, view/write divergence) and Flow Gap (execution × periphery across the factory, distributor and PoolManager flows; constructor and first-caller state). Each was checked against the code and none applies. Nothing in my area was left unreached.

One note, not a finding. Tokens sent to the token's own address are stranded with no recovery path. The README documents this as intended plain-token behaviour and it is self-harm only, so it is recorded as a coverage note rather than a defect.

The review is complete and written to .imd-findings.json. No tracked file was changed; only the findings file and my scratch test under test/scratch/ exist, both ignored by git.

Outcome: no defects in the Access Control, Trust Gap or Asymmetry area. Loom is a 15-line contract that inherits OpenZeppelin v5.0.2 ERC-20 unchanged and mints the fixed supply once to msg.sender. There is no owner, role, initializer, proxy, setter, fee path or external call for any of the three guides' failure modes to attach to.

What I verified, each by an executed trace rather than by reading alone:

• Vendored library integrity. All five OpenZeppelin files hash-match upstream tag v5.0.2 byte for byte, so the inherited permission logic is the audited one.
• Entry-point surface. The compiled ABI exposes exactly the three state-changing functions the verifier listed, plus views. No selector reaches the internal mint or burn after construction.
• Role map after deployment. Under a factory deployment the factory holds the whole supply and the transaction origin gets nothing. The factory then has no residual power: once it sends tokens on, its transferFrom against the holder reverts like anyone else's.
• Permission symmetry. Deployer, stranger, factory and the token itself all fail identically when trying to move a holder's balance. Allowances are isolated by owner and spender, and a spender cannot raise its own grant.
• Sentinel branches. The zero address is rejected on every writer, so no caller can trigger the mint or burn branch of the shared update function.
• Runtime bytecode. A linear scan found no CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE, CREATE2 or SELFDESTRUCT opcode, which rules out callbacks and reentrancy on every path.
• Existing suites. The project's 28 unit, fuzz and invariant tests pass, and my 7 scratch probes pass.

The one item recorded is an info-level note, not a defect: approve replaces the allowance while transferFrom consumes it, which is the standard ERC-20 replacement race. I included the concrete 100-then-50 sequence so the judge can see it was checked. The README already documents the mitigation and no launch flow depends on allowance adjustment, so it asks for no revision.

The coverage record has nine rows, all holds: the three entry points, the constructor role map, the fixed-supply and no-freeze invariants, the exact-amount launch flows, the trust-gap seams, and the single aderyn lead on the supply literal. Nothing in the assigned area was left unreached.

Review complete. The Loom token has no defects in my area, and the findings file records that with full coverage.

Outcome. .imd-findings.json holds an empty finding list and nine coverage rows, one for each of the three listed entry points plus six invariants I checked. Git status shows no tracked file changed. The scratch tests I ran were deleted.

What I verified, by guide:

• Execution Trace. I traced approve, transfer and transferFrom through the vendored OpenZeppelin code into _approve, _spendAllowance, _transfer and _update. Zero-address senders, receivers and spenders revert. Insufficient balance or allowance reverts and rolls back allowance changes. An unlimited allowance is preserved. No path lets the factory or deployer move a holder's tokens without approval.
• Periphery. I fetched the upstream OpenZeppelin v5.0.2 tag and diffed all five vendored files. They are byte-identical, and the storage layout is the stock ERC-20 layout.
• First Principles. The constructor mints exactly 1e27 once to msg.sender. Under a CREATE2 deploy from a probe contract, the probe holds the whole supply and the transaction origin holds nothing. Redeploying at the same salt reverts without a re-mint. The compiled ABI exposes nothing beyond ERC-20 views, the three mutators and the supply constant. ETH and unknown selectors revert.
• Launch flows. A scratch test moved the swarm share, pool share and remainder from the factory, then a claim and buy-and-sell round-trip. Every balance matched exactly and supply was unchanged.
• Bytecode. An independent opcode scan of the runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE or CALL.

Leads considered and dropped. The ERC-20 approve front-running race is reproducible but is standard documented behavior, so it is not a defect. The aderyn large-literal line is style only, and the literal evaluates to the brief's supply.

For the manifest step. The constructor takes no parameters, so constructorArgs must be an empty list, decimals is 18, and the contract identifier is Loom.

Expanded tests for constructor minting, failure paths, allowance boundaries, and state rollback. Added independent balance and allowance invariants.

forge build and forge test pass: 44 unit/fuzz tests and 3 invariants over 16,384 randomized calls.

Only test/ changed. No defects found.

The review is complete and .imd-findings.json is written at the repository root. No source files were changed, and the scratch test directory was removed.

Outcome: no defects. The Loom token is a parameterless OpenZeppelin v5.0.2 ERC-20 that mints the manifest supply to msg.sender. I kept the single specialist finding as an info-level trust assumption and found nothing new.

What I verified:

• Vendored library integrity. All five OpenZeppelin files under lib/ are byte-identical to the upstream v5.0.2 tag.
• Supply and deployment. A CREATE2 deploy from a probe contract gives the whole supply to the deploying contract. Total supply equals the manifest value. Creation and runtime bytecode are far under protocol limits. The ABI has no mint, burn, owner, pause or blacklist entry point, and no DELEGATECALL or SELFDESTRUCT.
• Launch flows. Transfers to the distributor, pool and remainder addresses arrive exact. transferFrom consumes finite allowances, preserves the unlimited allowance, and a reverted transfer rolls back the allowance decrement.
• Manifest. launch.json uses only schema keys, with constructor arguments, name, symbol, decimals and supply matching the compiled contract.
• Tests. The project's 45 tests pass, and my scratch tests covering the points above all passed.

Specialist findings settled:

• audit_permissions, approve replacement race. Reproduced exactly as described. It is standard ERC-20 behaviour, already documented in the README, and no launch flow depends on adjusting an allowance. Kept at info with the reproduction, no revision needed.
• aderyn large-numeric-literal. The literal already uses separators and an exponent and equals the manifest supply. Dropped.

Coverage: all three entry points answered, plus rows for the constructor and supply invariant, the manifest, and the static-analysis leads.