The Yolo token project is written and documented. I could not compile or run it: every shell command on this machine fails before starting with a sandbox error (apply-seccomp: write /proc/self/setgroups ... Permission denied), so forge build, forge test, forge fmt and git were all unavailable. The code was reviewed by hand instead.

What was delivered

• src/YoloToken.sol: a dependency-free ERC-20, name Yolo, symbol YOLO, 18 decimals, 1,000,000,000 tokens minted once to the constructor's msg.sender. No owner, no mint, no burn, no pause, no blocklist, no fee, no fallback, no delegatecall or selfdestruct. Unlimited allowance is not decremented. ERC-6093 error names.
• test/YoloToken.t.sol: 28 tests. Success paths for transfer, approve and transferFrom with event checks. Failure paths for insufficient balance, insufficient allowance, zero receiver and zero spender. Checks that the launch flows arrive whole, that no mint or admin selector exists, that no privileged call moves or freezes a holder, and that reachable runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT. Six fuzz tests for conservation of supply and allowance accounting, with inputs bounded so any seed passes.
• test/utils/TestBase.sol: a minimal cheatcode interface and assertions, so no forge-std or OpenZeppelin needed vendoring.
• foundry.toml: solc pinned to 0.8.26, optimizer on, bytecode_hash = "none", ffi off, no fs permissions.
• README.md: design, assumptions, manifest values for the launch step, "After launch" (nothing to set), operational responsibilities and chosen constants.

What was not verified

• forge build, forge test and forge fmt --check did not run here because the Bash sandbox refused every command. The verifier's offline build is the first real compile of this code.
• The working tree is not committed, since git could not run either. All files are plain files under the repository root.

Where the verifier's results matter most

• Overload resolution and cheatcode ordering in the tests were checked by reading, not compiling. If the build reports an error, it is most likely in test/YoloToken.t.sol, not in the token itself.

I found one low-severity defect and nothing high or critical. The findings are written to .imd-findings.json, and no project files were changed.

Scope: I reviewed all of src/YoloToken.sol (128 lines, no dependencies) and checked it against the Execution Trace, Periphery and First Principles guides, the token threat profile and the custom-token launch rules. The project's own 33 tests pass.

Finding 1 (low): transferFrom accepts the zero address as sender. At src/YoloToken.sol:96, _transfer checks only that the receiver isn't the zero address.

• Reproduction: anyone can call transferFrom(address(0), 0x…bEEF, 0). No allowance or balance is needed, it returns true and emits Transfer(address(0), 0x…bEEF, 0). I confirmed this with a Foundry trace.
• Why it matters: by ERC-20 convention a transfer from the zero address is a mint, so any caller can make post-launch "mint" events appear in the logs of a token whose supply is minted once. Explorers and monitors that rebuild supply or mint history from logs would show them. Balances and the total supply are not affected, and no launch transfer can trigger this, so it stays low.
• Fix: add if (from == address(0)) revert ERC20InvalidSender(address(0)); and declare that error. This matches OpenZeppelin, whose error names the contract already uses.

Coverage:

Entry point	Verdict	Reason
approve	holds	The owner is always the caller, a zero spender is rejected, and the allowance is set exactly.
transfer	holds	The balance is checked before the subtraction; sending to yourself leaves your balance unchanged; sending to the zero address reverts.
transferFrom	finding 1	Allowance spending and the unlimited-allowance case are correct; the only gap is the zero-address sender above.

Other checks, both hold:

• Fixed supply: only the constructor creates balance, minting 10⁹ × 10¹⁸ (10²⁷) to the deployer, and there is no other way to mint, burn or take control.
• Launch transfers: there is no fee, burn or hook on transfer, so every launch transfer and every pool deposit or swap moves exactly the stated amount.

The static-analysis "large numeric literal" warning at line 27 is just the supply constant. It is correct and I didn't report it.

Limits: the repository has no forge-std and no Uniswap v4 libraries, so I couldn't run the protected launch tests here. Instead, my scratch test stood alone, and I deleted it afterwards. No finding was high or critical, so none carries a proof.

Done. The manifest is written and verified against the accepted tree.

What I wrote: launch.json at the repository root, kind "custom_token", describing the accepted YoloToken contract.

• Token: contract YoloToken, name Yolo, symbol YOLO, 18 decimals, empty constructorArgs. The accepted constructor takes no parameters and mints the whole supply once to msg.sender.
• totalSupply: 1000000000000000000000000000 minor units, exactly what the constructor's TOTAL_SUPPLY constant mints.
• Contracts: an empty list. The accepted tree contains only the token, so no application contracts are named.
• Pool: IMD pair address, fee 12500, tick spacing 60, initialPrice as the reference gives it.
• Economics: copied verbatim from the job and checked byte for byte against the required object.
• Notes: one string, well under the 4000 character limit, describing only what is in the accepted source.

Checks run: the manifest parses with only the schema's top-level keys, the build compiles cleanly on solc 0.8.26, and all 33 existing tests pass with the verifier's fuzz seed. Git status shows launch.json as the only new or changed file.

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

