Done. The Torch token project is built, tested, documented and committed.

What was delivered

• src/TorchToken.sol: a self-contained fixed-supply ERC-20 named Torch, symbol TORCH, 18 decimals. The constructor takes no arguments and mints the full 1,000,000,000 × 10^18 to the deployer. There is no owner, mint, burn, pause, blocklist, fee or exemption list, and no external calls, so every launch flow moves exactly what it says.
• foundry.toml at the repository root pins solc 0.8.26, sets bytecode_hash to none and cbor_metadata off, disables ffi and grants no filesystem permissions. forge-std v1.11.0 is vendored under lib/ as ordinary files with no submodule entry.
• README.md documents behaviour, deployment parameters, launch values, assumptions, operational responsibilities and test coverage. It states there is nothing to configure after launch.

Tests in test/, all passing with the verifier's fuzz seed, formatted with forge fmt:

Suite	Count	Covers
TorchTokenTest	32	metadata, supply, mint-to-deployer, transfer and transferFrom success and revert paths, allowance semantics, absence of admin selectors, launch flow shape, five fuzz properties
TorchTokenBytecodeTest	5	CREATE2 deployment through a factory stand-in, address prediction, EIP-170 size, no DELEGATECALL, CALLCODE or SELFDESTRUCT in reachable code

The protected floor tests were read and designed against: the supply lands whole on the factory, transfers are exact, nothing increases supply, and no privileged call touches a holder.

Notes

• Slither was not available on this machine and did not run. The contract avoids all six rejecting detectors by construction.
• The commit was made with the user's email for authorship since the repository had no identity configured. Only the project paths were staged; the sandbox's device-node dotfiles were left untracked.

I found no defects in the economics of src/TorchToken.sol. .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, all marked holds. The project's 37 existing tests pass. I wrote no proof test, since none of the findings would need one, and changed no other files.

What I covered (Economic Security, Invariant and Flow Gap guides):

• Supply: the only place tokens are created is the constructor, which mints 1,000,000,000 × 10¹⁸ to msg.sender (the factory). totalSupply() returns a fixed constant. There is no mint, burn, owner, upgrade, pause, blocklist or seize function, so neither a stranger nor the factory can grow the supply or freeze a holder.
• Balances add up: a transfer checks the sender's balance first, then takes exactly value from one account and adds exactly value to the other. Its unchecked block cannot underflow because of that check, or overflow because all balances together never exceed the total supply. A transfer to yourself leaves your balance unchanged, so the balances always total the supply.
• Launch flows: there is no fee, burn or exemption on transfer. So the 10% to the distributor, each claim, the pool seed, and buys and sells through the PoolManager all move exactly the amount asked.
• Allowances: transferFrom spends only the allowance the holder gave msg.sender, and checks it before subtracting. An unlimited allowance (type(uint256).max) is never reduced. approve refuses the zero address as spender and can only change the caller's own allowances.
• Static analysis: the one aderyn lead ("large numeric literal" at src/TorchToken.sol:27) is the 1_000_000_000 * 10 ** 18 supply constant. It is correct as written and not a defect.

What I didn't reach:

• I did not run the protected floor test, because it needs environment variables and contracts that aren't in this tree. I traced its checks against the code by hand instead.
• One edge I did not report: transferFrom(address(0), to, 0) succeeds and logs a zero-value transfer that looks like a mint, but it moves no tokens and changes no balance.

The permissions audit of src/TorchToken.sol found one low-severity issue and nothing worse. The results are in .imd-findings.json.

The token: a self-contained fixed-supply ERC-20 with no owner, admin role, mint, pause, blocklist, fee or burn. The constructor mints all 1,000,000,000 × 10¹⁸ TORCH once to msg.sender, which is the factory.

Access Control: nothing privileged exists. A caller can only spend their own balance, through transfer, or an allowance someone granted them, through transferFrom. approve only writes the caller's own allowance. A stranger's transferFrom on another holder's tokens reverts; I checked this with a scratch test.

