Done. The Sooth Protocol token is implemented, tested and committed as a root-level Foundry project.

What was built

• src/SoothToken.sol: contract SoothToken, an OpenZeppelin 5.4.0 ERC-20 with ERC-2612 permit. Name "Sooth Protocol", symbol "SOOTH", 18 decimals. The constructor takes no arguments and mints the full 1e27 minor units once to msg.sender, which at launch is the ProjectFactory. There is no owner, mint, pause, blocklist, fee or upgrade path, so it clears every rule in the protected floor test.
• test/SoothToken.t.sol: 37 tests covering metadata, supply, transfers, allowances, permit success and failure paths, absence of mint and admin functions, the privileged-call probe from the protected test, a reachable-opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, exact launch flows, and the deploy script. Two fuzz tests pass under the verifier's seed.
• script/DeploySoothToken.s.sol: reference script with a deploy() function the tests call directly, and a run() wrapper. No environment reads.
• README.md: assumptions, launch parameters, an empty "After launch" section since nothing is configurable, operational responsibilities, and test coverage.
• foundry.toml pins solc 0.8.26, cancun, optimizer at 200 runs and bytecode_hash = "none", with ffi off and no filesystem permissions.

Dependencies are vendored as plain files under lib/ (forge-std 1.17.0 and OpenZeppelin Contracts 5.4.0) with all git metadata removed. The index contains no submodule entries, and the built bytecode has no link placeholders.

Checks run locally

Check	Result
forge build	passes
forge test with the verifier's fuzz seed	37 passed, 0 failed
forge fmt --check	passes

One judgment call to flag. The brief asked only for a fixed-supply token. I included ERC-2612 permit as a standard, non-privileged convenience and documented it in the README. It can be removed by dropping the ERC20Permit parent if the requester wants the bare minimum.

Commit b54f9e2 on main holds the work. No launch.json was written, and no deployment was performed.

I wrote launch.json for the Sooth Protocol launch. It is the only changed file.

What the manifest says

• Kind is custom_token. The token contract is SoothToken, named Sooth Protocol with symbol SOOTH and 18 decimals.
• constructorArgs is empty. The accepted constructor takes no parameters and mints the whole supply to msg.sender, so no launch placeholders apply.
• totalSupply is 1000000000000000000000000000, which matches the contract's TOTAL_SUPPLY constant of one billion tokens at 18 decimals.
• contracts is empty. The accepted tree has no application contracts, only the token, a unit test and a reference deploy script.
• pool and economics are copied verbatim from the launch reference: IMD as paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's poolBps, opening cap and remainderTo.
• notes describe only the token that is present and run 1453 characters.

Checks run

• A schema-shape check confirmed only the allowed top-level keys, string uints and addresses, numeric fee, tickSpacing and decimals, and a contract name under 32 characters.
• forge build compiled cleanly. forge test with the verifier's fuzz seed passed all 37 tests.
• git status shows launch.json as the sole new file. No configuration, lib or workflow files were touched.

I found no math defects in SOOTH. .imd-findings.json has an empty findings list and a coverage row for each of the 4 entry points, all marked holds, plus 2 rows for invariants I checked.

What I reviewed: src/SoothToken.sol and the library code it uses. The contract only adds constants, a constructor that mints the supply once, and decimals() returning 18. Everything else comes from the bundled OpenZeppelin 5.4.0 ERC20 and ERC20Permit. I compared the bundled copies of every file involved (ERC20, ERC20Permit, ECDSA, EIP712, Nonces, MessageHashUtils, ShortStrings, StorageSlot, IERC20, the error interface, Context) against the official npm 5.4.0 release, and they are identical.

Math precision: The contract has no division, fees, scaling between decimals, narrowing casts or rounding. The supply 1_000_000_000 * 10 ** 18 comes to exactly 1e27, as the brief requires. The only arithmetic that skips overflow checks is in the library's balance and allowance updates, and each one is checked first (fromBalance < value, currentAllowance < value). A balance can't overflow because all balances add up to the total supply, which is fixed at 1e27, far below the uint256 maximum.

Boundaries: I ran a scratch Foundry test, then deleted it; no repository files changed. It covered:

• Transfers: fuzzed transfers keep the total supply and the sum of balances equal; zero-amount and whole-balance transfers work.
• Allowances: fuzzed allowance and amount pairs leave exactly the expected remainder, or revert when the amount is too large. A maximum ("infinite") allowance is not reduced, as intended.
• Permit: a deadline equal to the current time is accepted and one second later is rejected. A replayed signature, a tampered (high-s) signature and a zero-address owner with a garbage signature all revert.

The existing 37 tests also pass.

Numerical gaps: No invariant depends on a rounded or edge-case number. Supply is fixed after deployment because nothing outside the constructor can mint or burn.

Static analysis: Aderyn's "large numeric literal" warning at line 30 points at the supply constant. It evaluates to the correct value, so it isn't a defect, and Slither reported nothing.