Outcome: the Yolo token holds up under the Math Precision, Boundary and Numerical Gap guides. I found no defect that moves value or breaks the supply. One informational deviation is recorded.

What I checked

• Math Precision: the contract has no division, no runtime multiplication, no scaling and no downcasts. The only arithmetic is the two unchecked blocks in _transfer and _spendAllowance. Both subtractions sit behind an explicit less-than revert, and the unchecked add cannot overflow because the sum of balances is fixed at 1e27 by construction. The aderyn "large numeric literal" lead resolves to exactly 1e27 at compile time and is style only.
• Boundary: no external calls, no payable function, no receive or fallback, no bytes decoding, so most of the guide has no entries here. I walked the zero and max edges directly: zero receiver and zero spender revert, zero amounts succeed with an event, max amount reverts in the guard, max allowance is the unlimited sentinel and max minus one decrements normally, self-transfer of the whole supply is a no-op, and a recipient can reach exactly the full supply.
• Numerical Gap: with no rounding anywhere, the conservation invariant cannot drift. A fuzzed test of random eight-step transfer sequences among four accounts kept the sum at exactly 1e27 across 256 runs.

Finding (info): transferFrom(address(0), to, 0) succeeds for any caller and emits a Transfer event from the zero address, which is the shape ERC-20 reserves for mints. No balance or supply changes, and a non-zero amount from the zero address reverts. The fix is a one-line ERC20InvalidSender check in _transfer, matching the OpenZeppelin semantics the error names are borrowed from.

Coverage: all three listed entry points have rows, plus rows for the supply invariant, the constant, the constructor and the absent external-call surface. Nothing was left unreached. The scratch tests live in test/scratch/MathBoundary.t.sol and used the project's own TestBase because forge-std is not vendored in this tree. No tracked file was changed.

The review is complete and .imd-findings.json is written and valid. The working tree is otherwise untouched: only the findings file and my scratch test under test/scratch/ exist, both gitignored.

Outcome: the Yolo token is clean in the assigned area. One informational finding, no medium or higher.

What I checked against the Access Control, Asymmetry and Trust Gap guides, plus the Senior Auditor's Mindset:

• Permission model. There are no roles, modifiers, owner slots, setters, initializers, receive, fallback, proxies or delegatecall. The ABI's only state-changing entry points are approve, transfer and transferFrom, each acting on the caller's own balance or allowance. The factory receives the supply in the constructor and afterwards is an ordinary holder with no pull power.
• Paired-surface diff. transfer and transferFrom share _transfer, so receiver validation, balance check and event emission are identical. The allowance writer pair (approve sets, _spendAllowance only decrements) cannot raise an allowance. The unlimited sentinel is handled as OpenZeppelin does. Self-transfer and whole-balance transfers conserve supply, and the unchecked add cannot wrap because the sum of balances is the constant 1e27.
• Trust gap. No fee, tax or exemption list exists, so the swarm share, the seed, claims and swaps move exactly what they state. There is no admin variant of any user function and no in-flight value an actor could redirect.
• Static analysis lead. Aderyn's large-literal note on line 27 is correct arithmetic (1e9 times 1e18 equals the manifest supply) and is not a defect.

The one finding (info): _transfer rejects a zero receiver but never rejects a zero sender, although the contract advertises ERC-6093 error names. Since the zero address can hold no balance and no allowance, the only passing value is zero, so anyone can call transferFrom(address(0), to, 0) and emit a mint-shaped Transfer(0x0, to, 0) event. No balance, allowance or supply changes. I confirmed it with a scratch test and gave the one-line fix that preserves behaviour.

Coverage record: all three listed entry points are answered (two hold, transferFrom carries the info finding), plus rows for the constructor and four invariants. Nothing in my area was left unreached. The project's existing 33 tests pass under solc 0.8.26.

The findings file is valid, the quoted snippet matches line 96 of the source exactly, and the working tree shows no tracked changes. The scratch test lives under the gitignored test/scratch/ directory.

Outcome: the Yolo token holds under every failure mode in the Economic Security, Invariant and Flow Gap guides. I reported one informational finding and no defects that block the launch.

What I checked

• Supply conservation. The constructor writes the full supply to the deployer once, and the only other balance writer is the internal transfer, which is conservative. A 256-run randomised fuzz over mixed transfer and transferFrom sequences across six actors, including self-transfers and unlimited allowances, kept the sum of balances equal to the constant supply every step.
• Launch flows. There are no fees, hooks, callbacks, exemptions or external calls, so the factory-to-distributor, claim, seed, swap and remainder hops each move exactly the requested amount. The 10/80/10 split of the supply divides without dust.
• Privilege and sentinel behaviour. No owner, pause, blocklist, mint or burn path exists. The deployer cannot pull from a holder without an allowance. Approve to the zero address and transfer to the zero address both revert.
• The three ABI entry points each have a coverage row, plus six rows for the invariants and flow properties I traced.

The one finding, severity info

