The robobet token project is complete, verified and committed.

What was built

• src/RobobetToken.sol: a self-contained fixed-supply ERC-20 named robobet / ROBOBET with 18 decimals. The constructor takes no arguments and mints the whole supply once to the deployer, which on launch is the factory. It has no owner, no mint or burn, no pause, blocklist, fee or tax, no external calls and no delegatecall, so every launch flow moves exactly what it says.
• script/Deploy.s.sol: a reviewable rehearsal script whose deploy function is called directly by a test and reads no environment.
• Tests in test/: ERC-20 success and failure paths with exact custom-error reverts, three fuzz tests for conservation, balance and allowance limits, a sweep of common mint and admin selectors from a stranger and from the deployer, a runtime-bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and a rehearsal of the launch economics split (10% swarm, 50% pool, 40% remainder) with whole-amount claims, a pool pull through an allowance, and a trader buy and sell-back.
• README.md: assumptions, deployment parameters, the launch economics, after-launch responsibilities, repository layout and security notes.
• foundry.toml pins solc 0.8.26, optimizer on, cancun, bytecode_hash = "none", ffi off. forge-std v1.10.0 is vendored as plain files under lib/forge-std with its licences, no submodule.

Verification

Check	Result
forge build (clean)	ok
forge test with the verifier's fuzz seed	34 passed, 0 failed
forge fmt --check	ok
RobobetToken runtime size	1,530 bytes

The work is committed on main as "Add robobet (ROBOBET) fixed-supply ERC-20 token with tests and docs". No launch.json and no .imd-blocked.json were written. Nothing was deployed, broadcast or signed; the manifest step and the IMD deployer handle the launch from the bytecode as built.

I wrote launch.json and changed no other file. It parses as valid JSON, forge build succeeds, and forge test passes all 34 tests with the required fuzz seed. Nothing ran a schema check on the manifest itself, so I checked its fields against the schema by reading them. The two protected tests weren't run either: they import src/LaunchLiquidity.sol, src/PoolInitializationGuard.sol and src/HookFlags.sol, which aren't in this tree.

• Token: the contract is RobobetToken (name robobet, symbol ROBOBET, 18 decimals). Its constructor takes no arguments, so constructorArgs is []. totalSupply is "1000000000000000000000000000", which is exactly what the constructor mints to msg.sender (1,000,000,000 × 10^18).
• Contracts: [], because the accepted tree contains only the token and no application contracts.
• Pool: IMD (0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7), fee 12500, tick spacing 60, and initial price 79228162514264337593543950336 (one to one, recorded for provenance only).
• Economics: copied verbatim from the job.
• Notes: a short description of the token: fixed supply, no owner, mint, burn, pause, blocklist or transfer fee, and no application contracts.

I found no defects in the permissions of src/RobobetToken.sol. .imd-findings.json holds an empty findings list and a coverage row for each of the three entry points, all marked holds. No other files were changed: the scratch test I wrote under test/scratch/ has been deleted.

What I checked, guide by guide:

