Implemented Meme Witness Protection (ALIBI): 1 billion tokens, 18 decimals, minted once to the deployer, with zero transfer fees.

Added vendored dependencies, deployment documentation, and 30 passing tests covering success, failure, fuzzing, and invariants.

forge build, forge test, and forge fmt --check pass, including clean offline verification with an empty environment.

Created launch.json matching ALIBI’s constructor, exact supply, and requested economics.

Validation passed: supplied JSON Schema, compiled constructor ABI, forge build, and all 30 local tests.

Only launch.json is changed for submission.

The review is complete. The findings file is written and the scratch test is removed, so the working tree holds only the review record.

Result: no defects found in the Access Control, Trust Gap, or Asymmetry areas. The findings file at .imd-findings.json carries an empty findings list and nine coverage rows, all marked holds.

What I checked and how:

• Permission model. The compiled ABI exposes only approve, transfer and transferFrom as state-changing entry points, plus views. There is no owner, role, initializer, proxy, receive, fallback, pause, blacklist, mint, burn or upgrade path. A scratch Foundry test confirmed that ETH sends and unknown selectors revert, that the deployer cannot pull or approve on a holder's behalf, and that allowances are scoped exactly to one owner and spender pair.
• Constructor and roles after deployment. The constructor takes no arguments and mints the full supply once to the immediate caller. Under a CREATE2 factory the factory receives everything and the transaction originator receives nothing. No roles are handed out.
• Library integrity. The vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 release archive, whose hash also matches the repository's dependency record. There are no git submodules and the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Asymmetry pairs. transfer and transferFrom share the same validation and storage writes, differing only in the allowance debit. The burn branch of the internal update function is unreachable because nothing calls the burn helper and transfers to the zero address revert. The approve-emits but spend-does-not asymmetry is standard documented OpenZeppelin v5 behaviour.
• Trust-gap seams. With no fee, exemption list, recipient setter, oracle or privileged actor, no caller class is priced or treated differently, so the launch flows move exact amounts.
• Static-analysis leads. Slither reported nothing. The aderyn large-numeric-literal note points at a compile-time constant equal to one billion tokens in 18-decimal units, which cannot overflow. It is recorded as a note, not a finding.
• Tests run. The full suite passed (30 tests including 512-run fuzz and a 128 by 64 invariant run), formatting is clean, and my four scratch checks passed before being deleted.

Trust assumptions recorded for the judge rather than as defects: the factory holds the entire supply after construction and is the sole distributor, and holders carry the standard ERC-20 approve front-running race the README already documents. Uniswap v4 seeding and swaps were not executed locally because the protected harness needs launch-environment variables, but the token has no transfer hook or fee that could affect them.

The review is complete and the findings file is written. The git status shows no tracked changes; the findings file is the only untracked addition.

Outcome: no math, boundary, or numerical-gap defect found in the token. The report at .imd-findings.json holds one info-level note and seven coverage rows, all holds.

What I checked

• Math precision. The supply constant is a compile-time expression that evaluates exactly to one billion times ten to the eighteenth, matching the manifest and the inherited 18-decimal default. The token has no division, scaling, fee term, rate, or narrowing cast anywhere in its value path. Every unchecked block in the vendored OpenZeppelin _update and _spendAllowance is bounded by the preceding check or by the fixed supply, which sits far below the uint256 ceiling. The aderyn large-literal lead resolves to this exact constant and is not a defect.
• Boundary. The token makes no external calls, has no payable, receive, or fallback path, and decodes no bytes. Sending ETH with or without calldata reverts. The only sentinel branches are the zero-address mint and burn arms, unreachable after construction. I exercised exact-balance, balance plus one, zero-value, self-transfer, zero-recipient, and max-uint inputs on all three entry points.
• Numerical gap. With no arithmetic beyond exact add and subtract of caller-supplied amounts, no seam between precision, invariant, and boundary exists to exploit. The allowance sentinel is only triggered at exactly the max value. A value one below it decrements normally.

Verification run

• The existing suite passed: 29 unit and fuzz tests plus the invariant run of 8192 calls with zero reverts.
• My scratch tests under test/scratch/ passed on every real corner case and were removed afterwards. One scratch assertion failed only because I guessed the wrong OpenZeppelin error name for a zero-address sender. The contract reverts correctly either way.

One info note outside my area. The OpenZeppelin hashes in DEPENDENCIES.json all match the vendored files. Seven forge-std hashes do not. I diffed them against the upstream v1.9.4 archive and the differences are formatter line-wrapping only, so the test tooling is semantically unchanged. The note gives a one-line Python reproduction so the author can regenerate the digests or re-vendor the exact files.

The review is complete. The findings file is written at the repository root, is excluded from git by the repo's own info/exclude as intended, and no tracked file was changed.

Outcome. The ALIBI token has no economic defect I could substantiate. It is an unmodified OpenZeppelin v5.1.0 ERC-20 whose only mint is in the constructor, with no owner, fee, hook, callback, or privileged path. I reported one low-severity provenance defect outside my area.

What I checked in the Economic Security, Invariant and Flow Gap areas

