The TORCHINU token is built, tested, documented and committed on main as 6fc4ec3.

What was delivered

• src/TorchInu.sol: contract TorchInu inheriting OpenZeppelin ERC20. The constructor takes no arguments and mints the full supply to msg.sender once. Name and symbol are both TORCHINU, decimals 18, supply 1,000,000,000 tokens. There is no owner, mint, burn, pause, blacklist, fee, receive or fallback.
• test/TorchInu.t.sol: 28 tests mirroring the protected floor. They cover supply minted to a factory-like deployer, exact launch flows, ERC-20 successes and typed-error failures, the admin-selector probes for supply growth and freezing, no ether acceptance, a bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and three fuzz tests.
• script/DeployTorchInu.s.sol: a reviewable deploy script whose deploy() function is tested directly and reads no environment.
• README.md: assumptions, the launch's deployment parameters, operational responsibilities, and the security checklist result.
• foundry.toml pins solc 0.8.26, bytecode_hash = "none", no ffi, no fs permissions. forge-std 1.17.0 and the five OpenZeppelin 5.4.0 ERC-20 files are vendored under lib/ as plain files with their licences, no submodules.

Checks run

Check	Result
forge build	pass
forge test with the verifier's fuzz seed and an empty environment	28 passed, 0 failed
forge fmt --check	pass

Slither and Mythril were not available on this machine and did not run. No launch.json was written. Nothing in the brief was left open, so no .imd-blocked.json was needed.

Done. launch.json is written and verified against the accepted tree.

What the manifest says

• Kind is custom_token. The token entry names the Solidity contract TorchInu, with name and symbol TORCHINU and 18 decimals.
• constructorArgs is empty, matching the compiled ABI, whose constructor has no inputs.
• totalSupply is 1000000000000000000000000000, which is exactly the TOTAL_SUPPLY constant the constructor mints to msg.sender.
• contracts is empty, because the accepted tree contains only the token. No application contracts exist.
• pool and economics are copied verbatim from the launch reference: IMD as paired currency, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object.
• notes describe the token's actual behaviour in about 1,300 characters, well under the 4,000 limit.

Checks run

• JSON parses, the key set is exactly the schema's six keys, and economics compares equal to the job's object.
• forge build compiled cleanly on solc 0.8.26.
• forge test with the verifier's fuzz seed passed all 28 tests.
• git status shows launch.json as the only new or changed file. No configuration, lib, or workflow files were touched.

The review is complete and the findings file is written. No defects were found in the Math Precision, Boundary and Numerical Gap areas.

What was reviewed. The token at src/TorchInu.sol is OpenZeppelin 5.4.0 ERC-20 with one constant supply minted in the constructor. It contains no division, no downcast, no fixed-point scaling, no external call, no payable path and no bytes decoding, so most of the three guides' failure modes have no code to attach to. The remaining ones were probed with a scratch Foundry test, which passed on every case and has been removed again.

What the probes pinned down.

• The supply constant is exactly 1e27, the manifest's minor-unit figure, well under any overflow or downcast hazard. The aderyn large-literal lead is informational only.
• Transfers of supply plus one and of max-uint revert with the typed error and leave balances untouched. Zero-value transfer, approve and transferFrom succeed without state corruption.
• Infinite allowance is never decremented. A finite allowance is decremented exactly and one unit over it reverts. The balance check still rules when allowance exceeds balance.
• The 10% swarm and 85% pool splits divide with zero remainder, so no dust reaches the distributor, pool or requester.
• The sum of balances equals total supply across fuzzed three-party transfers, and total supply never changes.
• Zero-address receiver and spender revert on both OZ sentinel branches. ETH sent to the token reverts.

Output. The file .imd-findings.json holds an empty findings list and eight coverage rows, all marked holds: the three listed entry points, the constructor, and four invariant or boundary rows with one-line reasons. The existing project suite of 28 tests also passes. No repository files were changed.

The review is complete. No defects were found in the assigned area, and the findings file records that with full coverage.

Outcome: .imd-findings.json holds an empty findings list and eight coverage rows, three for the listed entry points and five for the invariants and trust assumption I checked. No tracked file was changed. The only files written were the findings record and a scratch probe under test/scratch/, which is gitignored.

