The Robobet token project is complete and verified.

What was built

• src/RobobetToken.sol: contract RobobetToken, a fixed-supply OpenZeppelin 5.0.2 ERC-20. Name Robobet, symbol ROBOBET, 18 decimals. The constructor takes no arguments and mints 1,000,000,000 tokens once to msg.sender, the launch factory. There is no owner, mint, burn, pause, blacklist, tax or proxy, so every launch flow moves exactly what it says and no privileged hand can touch a holder.
• script/DeployRobobetToken.s.sol: a local deploy script whose deploy() function is tested directly. It reads no environment.
• foundry.toml: pins solc = "0.8.26", sets bytecode_hash = "none", optimizer on, ffi off, no filesystem permissions.
• lib/: forge-std 1.9.7 and the OpenZeppelin 5.0.2 token, utils and interfaces trees, vendored as ordinary files with no git submodule.
• README.md: assumptions, launch split, manifest values, deployment parameters, operational responsibilities and security notes.

Checks run

Check	Result
forge build (clean, solc 0.8.26)	passes
forge test with the verifier's fuzz seed, empty environment	26 passed, 0 failed
forge fmt --check	passes

The tests mirror the protected floor: supply and decimals, the swarm share arriving and being claimable whole, the 10/88/2 launch split conserving supply, exact transfers and allowances, reverts for insufficient balance, insufficient allowance and zero addresses, a sweep of admin selectors from a stranger and from the deployer, a bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and three fuzz tests.

Not done, and why

• I did not create a git commit, since the rules put .git/ off limits and the upload step collects the working tree.
• I did not write launch.json; the manifest step owns it. The README lists the values it needs.
• Slither and Mythril were not run because they are not provided on this machine. Only Foundry ran.

I found no defects in Robobet's access control, trust gaps or asymmetries, so .imd-findings.json has an empty findings list. It does have a coverage row for each of the three entry points, plus one for the token-wide invariant.

What I reviewed: src/RobobetToken.sol is a plain OpenZeppelin v5 ERC20 contract with only a constructor and a decimals() override, and I traced its checks into the vendored library code. I also read the deploy script, foundry.toml, the remappings and the protected test harness. The existing tests all pass (26 of 26).

• Access control: There is no owner or role system, and no external mint, burn, pause, blacklist, seize or upgrade function. _mint is called only once, in the constructor: exactly 1,000,000,000 × 10^18 to msg.sender, which is the factory. Nobody can change the supply or move or freeze a holder's balance after deployment.
• Trust gap: The constructor takes no arguments, so no launch address (factory, PoolManager or distributor) is trusted or exempted. Nothing can be set up wrongly or taken over by whoever calls first.
• Asymmetry: Transfers carry no fee and no exemption list, so the factory's payout to the distributor, the pool seed, the remainder and ordinary trades all treat every caller the same and move exactly the stated amount.

Coverage:

Entry point	Verdict	Why
approve(address,uint256)	holds	Changes only the caller's own allowance; a zero spender reverts.
transfer(address,uint256)	holds	Debits only the caller; reverts on too small a balance or a zero recipient.
transferFrom(address,address,uint256)	holds	Checks and reduces the allowance before moving tokens (an unlimited allowance is left as is); no path skips the allowance.

Leads I rejected:

• The approve front-running race is how every standard ERC20 works, not a defect in this code.
• Aderyn's "large numeric literal" at line 24 is just style.
• Slither reported nothing.

I did not write a proof test, since there were no critical or high findings.

I found no defects in the economics area, so .imd-findings.json has an empty findings list plus coverage rows. The file is valid JSON, and I changed nothing else in the tree.

What the code is: src/RobobetToken.sol is OpenZeppelin's standard ERC-20 (version 5.0.2), unmodified. It sets the name and symbol, returns 18 decimals, and mints the whole supply of 1,000,000,000 × 10^18 to the deployer once, in the constructor. The constructor takes no arguments and calls no other contract. There is no owner, mint, burn, pause, blacklist, transfer fee, exemption list or upgrade path.

Checked against the Economic Security, Invariant and Flow Gap guides:

• Supply: it can't grow or shrink, because the only mint is in the constructor. It matches the stated supply exactly and goes entirely to msg.sender, which is the factory.
• Launch flows: with no fee or burn on transfer, every transfer delivers exactly what it says. That covers the swarm's 10% going to the distributor, each claim paid out of it, the pool seed, and trades in both directions. I found no gap between what a flow says it moves and what arrives.
• Privileged powers: none exist, so nobody can move or freeze a holder's balance, and no admin call can create tokens.
• Allowances: transferFrom spends the allowance in the standard way: an unlimited allowance is never reduced, and too small an allowance reverts. The usual ERC-20 race when an owner changes a non-zero allowance is a property of the standard, not a defect here, so I didn't report it.
• Static analysis: slither reported nothing. Aderyn's "large numeric literal" note on line 24 is only a style remark about the supply constant.

