Implemented SOOTH: 1,000,000,000 tokens with 18 decimals, minted once to the deployer. No additional minting or admin powers.

Vendored dependencies support offline builds. Deployment parameters and responsibilities are documented in README.md.

Passed Solidity 0.8.26 build, formatting checks, 32 unit/fuzz tests, and both stateful invariants using the supplied seed.

Platform-specific pool integration remains for the launch verifier.

The review is complete. The findings file is valid JSON, the cited snippet matches README line 139, and the working tree is clean apart from the gitignored scratch test.

Outcome: no math defect found in the token. The arithmetic surface is one compile-time constant plus OpenZeppelin ERC20 v5.0.2, which I verified byte-for-byte against upstream. One info-level provenance note is recorded.

What I checked, per guide:

• Math Precision. The supply constant evaluates to exactly 10^27 and decimals is 18, matching the manifest. There is no division, rate, scale conversion, downcast or fee anywhere, so no rounding or truncation exists. The only unchecked arithmetic is OpenZeppelin's, each guarded by a preceding bounds check.
• Boundary. The token makes no external calls, has no payable, receive or fallback path, and decodes no bytes. The only sentinel branches are the zero-address rejections, walked on both sides. I executed 1 wei, full supply, supply plus one, max uint, zero amount, self-transfer, zero recipient, and zero-sender inputs.
• Numerical Gap. The single edge-case fast path is the infinite-allowance skip. A full-supply self-transferFrom under infinite allowance leaves balances, allowance and supply unchanged. Allowance of max minus one is correctly finite and decrements exactly.

Verification run:

The one recorded item is informational and outside my area. README and docs/REVIEW.md claim every vendored file matches its recorded SHA-256 hash. Seven forge-std files do not match the record or upstream v1.9.7. The diff is whitespace-only reformatting in test tooling, with no effect on the token, so the fix is either restoring those bytes or updating the hash record and the claim.

Coverage: all three listed entry points hold, plus rows for the constructor, the supply-conservation invariant, and the Boundary and Numerical Gap passes. Nothing in my area was left unreached.

Created launch.json matching SoothToken, its exact supply, empty constructor arguments, and the required pool and economics.

forge build succeeded. All 33 local tests passed with the supplied fuzz seed. Only the manifest changed outside permitted scratch artifacts.

The review is complete. No defects were found in the permissions area, and the findings file has been written with an empty list and full coverage.

What was reviewed. The token is a 17-line wrapper over the vendored OpenZeppelin v5.0.2 ERC20 with a single constructor mint of 10^27 units to msg.sender. I ran the Access Control, Trust Gap and Asymmetry passes from the Pashov reference against it, plus the entry-point inventory from the Trail of Bits guide.

Access Control. The compiled ABI exposes only the nine standard ERC-20 functions and the INITIAL_SUPPLY view. There is no owner, role, initializer, proxy, receive or fallback. The constructor stores no deployer address, so the factory holds the supply but no powers. A scratch Foundry test confirmed that 22 common mint, pause, blacklist, freeze, seize, upgrade and initialize selectors revert from the creator contract, the deployer and a stranger, and that the creator cannot pull from a holder without allowance. A reachable-opcode scan of the runtime found no CALL, DELEGATECALL, CALLCODE, CREATE, STATICCALL or SELFDESTRUCT.

Trust Gap. With no privileged actor and no economic formula beyond exact-amount transfers, there is no seam where authorization and economics interact. Launch flows to the distributor, claimants and the pool manager move exact amounts, so no exemption list exists to be misconfigured.

Asymmetry. transfer and transferFrom with the same from, to and value leave identical balances, fuzzed over 1,024 runs. transferFrom spends exactly the value from a finite allowance and leaves an unlimited allowance untouched. approve overwrites rather than adds, which is the ERC-20 standard and not a defect.

Verification. The project builds cleanly on Solidity 0.8.26, all 33 existing unit, fuzz and invariant tests pass with the README's seed, and the six vendored OpenZeppelin files match the hashes in lib/dependencies.json and read as upstream v5.0.2 line by line. Static analysis leads were both non-issues: Slither reported nothing, and Aderyn's large-literal note is a style remark on a constant that tests confirm equals 10^27.

What could not be done. A byte-for-byte comparison of the vendored ERC20 against GitHub could not run because the session's network allowlist excludes it. This is recorded as a note in the coverage record.

Output. .imd-findings.json holds {"findings":[]} with seven coverage rows: the three listed entry points, the constructor, and three invariants. The scratch test was removed and no project file was changed.

The control-flow audit of the SOOTH token is complete and found no defects. The findings file is written with an empty findings list and ten coverage rows.

What was reviewed. src/SoothToken.sol is a 17-line contract: it inherits the unmodified OpenZeppelin v5.0.2 ERC-20 and mints one billion tokens with 18 decimals to the deployer in the constructor. All three listed entry points execute entirely inside the vendored base, so the Periphery pass was the substance of the work.

Execution Trace pass. Each entry point was traced from call to final state. Transfers check the zero recipient and the balance before any write, the self-transfer re-reads storage so the balance is unchanged, and a failed transfer inside transferFrom rolls back the allowance write atomically. No external call sits between any read and its dependent write, so there is no stale-read or partial-update path. The only sentinel is the unlimited allowance, which skips just the decrement.

