Implemented Routr (ROUTR): 18 decimals, exactly 1,000,000,000 tokens minted once to the deployer. Dependencies are vendored, with deployment and operational documentation included.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed: 32 results, using the specified fuzz seed.
• forge fmt --check passed.

Protected integration tests require the verifier’s launch infrastructure and were not run locally.

Created launch.json matching Routr’s constructor, exact supply, pool settings, and economics. No other submission files changed.

forge build passed. forge test passed all 32 reported tests with the supplied fuzz seed. Manifest fields and constructor ABI checks also passed.

The review is complete. The findings file is in place and ignored by the repository's exclude list as the harness intends, and the tree holds no stray files.

Outcome: no defects found in the math area. The findings file at .imd-findings.json holds an empty findings list and six coverage rows, all holds.

What was reviewed

• src/Routr.sol is a 17-line fixed-supply token on OpenZeppelin v5.1.0 ERC20. The vendored files match their recorded SHA-256 hashes.
• The compiled ABI exposes only the nine standard ERC-20 functions plus the INITIAL_SUPPLY constant. There is no mint, burn, owner, pause, or callback path.

Math Precision pass. The contract has no division, no scaling, no casts, and no fixed-point systems. The constant was computed by command and equals exactly 10^27, which fits in uint128 and is far below uint256. The aderyn large-literal lead is style only.

Boundary pass. There are no external calls, no payable or fallback functions, no bytes decoding, and the only sentinel is the zero address, which reverts on every path. Max-uint, supply plus one, exact supply, zero, and one-wei inputs on each entry point behaved as specified.

Numerical Gap pass. The unchecked subtraction and addition in the inherited transfer path are bounded by the preceding balance check and by total supply. A fuzz over the full amount and allowance domain, with the infinite-allowance sentinel and its neighbour at max minus one, matched the model in every run. Conservation of balances against total supply held in both the project's invariant suite and my scratch probes.

Evidence run

Check	Result
Project build and test suite	32 passed, 0 failed
Scratch boundary and fuzz probes	10 passed, 0 failed
OpenZeppelin hash verification	all files OK

The scratch test directory was removed afterward. Static analysis reported nothing at low impact or above beyond the literal-style note. Nothing outside the assigned area was unreached: the three entry points and the three invariants each have a coverage row with a reason.

Result: no defects found in the control-flow area. The findings file holds an empty list plus eight coverage rows, and no tracked file was changed.

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

• Routr.sol itself is seventeen lines: an unmodified OpenZeppelin ERC-20 whose constructor mints exactly one billion tokens with 18 decimals to the deployer. The constructor is nonpayable, takes no arguments and makes no external calls, so the factory's CREATE2 deployment receives the whole supply.
• Execution trace of all three entry points through the inherited code. Approve overwrites the allowance and rejects a zero spender. Transfer checks balance before an unchecked subtraction, credits exactly what it debits, and never touches total supply. TransferFrom spends allowance before moving tokens and rolls both back together on any revert. The only sentinel is the unlimited allowance, which behaves as documented.
• Periphery: the five vendored OpenZeppelin files are byte-identical to upstream commit 69c8def5 (v5.1.0), fetched independently, so the hash file in the tree is not the only evidence. Context returns plain msg.sender with no forwarder logic.
• First principles and launch floor: the runtime bytecode has no reachable CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT, is 1,752 bytes, and exposes only the standard ERC-20 surface plus a constant. Exact transfers mean the swarm share, pool seed and trader swaps cannot arrive short or revert.
• Verification: the committed suite builds and passes offline (32 tests including fuzz and invariants). A scratch probe of my own also passed: CREATE2 deployment with a foreign tx.origin, redeploy at the same salt, deployment with value, exact allowance consumption, near-max finite allowance, and short or unknown calldata. The scratch file was removed afterwards.

Leads not promoted: the aderyn large-numeric-literal line at src/Routr.sol:12 is cosmetic and the constant evaluates correctly to 10^27, so it is not a defect. The README names Ethereum as the intended chain; the launch chain comes from the job, not from the README, so this is documentation only.

Nothing left unreached in the assigned area. The manifest step has not run yet, so there is no launch.json to check; when it is written it should carry an empty constructorArgs list and a totalSupply of 1000000000000000000000000000.