Coverage: all three entry points (approve, transfer, transferFrom) are marked holds. I added two rows for invariants I checked: the supply stays fixed forever, and every launch flow moves exactly its amount.

Limits: the project's own 26 tests all pass. The two protected launch tests in .imd/reads/protected depend on harness files and environment variables that aren't in this tree, so I read them but couldn't run them. I compared their requirements against the source by hand. No manifest exists yet, so I couldn't review one.

Done. launch.json is written and is the only new or changed file in the tree.

What the manifest says

• Kind is custom_token with token contract RobobetToken, name Robobet, symbol ROBOBET, 18 decimals.
• Constructor arguments are an empty list, matching the no-argument constructor in src/RobobetToken.sol.
• Total supply is 1000000000000000000000000000 minor units, exactly what the constructor mints to msg.sender.
• Contracts is an empty list, since the accepted tree has no application contracts.
• Pool is IMD at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tick spacing 60, and the one-to-one initialPrice from the reference.
• Economics is copied verbatim from the job.
• Notes describe the token's fixed supply, lack of owner or privileged calls, and that pool.initialPrice is provenance only.

Checks

• The JSON parses with exactly the six schema keys, and the notes are well under the 4000 character limit.
• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 26 tests in both suites.
• git status shows only launch.json as untracked. No scratch files were left behind.

The review is complete. No defects found, and the findings file is written with full coverage.

Result: .imd-findings.json holds an empty findings list and nine coverage rows, one for each of the three listed entry points plus the constructor, the supply invariant, the vendored base contracts, metadata, the launch floor, and the deploy script. Every row is holds. The working tree is otherwise unchanged.

What I checked in my area:

• Execution Trace. Traced approve, transfer and transferFrom through OpenZeppelin's _approve, _spendAllowance, _transfer and _update. Scratch probes confirmed self-transfer conserves balance, zero-value transferFrom without allowance moves nothing, spender equal to owner still needs an allowance, max allowance is infinite while max minus one decrements, and transferFrom from the zero address is unreachable. The approve overwrite race exists as in every ERC-20 and the README already documents it, so I did not report it.
• Periphery. Diffed each vendored file the token depends on against upstream OpenZeppelin v5.0.2. All five are byte-identical. There are no libraries, assembly, external calls, receive or fallback.
• First Principles. The constructor mints exactly 1e27 once to the factory and nothing can reach _mint or _burn afterwards, so supply is fixed. Decimals, name and symbol come from constants and match the README's manifest values. The compiled ABI has only the three state-changing functions the verifier listed, and the runtime is free of DELEGATECALL, CALLCODE and SELFDESTRUCT.

Static-analysis leads. Slither reported nothing. Aderyn's large-numeric-literal line is style only, and the literal evaluates to the correct supply.

Checks run. forge build, the full test suite (26 passing), nine scratch probes (all passing, since removed), and forge fmt --check with no complaints.

The review is complete. The math audit of RobobetToken found no defects, and the findings file records that with a full coverage record.

What I checked, against the Math Precision, Boundary and Numerical Gap guides:

• The token's own arithmetic. The only arithmetic in src/RobobetToken.sol is the supply constant on line 24, which the aderyn large-literal lead pointed at. It evaluates in uint256 to exactly 1e27 and is minted once. Nothing in the contract divides, scales, downcasts or mixes decimals, so the guides' rounding, truncation and overflow-intermediate failure modes have nothing to attach to.
• The inherited OpenZeppelin math. The vendored library is plain files rather than a submodule, so I diffed the five files the token inherits against the upstream v5.0.2 tag. All are byte-identical. I then traced the unchecked subtractions and additions in _update and _spendAllowance and confirmed each is preceded by the guard that makes it safe.
• Boundaries. A scratch Foundry suite of 18 tests exercised max-uint and balance-plus-one transfers, self-transfer at full balance, allowance at max and max-minus-one, the zero-address sender and receiver paths that would reach mint or burn, zero-value calls, ether sent to the contract, and a fuzzed sum-of-balances conservation check over random transfer sequences. All passed, and the suite was removed afterwards so the tree is unchanged.
• Launch-side numerics. The 10/88/2 percent split of 1e27 divides with no dust, and the supply sits below the int128 and uint128 limits Uniswap v4 uses, so no pool balance can truncate.

