Implemented Sooth Protocol (SOOTH): 1 billion tokens with 18 decimals, minted once to the deployer. No additional minting or administrative powers.

Dependencies are vendored; deployment parameters, assumptions, and operational responsibilities are documented in README.md.

Verified with Solidity 0.8.26:

• forge build passed
• forge test passed: 31 tests using the supplied fuzz seed
• forge fmt --check passed

Protected launch integration checks remain for the independent verifier.

I found no math, precision or boundary defects in SoothToken, so .imd-findings.json holds an empty findings list and a coverage row for each of the three entry points, all marked holds.

Why there's nothing to report:

• src/SoothToken.sol is plain OpenZeppelin ERC20 v5.2.0. Its only addition is a constructor that mints INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18 (1e27) to msg.sender. That number is right for 18 decimals and far below the uint256 limit. The supply is fixed, so the unchecked add in _update cannot overflow.
• Every unchecked subtraction in OZ's _update and _spendAllowance is preceded by a balance or allowance check. I traced the edge cases and each behaves correctly: zero transfers, sending to yourself, sending the exact balance, balance + 1 (reverts), an allowance exactly equal to the amount, the maximum "infinite" allowance (left untouched, as the standard intends), and the zero address.
• Nothing rounds, takes a fee, burns or rebases. No path mints after the constructor and no role holds special powers. The aderyn "large numeric literal" warning is about formatting only.
• The OpenZeppelin files match the hashes in DEPENDENCIES.sha256. All 31 project tests pass under forge test.

Coverage: besides the three entry points, I added two rows for properties I checked: the supply stays fixed, and all balances always add up to the total supply.

Not reported:

• Six forge-std files fail the DEPENDENCIES.sha256 check. They are test-only, outside the math area and not in the deployed bytecode.
• The usual ERC20 approve race is how the standard works, not a defect in this code.

I didn't write any proof tests because there were no findings that needed one, and I changed no repository files apart from the findings file.

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

forge build succeeded. All 31 tests passed with the specified fuzz seed. Only launch.json changed outside permitted scratch files.

The review is complete and .imd-findings.json is written. The tree is otherwise untouched: the scratch tests were removed and git status shows only the findings file.

Outcome: the token holds in the economics area. SoothToken is a two-line wrapper over OpenZeppelin ERC20 v5.2.0, and the vendored ERC20.sol matches the upstream hash at the pinned commit byte for byte. I checked it against the Economic Security, Invariant and Flow Gap guides and found no defect in the token itself.

What I verified, with reproductions run locally:

• Conservation invariant. Sum of balances equals totalSupply equals 10^27 permanently. The constructor is the only mint; there is no burn, admin, receive, fallback, DELEGATECALL, CALLCODE or SELFDESTRUCT in reachable runtime code. I re-ran the project's fuzz and invariant suites under the documented seed and a scratch opcode scan matching the protected test's method. All pass.
• Launch flows. Factory to distributor, distributor to claimant, factory to pool-manager pull via approve plus transferFrom, trader buy and sell, and remainder forward each move exactly the requested amount, so the protected floor's swarm, seed and swap checks cannot come up short.
• Economic dependencies. None exist. No oracles, no callbacks, no fee formulas, no sentinel addresses, no payable path. The approve race is standard and documented in the README.
• Entry points. All three listed entry points are marked holds, with reasons, plus invariant and flow rows.

One low finding, outside my area but concrete. DEPENDENCIES.md claims all vendored files are unmodified upstream sources and instructs the reader to verify with the recorded SHA-256 list. That check fails for six forge-std files. The recorded hashes are the true upstream v1.9.6 hashes, but the committed copies were run through forge fmt afterward. I confirmed each vendored file is byte-identical to the upstream file after formatting, so the difference is cosmetic and test-only, and the token's bytecode is unaffected. The documented provenance check is nonetheless false as shipped. No proof test is attached since the severity is low.

Not reached. There is no launch.json in the tree, which the README says the launch service writes later, so the manifest row is marked unreached with the values it must carry.

The review is complete. The findings file is written at the repository root and no project files were changed.

Outcome. The token is a 17-line plain OpenZeppelin v5.2.0 ERC-20 with one constructor mint and no roles, hooks, or overrides. I found no defect in the three state-changing entry points. The one finding is a low-severity provenance issue in the vendored test library.

What I checked, from the Execution Trace, Periphery and First Principles guides:

• Traced approve, transfer and transferFrom through the vendored ERC20 into _update, _approve and _spendAllowance. Every revert path leaves balances and allowances untouched, amounts are delivered exactly, and the unchecked arithmetic is bounded by the fixed 10^27 supply.
• Verified the constructor mints the whole supply once to msg.sender, which is the factory under CREATE2 deployment, not the transaction origin. The compiled ABI exposes only the three listed mutators plus views, so there is no mint, burn, pause, blacklist, initializer, receive or fallback.
• Ran the project's 31 unit, fuzz and invariant tests with the documented seed, and the formatter check. All pass.
• Wrote and ran a scratch test mirroring the protected floor's reachable-opcode scan and the launch flows. No DELEGATECALL, CALLCODE or SELFDESTRUCT is reachable, and the flows move exact amounts. The scratch test was removed afterwards.
• Fetched the pinned upstream commits over the network and compared hashes. All five OpenZeppelin files the token compiles against are byte-identical to upstream.

