The Claus token is complete, committed on main, and verified from a fresh clone of the commit.

What was delivered

• src/ClausToken.sol: contract identifier ClausToken, name "Claus", symbol "CLAUS", 18 decimals. The constructor takes no arguments and mints the full 1,000,000,000 × 10^18 supply once to the deployer. It is OpenZeppelin 5.4.0 ERC20 with nothing else: no owner, mint, burn, pause, blocklist, fee or external call.
• script/DeployClausToken.s.sol: a deploy function with constants that the tests call directly, plus a broadcast wrapper. No environment variables are read in the deploy path.
• Tests in test/: 32 tests across unit, fuzz and invariant suites. They cover metadata, the one-time mint event, launch flows arriving whole, transfer and allowance success paths, revert paths with typed errors, rejection of every common admin or freeze selector from both a stranger and the deployer, no delegatecall or selfdestruct in the runtime, and supply conservation under 128,000 random handler calls.
• README.md: assumptions, manifest values, deployment parameters, after-launch section, operational responsibilities and the security checklist pass.
• Vendored dependencies as plain files under lib/: forge-std 1.17.0 sources and the five OpenZeppelin files the ERC20 needs. No git submodules.

Checks run

Check	Result
forge build with solc 0.8.26	pass
forge test with an empty environment	32 passed, 0 failed
forge fmt --check	pass
Fresh clone of the commit, same three checks	pass

foundry.toml sets bytecode_hash = "none" and disables CBOR metadata, so the creation bytecode carries no metadata trailer. No launch.json was written. Slither and Mythril were not run, and the README says so.

Open items for the requester

None required for the launch. If burns or any admin power are wanted later, that would be a new contract rather than a change to this one.

Done. launch.json is written and verified, and it is the only change in the working tree.

What the manifest says

• Token: contract ClausToken, name Claus, symbol CLAUS, 18 decimals, empty constructorArgs, totalSupply 1000000000000000000000000000. That matches the compiled ABI, which has no constructor inputs, and the single mint to msg.sender in the constructor.
• Contracts: an empty list. The accepted tree holds only the token in src. The deploy script is a manual-deployment helper, not a launch contract.
• Pool and economics are copied exactly from the launch terms: IMD pair at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object verbatim.
• Notes describe only ClausToken and its behaviour, at 1180 characters.

Checks run

• A script asserted the schema keys, string types for uint256 and address fields, lowercase addresses, the contract-name constraint, the supply value and the verbatim economics.
• forge build compiled cleanly and forge test passed all 32 tests in 3 suites.
• git status shows launch.json as the sole untracked file. No configuration, lib or workflow file was touched.

The review is finished and the working tree is clean apart from the required findings file.

Outcome: no defects found in the Claus token. The findings file at the repository root holds an empty findings list and seven coverage rows, one for each of the three listed entry points plus four invariant and periphery rows.

What I checked in my area (Execution Trace, Periphery, First Principles):

• Traced approve, transfer and transferFrom through the vendored OpenZeppelin ERC20 to every guard, state write and revert path. Zero addresses revert, insufficient balance or allowance reverts before any write, infinite allowance is not decremented, and a failed balance check does not spend allowance.
• Verified the five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tag by hash, so the base contract the token trusts is the audited one.
• Confirmed the compiled ABI exposes exactly three state-changing functions with no mint, burn, owner, pause, receive or fallback entry.
• Deployed the creation code via CREATE2 from an etched factory address in a scratch test, confirmed the whole 1e27 supply lands on that address, and walked the 10/88/2 launch flows plus an approve and transferFrom round trip. All amounts arrived whole and supply stayed fixed. The scratch test was removed afterwards.
• Checked the static-analysis lead about the large numeric literal. The constant evaluates to exactly one billion times ten to the eighteenth, so it is not a defect.
• Ran the full repository suite: 32 tests pass, including the invariant suite at 128,000 calls.

Not covered: the verifier's protected floor test imports Uniswap v4 sources that are not in this tree, so I did not run it directly. The token has no fee, hook or exemption logic, and the equivalent flows passed in the scratch test, so I expect it to pass.

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

Result: .imd-findings.json holds an empty findings list and eight coverage rows, one for each of the three ABI entry points plus five invariants and boundaries I checked. The working tree is otherwise unchanged. The scratch test directory was removed after use.

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