Coverage record. All three entry points the verifier listed are marked holds, plus five invariant rows covering the supply constant, the launch split, the v4 bounds, the absence of any external-call or payable surface, and the vendored-library check.

One point for the judge rather than the author: the only non-standard behaviours are the ones the README already documents, namely the inherent ERC-20 approve race and the absence of any rescue path for tokens sent to the contract itself. Neither is a defect under the guides, so neither is reported.

Done. The suite passes in full, with and without the verifier's fuzz seed, and I found no defect to report, so there is no findings file.

What I added (two new files under test/, nothing else touched):

• test/RobobetToken.invariant.t.sol is the handler-driven invariant suite the acceptance criteria required and the existing work lacked. The handler deploys the token, so it plays the factory holding the supply, and drives four EOAs plus the token contract itself as a stuck-funds sink through nine actions: bounded and unbounded transfer and transferFrom, transfer to the zero address, approve, approve of the zero spender, sixteen admin-shaped selectors from strangers and the deployer, and ether sends. Every unbounded action asserts the exact revert selector and arguments, so the run uses fail-on-revert. Seven invariants hold over 256 runs of depth 64: fixed supply, every balance equals a ghost ledger of received minus sent and the tracked balances sum to the supply, the sink only grows, the zero address holds nothing, allowances match the ghost ledger, runtime code and ether balance never change, and every holder can still sweep its whole balance after any sequence. A unit test grounds the handler by driving each success and failure branch once.
• test/RobobetToken.edges.t.sol pins the inputs the earlier suite skipped: any deployer receives the supply, two deployments are independent with identical runtime, one wei and the full supply, the same transfer twice, zero transfer from an empty account, the zero address as sender, owner, spender and receiver, approvals overwriting rather than accumulating, exact and max-minus-one allowances, transferFrom emitting only one event, tokens sent to the contract being unrecoverable, and the standard ERC-20 approval race the README documents. Fuzz tests at 1000 runs cover split allowance spends, re-approval, transfer round trips, and arbitrary unknown selectors.

Result of the checks

Check	Outcome
forge build	clean
forge test with verifier seed	54 passed, 0 failed
forge test without seed	54 passed, 0 failed
invariant handler calls	16,384 with 0 unexpected reverts

Assessment of the implementation. The token is a plain OpenZeppelin 5.0.2 ERC-20 with no owner, mint, burn, pause, or tax, and no DELEGATECALL, CALLCODE, or SELFDESTRUCT in its runtime. Against the protected floor tests it mints exactly the manifest supply to the factory, moves every launch flow whole, and exposes no privileged call. I did not find a defect, so .imd-findings.json was not written. The new files are left uncommitted in the working tree, since committing was not asked for.

The review is complete. The Robobet token has no defects, and .imd-findings.json holds an empty findings list with a coverage record answering all three entry points plus five invariant rows.

What I verified

• The specialists' reports all came back empty across flow, permissions, math and economics, and the independent tester found nothing. There was nothing to reproduce or merge, so I re-audited the code from scratch.
• The contract in src/RobobetToken.sol is a 42-line fixed-supply OpenZeppelin ERC-20. Its no-argument constructor mints exactly one billion tokens with 18 decimals to the deployer. It adds no mint, burn, owner, pause, blacklist, hook or fallback.
• The vendored library is genuine. I read the vendored ERC20 and Context sources in full and they match the upstream 5.0.2 text, including an untouched _msgSender.
• The bytecode passes the floor. The runtime is 2,181 bytes and contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. The creation code is well under the 49,152-byte limit and needs no address bits, so the factory's CREATE2 deployment works at any salt.
• The launch flows are exact. A scratch harness deployed the token by CREATE2 from a factory stand-in, moved the ten percent swarm share, the eighty-eight percent pool share and the two percent remainder, and confirmed each arrived whole with the supply unchanged. Claims and allowance-based pulls behaved the same way. The project's own 54 tests, including fuzz and invariant suites, also pass.
• The manifest uses only schema keys, states the supply the constructor actually mints, matches the token's decimals, and has lowercase addresses with the correct field types.
• The static-analysis lead from aderyn about a large numeric literal is a style note. The expression evaluates to exactly the manifest supply.

One non-defect worth noting: the README still says the repository does not contain a launch.json, but a valid one is now present. That is stale documentation rather than a code or manifest fault, so I did not file it as a finding.

The scratch test was removed and no tracked files were changed.