The routr (ROUTR) token is built, tested, documented, and committed on main.

What was delivered

• src/RoutrToken.sol: contract RoutrToken, a thin OpenZeppelin v5 ERC-20. Name routr, symbol ROUTR, 18 decimals. The constructor takes no arguments and mints the full supply of 1,000,000,000 tokens once to msg.sender, which on the launch is the factory. There is no owner, mint, burn, pause, blocklist, fee or tax, so the supply can never grow and no privileged hand can touch a holder's balance.
• test/RoutrToken.t.sol: 31 tests. They cover metadata and supply, minting to a contract deployer standing in for the factory, transfer and allowance success and failure paths, the absence of every mint and admin selector the protected floor probes, ether rejection, EIP-170 size, the same reachable-opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and four fuzz tests for supply conservation and allowance accounting.
• script/DeployRoutrToken.s.sol: a reference deploy script whose deploy() function the tests call directly. It reads no environment.
• README.md: behaviour, deployment parameters, the launch values for reference, an empty "After launch" section since nothing is configurable, and the assumptions and open items.
• foundry.toml pins solc 0.8.26, enables the optimizer, and sets bytecode_hash = "none" and cbor_metadata = false for reproducible bytes. forge-std v1.9.7 and OpenZeppelin Contracts v5.4.0 are vendored under lib/ as plain files with no git metadata, so the build works offline.

Checks run

Check	Result
forge build (clean, offline)	passes
forge test with the verifier's fuzz seed	31 passed, 0 failed
forge test under an empty environment	31 passed
forge fmt --check	passes

Slither was not available on this machine, so it did not run. The source avoids the six rejected patterns by construction. No launch.json or .imd-blocked.json was written. The pinned owner check applies only to application contracts, and this launch has none.

Done. I wrote launch.json for the routr (ROUTR) custom token launch and verified it against the accepted tree.

What the manifest says

• Kind is custom_token. The token contract is RoutrToken, named routr, symbol ROUTR, 18 decimals.
• The constructor takes no arguments, so constructorArgs is empty. The compiled ABI confirms an empty constructor input list.
• totalSupply is 1000000000000000000000000000, the exact value the constructor mints once to msg.sender.
• The contracts list is empty, since the accepted tree holds only the token and no application contracts.
• pool and economics are copied exactly as the launch gives them: IMD as paired currency, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object verbatim.
• notes describe only the token present in the tree and run to about 925 characters.

Checks run

• The manifest parses as JSON with only the schema's top-level keys, and a script confirmed the supply and economics values.
• forge build compiled cleanly with solc 0.8.26.
• forge test with the verifier's fuzz seed passed all 31 tests.
• Git status shows launch.json as the only new or changed file.

The review is complete. .imd-findings.json is written with an empty finding list and six coverage rows. No source files were changed, and the scratch directory was removed.

Result: no defects in the Math Precision, Boundary or Numerical Gap areas.

What I checked and why it holds:

• The only arithmetic in the token is the compile-time constant at src/RoutrToken.sol:26. It evaluates to exactly 10^27, matches the README's manifest supply string digit for digit, and sits well below the uint128 and int128 limits that the Uniswap v4 liquidity and delta math rely on. The aderyn large-literal lead is therefore not a defect.
• Launch splits divide exactly. The swarm, pool and remainder shares of 10^27 at 1000, 8800 and 200 basis points leave no remainder and sum back to the supply.
• Vendored library is genuine. I fetched OpenZeppelin v5.4.0 from GitHub and diffed the five files the token depends on. All five are byte-identical, so the _update, _spendAllowance and _approve paths are the audited upstream ones.
• Boundary enumeration is empty. The token makes no external calls, has no payable function, no receive or fallback, no bytes decoding, and no sentinel branches beyond OpenZeppelin's zero-address guards.
• Edge probes passed. A scratch suite of 13 tests covered zero and 1-wei transfers, whole-balance and self transfers, SUPPLY+1 and uint256.max amounts, max and max-minus-one allowances, zero-value transferFrom without allowance, from or to the zero address via transferFrom, and conservation of the balance sum. The project's own 31 tests also pass.

Coverage rows: approve, transfer and transferFrom all marked holds, plus three invariant rows for the supply constant, the exact launch splits, and the supply never growing after construction. Nothing was left unreached.

The review is complete. The findings file is valid JSON and no tracked file was changed.

Result: no defects in the Access Control, Trust Gap or Asymmetry area. The token at src/RoutrToken.sol is a 47-line wrapper over the stock OpenZeppelin v5.4.0 ERC20 with no roles, no initializer, no admin variants, and no proxy or delegatecall. The constructor takes no arguments and mints the whole supply once to the deployer.

What I checked

• Access surface. The compiled ABI exposes exactly three nonpayable functions, matching the verifier's list, with no receive or fallback. Every common mint, pause, blacklist, freeze, seize, upgrade and owner selector reverts from any caller including the deployer.
• Guard consistency. Balances are written only through the one _update path, and allowances only by the owner's own approve or by an allowance-gated decrement in transferFrom. The initial holder has no pull power over anyone without an allowance.
• Asymmetry pairs. Transfer and transferFrom share the same inner path. Mint is constructor-only and burn is unreachable because a zero receiver is rejected. The vendored ERC20.sol and Context.sol were read in full and match the stock release.
• Trust gap. There is no privileged actor and no formula, so no access-by-economics seam exists. The only asymmetry with a concrete input is the standard ERC-20 approve race, which is inherent to the plain ERC-20 the brief asked for and is already documented in the README, so I recorded it as a holding note rather than a finding.

Evidence. The existing suite of 31 tests passes. I added six probes under test/scratch/AccessProbe.t.sol for self-scoped approve, allowance gating against the factory, the absent burn path, the max-allowance exception, the approve race and the missing fallback. All six pass as traced.

