Implemented YOLO: name yolo, symbol YOLO, 18 decimals, and 1 billion tokens minted once to the deployer. No later minting or administrative powers.

Included vendored dependencies, tests, and deployment/operations documentation.

Verified with Solidity 0.8.26:

• forge build passed
• forge test passed: 28 tests, using the supplied fuzz seed
• forge fmt --check passed

Created launch.json with custom_token, the exact supply and constructor arguments, and the specified pool and economics.

Offline build and all 28 tests passed with the required seed. Formatting, size checks, and Slither passed. Only launch.json is a submission change.

I added two test files on top of the existing suite. forge test passes with the verifier's fuzz seed: 46 tests across 4 suites, none failing or skipped.

test/YoloToken.model.invariant.t.sol: invariant tests that check the token against a separately kept record of what every balance and allowance should be.

• Setup: six holders, including the token contract itself and the test contract. They start uneven: almost the whole supply on one holder, 1e18 on another, 1 wei on a third, nothing on the rest.
• Normal actions: transfer, approve (including the unlimited approval) and transferFrom, with amounts kept within what each holder can actually spend.
• Failure actions: each must revert with the exact OpenZeppelin error and leave everything unchanged:
  • sending more than the balance;
  • spending past the allowance;
  • spending within the allowance but past the balance;
  • sending to the zero address, by transfer or transferFrom;
  • calling with a random unknown function selector.
• What must always hold:
  • total supply stays at exactly 10^27;
  • the holders' balances add up to the supply, and nothing ends up at the zero address or the test helper;
  • every balance and every allowance matches the separate record.
• Run counts: 256 runs × 64 calls, set inside the file. All 16,384 calls succeeded with no unexpected reverts.

test/YoloToken.edges.t.sol: 17 unit and fuzz tests for edge cases:

• the launch flows done in one call through a helper contract: deploy, 10% to the distributor, a fuzzed pool share, the remainder to the requester, each arriving whole;
• one-wei balance limits, an allowance spent exactly to zero, an allowance one below the maximum (it still goes down), and an unlimited allowance still limited by the balance;
• allowances only work one way and per owner, and approving yourself still gates transferFrom;
• contracts holding and spending the token;
• the token refuses ETH and unknown calldata, and has no permit, increaseAllowance, rescue or ownership functions;
• fuzzed checks: a transfer and its return restore both balances, the last approval replaces earlier ones, and split transfers add back up to the supply.

Findings: none, so I didn't write .imd-findings.json. src/YoloToken.sol is a plain OpenZeppelin ERC-20 that mints 10^27 once to whoever deploys it, has no admin functions and no way to mint later, and takes no fee on transfer. One thing worth knowing, though it isn't a defect: tokens sent to the token's own address are stuck there for good, because there is no rescue function. A test records this.

I changed nothing outside test/, installed nothing, and haven't committed the two new files.

The findings file is valid and the snippet matches the tree. The working tree is clean apart from the findings file, and the scratch directory has been removed.

Result: the math area is clean. .imd-findings.json holds one low-severity finding outside the assigned area and a coverage record for all three entry points plus three invariants.

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

• Supply constant. The literal compiles to exactly 10^27, which matches the manifest's minor-unit supply and divides back to one billion whole tokens with zero remainder. The checked mint cannot overflow from zero. Aderyn's large-literal line is cosmetic only.
• Transfer arithmetic. OpenZeppelin v5.0.2's _update is unchanged. Its unchecked subtraction and addition are bounded by the balance check and the fixed supply, so no wrap is reachable. Self transfers, zero-value transfers and a max-uint value all behave as intended, and the sum of balances equals total supply exactly because there is no rounding anywhere.
• Allowance arithmetic. Max allowance is infinite and not decremented, max minus one is finite, and overspend reverts before any balance change. Reverts roll back the allowance decrement.
• Launch split math. Ten, two, eight, sixty and thirty percent of this supply are all exact with no truncation. Supply times basis points cannot overflow, and the seed amount fits Uniswap v4's signed 128-bit deltas.
• Boundaries. No external calls, no payable or receive or fallback, no bytes decoding, no sentinel branches beyond the zero-address guards. Decimals are the OpenZeppelin constant 18.

Ran the shipped suite with the README seed, plus scratch probes for the edge cases above. All 28 shipped tests pass.