• Math. The only arithmetic the token adds is the supply constant at src/ClausToken.sol:21. It evaluates to 1e27 at compile time with checked arithmetic, uses a widening cast only, and is the single value ever minted. The aderyn large-literal lead resolves to this constant and is not a defect. All other arithmetic is OpenZeppelin's _update, whose unchecked blocks are bounded by the prior balance check and by a supply far below the type limit.
• Boundary. The token makes no external calls, has no payable, receive or fallback function, decodes no bytes, and its only sentinel branches are the zero-address reverts. I traced both sides of each. Scratch tests confirmed 1 wei, zero, exact-supply, supply-plus-one and max-uint inputs, self-transfer through transferFrom, max and max-minus-one allowances, and that sending value to any selector reverts.
• Numerical gap. There is no division, fee, rounding or scale conversion, so no seam between precision, invariant and boundary exists. Fuzzed transfer chains kept the balance sum exactly equal to total supply.
• Dependency integrity. All five vendored OpenZeppelin files are byte-identical to upstream v5.4.0, so the inherited behaviour is the audited library's.

Tooling that ran: the project's own suite of 32 tests including the invariant suite, plus 13 scratch tests. The one scratch failure was a wrong expectation on my side about which custom error fires for a zero-value transferFrom from the zero address. The call reverts in every case.

Outside the area, nothing severe surfaced. The token has no privileged functions, no exemptions and no transfer-time logic, so the launch flows, pool seed and swaps move exact amounts as the protected test requires.

The review is complete. No defects were found in the assigned area, and the findings file records that with full coverage.

Outcome. .imd-findings.json holds an empty findings list and seven coverage rows, one for each of the three listed entry points plus the constructor and three invariants, all marked holds. No repository file was changed. The scratch test I used was removed and the working tree is clean apart from the findings file.

What was checked, per guide:

• Access Control. The permission map is empty. The contract has no modifiers, roles, inline sender checks, initializer, owner, mint, burn, pause or upgrade path. The compiled ABI exposes only the standard ERC-20 functions plus two view constants. There is no fallback or receive, and the deployer, once tokens leave it, cannot pull from any holder without allowance. I confirmed that with a test that got the expected insufficient-allowance revert.
• Trust Gap. The one place a backdoor could hide in a "plain" token is the vendored library. The five OpenZeppelin files hash identically to the upstream v5.4.0 tag, and _msgSender is plain msg.sender. No actor class is treated differently from any other, so no seam between access, economics and asymmetry exists.
• Asymmetry. The approve/transferFrom pair and the transfer/transferFrom pair share the same zero-address and balance guards, the only storage writers are the inherited ones, and the infinite-allowance boundary behaves as documented at both max and max - 1. The runtime bytecode scan found no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Static-analysis leads. Slither reported nothing. The aderyn large-numeric-literal note on TOTAL_SUPPLY is cosmetic; the constant evaluates to exactly 10^27 and matches the manifest supply.

Not a finding, but worth the author knowing. The standard ERC-20 approve front-running race exists here as it does in every OpenZeppelin ERC20. The README already states standard semantics, so I did not report it as a defect.

The review is complete. The findings file is written and the working tree is otherwise unchanged.

Result: no defects found. The economics, invariant and flow-gap review of src/ClausToken.sol turned up nothing to fix. .imd-findings.json holds an empty findings list and nine coverage rows, all holds.

What was checked

• The token is OpenZeppelin 5.4.0 ERC20 plus a one-time constructor mint and a decimals() override. I diffed all five vendored OpenZeppelin files against upstream v5.4.0 and they are byte-identical.
• Supply conservation: _mint runs once in the constructor, _burn is never called, and _transfer rejects the zero address on both sides. No post-deployment path can change the total of 1e27 or let the sum of balances diverge from it.
• Launch flows: there is no fee, tax, reflection or exemption logic, so the swarm's share, each claim, the pool seed and both swap directions move exactly the amount requested. Nothing in the token treats the factory, PoolManager or distributor differently from any holder.
• Economic surface: no external dependency, oracle, price or fee formula exists to manipulate. Zero-address sentinel paths revert with ERC-6093 errors. Zero-value transfers succeed and emit as ERC-20 requires.
• The aderyn "large numeric literal" lead is correct arithmetic and tested, so it is not a defect.
• The existing suite passed, including the invariant suite at 128,000 calls. A scratch test I wrote for whole-supply hops, exact allowance spending, self-pull without allowance, zero-value transfers from empty accounts and unknown selectors also passed, and I removed it afterwards.