• Access Control: the contract has no owner, roles, modifiers, initializer, mint, burn, pause, blocklist, delegatecall or selfdestruct. The constructor takes no arguments and mints exactly 1,000,000,000 × 10^18 to the deployer. Nothing can be given privileges after deployment, so there is nothing to escalate to and no guard to get around.
• Asymmetry: I compared every function that writes the same storage:
  • Balances are only changed in one internal transfer function, which takes the amount from one account and adds the same amount to the other.
  • Allowances are only changed by approve (for the caller's own allowance) and by transferFrom, which first checks and reduces the caller's allowance.
  • A holder gets no automatic allowance over their own tokens, and setting an allowance to the maximum value makes it unlimited, as the code comments say.
  • The zero-address checks and revert paths match across these functions.
• Trust Gap: this guide looks for problems where who is allowed to act, who profits, and who is treated differently interact. The token has no privileged party, no fees and no exemptions, so there is nothing for those to combine into.

What I ran: the existing 34 tests all pass. I also ran fuzz tests in a scratch file, each 256 runs, and they all passed:

• No caller without an allowance can move a holder's tokens.
• An allowance goes down by exactly the amount spent.
• The total of all balances always equals the total supply.

Static-analysis leads: Aderyn flagged a large number at line 46. That is the total-supply constant, and its value is correct. Slither reported nothing.

What I didn't cover: I only lightly reviewed the specialty areas outside these three guides, such as maths and economics. The contract does no maths beyond transfer and allowance arithmetic, which the fuzz tests covered.

The review is complete. The findings file holds an empty list and six coverage rows, and the working tree is otherwise clean (the only untracked file is .imd-findings.json, which git status shows as ignored or absent from the diff).

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

What I checked in src/RobobetToken.sol:

• Supply constant. The literal at line 46 evaluates to exactly 1e27 at compile time, matching the manifest value. Aderyn's "large numeric literal" lead is style only, not a defect.
• Unchecked blocks. Both subtractions sit behind a strict less-than guard on the same operands. The balance addition cannot overflow because the constructor is the only non-transfer write and the sum of balances is pinned at 1e27. The Approval emission at line 138 recomputes the subtraction in checked mode, which is redundant but harmless.
• Edge inputs. Self-transfer of a full balance, allowance exactly equal to value, max-minus-one allowance staying finite, infinite allowance still bounded by balance, value 0 and value max, and transferFrom from the zero address all behave correctly. I confirmed each with a scratch Foundry test that passed, then deleted the scratch file.
• Launch split. Ten, fifty and forty percent of 1e27 divide with no remainder, and the token has no fee or burn, so every launch leg arrives whole.
• Boundary enumeration. There are no external calls, no payable or receive paths, no decimals scaling and no bytes decoding, so the Boundary guide's work list is empty beyond the zero-address checks, which I traced on both sides.

The three entry points (approve, transfer, transferFrom) are each marked holds, with three additional invariant rows for supply conservation, the launch split and the boundary inventory. Nothing was left unreached. The existing suite of 34 tests passes with forge 1.8.5 and solc 0.8.26.

The review is complete. The findings file is written with an empty list and a full coverage record, the scratch test is removed, and the tree is otherwise untouched.

Result: no defects found in the Execution Trace, Periphery or First Principles areas.

What the code is. src/RobobetToken.sol is a 140-line self-contained ERC-20 with no owner, no mint or burn, no fee, no hooks, no inheritance and no external calls. The constructor mints the fixed supply once to the deployer. The Solidity name is RobobetToken, within the manifest's 32-character limit.

What I checked and how it held up:

• Execution trace. Every state-changing path has one guard then one or two writes, with no external call between a read and its use. Self-transfer re-reads storage after the subtraction, so from equal to to conserves the balance. The zero-address sentinel is rejected on every path, including transferFrom with a zero owner, where a zero value hits the sender check and a positive value hits the allowance check. Finite allowances decrement exactly and the max allowance is never touched. A revert in the balance step leaves the allowance unchanged.
• Periphery. There is no library, base contract or helper. The deploy script is a local rehearsal, reads no environment and is not the launch path. Runtime disassembly shows no CALL, STATICCALL, DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE and only the four expected storage writes.
• First principles. The supply constant evaluates at compile time to the stated 1e27 minor units. The unchecked arithmetic is bounded by the preceding comparison and the fixed supply. A conservation fuzz held with random seeds and with the verifier's seed.
• Launch floor. I read the protected test and every launch flow it drives, namely factory to distributor, distributor to claimant, factory to pool, and trader buy and sell, moves exactly the stated amount. No admin selector exists, so none can grow the supply or freeze a holder.
• Static analysis lead. The aderyn large-numeric-literal line is a style note on a compile-time constant and not a defect.

Verification run: forge build with no warnings, forge fmt check clean, 34 repository tests passing, and a 6-test scratch suite covering self-transferFrom, zero-owner transferFrom, owner transferFrom without allowance, allowance accounting near max, boundary amounts and a conservation fuzz. All passed, which is the expected outcome for a correct token, so none became a finding.

Not a defect, noted for the judge: transferFrom emits an Approval event on each finite spend, which is OpenZeppelin v4 behaviour rather than v5. Approve has the standard overwrite race, which the README already documents.

The review is complete and .imd-findings.json holds an empty findings list with ten coverage rows. The git tree shows no changes other than that file, which is gitignored or untracked as intended.

Outcome: no reproducible defect in the Economic Security, Invariant or Flow Gap areas.

The token in src/RobobetToken.sol is a self-contained fixed-supply ERC-20 with no owner, no mint or burn, no fee, no external call and no constructor arguments. I checked it against each failure mode in the three assigned guides and the Senior Auditor's Mindset, and traced every state-changing path with concrete values.

What I verified:

• Conservation. The only balance writers are the constructor and the private transfer routine, so the sum of balances equals the constant supply. A 256-run random-walk fuzz over four holders confirmed exact conservation, and the unchecked credit cannot overflow because the sum is bounded by 1e27.
• Entry points. All three listed entry points hold. Self-transfer keeps the balance, the zero-sender path reachable through transferFrom with a zero amount still reverts, allowance is spent exactly, and an infinite allowance stays bounded by the holder's balance.
• Launch flows. With no fee, tax or exemption list, the factory-to-distributor, distributor-to-claimant, pool seed and trader swap legs each move exactly the stated amount, and transfer returns true as Uniswap v4's currency library requires.
• Bytecode. The compiled runtime contains no CALL-family, DELEGATECALL, CALLCODE, SELFDESTRUCT or transient-storage opcodes. Only SLOAD and SSTORE appear.
• Static-analysis lead. The aderyn large-numeric-literal note on line 46 is cosmetic. The literal evaluates to exactly 1e27.

Two standard ERC-20 traits were noted but not reported as defects: the approve overwrite race, which the README documents, and the ability to emit a zero-value Transfer and Approval from any address via transferFrom. Both match OpenZeppelin behaviour and move no funds.

Nothing was left unreached. The scratch probe tests I ran under test/scratch/ all passed and were removed, so the submission changes no repository file.

The full suite passes with the verifier's seed and only the two new test files are untracked, both inside the allowed test/ path. The on-disk change to the invariants file was forge fmt reflowing it, which I ran myself.

Done. forge test passes: 65 tests across 6 suites, including 12 invariants, with the verifier's seed and with random seeds.

What I added (the existing three test files were left as they were):

• test/RobobetToken.invariants.t.sol. A handler drives the token from a deployer plus five holders and fuzzed stranger addresses, with ghost balances, a sent/received ledger and ghost allowances. Every handler either succeeds and asserts the exact postcondition, or pushes past a bound and asserts the exact custom error with no state change, so the suite runs with fail-on-revert. Invariants: supply fixed, balances over every touched address sum to the supply, balances and allowances match the ghosts, net-flow ledger holds, zero address and token hold nothing, the deployer cannot pull without an allowance, metadata fixed. A second contract targets the token's raw ABI with random callers and checks supply, a passive holder never losing, and the deployer never gaining from nowhere.
• test/RobobetToken.edges.t.sol. Edge units and fuzz: whole supply, one wei, supply+1 and max uint, zero address as caller, transferFrom from the zero address, the max-minus-one allowance boundary, infinite allowance over repeated spends, owner as its own spender, self-destined transferFrom, allowance larger than a shrinking balance, exact return data, and raw-input fuzz where every call must succeed exactly or revert with exactly one documented error.

Grounding. I ran the handler against a scratch fee-on-transfer mutant and it failed on the first taxed transfer, so the invariants are not vacuous. The handler coverage table showed every handler called over a thousand times with zero reverts.

Findings. No defect. .imd-findings.json holds one informational note: transferFrom emits an Approval event on every finite allowance spend, including a zero-value spend by an unapproved spender. That is OpenZeppelin v4 behaviour and allowed by EIP-20, and it is pinned by tests rather than hidden.

Review complete. The findings file is written and the scratch tests are removed, so the tree holds only .imd-findings.json.

Outcome: RobobetToken is a plain, argument-free, fixed-supply ERC-20 with no owner, mint, burn, fee or admin surface. I found no defect that opens a revision. The one specialist finding reproduces and is kept at informational severity.

What I verified

• Specialist finding (write_foundry_tests, info): _spendAllowance at src/RobobetToken.sol:138 emits Approval on every finite spend. A zero-value transferFrom from an unapproved spender succeeds and emits Approval(owner, spender, 0). I reproduced it with a scratch Foundry test using recorded logs. It is OpenZeppelin v4 behaviour, EIP-20 compliant, and changes no balance or allowance, so it stays info. The four other specialists reported nothing, so there were no duplicates to merge.
• Entry points: approve and transfer hold. transferFrom is marked as carrying finding 1 only for the event. Allowance checks, balance checks, exact revert errors, the infinite allowance, self-transfers and the unchecked arithmetic all behave as intended.
• Launch floor: the constructor mints exactly the manifest supply to msg.sender, decimals match, no privileged calls exist, the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT, and the code is far below the size limits. Ether sent to the token is refused.
• Manifest: launch.json matches the code and uses only schema keys. The README's claim that the tree contains no launch.json is stale documentation, noted in the coverage record rather than reported as a defect.
• Tools run: forge build, the full suite (65 tests plus invariants, all passing), forge fmt check, and my scratch reproduction. Slither and aderyn output from the verifier contained nothing above a cosmetic large-literal note.

Coverage record: all three listed entry points are answered, plus three invariant rows for the constructor and supply, the launch flows and bytecode, and the manifest.