The review is complete and the findings file is written. The working tree is unchanged apart from the deliverable, which the repository already excludes from tracking.

Outcome: no defect found in the Routr token's economics. The findings file at .imd-findings.json holds one info-level note and eleven coverage rows, all three verifier entry points marked holds.

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• Supply and mint. The constructor mints exactly 10^27 minor units to the caller, once. Deployed via CREATE2 from a factory contract, the factory holds everything and the transaction origin holds nothing.
• Conservation. No runtime path reaches mint or burn, and transfers to the zero address revert, so the sum of balances equals total supply forever. The existing stateful invariant suite passes with the pinned fuzz seed.
• Launch flows. No tax, exemption list or hook exists. Factory to distributor, distributor to claimant, pool pushes and allowance-based pool pulls all produce balance deltas equal to the requested amount in a local probe.
• Privileged powers. The compiled ABI has only the nine ERC-20 and metadata functions plus the supply constant. No owner, initializer, pause, blacklist, receive or fallback.
• Bytecode. The protected floor's reachable-opcode walk, rerun locally, finds no DELEGATECALL, CALLCODE or SELFDESTRUCT. Runtime is under the EIP-170 limit.
• Dependency integrity. All five vendored OpenZeppelin files hash identically to the pinned v5.1.0 commit on GitHub, and the project's checksum file passes.
• Static analysis leads. Slither reported nothing. Aderyn's low-severity large-literal note is style only and the literal is already written with digit separators.

The one note recorded is the standard ERC-20 allowance overwrite race, where a spender can consume both the old and the replacement allowance. It reproduces on this code, but it is inherent to the ERC-20 interface, documented in the README, and needs no change. I recorded it as info so the judge sees it was considered.

Not reached. The full Uniswap v4 seed and swap in the protected harness cannot run here because the v4 sources and launch environment are not in the repository. A plain exact-transfer token has no mechanism that could fail there, but that run belongs to the verifier.

I added a new test file, test/RoutrLaunch.t.sol, alongside the earlier contributor's tests, which I left unchanged. forge build succeeds, and forge test with the verifier's fuzz seed passes all 46 tests: the 32 that were already there and 14 new ones, with no failures or skips.

I found no defects. Routr is OpenZeppelin's ERC-20 with one mint in the constructor, so I wrote no .imd-findings.json. One fuzz test failed on my first run, but the mistake was in my test setup, not the token. The test tried to fund an account with more tokens than the deployer still held after setUp. I fixed the test's input range and it passes.

New unit and fuzz tests (RoutrLaunchTest):

• Launch deployment: a stand-in factory deploys the token at a predicted address and receives the whole supply, and the person sending the transaction gets nothing. Deploying twice with the same salt reverts. A fuzz test then runs the whole launch in one call, with the pool share fuzzed from 0 to 90% of supply. The 10% swarm share, the pool seed and the remainder each arrive exactly, and a claim from the distributor arrives whole.
• Admin calls: all 21 privileged calls the launch's protected test tries, with the same oversized arguments, fail from both a stranger and the deployer. Supply and the holder's balance are unchanged, and the holder can still transfer afterwards. A further fuzz test sends random calls that aren't part of the token's interface: each one reverts and nothing changes.
• Bytecode: the deployed code contains no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, checked the same way the protected test checks it, and is within the 24,576-byte size limit.
• Edge cases:
  • Address(0) can't call approve or transfer.
  • An allowance of max − 1 is reduced when spent, but the max allowance is not.
  • Spending with exactly the allowance and exactly the balance works, and the next pull fails.
  • Tokens sent to the token contract itself are stuck for good.
  • Any approved amount is stored exactly.
  • A pull larger than the owner's balance reverts with the balance error and leaves the allowance untouched.

New invariant suite (RoutrOpenInvariantTest): 256 runs × 64 calls with no unexpected reverts. Balances spread across up to 64 addresses, including new ones and the token contract itself, with unlimited approvals mixed in. The random calls also include ones that must fail: spending over the allowance, sending to the zero address by either transfer or transferFrom, overdrawing, and approving the zero address. Each must revert with the exact expected error. After every sequence these hold:

• Total supply never changes, and the balances of all addresses used add up to it.
• Every balance and allowance matches an independent record kept by the test.
• The zero address has no balance and no allowance either way.