Periphery pass. I read ERC20.sol and Context.sol in full and compared them to upstream v5.0.2 text. All six vendored files match the hashes recorded in the dependency manifest. The compiled ABI exposes only the ERC-20 surface plus the supply constant. A reachable-opcode scan of the runtime, using the protected harness's algorithm, found no DELEGATECALL, CALLCODE, SELFDESTRUCT, and no CALL or CREATE at all.

First Principles pass. The supply constant equals ten to the twenty-seventh power, name and symbol match the brief, and the constructor is nonpayable with no arguments. With no fee, exemption list or transfer override, every launch flow moves exactly the requested amount, which is what the protected harness demands. A clean offline build from scratch and the full suite passed, 33 tests including the stateful invariants.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal line is style only, and the literal is checked against its decimal form in the unit tests.

One assumption left unverified. The build targets the Cancun EVM, and both creation and runtime code contain PUSH0 and MCOPY. Confirming that chain 4663 executes those opcodes needed a creation-style eth_call through the contributor's RPC relay, which the sandbox network allowlist blocked in this session. That row is recorded as unreached for the launch operator to confirm. It is a deployability check on the target chain, not a defect in the token's logic.

Only .imd-findings.json was added to the tree. Nothing was written under test/scratch, since no finding needed a proof test.

Nothing remains to request. The findings file is written and validated, the scratch directory is gone, and the working tree is clean apart from the findings file.

Outcome: the Sooth Protocol token holds up under the Economic Security, Invariant and Flow Gap passes. The only substantiated defect is a provenance documentation error, recorded as one low finding in .imd-findings.json.

What I verified

• The token is an unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint. The vendored ERC-20 closure is byte-identical to upstream, confirmed by download and comparison.
• The compiled ABI exposes only the ERC-20 surface plus the supply constant. No mint, burn, owner, pause, initializer or upgrade path exists.
• A reachable-opcode scan of the runtime shows no CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT, so there is no callback, reentrancy or external-dependency surface.
• Transfers and allowance spends move exactly the requested amount with no fee, exemption list or address branch. A scratch test confirmed the 10/80/10 launch split, a pool-manager style pull and payout, and conservation of the full supply under fuzzing. The existing 33-test suite also passes with the project's fuzz seed.
• The aderyn large-literal lead resolves to exactly 10^27, matching the manifest supply and 18 decimals. Not a defect.

The one finding (low): docs/REVIEW.md and the README claim all 36 vendored files match the SHA-256 hashes in lib/dependencies.json. Seven forge-std files do not. The recorded hashes are the correct upstream v1.9.7 values, and the vendored copies differ only by line-wrapping, consistent with a formatter pass. This is a test-only dependency with no effect on the token's bytecode, but the provenance claim is false as committed. The reproduction is a hash-check script included in the finding, and the fix is to either restore the upstream bytes or re-record the hashes and amend the wording.

Coverage: all three listed entry points are marked holds, with additional rows for the supply conservation invariant, the exact launch-flow invariant, the no-external-call invariant, the static-analysis lead, and both dependency provenance checks. No entry point is unreached.

I found no defects in the token itself. One documentation finding stands, rated low, and it's written to .imd-findings.json.

The token: src/SoothToken.sol is a plain OpenZeppelin v5.0.2 ERC-20. Its constructor takes no arguments and mints 1,000,000,000 SOOTH (18 decimals) once to the deployer. There is no other way to mint or burn, no owner role, no fees and no overridden transfer logic. The vendored OpenZeppelin files are byte-for-byte the recorded originals.

• Deployability: creation code is 2,644 bytes and deployed code is 1,752 bytes, well under the limits. It links no libraries and uses no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Tests: forge test runs 52 tests and all pass.
• Manifest: launch.json matches the code. It has the right supply and decimals and an empty constructorArgs, which fits the constructor taking none. I could not check that the economics were copied exactly from the job, because the job's figures weren't in front of me.
• Static analysis: aderyn flagged the large number on SoothToken.sol:12. It's 1_000_000_000 * 10 ** 18, correct and readable, so I didn't report it.

Kept finding (low): the math and economics specialists reported the same problem, so I merged them into one finding. README.md:139 says "Vendored code is unmodified" and docs/REVIEW.md:37 says all 36 vendored files matched their recorded hashes. Seven test-only forge-std files actually differ from the hashes in lib/dependencies.json:

• src/StdAssertions.sol, src/StdJson.sol, src/StdToml.sol, src/Vm.sol, src/console.sol, src/interfaces/IERC7540.sol, src/interfaces/IMulticall3.sol

I reproduced this by recomputing every hash: 7 of 36 don't match. I also downloaded three of the files from upstream v1.9.7. Their hashes equal the recorded ones, and once whitespace is stripped they are identical to the committed copies. So someone reformatted them, and nothing about how they behave changed. The token's compiled code is unaffected. The fix is either to restore the seven files or to re-record their hashes and correct the two statements.

Coverage: all three entry points, approve, transfer and transferFrom, are marked holds. I also added rows for two checks: the supply can't grow after launch, and the token deploys through the factory.

I attached no Foundry test, since there is no critical or high finding. I modified no files, and .imd-findings.json is valid JSON.