Not covered: I didn't run the supplied launch-flow test (Token.protected.t.sol) or review its PoolManager seeding flow, which belongs to another specialist's area. It imports src/LaunchLiquidity.sol and Uniswap v4 code, neither of which is in this repository. The token has no transfer fees or exemptions, so nothing in my area affects that flow.

I added two test files. forge test passes all 70 tests (37 from the earlier suite plus my 33), both with the verifier's seed 0x808c…cb18 and with a random seed. I found no defects, so I didn't write .imd-findings.json.

test/SoothToken.invariant.t.sol: random-sequence tests over balances, allowances and permit nonces.

• A handler contract drives the token from 5 actors that can each sign permits. Coins can go to those actors or to the token contract itself, so the list of possible holders is closed and the sum check below covers everyone.
• It calls transfers, approvals (including unlimited ones), transferFrom, permits and time jumps. It also makes calls that must fail and checks the exact error each time: sending more than the balance, sending to the zero address, spending over the allowance, a reused or old permit, an expired permit, and a permit signed by the wrong key.
• It keeps its own record of every balance, allowance and nonce. After every call it checks:
  • the total supply never changes;
  • all holder balances add up to the full supply;
  • each balance, allowance and nonce matches the handler's record;
  • the token holds no ETH and its name, symbol and decimals stay the same.
• Settings are in the file: 256 runs of 64 calls each (16,384 calls), with no handler call reverting unexpectedly. Every function was called about 1,400–1,550 times, so none of the checks pass without being exercised.

test/SoothToken.edge.t.sol: failure paths and boundary values the earlier suite didn't cover.

• Amounts: one wei, the full supply plus one, and the maximum possible amount. Zero-amount transfers still emit the event, and sending zero to the zero address still reverts. Tokens sent to the token contract itself stay stuck there.
• Allowances:
  • spending exactly the allowance leaves zero;
  • an allowance one below the maximum still goes down when spent;
  • an owner needs an allowance even to move their own tokens with transferFrom;
  • setting an allowance to zero revokes it, and allowances are kept per spender;
  • a failed transferFrom leaves the allowance unchanged;
  • two fuzz tests check the allowance arithmetic.
• Permit:
  • signatures in the alternate "high-s" form, which would let a valid signature be reused, are rejected, and so are invalid v values;
  • nobody can approve on behalf of the zero address, and approving the zero address as spender is rejected;
  • signatures with the wrong spender or a future nonce are rejected;
  • a signature made for another copy of the token or another chain doesn't work;
  • the signing domain's name, version, chain and address are checked;
  • a deadline equal to the current time is accepted, and anyone can submit a permit;
  • nonces go up by one per permit, plus fuzz tests over any value and any wrong key.
• Unknown calls: a fuzz test sends arbitrary calls from the deployer and checks the deployer's balance and the total supply never change.

Findings: none. SoothToken is a plain OpenZeppelin token with permit: the whole supply is minted once to the deployer, and there's no owner, extra minting, pause or fee. Nothing I tested behaved incorrectly.

I couldn't commit because git on this machine has no author name or email set. I didn't change the git config, so the two files are in the working tree but not committed.

The review is complete and .imd-findings.json holds the result. The working tree is clean apart from the gitignored scratch test and the findings file.

Outcome: no defect found in the assigned area. The token is OpenZeppelin 5.4.0 ERC20 plus ERC20Permit with a single constructor mint and a decimals() override, and it has no privileged surface at all.

What I verified

• Vendored libraries are genuine. The OpenZeppelin tree (319 files) and forge-std match upstream v5.4.0 and v1.17.0 byte for byte, so the inherited guards are the audited ones, not a tampered copy.
• Access control. No owner, role, initializer, pause, blocklist, mint, burnFrom or upgrade selector exists in the compiled ABI. The only balance writers are transfer and transferFrom, both bound to the caller or an allowance the holder granted.
• Deployment phase. The constructor mints exactly 1e27 to msg.sender. A CREATE2 deployment from a factory-like contract credits that contract with the whole supply, as the floor requires.
• Permit. Deadline, nonce consumption, low-s malleability rejection, zero owner or spender rejection, and chain-id-aware domain separator all hold on the actual library lines and in scratch tests.
• Asymmetry and trust-gap seams. Every paired function routes through the same internal helper with identical checks. There is no settable parameter, fee recipient or pricing formula, so no seam exists for a privileged actor to exploit.

Tests run. The project's 37 tests pass with the verifier's fuzz seed, and 10 scratch probes in test/scratch/AccessProbe.t.sol pass. The protected pool-seed test could not be run here because it needs the floor harness and v4-core, but no transfer path treats any address differently, so the exact-amount flows hold by construction.

Reported. One info-level note: anyone can submit a holder's signed permit first, which is standard ERC-2612 behaviour. The allowance is still set and nothing moves, so integrators should wrap permit in a try/catch. No token change is recommended.

Coverage record. All four listed entry points have rows (three hold, permit references the info note), plus ten invariant rows covering the constructor, supply cap, launch flows, bytecode opcodes, vendored dependencies, deploy script, trust-gap seams and asymmetry pairs.

Review complete. The findings file is written and valid, and no tracked file was modified.