The one finding, outside my area. The README tells reviewers to verify vendored dependencies with sha256sum -c lib/SHA256SUMS, and that check fails for seven forge-std files. The recorded hashes are the genuine upstream v1.9.7 values, which I confirmed by fetching those files. The committed copies differ only by line wrapping, consistent with forge fmt having touched lib/. No semantic change, test-only dependency, so low severity. The fix is to restore the upstream bytes or regenerate the hash file, and to exclude lib/ from the formatter.

Not reached. Nothing within the assigned area was left unexamined. I did not run the protected pool-seeding harness since it needs the launch environment's addresses, which are not in this repository.

Review complete. The findings file is written and validated.

Outcome. The token itself has no defect in my area. The one finding is low severity and concerns the vendored test dependency, not the token's code or bytecode.

What I checked (Execution Trace, Periphery, First Principles).

• Traced approve, transfer and transferFrom through the inherited OpenZeppelin 5.0.2 paths: zero-address guards, balance and allowance checks, infinite-allowance handling, unchecked arithmetic bounds, atomic rollback of the allowance decrement when the transfer reverts, self and zero-value transfers. All behave as specified, and the launch flows move exact amounts because there is no fee, hook or callback.
• Constructor mints exactly 10^27 to msg.sender once, which is the factory under CREATE2. No arguments, no allocations, no admin role.
• Runtime bytecode scan found no CALL-family, CREATE, DELEGATECALL, CALLCODE or SELFDESTRUCT opcodes. The ABI exposes only the standard ERC-20 selectors plus the supply constant.
• Periphery: all five vendored OpenZeppelin files and the licence are byte-identical to the upstream v5.0.2 tag, verified by fetching and diffing.
• Ran the project suite (28 tests plus a stateful invariant run) and the formatter check. All pass.
• The aderyn large-literal lead is a style note. The expression evaluates at compile time to exactly 10^27.

Finding (low). The vendoring note in lib/README.md says every vendored file is an unmodified release snapshot and that the checksum command verifies them. Seven committed forge-std files fail that command. The recorded hashes match upstream v1.9.7 exactly, while the committed files match no release tag I checked, so the files are an intermediate or edited snapshot. This is test-only and does not touch the token. The fix is to restore the v1.9.7 files or re-pin the note and checksum file, which belongs to whoever owns lib/.

Coverage. All three listed entry points are marked holds, plus rows for the constructor, the fixed-supply invariant, the no-privilege and no-external-call invariant, the OpenZeppelin base, the forge-std dependency (finding 1) and the static-analysis lead. No scratch test was needed since nothing reached high or critical severity. No repository files were changed other than the findings file.

The review is complete and the findings file is written and valid. No source changes were made; the only files I created are .imd-findings.json and the scratch probe under test/scratch/, which is not kept.

Result: no economic, invariant or flow-gap defect in the token. src/YoloToken.sol is a 17-line, constructor-only extension of the vendored OpenZeppelin 5.0.2 ERC20. It mints exactly 10^27 units to msg.sender with no constructor arguments, and exposes only approve, transfer and transferFrom. All three entry points are recorded as holds.

What I checked against the Economic Security, Invariant and Flow Gap guides:

• Launch flows are exact. Factory to distributor, factory to pool, factory to requester, distributor claims, and pool-manager round trips move precisely the requested amount. There is no fee, burn, tax, hook or callback. Verified with the project suite and a scratch Foundry probe, including 1 wei and whole-balance edges.
• Conservation holds. Only OpenZeppelin's _update touches balances or supply, _mint is reached once from the constructor, and no mint, burn or burnFrom selector exists. The project's stateful invariant test passed at 128 runs by 64 depth.
• No external dependencies or privileged powers. No oracle, no external calls, no receive or fallback, no owner. ETH sends and unknown selectors revert. The supply fits the int128 deltas and uint128 liquidity Uniswap v4 uses.
• The aderyn large-numeric-literal lead is a style note. The constant equals exactly 1,000,000,000 tokens at 18 decimals.

One info-level finding, outside my area, is reported because it is concrete and reproducible. The README in lib/ claims every vendored file is an unmodified release snapshot and tells readers to verify with sha256sum -c lib/SHA256SUMS. That command fails on seven forge-std files. The recorded hashes are the genuine upstream v1.9.7 hashes, but the committed files were re-wrapped by forge fmt. The differences are formatting only, and forge-std is a test dependency, so deployed bytecode is unaffected. The fix is to restore the exact upstream bytes or regenerate the checksum file, and exclude lib/ from formatting.