transferFrom(address(0), anyone, 0) succeeds from any caller and emits a zero-value Transfer from the zero address. The sender is never validated in the internal transfer, and a zero value passes the allowance check. No balance or allowance changes, so there is no economic impact. Indexers that classify Transfer-from-zero as a mint can record spurious zero-value mints. The reference OpenZeppelin implementation rejects this with an invalid-sender error. The reproduction and a one-line fix are in the findings file.

Not reached: nothing in my area. The static-analysis lead about the large numeric literal at line 27 is a style note, not a defect, since the constant equals the brief's supply exactly.

I added two test files on top of the existing suite. forge build succeeds, and forge test with the verifier's fuzz seed passes all 58 tests (33 existing, 25 new). The token is plain and I found no real defect, only one cosmetic issue, which I reported instead of writing a test that treats it as correct.

test/YoloTokenInvariant.t.sol: invariant tests over random call sequences

• A handler moves tokens between five holders (the factory plus four others). It keeps its own record of what every balance and allowance should be, worked out from the arguments of each call rather than read back from the token.
• It also drives the calls that should fail: sending more than the balance, sending to the zero address, spending more than the allowance or the owner's balance, and approving the zero address. Each must revert and leave everything unchanged.
• The invariants checked after every call:
  • total supply stays at 1,000,000,000 × 10¹⁸;
  • the five holders' balances add up to the supply, and nothing ends up at the zero address, the token contract or the handler;
  • every balance and allowance matches the handler's record;
  • no call that should fail succeeds, no failed call changes state, and an unlimited (type(uint256).max) allowance is never reduced.
• Settings are 256 runs at depth 64, about 16,000 calls, with zero reverts.
• To check that these tests can actually fail, I broke the source two ways: once so unlimited allowances get reduced, once so transfers deliver 1 wei short. Each break was caught; I then restored the source, and git shows it unchanged.

test/YoloTokenEdges.t.sol: 24 edge-case and fuzz tests

• Maximum values: transferring type(uint256).max or the supply plus 1 reverts, and an allowance of max − 1 counts down like a normal one.
• Repeated calls: a second spend of a used-up allowance reverts, re-approving the same amount replaces it rather than adding, and approving 0 revokes.
• Unexpected callers: an owner can't spend their own tokens through transferFrom without approving themselves, and allowances apply only to the one owner and spender they were set for.
• Clean failures: a failed transferFrom leaves the allowance intact, and sending zero to the zero address still reverts.
• Fuzz tests (1,000 runs): a transfer between any two holders conserves their combined balance, two partial spends of an allowance end the same as one full spend, and an unlimited allowance is never reduced.

Reported in .imd-findings.json (info severity): anyone can call transferFrom(address(0), to, 0). It succeeds and emits Transfer(address(0), to, 0), which block explorers and indexers can show as a zero-value mint. No balance or supply changes. OpenZeppelin's ERC-20 rejects this with ERC20InvalidSender, which this contract leaves out (src/YoloToken.sol:96). I confirmed it with a test in test/scratch/ before writing it up. That file isn't submitted, and because the finding is info-level it carries no proof.

.imd-findings.json is listed in .git/info/exclude, so git status doesn't show it, but the file is in the repository root.

I didn't change any existing file, source or configuration.

The review found one low-severity defect, and nothing that blocks the launch. All five specialists reported the same root cause, so I merged their reports into one finding and reproduced it myself.

Finding 1 (low), src/YoloToken.sol:96: _transfer checks that the receiver isn't the zero address but never checks the sender. So anyone can call transferFrom(address(0), to, 0) and it succeeds:

• The allowance check passes, because the allowance is 0 and the amount is 0.
• The balance check passes, because the zero address holds 0.
• The token then emits Transfer(address(0), to, 0), which explorers and indexers treat as a mint.

I confirmed this with a temporary Foundry test and a -vvvv trace. Balances, allowances and totalSupply don't change. Any amount of 1 or more reverts on the allowance check, and the launch's own transfers never come from the zero address. The impact is limited to fake "mint" events that log-reading tools may record after launch.

The fix is to declare ERC20InvalidSender(address) and add if (from == address(0)) revert ERC20InvalidSender(address(0)); at the top of _transfer. This is the OpenZeppelin behaviour whose error names the contract already uses. I attached no proof file, since the task only asks for one on critical and high findings.

Coverage:

• approve: holds.
• transfer: holds, including transferring to yourself, which I tested.
• transferFrom: has finding 1.

I also checked two invariants:

• Fixed supply: 1e27 is minted once to the deployer and nothing can mint or burn afterwards. This matches launch.json, which has the right supply, 18 decimals and empty constructor arguments for the no-argument constructor.
• Launch transfers arrive whole: there's no fee, owner, pause, blocklist, delegatecall or selfdestruct.

The aderyn "large numeric literal" warning on line 27 is just a style note about 1_000_000_000 * 10 ** 18, so I didn't report it.

What I couldn't run:

• The project's existing 58 tests pass.
• I couldn't run the protected launch tests: they need libraries that aren't installed here (v4-core, and forge-std, which the task's proof format expects). I wrote my reproduction test without forge-std for that reason.
• I deleted the scratch test afterwards, and no tracked files changed.

The findings and coverage are in .imd-findings.json, which is valid JSON.