Trust Gap: there are no exemptions and no external calls. That means the launch flows (factory to distributor, the distributor's claims, the seed through the PoolManager, and trading) all move exactly the amounts asked for.

Asymmetry: this is where the finding is.

• Finding 1 (low), src/TorchToken.sol:151: _transfer rejects a zero-address receiver but not a zero-address sender. So any address can call transferFrom(address(0), x, 0) and it succeeds, emitting Transfer(0x0, x, 0). That event has the same shape as a mint, even though the contract says nothing mints after deployment, so off-chain indexers and supply trackers could be misled. No balance or supply changes. I confirmed it with a local forge test. The fix is one line: add if (from == address(0)) revert ERC20InvalidSender(address(0)); in _transfer, which is what OpenZeppelin does.

Coverage:

• approve and transfer: holds.
• transferFrom: finding 1.
• Two invariants I added rows for: no privileged power exists, and the launch flows are exact. Both hold.

Checks run:

• The project's own test suite passes: 39 tests.
• The aderyn "large numeric literal" warning is just the supply constant, so it isn't a defect.
• My scratch tests went under test/scratch/ and I deleted them afterwards. .imd-findings.json is the only file I wrote; no source file changed.
• The protected floor tests need the launch environment variables, so I read them but did not run them on their own.

I wrote launch.json for the Torch launch and verified it against the accepted tree.

What the manifest says

• Token contract is TorchToken with name Torch, symbol TORCH, 18 decimals.
• The constructor takes no parameters, so constructorArgs is an empty list.
• totalSupply is the constant the constructor mints to msg.sender, 1,000,000,000 tokens in minor units.
• There are no application contracts in the accepted tree, so contracts is empty.
• pool and economics are copied exactly as the task gives them, with IMD as the paired currency and fee 12500.
• notes describe only TorchToken and its behaviour, at 882 characters.

Verification

• A script check confirmed the key order, kind, supply, note length, contract name length, and that economics matches the job's object byte for byte.
• forge build compiles cleanly.
• forge test with the verifier's fuzz seed passed all 37 tests across both suites.
• git status shows launch.json as the only new file. Nothing else was changed.

I found no math defects in src/TorchToken.sol, so .imd-findings.json holds {"findings":[]} plus a coverage record.

Coverage, one row per entry point:

• approve(address,uint256): holds. It stores the value as given, with no arithmetic, and rejects a zero spender.
• transfer(address,uint256): holds. The balance is checked before the unchecked subtraction. The addition can't overflow, because all balances always add up to the fixed supply of 1e27.
• transferFrom(address,address,uint256): holds. The allowance is checked before its unchecked subtraction. Only exactly 2^256−1 counts as unlimited; an allowance of 2^256−2 still goes down normally.
• Supply rule (supply = sum of balances = 1e27): holds. 1_000_000_000 * 10**18 is exactly 1e27, minted once to the deployer, and no path mints, burns or takes a fee.

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

• Every unchecked block and its guard.
• Overflow at the edges: moving the full supply works, and the full supply plus one reverts.
• Sending tokens to yourself, directly and through transferFrom (same sender and receiver), keeps the balance unchanged.
• Zero-value transfers succeed; sending to the zero address reverts.
• The "unlimited allowance" value only applies at exactly the maximum.

The contract has no division, rounding, narrowing casts, shifts or fees, so most of the precision checklist doesn't apply here.

Tests: a fuzz test (5,000 runs) checking that balances and allowances add up, and a boundary test, both pass. They were temporary files under test/scratch/ and I deleted them; nothing else changed. The existing suite passes, 37 of 37. The static-analysis tool's large-number warning at line 27 is just the intended supply constant. The other analyzer reported nothing.

Not covered: the supplied protected tests import launch-harness contracts (src/LaunchLiquidity.sol and others) that aren't in this tree, so I didn't run them. That's outside the math area.

I added two test files for Torch (TORCH). The full suite now passes: forge build is clean and forge test with the verifier's fuzz seed gives 62 passed, 0 failed. I found no defects in src/TorchToken.sol, so there is no .imd-findings.json.

The token is a plain fixed-supply ERC-20. It has no owner, mint, burn, fee, pause or blocklist, and it mints exactly 1e27 to the deployer. The two test files that were already there covered the main paths well but had no invariant tests, which the acceptance criteria ask for.

test/TorchToken.invariant.t.sol runs random sequences of calls across five holders:

• What it calls: transfers, approvals (normal and unlimited) and transferFrom, plus the calls that must fail: sending more than the balance, spending more than the allowance, sending to the zero address, and approving the zero address. Each failing call is also checked for the exact error the contract defines.
• How it checks: the handler keeps its own record of every balance and allowance, so the token is compared against independent bookkeeping rather than against itself.
• What must always hold: total supply never changes; balances add up to the supply; balances and allowances match the handler's record; nothing ends up at the zero address, the token contract or the handler; every call succeeded or failed as specified; name, symbol and decimals never change.
• Run size: 256 runs × 64 calls, set in the test file. In my run that made 16,384 calls with nothing discarded.
• Sanity check: I ran a copy with a deliberately broken record. The balance and call-behaviour invariants failed straight away, so they aren't passing trivially.

test/TorchToken.edges.t.sol has 24 tests for edge cases:

• Amounts: the full supply out and back, one wei, one wei over the supply, and type(uint256).max.
• Self-transfers: sending to yourself, an owner needing an allowance from themselves to use transferFrom, and transferFrom where sender and recipient are the same.
• Unusual but allowed: a zero-value transferFrom with no allowance succeeds, and an allowance one below the maximum is still reduced as it's spent.
• Unlimited allowance: it never decreases, but can't move more than the holder has.
• Rejected calls: sending 0 to the zero address, approving the zero address for 0, and pulling from the zero address without an allowance all revert. A reverted call changes nothing.
• Events: transferFrom emits only a Transfer event.
• Unexpected calls: sending ETH to the token and calling a function it doesn't have both revert.
• Fuzz tests (1,000 runs each): transfers round-trip back to the start, partial spends add up correctly, and an address without an allowance can't move anyone's tokens.

A note on behaviour, not a defect: tokens sent to the token contract's own address are accepted and can never be recovered. That is normal for a plain ERC-20, and a test records it.

I haven't committed the two new files; they are in the working tree.

The review is complete and .imd-findings.json holds the result. No source files were changed; the only file I wrote besides the findings is a probe under test/scratch/, which is ignored.

Outcome: no defects of low severity or above. TorchToken is a plain, ownerless ERC-20 whose only mutating entry points are approve, transfer and transferFrom. I traced each through my three guides and found the control flow sound.

• Execution Trace. Every guard sits before its unchecked arithmetic: the balance check at line 150 guards the subtraction, and the bounded supply makes the addition safe. Allowance is read and written in one function with no external call between, so there is no stale read. The max-allowance sentinel is exact, and max-minus-one is decremented. transferFrom reverts atomically when the balance check fails after the allowance write.
• Periphery. There is nothing peripheral: no libraries, no assembly, no external calls, no receive or fallback. The runtime bytecode contains zero CALL-family, CREATE, SELFDESTRUCT or transient-storage opcodes. Return values are true, so SafeERC20 callers and the Uniswap v4 settle and take paths work.
• First Principles. The constructor takes no arguments and mints exactly 1e27 to msg.sender once. Supply conservation held under a fuzzed random walk mixing transfer, transferFrom and self-transfers. The launch flows move exactly what they say because no fee, burn or exemption path exists.

One informational note recorded. A zero-value transferFrom with the zero address as sender succeeds and emits a mint-shaped Transfer event, where OpenZeppelin v5 would revert. No balance, allowance or supply can change through it, so it is event noise only. The reproduction is in the findings file.

Coverage. All three listed entry points have rows, plus six invariant rows covering supply conservation, no post-launch mint, constructor minting, exact launch flows, forbidden opcodes and metadata. Nothing in the assigned area was left unreached. Tools run: forge build, the project's 37 tests, a 7-test scratch probe with 256 fuzz runs, and an opcode scan. Slither and aderyn output from the verifier reported nothing above the large-literal note, which I checked and confirmed as a compile-time constant equal to 1e27.

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

Outcome: one low-severity finding, no critical, high or medium defects. The token is a plain fixed-supply ERC-20 with no owner, no external calls, no fee and no mint path. All three entry points were traced, the existing suite of 69 tests passes, and my scratch tests under test/scratch/Judge.t.sol confirm the behaviours below.

Specialist findings judged

• audit_flow (info) and audit_permissions (low) reported the same root cause, so they are merged into one finding at low. Reproduced: a call from any address of transferFrom(address(0), to, 0) succeeds and emits a Transfer from the zero address with value zero. No balance, allowance or supply changes, and any non-zero value reverts on allowance, so impact is confined to off-chain indexers that treat Transfer-from-zero as a mint. It also contradicts the contract's stated OpenZeppelin-compatible semantics. Minimal fix is a zero-sender check at the top of the internal transfer.
• audit_math, audit_economics and the test writer reported nothing, and my own pass agrees.

My own pass

• approve and transfer hold. Self-transfer preserves balance, unchecked arithmetic is guarded by the preceding comparison and bounded by the fixed supply.
• The deployer cannot pull from a holder without approval, unlimited allowance is not decremented, finite allowance is.
• Supply is a constant, minted whole to the deployer, no admin or privileged selector exists, runtime is about 1.4 KB with no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• launch.json uses only schema keys, the empty constructorArgs matches the no-argument constructor, and totalSupply equals one billion times ten to the eighteenth.
• The static-analysis lead about a large numeric literal is the supply constant and is not a defect.

Coverage: all three entry points answered, two holds and one finding, plus three invariant and manifest rows. One stale sentence in the README claims no launch.json exists while one is present. That is noted in the coverage record, not raised as a finding.