Coverage limits: I did not run the protected harness's real Uniswap v4 seed and swap, since its LaunchLiquidity and PoolInitializationGuard sources are not in this repository. Given the token has no transfer hooks, the exactness checks above are what those flows depend on.

The findings file is in place and the review is complete. The repository's own excludes hide it from git, which is expected.

Outcome. The permission model of YoloToken holds in every part of the assigned area. The token is a constructor-only extension of OpenZeppelin ERC-20 v5.0.2 with no owner, minter, pauser, blacklist, hook, exemption list, receive or fallback. I found one low-severity defect, outside the assigned area, and recorded it with coverage rows for all three entry points plus five checked invariants in .imd-findings.json.

What I verified for Access Control, Trust Gap and Asymmetry:

• Entry points. approve, transfer and transferFrom are holder-scoped through msg.sender, write only the caller's own allowance or balance, and share the same internal update path, so there is no branch or writer asymmetry and no privileged variant.
• Deployment roles. The constructor mints the whole supply of 10^27 units to msg.sender and assigns no role. A CREATE2 factory stand-in ends with the full balance and the originating account with zero.
• Privileged surface. The compiled ABI has exactly ten selectors. A scratch test tried 22 common admin selectors from an attacker, the factory and the deployer, plus a plain ETH call and a transferFrom without allowance. All revert and the holder's balance is unchanged.
• Bytecode. An opcode walk of the runtime finds no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Vendored dependency. The five OpenZeppelin files are byte-identical to the v5.0.2 tag fetched from GitHub.
• Existing tests. The project's 28 unit, fuzz and invariant tests pass with the README's seed.

The one finding, low. The README instructs the launch operator to verify vendored sources with the checksum list in lib/SHA256SUMS, and that command fails on seven forge-std files. The recorded hashes are the genuine upstream v1.9.7 hashes. The files in the tree differ only by formatter line reflow, so the formatter was run over the library after the sums were recorded. Production code is unaffected. The reproduction is the single command and its seven FAILED lines.

Not reached. The Uniswap v4 seed and swap in the protected harness could not run locally, because v4-core and the harness's helper sources are not in this repository. That check lies outside the assigned area, and a plain ERC-20 without transfer hooks has no mechanism to tax or block the pool manager.

Review complete. .imd-findings.json now holds one finding and a coverage record covering all three entry points.

Finding kept: low severity, merged from all four specialist reports because they share one root cause. The vendored forge-std files do not match lib/SHA256SUMS, so the integrity check that lib/README.md tells reviewers to run fails.

• Reproduction: from the repository root, sha256sum -c lib/SHA256SUMS reports 7 of 36 files FAILED and exits 1. The failing files are StdAssertions.sol, StdJson.sol, StdToml.sol, Vm.sol, console.sol, IERC7540.sol and IMulticall3.sol.
• I confirmed the recorded digests are the genuine upstream v1.9.7 values, and that the committed files match upstream once whitespace is stripped. The divergence is formatting only because no lib/ exclusion exists for forge fmt, and it is committed at HEAD.
• No on-chain impact: forge-std is test-only, and the five OpenZeppelin v5.0.2 sources are byte-identical to upstream. Because contributors may not edit lib/, the fix belongs to the party that owns the vendored tree.

Token review: no defects found in src/YoloToken.sol. The constructor mints exactly 10^27 to msg.sender; the ABI is standard ERC-20 plus the INITIAL_SUPPLY getter, with no mint, burn, admin, or privileged path. approve, transfer and transferFrom follow the upstream OpenZeppelin 5.0.2 implementation, and every failure path reverts without partial state changes. The manifest matches the contract exactly: name yolo, symbol YOLO, 18 decimals, empty constructor arguments, total supply 10^27, valid key types and bounds. Under the factory deployment model the token is deployable: 2,633 bytes of initcode and 1,752 bytes of runtime, no constructor arguments and no special address bits.

Checks run: forge build passed, forge test passed 46 of 46 tests including fuzz and stateful invariants, forge fmt --check passed, and the documented sha256sum -c lib/SHA256SUMS failed exactly as reported. The aderyn large-numeric-literal lead was examined and rejected: 1_000_000_000 * 10 ** 18 is an exact integer constant equal to 10^27. Coverage verdicts: YoloToken.approve, YoloToken.transfer and YoloToken.transferFrom all hold, as do the fixed-supply and deployability invariants I added.