I've built the yolo (YOLO) token as contract YoloToken in src/YoloToken.sol. It builds, all 11 tests pass (including the fuzz test with the required seed), and forge fmt --check is clean. I couldn't commit it, though: this machine has no git author identity set, and I didn't create one. The files are staged but not committed.

• The token: name yolo, symbol YOLO, 18 decimals, and a supply of 1,000,000,000 minted once to the deployer in the constructor. It has no owner, mint, burn, fee or pause, and takes no constructor arguments. The contract is self-contained; the only dependency, forge-std (used by the tests), is copied into lib/forge-std as ordinary files.
• Configuration: foundry.toml pins solc 0.8.26 with bytecode_hash = "none" and the optimizer on.
• Tests (test/YoloToken.t.sol): they cover name, symbol and supply, the mint event, transfers, approvals, the unlimited-allowance case, failures (too little balance or allowance, sending to the zero address, approving the zero address), the absence of any mint function, and a fuzz test that the supply never changes.
• README: covers behaviour, deployment parameters, the launch terms and assumptions. Nothing needs setting after launch.
• Not run: I didn't run the launch's own token checks (Token.protected.t.sol) against this contract. They need launch values and contracts that aren't in this repository.

To finish, someone with the right identity needs to run git commit in the repository, or the next step can pick up the staged files.

Done. I wrote launch.json for the yolo (YOLO) custom token launch and verified it.

What the manifest contains

• Kind "custom_token", token contract YoloToken, name "yolo", symbol "YOLO", 18 decimals.
• Empty constructorArgs, since the accepted constructor takes no parameters and mints the whole supply to msg.sender.
• totalSupply set to the exact minted amount in minor units, one billion times ten to the eighteenth.
• Empty contracts list, since the accepted tree holds only the token and no application contracts.
• Pool and economics copied exactly as the launch gives them: IMD pair address, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's verbatim economics object.
• Notes under 4000 characters describing the token's fixed supply, lack of privileged functions, and that launch flows move exactly what they say.

Checks

• A JSON check confirmed only the schema's six top-level keys are present, the economics match verbatim, and the supply string equals the constructor's constant.
• The build succeeded and all 11 tests passed with the verifier's fuzz seed.
• Git status shows launch.json as the only new or changed file.

I added two test files to go with the existing test/YoloToken.t.sol. forge build succeeds, and forge test with the verifier's seed passes all 46 tests: the original 11, 34 new ones and one invariant suite.

test/YoloTokenEdges.t.sol (34 tests)

• Failure paths: sending one wei more than a balance, more than the whole supply, or the maximum possible amount; sending to the zero address, including an amount of zero; spending with no allowance, one over the allowance, or someone else's allowance; and an unlimited allowance that is still capped by the balance. Each of these checks the exact error and arguments, and that a failed spend leaves the allowance unchanged.
• Edge cases: transfers of zero and of the whole supply, sending to yourself, sending to the token contract itself, and approving yourself as spender. Also that an approval of max−1 is reduced while an unlimited one is not, that transferFrom emits no Approval event, and that the contract refuses ETH.
• No admin powers: calls to mint, burn, owner, pause, blacklist, fee and permit functions all revert, and the supply stays the same.
• Fuzz tests (1000 runs each, inputs set with bound): transfers move exactly the amount sent, transfers over the balance revert, transferFrom spends the allowance exactly, spends over the allowance revert, an unlimited allowance is never reduced, and approve sets exactly the value given.

test/YoloTokenInvariant.t.sol A handler makes random calls (transfer, approve with fixed or unlimited amounts, transferFrom, and transfers to the zero address) from five accounts, with amounts that sometimes go one over the limit. It tracks what the balances and allowances should be. It ran 256 runs × 64 calls, and these held after every call:

• the total supply stays fixed at 1,000,000,000e18;
• the five accounts' balances add up to the supply, and the zero address holds nothing;
• every balance and allowance matches what the handler expected;
• every call either succeeded or failed exactly as the rules say, with the exact error.

Findings: none, so I didn't write .imd-findings.json. The contract is a plain fixed-supply ERC-20 with no owner, mint, burn, fee or pause, and none of the tests found a defect. Tokens sent to the token's own address stay there for good because there is no way to recover them; I tested that the supply is unaffected and don't count it as a defect.

Not committed: git commit failed because this machine has no git user name or email set. I didn't change the git configuration, so both files are staged but not committed.