Fuzz and invariant run counts are set in the test file itself, since foundry.toml is not mine to change. The new file is the only change and is not committed yet.

The permissions review of Routr is complete. The findings file is written and the tree is otherwise unchanged.

Result: no defect in the permission model. Routr is OpenZeppelin v5.1.0 ERC20 with a single constructor mint and nothing else. There is no owner, role, initializer, pause, blacklist, mint, burn, upgrade, fallback or receive. Each of the three state-changing entry points acts only on the caller's own balance or allowance row.

What I verified, against the Access Control, Trust Gap and Asymmetry guides:

• Entry points. The compiled ABI has exactly the nine ERC-20 and metadata functions plus the supply constant. Every selector called from the deployer leaves the supply unchanged. Unknown selectors and ETH revert.
• Guard consistency. Balances are written only through the inherited update path, reached from transfer with the caller as sender and from transferFrom after the allowance is spent. Allowances are written only by approve for the caller's own row and by the decrement inside transferFrom. No weaker writer exists.
• Deployer trust. The constructor mints to msg.sender, which under the factory launch is the factory, not the transaction origin. After deployment the deployer has no power beyond an ordinary holder's, so the trust ends once the factory's one transaction distributes the supply. The deployer and a stranger both fail to pull a holder's balance without allowance.
• Bytecode. An opcode walk of the runtime finds no CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE, CREATE2 or SELFDESTRUCT in reachable code, so no reentrancy or confused-deputy surface exists.
• Dependencies. All five vendored OpenZeppelin files are byte-identical to upstream v5.1.0, fetched and diffed. The sender context is plain msg.sender, so no meta-transaction spoofing.
• Suite. The full suite passes offline from a clean build with no environment variables.

One info item is recorded: the inherent ERC-20 approve replacement race, with a concrete sequence showing a spender obtaining 150e18 where the holder intended a cap of 100e18. It is a standard property the README already documents, and I recommend no code change. It is included so the Asymmetry pass on the approve and transferFrom pair is accounted for.

Coverage in .imd-findings.json has eight rows: the three listed entry points all hold, plus rows for the constructor mint, absence of privileged entry points, bytecode safety, dependency integrity and the deployer trust assumption.

Out of my area but noted for the manifest step: the constructor takes no arguments, so constructorArgs must be an empty list and totalSupply the exact 10^27 string. The scratch test I used was removed and build output cleaned. Only the findings file remains, which the repository's exclude list already covers.

The review is finished and .imd-findings.json is written: one info finding, no blockers, and no repository files changed. git status is clean, so the findings file is git-ignored, but it exists and parses as valid JSON.

• Specialist findings: the two reports of the allowance replacement race (audit_economics and audit_permissions) share one root cause, so I merged them into one info finding at ERC20.sol:287. My Foundry test reproduced it: after approve 100, spend 100, approve 50, spend 50, the spender holds 150e18. It's standard ERC-20 behaviour and the README documents it, so no code change is needed. There's no proof attached because proofs are only required for critical or high findings.
• Static analysis: the aderyn large-literal warning is a false positive and is left out. INITIAL_SUPPLY is exactly 10^27.
• My own pass found nothing new:
  • Routr is unmodified OpenZeppelin v5.1.0 ERC20 plus a constructor mint, and the vendored files match their hashes.
  • A contract deploying it through CREATE2 receives the full supply.
  • The empty constructorArgs match the constructor, and launch.json reads as schema-valid.
  • The runtime is 1,752 bytes, with no reachable call, create or SELFDESTRUCT opcodes and no admin functions, receive or fallback.
• Coverage: approve is marked finding (ref 1); transfer and transferFrom are marked holds. I also added three invariant rows, all holds: fixed supply, deployability and no privileged behaviour.
• Tests: all 46 existing tests pass, and my three scratch tests passed before I deleted them.
• Not run: the protected launch suite needs the verifier's Uniswap v4 setup, which isn't in this repository. The real seed and swap flows are therefore unexercised, though nothing in the token could tax or block them, since transfers are exact.
• Stale docs (not reported as defects): the README says the project doesn't supply a launch manifest, but launch.json is present. REVIEW.md says 31 unit/fuzz tests, while the suite now runs 46 tests in total.