Implemented robobet (ROBOBET) with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer. No later minting or administrative controls.

Dependencies are vendored for offline builds. README documents assumptions, deployment parameters, and operational responsibilities.

Verified successfully:

• forge build
• Forced offline build
• forge test: 34 passing with the supplied fuzz seed
• forge fmt --check

Done. The manifest is written and is the only change in the working tree.

What I wrote in launch.json:

• kind custom_token, token contract RobobetToken with name robobet, symbol ROBOBET, 18 decimals.
• constructorArgs is empty. The accepted constructor takes no parameters, confirmed against the compiled ABI, and mints the whole supply once to msg.sender.
• totalSupply is the constructor's mint in minor units, one billion times ten to the eighteenth.
• contracts is empty. The accepted tree contains only the token and no application contracts.
• pool and economics are copied verbatim from the launch reference: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.
• notes describes the token's behavior, the absence of owner or privileged calls, and why no launch placeholders are needed.

Verification

• forge build compiles cleanly with solc 0.8.26.
• forge test with the verifier's fuzz seed passes all 34 tests, including the invariant suite.
• git status shows only the new launch.json. No configuration, lib, or source file was touched.

The review is complete and .imd-findings.json holds the result. The working tree is otherwise untouched.

Outcome: no math, boundary, or numerical-gap defect in the token. RobobetToken is OpenZeppelin v5.0.2 ERC20 with a single constructor mint of a compile-time constant. There is no fee, division, scale conversion, downcast, external call, payable path, or bytes decoding anywhere in the contract, so every failure mode in the three assigned guides has no surface to act on.

What I verified, with concrete inputs:

• Supply constant evaluates to exactly 10^27, below 2^128, and divides by 10^18 with zero remainder. The aderyn large-literal lead is not a defect.
• Transfer boundaries: full-balance transfer, one unit over, max uint, one wei, zero amount, and self-transfer at full balance all behave as intended. The unchecked arithmetic in _update is bounded by the balance guard that precedes it.
• Allowance boundaries: max is treated as infinite, max minus one is finite and decremented, and an allowance larger than the balance is left intact when the balance check reverts.
• Launch split: 10% swarm, 60% pool and 30% remainder of 10^27 are exact with no dust, and the intermediate product cannot overflow.
• Conservation: the project's 34 tests pass under the documented seed, and my own 1000-run fuzz plus a 12-case scratch probe passed before I deleted the scratch directory.
• Vendored OpenZeppelin: all six files match the lock-file digests.

One info item outside my area is recorded. Seven vendored forge-std files do not match the lock digests or the pinned upstream commit, although stripping whitespace shows the differences are formatting only and forge-std is never in deployed bytecode. The finding cites the "unchanged from those commits" claim in DEPENDENCIES.md with a reproducible hash check.

Coverage rows: all three entry points holds, plus rows for the supply invariant, the launch split, the boundary enumeration, library integrity, and one unreached row for the deployer-side pool price derivation, which no code in this tree computes.

The review is complete and the record is written to .imd-findings.json. The tree is otherwise untouched.

Outcome: no permission, trust-gap or asymmetry defects in the token. The contract in src/RobobetToken.sol is a 17-line wrapper over the vendored OpenZeppelin v5.0.2 ERC20. It mints exactly 10^27 base units to the constructor caller and adds nothing else. The compiled ABI exposes only the standard ERC-20 surface plus a supply constant view. There is no owner, role, initializer, forwarder, proxy, pause, blacklist, mint or burn path, and the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.

What I verified for the three entry points:

• approve writes only the caller's own allowance row, rejects a zero spender, and has no admin variant.
• transfer moves exactly the stated amount with no fee, burn or hook branch, so every launch flow arrives whole.
• transferFrom spends the caller's allowance exactly, never decrements an infinite allowance, and rolls back atomically on any failure.
• Access from the factory position. From a CREATE2 factory probe holding the remaining supply, 14 common privileged signatures all revert and a pull from a holder without approval fails. Appending a holder's address to calldata does not spoof the sender.

Evidence gathered: the project's 34 tests pass under the documented seed, forge fmt --check is clean, and the six vendored OpenZeppelin files hash identically to upstream commit dbb6104c.

One info-level note recorded. Seven forge-std files differ from the digests in dependencies.lock.json. I diffed each against the pinned upstream commit and the differences are line-wrapping only, so the test library is not semantically altered and the deployed bytecode is unaffected. The note asks the author to restore upstream bytes or regenerate the lock so the provenance claim holds.

Coverage: all three listed entry points are marked holds, plus rows for the constructor and supply handout, the no-growth and no-freeze invariant, the three trust-gap seams, and the aderyn numeric-literal lead. Nothing in my area was left unreached.

The review is complete and .imd-findings.json is written. Only that file was touched; the scratch test was removed.

Outcome. The ROBOBET token holds across the Economic Security, Invariant and Flow Gap guides. It is a verbatim OpenZeppelin v5.0.2 ERC20 with one constructor mint of 10^27 base units to the deploying factory. I found one low-severity defect, and it is a provenance issue outside my area.

What I checked in my area