One observation, not a finding. The standard ERC-20 approve front-running property applies, as it does to every plain OpenZeppelin token. It is inherent to the requested design and noted in the coverage record rather than reported as a defect.

The findings file is in place and excluded by the repository's own exclude list, as intended. The work is complete.

Outcome. forge test passes with 79 tests across 5 suites, up from 32. I found no defect in the token, so .imd-findings.json reports an empty findings list. The vendored OpenZeppelin files are byte-identical to upstream v5.4.0, and the token adds only a name, symbol, decimals override and a one-time mint on top of them.

What I added, both under test/:

• ClausToken.edges.t.sol holds 46 adversarial unit and fuzz tests that the existing suite did not cover. It deploys through CREATE2 from a factory contract the way the launch does, and checks the predicted address and that trailing constructor data changes nothing. It pins balance boundaries (exactly the supply, one wei over, max uint), the zero address on every side of transfer, approve and transferFrom, an owner spending from itself with and without self-approval, the max-minus-one allowance boundary, allowance survival across plain transfers, event counts on transferFrom, inert contract and self-address recipients, unknown selectors from fuzzed callers, truncated calldata, ether on every entry point, and the exact number of storage writes each call may make with no outgoing calls. Fuzz properties cover round trips, split-then-merge, self-transfer identity, fan-out conservation, and reverts beyond allowance or balance.
• ClausToken.ledger.invariant.t.sol is a second invariant suite that runs with fail-on-revert. The handler keeps a ghost ledger of every accepted transfer and allowance, grows the holder set with fuzzed strangers up to a cap, and includes the token's own address as a holder. Five handler paths exercise failure cases and assert the revert plus unchanged state inside the handler. Nine invariants check the fixed supply, that tracked holders sum to the supply, balances equal received minus sent, allowances equal granted minus spent, strangers hold no allowance, the zero address holds nothing, no ether is held, and the code hash and metadata never change. Run counts are set with inline config so foundry.toml is untouched.

Grounding. A scratch mutant that skims one wei per transfer failed the ledger invariant on the first drifted balance, so the harness is live rather than vacuous. The scratch directory has been removed.

One behaviour worth knowing, not a defect. The token accepts itself as a transfer recipient, and with no admin or rescue function those tokens stay there permanently. That is standard ERC-20 behaviour and consistent with the stated design of having no privileged powers, so it is documented in a test rather than reported.

The review is complete. No defects were found, and .imd-findings.json holds an empty findings list with a full coverage record.

What I checked

• The token is OpenZeppelin v5.4.0 ERC20 with only a name, symbol, 18 decimals and a one-time mint of the manifest supply to the deployer. There is no owner, minter, pause, blocklist, fee, burn or hook.
• All three listed entry points are unmodified library code. I traced the zero-address, balance and allowance revert paths for each and marked them as holding.
• Deployability holds under the factory's CREATE2 model. The constructor takes no arguments, matching the empty constructorArgs in launch.json, and the manifest supply and decimals match the contract.
• The runtime bytecode contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, and both runtime and creation sizes are far below the protocol limits.
• Dependencies are committed as ordinary files with no git submodules, so an offline build succeeds.
• The build passed and all 79 existing tests passed, including the fuzz and invariant suites.

Specialist and tool input

All four specialists and the independent tester reported nothing, so there was nothing to reproduce or merge. Slither reported nothing. The single aderyn note is the compile-time supply constant on line 21, which evaluates exactly to the manifest supply and is not a defect.

What I could not run

The protected token test imports Uniswap v4 core and launch helper sources that are not in this tree, so it cannot execute here. Its individual assertions, supply to factory, decimals, whole-amount transfers, no supply growth, no privileged balance moves, and the opcode scan, were each verified by hand against the code and the existing tests.

No files other than .imd-findings.json were created or changed.