The finding. Six vendored forge-std files differ from the pinned commit and from the repository's own hash manifest, so the integrity command documented in DEPENDENCIES.md fails on the committed tree. The diffs are whitespace-only reformatting, so no test logic changed and the token bytecode is unaffected, but the claim that the copies are unmodified is false and a verifier following the instructions gets a hard failure.

Coverage record. All three entry points are marked holds, with additional rows for the constructor mint, fixed supply, launch flow exactness, forbidden opcodes, library provenance and metadata. Nothing in the assigned area was left unreached.

Leads not promoted. The standard ERC-20 approve race and tokens sent to the contract address are documented in the README and are inherent to the requested design, so neither is reported.

The review is complete. The findings file is valid JSON with one finding and eight coverage rows, and the only files I created are .imd-findings.json and a scratch test under test/scratch/.

Outcome: the token is a bare OpenZeppelin v5.2.0 ERC-20 with a single constructor mint and no roles. Within the Access Control, Trust Gap and Asymmetry guides it holds. The three state-changing entry points all behave as intended. The one defect I could substantiate is in dependency provenance, not in the token.

Finding (low): six vendored forge-std files fail the project's own hash manifest. DEPENDENCIES.md claims the copies are unmodified upstream and tells readers to run sha256sum -c DEPENDENCIES.sha256. That command reports six FAILED lines. The recorded hashes are the genuine upstream v1.9.6 hashes. I fetched the upstream files and diffed them against the committed copies. Every difference is line-wrapping only, so test behaviour is unaffected and the token runtime is untouched. All five vendored OpenZeppelin files match upstream byte for byte.

What I verified for the coverage record:

• approve writes only the caller's own allowance and rejects a zero spender.
• transfer debits only the caller, rejects the zero address, and has no fee, exemption, pause or blacklist branch.
• transferFrom spends allowance before moving funds, and the deployer has no privileged pull path. A scratch test confirms the factory gets an insufficient-allowance revert when it tries to pull from another holder.
• No owner, initializer, receive, fallback, delegatecall or selfdestruct exists. Unknown selectors and plain ETH sends revert.
• Asymmetry and Trust Gap passes found nothing to compare. There are no admin variants, settable parameters or price formulas.

The project's 31 tests, including the invariant suite, pass with the documented fuzz seed, and forge fmt --check is clean. No manifest exists yet, which is expected this early. The ERC-20 approve front-running race is inherent to the standard and is documented in the README, so I left it out per the guide's do-not-report list.

Added 17 tests covering failure paths, allowance boundaries, revocation, rollback/retries, and caller identity. Strengthened invariants across 32,768 randomized calls.

forge build and full forge test passed offline with the required seed: 48 passed, 0 failed.

Only files under test/ changed. No implementation defects found.

The review is complete and .imd-findings.json is written. The working tree is otherwise unchanged.

Outcome. The token is a plain, unmodified OpenZeppelin v5.2.0 ERC-20 with a zero-argument constructor that mints the full supply once to the deployer. I found no defect in the contract itself. One low finding is kept.

Specialist findings. Three specialists (permissions, flow, economics) each reported the same root cause, so I merged them into one low finding:

• The documented integrity check sha256sum -c DEPENDENCIES.sha256 fails for six forge-std files. I reproduced the failure on the clean tree, then fetched the six files from the pinned upstream commit. The recorded hashes are the genuine upstream hashes. The committed copies differ from upstream only in whitespace, and the OpenZeppelin ERC20 the token compiles against is byte-identical to upstream. So the provenance claim in DEPENDENCIES.md is false as shipped, but the token's bytecode is unaffected.

My own pass. Build and all 48 project tests pass with the README's seed, and forge fmt --check passes. The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions. I traced each through the vendored ERC20 and recorded them as holding. The creation code is 2645 bytes and the runtime 1753 bytes, with no DELEGATECALL, CALLCODE or SELFDESTRUCT, and no address-bit requirement, so the factory's CREATE2 deployment works with the manifest's empty argument list. The manifest uses only schema keys with correct types and matching name, symbol, decimals and supply. The paired currency address on chain 4663 answers with the IMD symbol. The aderyn "large numeric literal" lead is the supply constant, which equals the manifest's total supply exactly, so it is not a defect.

What is next. The author's only open item is the forge-std checksum drift: either restore the six files byte-for-byte or regenerate the hash manifest and reword the "unmodified" claim.