Coverage record. The findings file holds eight rows, all holds: the three entry points, the constructor role handout, the no-privileged-selector invariant, the fixed-supply invariant, the paired-surface diff, and the reference deploy script outside my area. Nothing was left unreached. The static-analysis lead on the large numeric literal is correct arithmetic for one billion tokens at 18 decimals and is not a defect.

The review is complete. The findings file is valid JSON and the working tree is unchanged apart from the findings file and my scratch tests, which are ignored and not submitted.

Result: no defects found in the Economic Security, Invariant or Flow Gap area. The findings list in .imd-findings.json is empty, and the coverage record answers all three entry points plus six invariant and flow rows.

What I verified, and how:

• Entry points. approve, transfer and transferFrom are the unmodified OpenZeppelin v5.4.0 implementations. I read the vendored ERC20, Context and error-interface bodies in full, since the library is committed as plain files rather than a submodule, and they match upstream with no added branches, fees or hooks.
• Supply invariants. The supply is minted once in the constructor to the deployer and can neither grow nor shrink: there is no mint or burn path, and a transfer to the zero address reverts. A stateful invariant suite with a handler driving all three entry points across seven actors held sum of balances equal to total supply and total supply equal to one billion tokens over 256 runs of depth 64 with the verifier's fuzz seed.
• Launch flows. A simulation of the factory flows showed the swarm share, pool seed via transferFrom, remainder and a trader round-trip all moving exact amounts. No exemption list is needed because nothing taxes any path.
• Economic dependencies. The compiled runtime contains no call-family opcode at all, so there are no oracles, callbacks, reentrancy surfaces or external token interactions. The ABI exposes only the three state-changing functions and no receive or fallback.
• Static-analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note on the supply constant is style only; the constant evaluates to exactly the manifest's supply.

One item is recorded as a trust assumption rather than a finding: the standard ERC-20 approve front-running race, which the README already documents and which is inherent to the standard.

Nothing in my area was left unreached. No manifest exists in the tree yet, so there was nothing to check there.

The review is complete and the findings file is written. No defects were found in the assigned area.

Outcome. The token at src/RoutrToken.sol is a fixed-supply OpenZeppelin v5.4.0 ERC-20 with no additions beyond read-only getters and one event. All three listed entry points hold, so .imd-findings.json carries an empty findings list and eight coverage rows, including five invariant rows. The file is valid JSON and is the only change in the tree apart from my gitignored scratch test.

What I checked, by guide:

• Execution Trace. Traced approve, transfer and transferFrom through Context and ERC20 to final storage. Allowance is spent before the transfer and the call is atomic. Zero-address sender and receiver revert on every path. Self-transfer and from-equals-to transferFrom leave balances unchanged. There are no external calls, so no reentrancy or stale-read window exists.
• Periphery. Every vendored OpenZeppelin file is byte-identical to the upstream v5.4.0 tag, and every forge-std file to v1.9.7. Context returns msg.sender with no meta-transaction path. The compiled ABI exposes only the three state-changing functions, with no receive, fallback, owner, pause, mint or burn.
• First Principles. Total supply is written only on mint or burn paths, which are reachable only from the constructor, so supply can neither grow nor shrink. The constructor takes no arguments and credits msg.sender, which is the factory under CREATE2. Name, symbol, decimals and supply match the brief. Transfers move exactly the requested amount, so the swarm share, pool seed and swaps in the protected floor arrive whole.

Verification run. The shipped suite passes with the verifier's fuzz seed, formatting passes on tracked files, and a scratch test with 2000 fuzz runs of random transfer, approve and transferFrom interleavings conserved supply. The two static analysis leads were a clean Slither run and a style note on the supply literal, neither a defect.

Not reached. The protected pool test depends on Uniswap v4 sources that are not vendored, so I confirmed the launch flows by reading rather than executing it. The launch chain and manifest do not exist in this tree and were not assessed.

Added failure-path, boundary, fuzz, and stateful invariant tests. Only test/ changed.

Offline forge build and forge test pass with the required seed: 56 tests passed, including 32,768 randomized handler calls. No reproducible defects found.

The review is complete. The findings file holds an empty findings list with a full coverage record, and the working tree is clean apart from that file.

Outcome: no defects found. All four specialists and the independent tester reported nothing, so there was nothing to reproduce or merge. My own pass against the Pashov, x-ray, Trail of Bits and ethskills checklists found nothing either.

What I verified:

• The token in src/RoutrToken.sol is a plain OpenZeppelin ERC-20 with a no-argument constructor that mints exactly 1e27 minor units once to the deployer. It overrides nothing but decimals(), which returns 18.
• The vendored OpenZeppelin files it imports are the genuine v5.4.0 sources. The compiled ABI exposes only the ERC-20 surface plus constant getters, so there is no mint, owner, pause, blocklist, burnFrom or upgrade path.
• The existing suite of 56 tests passes, including the reachable-opcode scan that mirrors the protected floor's DELEGATECALL, CALLCODE and SELFDESTRUCT check.
• A scratch test I wrote and then deleted deployed the token by CREATE2 from a contract, confirmed the supply landed at that contract, and moved the distributor, pool and remainder shares plus a trader round-trip. Every balance was exact and supply stayed constant.
• Creation code is 3510 bytes and runtime 2254 bytes, well within the factory's limits. The manifest uses only schema keys and its supply, decimals and empty constructor arguments match the code.
• The aderyn "large numeric literal" lead at line 26 is the intended supply constant and equals 1e27, so it is not a defect.

The three listed entry points, approve, transfer and transferFrom, are all marked holds in the coverage record, along with seven invariant rows covering the constructor mint, supply immutability, deployability, launch flows, bytecode, library integrity and the manifest.