Result: no defects found in the Economic Security, Invariant and Flow Gap areas for SoothToken. The contract is an unmodified OpenZeppelin 5.4.0 ERC20 plus ERC20Permit with a single constructor mint and a decimals override, and I could not construct a failing input for any of the four entry points.

What I verified, beyond reading:

• Library integrity. All 22 OpenZeppelin files the token compiles against are byte-identical to the upstream v5.4.0 tag. The README calls them plain vendored files, so a tampered copy was the most plausible hidden defect, and there is none.
• Conservation invariants. A scratch Foundry invariant suite ran 128,000 randomized transfer, transferFrom and permit calls with zero reverts. The sum of balances and totalSupply stayed at exactly 1e27 throughout, and allowance and nonce accounting were exact on every call.
• Permit domain. DOMAIN_SEPARATOR equals the EIP-712 hash of name "Sooth Protocol", version "1", chain id 4663 and the token address, and it changes when the chain id changes, so signatures cannot replay across chains. Replay, expiry, wrong signer, tampered value and zero signature all revert.
• Launch flows. The 10 percent swarm share, 80 percent pool seed and 10 percent remainder, a claim, and a trader round trip all move exactly the stated amounts from a factory-like deployer. The token taxes nothing, so no exemption list is needed.
• Fixed supply and no privilege. The compiled ABI exposes only the four listed state-changing functions plus views. Mint-like, admin-like and freeze-like selectors revert from both the factory and a stranger, ETH sent to the token reverts, and the project's own 37 tests pass under the verifier's fuzz seed.

The static-analysis lead (aderyn's large numeric literal at line 30) resolves to the correct value 1e27, so it is not a defect.

The coverage record lists all four entry points as holds plus six invariant and dependency rows. The scratch test lives under test/scratch/, which is git-ignored and not part of the submission.

The review is complete. .imd-findings.json is written at the repository root with an empty findings list and eight coverage rows, and the working tree is otherwise untouched (scratch tests and build output removed).

Result: no defects found in the Execution Trace, Periphery and First Principles areas. The token is a 44-line wrapper over OpenZeppelin 5.4.0 ERC20 + ERC20Permit with one constructor mint and a decimals() override, and every path I traced behaves as the brief requires.

What I checked, and how:

• Execution flow of all four entry points. Traced transfer, transferFrom, approve and permit through OZ's _update, _spendAllowance, _approve, ECDSA.recover and EIP712. There are no external calls, hooks, payable functions or fallback, so no reentrancy, value-leak or stale-read surface exists. Amounts move exactly, so the swarm, seed and trader flows arrive whole.
• Edge inputs by scratch test. Zero owner, zero spender, flipped-s (malleable) signatures, deadline boundary, chain-id change, infinite allowance, transferFrom with zero sender or without self-approval, ETH sends and unknown selectors all revert or behave correctly. A 2000-run fuzz confirmed sum of balances equals the supply after mixed transfers.
• Periphery integrity. Diffed the vendored lib/openzeppelin-contracts/contracts against npm @openzeppelin/[email protected] and lib/forge-std/src against forge-std v1.17.0. No Solidity file differs, so the inherited code is genuine. The ECDSA high-s guard is present.
• First principles. The supply constant folds to exactly 1e27 and matches the manifest; the constructor takes no arguments, so the CREATE2 address is deterministic and the whole supply lands on the factory. The storage layout is pure OZ, the ABI has only standard ERC-20/2612/5267 functions, and the existing opcode scan for DELEGATECALL/SELFDESTRUCT passes.

The static-analysis lead (a large numeric literal at line 30) is a style note only: the literal is the intended supply. The one thing outside my reach was running the protected floor test itself, which needs the verifier's environment variables; the project's own 37 tests and my probes pass under forge 1.8.3.

Review complete. The findings file is valid, the snippet matches line 19 of the source, and no tracked file changed.

Outcome: SoothToken has no defects. The single specialist report, an informational note on ERC-2612 permit front-running, reproduces exactly as described and is kept at info severity. Nothing else was found.

What I verified:

• Specialist finding reproduced. Any third party can submit a holder's signed permit first. The holder's identical resubmission then reverts, the allowance is set as signed, and no balance moves. This is standard OpenZeppelin ERC20Permit behaviour, so it stays an integrator note, not a defect. My scratch test confirms it.
• Dependencies are clean. The vendored OpenZeppelin tree is byte-identical to a fresh clone of upstream v5.4.0.
• Deployment model holds. CREATE2 from a factory-like contract with no constructor arguments mints the whole supply to the factory. Creation and runtime bytecode are far under the protocol size limits.
• Launch flows are exact. Factory to distributor to claimant moves exactly the amounts requested, and total supply stays fixed.
• No admin surface. No mint path, owner, pause, blocklist, fallback, or receive. Runtime contains no DELEGATECALL, CALLCODE, or SELFDESTRUCT.
• Manifest matches the code. Empty constructorArgs, supply, decimals and contract name all agree with the source.

All 70 project tests and my 5 scratch tests pass. Coverage records holds for all four entry points plus three invariant rows. Static analysis leads were a style note only.