• Economic security. No external dependencies, oracles, fees, taxes, rebasing, blacklist or pause. Sentinel paths revert as the standard requires. No value can be extracted from any transfer path.
• Invariants. Sum of balances equals total supply on every path, including transfers to the token's own address. Mint is reachable only in the constructor, and the ABI exposes no supply-growing or balance-moving privileged selector.
• Flow gaps. Factory to distributor, distributor to claimant, PoolManager settle-by-delta pulls and trader takes all move the exact stated amount. No exemption list is needed because no transfer rule exists. Constructor takes no arguments and makes no external calls.
• Verification run. The delivered suite passes with the README seed. A scratch test with exact launch amounts and a conservation fuzz also passed before I removed it. The vendored OpenZeppelin files match their lock digests byte for byte.

The one finding (low). Seven files under the vendored forge-std library were reformatted and no longer match the digests in the lock file or the pinned upstream commit, contradicting the "unchanged from those commits" claim in DEPENDENCIES.md. The differences are whitespace reflows only, and forge-std is a test-only dependency absent from the deployed bytecode. The reproduction is a one-line digest check in the findings file.

Coverage. All three listed entry points are marked holds, with three further rows for the supply, constructor and flow invariants. Nothing was left unreached. The aderyn large-numeric-literal lead is stylistic and was not reported.

The review is complete and written to .imd-findings.json. No tracked files were changed.

Result: the token holds under all three assigned guides. One low-severity defect, in the dependency integrity record.

The contract at src/RobobetToken.sol is a 17-line OpenZeppelin ERC20 with a single constructor mint. I traced each of the three listed entry points from call to final state through the vendored ERC20 and found no execution-flow, periphery, or first-principles defect:

• approve: overwrites the allowance, rejects a zero spender, touches no other state.
• transfer: exact-amount delivery, zero recipient and insufficient balance revert atomically, no hooks, fees, or external calls, so factory, distributor, and pool flows arrive whole.
• transferFrom: allowance checked before balance, infinite allowance not decremented, any later revert rolls back the allowance write, and the deployer cannot move a holder's balance without approval.
• constructor: mints exactly 10^27 base units once to the immediate deployer, with no owner, role, initializer, or external call. The compiled ABI exposes only these three state-changing functions plus views, and the runtime contains no DELEGATECALL, CALLCODE, or SELFDESTRUCT.

Build and the full suite of 34 tests pass with the README's fuzz seed, including the stateful supply-conservation invariant. The six vendored OpenZeppelin files match both the lockfile and upstream v5.0.2 byte for byte.

The one finding (low): seven forge-std files under lib/forge-std/src do not hash to the digests in dependencies.lock.json, even though DEPENDENCIES.md says the libraries are unchanged from their pinned commits. I fetched the pinned upstream files to settle which side drifted. The lockfile digests are the genuine upstream values, and the tree's files differ only by formatter line reflow, with content identical once whitespace is stripped. Forge-std is test-only and absent from deployed bytecode, so there is no runtime impact. The defect is that the project's own supply-chain evidence fails verification, and a reader cannot tell this benign reformat from tampering without repeating the upstream comparison. The finding includes an offline one-line reproduction and the exact mismatched digests. The suggested fix is to restore the exact upstream bytes or regenerate the digests, and add a check that recomputes them.

The coverage record has seven rows: the three listed entry points and the constructor hold, the fixed-supply invariant holds, the OpenZeppelin periphery holds, and the forge-std integrity record points to finding 1. Nothing in the assigned area was left unreached. Both static-analysis leads were reviewed: Slither reported nothing, and the aderyn "large numeric literal" note is the supply constant, which is correct and intentional.

Added 13 boundary, failure-path, and fuzz tests. Strengthened invariants to verify balances and allowances across 32,768 random actions.

Offline build and full test suite passed with the required seed: 47 passed, 0 failed.

Only test/ files changed. No implementation defects found.

The review is complete and .imd-findings.json is written. Nothing else is needed.

Outcome: the RobobetToken code is clean. One low-severity provenance finding is kept, merged from all four specialists.

What I verified

• The token is a no-argument contract inheriting OpenZeppelin ERC20. The vendored ERC20 file is byte-identical to upstream v5.0.2, which I fetched and compared.
• It mints exactly the manifest supply to the deployer once, exposes only approve, transfer and transferFrom as state changes, and has no owner, mint, burn, fee, pause or blacklist path.
• The runtime is 1,752 bytes, well under the deployment limits, with no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE opcodes.
• The manifest matches the source: empty constructor arguments, matching name, symbol, decimals and total supply, lowercase addresses, no extra keys.
• All 47 project tests pass, including the 256-run invariant suite. The protected floor tests cannot run here since they need the floor's own sources, but each of their checks holds by inspection of a plain ERC20.

The one finding kept (low) Seven vendored forge-std files do not hash to the digests in dependencies.lock.json, while DEPENDENCIES.md claims they are unchanged from upstream. I reproduced it offline and confirmed against the pinned upstream commit that the lockfile is correct and the vendored copies were reformatted. Every difference is whitespace only, and forge-std is a test-only dependency absent from the deployed bytecode. The fix is to restore the seven files byte-for-byte or regenerate the digests and drop the "unchanged" wording.

Dropped: nothing. The specialists reported no other findings, and my own pass with the Pashov and Trail of Bits checklists found none.

Coverage: all three listed entry points marked holds, plus six invariant rows covering the constructor, supply growth, privileged calls, deployability, manifest consistency and the aderyn lead.