What I verified

• Access control. The compiled ABI exposes exactly three state-changing functions: approve, transfer and transferFrom. There is no owner, initializer, mint, burn, pause, blacklist, receive or fallback. All 22 common admin selectors revert from both an attacker and the deployer, and the deployer holds no allowance over any holder.
• Trust gap. The only privileged position is that whoever deploys receives the whole supply, which the launch floor requires. The constructor takes no arguments and trusts no address, so no actor can combine a permission with an economic formula to extract value.
• Asymmetry. The approve and transferFrom pair debits the allowance exactly, leaves it untouched on a failed transfer, and treats the infinite allowance as the standard sentinel. transfer and transferFrom move the same exact amount with the same zero-address and balance guards.
• Supply chain. All five vendored OpenZeppelin files hash identically to upstream v5.4.0. The deployed runtime contains no CALL-family opcode, no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Static-analysis lead. The aderyn large-literal note on line 25 is benign: the constant evaluates to exactly 1e27, which the project test asserts.

Tooling run: forge build, the 28-test project suite and my 7-test scratch probe all pass. Slither was not run, per the assignment.

One standard ERC-20 property is worth noting without being a defect: the approve-then-reapprove race inherent to the standard allowance model. OpenZeppelin documents it, and nothing in this token makes it worse. I left it out of the findings as it is not a defect of this code.

I added two test files for TORCHINU, and the full suite passes with the verifier's fuzz seed: 49 tests (the 28 that were already there plus 21 new), forge build clean. I found no defects, so there is no .imd-findings.json.

src/TorchInu.sol is OpenZeppelin's standard ERC-20 (v5.4.0, its core transfer and allowance code reads as stock) with a single mint in the constructor. It has no owner, no fee, no admin functions and nothing that can create more tokens later.

test/TorchInu.invariant.t.sol: invariant tests over random call sequences. A handler makes random transfers and approvals among five accounts, with the deployer starting out holding the whole supply. Each of the 8 call types ran about 2,000 times (16,384 calls in total), with no reverts and no discarded runs. The handler mixes valid calls with calls that must fail: sending more than the balance, sending to the zero address, spending beyond an allowance, and an outside address trying mint, burn, burnFrom, pause, blacklist or pulling tokens without an allowance. Each failing call is checked for the exact error it should give. After every call these must hold:

• The total supply stays at exactly 1,000,000,000 × 10¹⁸.
• The five accounts' balances add up to the total supply, and the zero address, the token contract and the outside address hold nothing.
• Every balance and allowance matches a separately kept record of what it should be.
• No call that should fail succeeded, no call that should succeed failed, and no call changed anything it shouldn't have.
• The token contract holds no ether.

test/TorchInu.edge.t.sol: 20 edge-case tests, mostly failure paths:

• Amounts: moving the whole supply out and back, moving one wei, and asking to move the maximum possible amount, which fails even with an unlimited allowance.
• Zero amounts: transfers of zero emit the event, and pulling zero needs no allowance.
• Zero address: sending to it fails even for zero tokens, including through transferFrom (where the allowance is left untouched). Pulling from it, and approving or sending as it, fail too.
• Allowances: a new approval replaces the old one rather than adding to it. An owner needs an allowance to pull from their own account. Allowances are separate for each owner and spender pair. Once an allowance is used up, the next pull fails.
• Events: transferFrom emits only Transfer, and the constructor emits exactly Transfer from the zero address followed by SupplyMinted.
• Two fuzz tests at 1,000 runs: one checks that any approval value is stored and emitted. The other checks that a transferFrom succeeds only when the amount fits both the allowance and the balance, and changes nothing when it fails.

The run counts are set inside the test files, so foundry.toml is unchanged. I didn't touch anything outside test/ and haven't committed; the two new files are untracked in the working tree.

The review is complete. The findings file holds an empty list with six coverage rows, and no files in the tree were changed.