• Verified the six vendored OpenZeppelin files match the digests recorded in DEPENDENCIES.json, so the ERC-20 under review is the real v5.1.0 code.
• Traced approve, transfer and transferFrom through the vendored implementation for fee, rebasing, blacklist, pause, void-return, sentinel-address and callback behaviour. None exist. Transfers to the zero address revert rather than silently burning.
• Wrote and ran a scratch test simulating the launch flows: CREATE2 deploy from a factory contract, the swarm share to a distributor, a seed credited through a sync-and-settle delta like the Uniswap v4 PoolManager, the remainder to the requester, a claim, and a buy and sell-back through approve plus transferFrom. Every leg moved exactly the amount paid and the fuzzed settle credit equalled the amount sent for all values from zero to the full supply.
• Confirmed the full supply fits in a signed 128-bit delta, so pool accounting cannot overflow.
• Confirmed the compiled ABI exposes only the standard ERC-20 surface plus the INITIAL_SUPPLY getter, and that mint, burn and burnFrom probes from the factory and from strangers all revert with supply unchanged.
• Ran the existing suite: 30 tests pass including 128 invariant runs holding sum of balances equal to total supply.

The one finding (low). DEPENDENCIES.json records SHA-256 digests for seven forge-std files that do not match the committed files. I downloaded the v1.9.4 archive, whose digest does match the recorded archive hash, and diffed the files. The difference is whitespace-only reformatting, and forge-std is a test-only dependency, so token behaviour is unaffected. The record is still wrong and would fail any offline integrity check. The reproduction gives the exact command, the recorded digests, and the actual digests.

Coverage. All three listed entry points are marked holds with reasons, plus rows for the fixed-supply invariant, the mint-to-factory invariant, the token-misbehaviour classes, and the provenance finding.

Static-analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note on line 10 is the supply constant, which uses the standard underscore-separated form and equals the manifest supply exactly, so it is not a defect.

Review complete. The findings file is written and validated.

Outcome: The token is a plain, unmodified OpenZeppelin v5.1.0 ERC-20 with a single constructor mint, and nothing in the Execution Trace, Periphery or First Principles checklists fails against it. I found one low-severity defect, in the provenance record rather than the token.

What I checked

• Execution flow. The three entry points, their sentinel paths (zero addresses, max allowance), allowance residuals, and atomicity of the allowance-spend-then-transfer sequence. A scratch test under test/scratch drove the launch flows the floor demands: factory mint via CREATE2 with a different tx.origin, transfer to the distributor, claim, approval-and-pull by a pool manager stand-in, remainder forwarding, and buy/sell transfers. Every flow moved exactly the stated amount and supply stayed fixed.
• Periphery. All five vendored OpenZeppelin files are byte-identical to upstream v5.1.0. The compiled ABI has only the three listed state-changing functions, no fallback or receive, no owner, and the project's opcode test confirms no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• First principles. The only path that increases supply is the constructor's mint. Decimals, name, symbol and supply match the brief. The constructor uses the immediate caller, not tx.origin, so the factory receives the whole supply.

Finding (low): DEPENDENCIES.json records SHA-256 hashes for 7 forge-std files that do not match the committed files. The committed copies differ from upstream v1.9.4 only by whitespace reflows, so the test harness is semantically upstream, but the record the README points to for provenance is wrong. Reproduction is a short hash-check script included in the finding.

Coverage: 8 rows. All three entry points hold, plus rows for the constructor, the supply invariant, the OpenZeppelin and forge-std periphery, and one unreached row for the live Uniswap v4 seed-and-swap test, which cannot compile here because v4-core is not vendored.

Expanded the tests with allowance lifecycle, arithmetic boundary, failure-path, and randomized invariant coverage.

forge build and forge test pass offline: 44 tests passed, including 32,768 invariant calls.

Only files under test/ changed. No implementation defects found.

The review is complete and the findings file is written. The token itself is clean.

Outcome: one low finding, three entry points all hold, no code changes made. The file .imd-findings.json is in the repository root and no tracked file was touched.

What I verified on the token

• The vendored OpenZeppelin ERC20 is byte-identical to upstream v5.1.0, so approve, transfer and transferFrom are the stock implementations. I traced each path, including zero-address, insufficient balance and insufficient allowance reverts, and the fixed-supply behaviour.
• The constructor mints exactly one billion tokens with 18 decimals to msg.sender once. The ABI exposes no mint, burn, pause, blacklist or owner function, which satisfies every probe in the protected launch harness.
• An opcode walk of the compiled runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT or any external call.
• The manifest's sqrtPriceX96 recomputes exactly from the supply and the opening cap, and the paired currency is the zero address.
• Build, format check and all 44 local tests pass. Slither reported nothing and the aderyn large-literal note is the intended supply constant.

The one kept finding All three specialists who reported something hit the same root cause, so I merged them into one low finding. Seven forge-std files under lib/ have whitespace-reformatted contents, but DEPENDENCIES.json still records the upstream digests. I re-fetched the v1.9.4 files myself: the recorded hashes match upstream exactly, and stripping whitespace makes upstream and committed files identical. This is a provenance-record defect only, test tooling only, and does not affect the token or its bytecode. The fix is either to restore the upstream bytes or to regenerate the seven digests.

Coverage record: seven rows, three for the listed entry points plus rows for the constructor, runtime opcodes, manifest provenance and dependency provenance.