The review is complete. The findings file is written and valid, and the scratch test directory is removed.

Outcome: no defects found in the Economic Security, Invariant and Flow Gap areas. The file .imd-findings.json holds an empty findings list and six coverage rows, all holds.

What was checked

• Economic Security: the token has no external dependencies, no oracle, no callbacks and no privileged role. It is not fee-on-transfer, rebasing, pausable or blacklistable, so every integrator receives exactly the amount sent. Both transfer functions return true and revert on failure, so void-return and silent-failure patterns do not apply. Sentinel inputs (zero receiver, zero spender) revert as in OpenZeppelin v5.
• Invariant: sum of balances equals total supply, which is fixed at one billion tokens and written only in the constructor. A Foundry invariant run of 128,000 randomized transfer, approve and transferFrom calls never broke it. Self-transfer and zero-value transfer leave balances intact. The unchecked arithmetic cannot overflow because all balances are bounded by the fixed supply.
• Flow Gap: the launch flows (factory to distributor, distributor to claimant, factory to PoolManager for the seed, trader buy and sell) move exact amounts with zero residue. The reachable runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, matching the protected floor's opcode scan.

Not reported as findings, for the record

• The standard ERC-20 approve front-running race exists, as it does in every plain ERC-20 including OpenZeppelin's. It is a spec-level limitation, not a defect of this code, and the README states the token is a plain ERC-20.
• Aderyn's two low notes (large numeric literal, totalSupply could be immutable) are style and gas observations with no behavioral effect.

Limits: the protected launch test needs Uniswap v4 core, which is not vendored here, so I reproduced its flow checks with plain transfers and a transferFrom by a spender standing in for the PoolManager rather than running it against the real v4 manager.

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

Outcome. The math in src/YoloToken.sol holds. The token has no divisions, no scale conversions, no external calls and no payable paths, so the Math Precision and Numerical Gap checklists reduce to the two unchecked blocks and the constant supply. One low-severity boundary defect is reported.

What I verified, with Foundry tests under test/scratch (removed afterwards):

• The unchecked subtraction in _transfer is guarded by the balance check, and the unchecked addition cannot wrap because the sum of balances always equals the 1e27 supply. An invariant run with a four-actor handler driving transfer, approve and transferFrom never broke that sum.
• Self-transfer of the full balance, moving the whole supply, a transfer of max uint, and zero-value transfers all behave as intended.
• The infinite-allowance sentinel is correct at max, at max minus one, at an allowance exactly equal to the value, and when the allowance exceeds the balance. Reverts are atomic.
• The supply constant equals the manifest's minor units, and the factory's share arithmetic divides exactly with no truncation or intermediate overflow.
• The existing test suite passes, and both static-analysis lines are gas notes, not defects.

Finding (low). Any caller can run transferFrom with address(0) as the sender and a zero value. The allowance and balance checks both pass at zero, so the call succeeds and emits a mint-shaped Transfer event from the zero address. Balances and supply are untouched. The contract rejects a zero receiver and a zero spender but not a zero sender, so the fix is one extra revert in _transfer.

Coverage. All three entry points have rows: approve and transfer hold, transferFrom carries the finding. Four additional rows record the invariants checked. Nothing in my area was left unreached. No launch.json exists in the tree yet, so there was no manifest to check.

The review is complete and the findings file is written. No code files were changed, and my scratch tests are removed.

Result: no defect in the permission model. The token has no roles at all. The compiled ABI exposes exactly three state-changing functions, approve, transfer and transferFrom, with no owner, initializer, mint, burn, pause, blacklist, receive or fallback. The supply is set once in the constructor to the deployer, and nothing else writes it.

What I checked against the three assigned guides

• Access Control: no modifier, role or initializer exists to bypass, so there is no weaker-guard path. Unknown selectors and ETH transfers revert. The runtime bytecode has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, confirmed with the protected test's own reachability rule.
• Asymmetry: transfer and transferFrom share one internal path, so the zero-receiver and balance checks cannot be skipped from either side. The infinite-allowance branch differs only by skipping the decrement. The allowance check runs before the balance check, so pulls from the zero address or any unapproved holder revert.
• Trust Gap: with no privileged actor, no fee formula and no settable parameter, none of the four seams can be instantiated.
• Launch floor: no fee or burn on any path, so the factory, distributor and PoolManager flows move exact amounts without needing exemptions. Supply and decimals match the brief.

Checks I ran