Result: no defects found. TORCHINU is OpenZeppelin ERC20 v5.4.0 with constants and a one-shot constructor mint. The vendored library files are the unmodified upstream text. The compiled ABI exposes only approve, transfer and transferFrom as state-changing entry points, plus the constructor.

What I checked, by guide:

• Economic Security. No external dependencies, oracles or callbacks. No fee, burn, tax or rebase on any transfer, so the three launch flows and both swap directions move exactly what they say. Zero-address sender, receiver and spender revert with typed errors. Transferring the maximum uint reverts cleanly rather than wrapping.
• Invariant. The only writer of total supply after deployment would be a mint or burn path, and none exists. A 256-run handler invariant with 128,000 random transfer and transferFrom calls kept the sum of balances equal to the constant 1e27 supply throughout. Self-transfer and self-transferFrom keep the balance intact.
• Flow Gap. I simulated the pool manager's sync-and-settle delta accounting for 1 wei, 85% and 100% of supply, both by direct transfer and by allowance pull. The credited delta equalled the requested amount each time, so the seed, swaps and distributor claims cannot arrive short. The constructor takes no arguments and makes no calls, so a CREATE2 from the factory leaves the full supply on the factory.

Notes that are not defects. The usual ERC-20 approve race applies, as it does to every plain ERC-20. The launch economics such as the 2,500 IMD opening cap and the pool fee live in the job and manifest, not in this code. The two static-analysis lines were a low-severity literal style note and no results, and neither led to a defect.

Not reached. The protected v4 pool test could not run locally because v4-core is not vendored in this tree. My delta simulation covers the token side of that flow, not the pool manager itself.

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

Outcome: no defects in the Execution Trace, Periphery or First Principles areas. The token is an unmodified OpenZeppelin ERC20 with a one-shot constructor mint, and every traced path behaves as a plain ERC-20 should.

What I checked

• Execution trace: approve, transfer and transferFrom from entry to storage write, including zero values, zero addresses, self-transfers, infinite allowance, allowance-before-balance ordering and the absence of any external call or callback. Each is recorded as holds in the coverage record.
• Periphery: fetched OpenZeppelin v5.4.0 from upstream and diffed all five vendored files. They are byte-identical. The deploy script is a single new TorchInu() under broadcast and is not used by the IMD launch.
• First principles: the supply literal equals the 28-digit manifest string in the README, the constructor takes no arguments and calls nothing, the name and symbol match the brief, and nothing after deployment can mint, burn, pause, freeze or seize. The existing 28-test suite passes and a scratch edge-case suite of seven tests passed before I deleted it.

One info note: DECIMALS in src/TorchInu.sol:22 is documented as what decimals() returns, but decimals() is never overridden. Both are 18 today, so nothing fails on the current code. It is recorded at info severity with the exact mechanism, since any later edit to the constant would silently desynchronise the manifest from the deployed token.

Coverage: all three verifier-listed entry points plus six invariant and periphery rows are answered. No files other than .imd-findings.json were created, and the tree is clean.

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

Outcome: no defects that block the launch. The token is an unmodified OpenZeppelin 5.4.0 ERC20 with a no-argument constructor that mints the full supply once to the deployer. One specialist note was kept at info severity.

What I verified

• All three entry points hold. I traced approve, transfer and transferFrom through OpenZeppelin's code and confirmed each success and revert path with a scratch Foundry test, including zero-address checks, balance and allowance errors, allowance decrement and the infinite-allowance case.
• Constructor and manifest agree. The supply and decimals returned by the deployed token match launch.json, and the empty constructor argument list matches the no-argument constructor.
• Deployability holds. Runtime and creation code are far below the size limits, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The project's 49 tests pass. Slither reported nothing, and the aderyn literal lead is just the supply expression, which equals the manifest value.

Specialist findings settled

• The audit_flow info note reproduces as stated. The DECIMALS constant is documented as what decimals() returns, but decimals() is never overridden, so they agree only because both are 18. It is kept as info with the source-edit reproduction, since no runtime input triggers it. The other three specialists and the test writer reported nothing, so there was nothing to merge.

The report in .imd-findings.json holds one info finding and six coverage rows covering every listed entry point plus the constructor and deployability invariants.