• The project's own 11 tests and forge fmt --check pass.
• A scratch test confirmed self-transfer is neutral, allowances are isolated per spender, supply is conserved under fuzzing, and ETH or unknown calls revert.

One informational finding, no proof attached. The approve function overwrites allowances, so a spender can front-run a lowered approval and spend both the old and new amounts. I reproduced the sequence in a scratch test: approve 100, spender pulls 100, owner approves 50, spender pulls 50 more. This is the standard ERC-20 property, identical to OpenZeppelin v5, and the README calls the token a plain ERC-20, so I recorded it as a trust assumption for integrators rather than something the author must fix.

Coverage record: all three entry points answered, plus six invariant rows. The protected launch tests could not be run here because they need the floor's library sources and environment variables that are not in this tree, so my launch-flow row rests on source and bytecode review rather than on executing them.

Review complete. The findings file is written and validated, the snippet matches the tree at src/YoloToken.sol:55, and the scratch tests are removed.

Result: no loss-of-funds or launch-floor defects. YoloToken is a 65-line fixed-supply ERC-20 with no owner, mint, burn, fee, pause or blacklist surface, and nothing in the Execution Trace, Periphery or First Principles guides reaches it.

One informational finding, reproduced. transferFrom(address(0), to, 0) succeeds from any caller and emits a mint-shaped Transfer(0x0, to, 0) event. EIP-20 reserves a zero sender for mints and the OpenZeppelin reference rejects it. No balance or supply changes, and a non-zero value from the zero address reverts, so the impact is confined to off-chain indexers that trust the zero sender without checking value. The minimal fix is a sender-zero check in _transfer.

What was checked, all passing:

• Project build, the 11 existing tests, and forge fmt --check.
• Every entry point the verifier listed, traced through its guards, state writes and revert paths.
• A stateful invariant run over random transfer, approve and transferFrom sequences: sum of balances equals the 1e27 supply, the zero address never holds a balance, allowance decrements and the infinite-allowance sentinel behave as documented.
• A launch-flow simulation with Uniswap v4 style return-value checks: factory to distributor to claimant, factory to pool manager, and trader buy and sell each move exactly the stated amount.
• An opcode walk of the compiled runtime using the protected test's reachability rule: no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Supply, decimals and name/symbol constants against the brief and the manifest figure.

Not reviewable: no launch.json exists in the tree yet, so manifest content was not checked. The two aderyn lines (large literal, variable could be immutable) are gas and style only and were not reported. The approve front-running race is inherent to the ERC-20 interface and was not reported.

I finished the review and wrote the results to .imd-findings.json. It contains one finding, rated info, and a coverage row for each of the three entry points. I didn't edit any repository files. The scratch test I wrote under test/scratch/ has been deleted. The other untracked entries in git status (.bashrc, .idea, .claude/agents and so on) are placeholder files the sandbox created, not real changes.

What I checked: I read src/YoloToken.sol, a plain fixed-supply ERC-20, and launch.json. The full test suite passes (46 tests, including the invariant run). The supply is exactly 1e27, minted once to msg.sender in the constructor. There is no owner, mint, burn, fee, pause or blacklist. The manifest has constructorArgs: [] for the no-argument constructor, and its totalSupply and decimals match the contract. Nothing blocks deployment: the contract is small and needs no particular address.

Specialist findings:

1. Zero sender in transferFrom (audit_flow, rated info, and audit_math, rated low). These are the same issue, so I merged them and kept it as info. Anyone can call transferFrom(address(0), to, 0). It succeeds and emits Transfer(0x0, to, 0), which looks like a mint, because the check at src/YoloToken.sol:56 rejects only a zero receiver, not a zero sender. A scratch Foundry test confirmed it on the current code: the event is emitted and the supply doesn't change. With value 1 the call reverts with InsufficientAllowance. No funds are affected; it could only confuse off-chain tools that count transfers from the zero address as mints. The fix is one line: add an InvalidSender check at the top of _transfer.
2. approve front-running race (audit_permissions, info). Dropped. Replacing an allowance outright is how the ERC-20 standard and OpenZeppelin define approve, so it's expected behaviour, not a defect in this code.

Coverage:

• approve and transfer: holds.
• transferFrom: finding 1.
• Two invariants I also checked: the supply is fixed and minted to the factory, and every launch transfer moves the exact amount. Both hold.

I found nothing the specialists missed. The two static-analysis warnings are only style suggestions.