Implemented Conditionals (COND): 1 billion tokens with 18 decimals, minted once to the deployer. No admin or additional minting powers.

Includes offline dependencies, success/failure tests, fuzz and invariant coverage, and deployment documentation.

Verified successfully:

• forge build
• forge test with the supplied seed
• forge fmt --check

I wrote launch.json for the Conditionals (COND) launch and committed it. It is the only file changed. forge build and forge test with the given fuzz seed both pass (34 of 34 tests). I couldn't run the two protected tests here because the files they import (src/LaunchLiquidity.sol and others) aren't in this tree, so they only run on the verifier.

What the manifest says:

• Token: contract Conditionals, name "Conditionals", symbol "COND", 18 decimals. constructorArgs is empty because the constructor takes no arguments. totalSupply is "1000000000000000000000000000": the 1,000,000,000 × 10^18 the constructor mints once to msg.sender.
• Contracts: none. The accepted tree only contains src/Conditionals.sol.
• Pool: paired with IMD (0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7), fee 12500, tick spacing 60, initial price 79228162514264337593543950336 (one to one).
• Economics: copied exactly from the job.
• Notes: a short description of the token: no owner, no mint or burn after launch, no fees, pause, blacklist or upgrades, and no application contracts.

The review is complete and the findings file is written with no defects and full coverage.

Outcome. The Conditionals token has no math, boundary, or numerical-gap defects. The file .imd-findings.json holds an empty findings list and eight coverage rows, one for each of the three state-changing entry points plus five invariants and boundaries I checked.

What the code is. The token is a fixed-supply ERC-20 that inherits OpenZeppelin v5.0.2 unchanged and adds only a constant and a constructor mint. It has no division, fee, scaling, cast, external call, payable path, or bytes decoding, so most failure modes in the three guides have nothing to attach to.

What I verified.

• All five vendored OpenZeppelin files hash identically to the upstream v5.0.2 sources fetched from GitHub, so the arithmetic under review is the audited upstream code.
• The supply constant compiles to exactly 10^27, which divides into one billion whole tokens with no remainder. The aderyn "large numeric literal" lead is style only.
• Transfer and transferFrom check balance and allowance before each unchecked subtraction, so max-uint amounts and supply-plus-one revert cleanly. Allowance at max minus one decrements, at max it does not, and a balance revert leaves the allowance untouched.
• Zero-amount and self-transfer fast paths leave balances and allowances exact, so no invariant is skipped at the edge.
• The launch's ten, eighty and ten percent split of 10^27 in basis points is exact with no truncation residue.
• The project's own 34 tests pass, including the stateful invariant suite, and my eleven scratch probes passed before I removed them.

Not covered. Nothing in my area was left unreached. Uniswap v4 seeding and swap arithmetic belong to the deployer and the protected integration suite, not to this token's code, and I did not model them beyond confirming the supply fits comfortably in the pool manager's signed 128-bit deltas.

The review is complete and the result is written to .imd-findings.json with an empty findings list and eight coverage rows. The working tree is otherwise untouched.

Outcome: no defects found in the control-flow area. The token is a 17-line contract that inherits OpenZeppelin ERC20 v5.0.2 and mints the full supply once to msg.sender in its constructor. There is no override of transfer logic, no owner, and no external call anywhere.

What I verified, by guide:

• Execution Trace. Traced approve, transfer and transferFrom through OpenZeppelin's internal functions. Allowance is spent before the balance moves, so any revert rolls back both. The infinite-allowance sentinel skips only the decrement, not the balance check. The constructor is non-payable and makes no calls, so a factory CREATE2 deployment lands the whole supply on the factory.
• Periphery. The five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag, so the base contract the token trusts is the audited one.
• First Principles. The only implicit assumption is that the deployer is the intended recipient, which the launch design makes true. The token's name suggests transfer conditions, but the brief asks for none and the README states that plainly.

Checks I ran:

• The project's own 34 tests, including fuzz and stateful invariants, all pass.
• A scratch test mirroring the protected floor: launch flows arrive whole, 22 privileged selectors revert from both a stranger and the factory, the factory cannot move a holder's balance, and a reachable-opcode scan finds no DELEGATECALL, CALLCODE, SELFDESTRUCT or even CALL.
• Formatting check passes.

The one static-analysis lead, the large numeric literal, is cosmetic. The constant equals exactly 10^27 and the project's test asserts that. I recorded it as a coverage row rather than a finding. All three listed entry points are marked holds, and nothing in my area was left unreached.

The findings file is in place and excluded from git by the repository's own exclude rules, and the working tree holds no other change.

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

What the code is. The only production contract is a bare OpenZeppelin v5.0.2 ERC20 whose constructor mints the full supply to msg.sender once. There is no owner, fee, burn, mint, pause, blacklist, callback, external call, receive or fallback. The compiled ABI exposes exactly the three state-changing entry points the verifier listed plus standard views.

What I checked, per guide:

• Economic Security. No external dependencies or oracles to break. No fee-on-transfer, rebase or blacklist behaviour, so every launch flow moves exactly what it says. A scratch test reproduced the 10/80/10 split and a PoolManager-style approve plus transferFrom pull, all arriving whole. ERC-20 compliance matches EIP-20, with the revert-on-zero-address choices documented in the README.
• Invariant. Sum of balances equals total supply equals 1e27 forever. The single mint is at line 15 of the token file and nothing else writes supply. Boundaries tested: zero amount, full supply, supply plus one, max uint, self-transfer, over-allowance rollback and unlimited allowance.
• Flow Gap. No periphery calls exist inside the token, so no execution-times-periphery seam. The token's stated purpose, a plain fixed-supply token despite the name, is what the code does. A runtime opcode scan found no DELEGATECALL, CALLCODE or SELFDESTRUCT on reachable paths.
• Dependency integrity. All six vendored OpenZeppelin files hash identical to upstream v5.0.2 raw sources.

Test runs. The project's own 34 tests pass with the README seed. My scratch suite of four tests, including a 1024-run conservation fuzz, passed and was then deleted.

Observation, not a defect. The standard ERC-20 allowance replacement race applies, as it does to every OpenZeppelin v5 token. The README already tells clients to revoke before re-approving.

Not reached. Nothing within the token. The Uniswap v4 seed and swap path itself runs only in the protected launch environment, which this workspace cannot execute. The token's transfers are standard, so that path has no token-side reason to fail.

Added failure-path, boundary, and fuzz tests; strengthened balance and allowance invariants. All changes are under test/.

• Offline build passed.
• Supplied-seed test run: 51 passed.
• Invariants: 32,768 randomized calls, no unexpected reverts.
• Formatting checks passed.

No implementation defects found.

The review is complete. .imd-findings.json holds zero findings and a full coverage record. No specialist reported a finding, so there was nothing to reproduce or merge, and my own pass found no defect.

What I verified against the code

• Token source is a 17-line wrapper over OpenZeppelin ERC20 with a no-argument constructor that mints the constant supply once to msg.sender. Build artifacts show exactly three state-changing functions: approve, transfer, transferFrom. No receive, fallback, owner, mint, burn, pause or blacklist path exists.
• Vendored library is genuine. I downloaded the upstream v5.0.2 archive, which matched the SHA-256 recorded in lib/DEPENDENCIES.md, and all five vendored Solidity files match upstream byte-for-byte.
• Launch floor behaviour was reproduced in a scratch Foundry test. A CREATE2 factory probe deployed the token and held the whole supply of 1e27, decimals read 18, the factory-to-distributor-to-claimant flow arrived whole, finite allowances decremented and the unlimited allowance did not, over-allowance spends reverted, and unknown admin selectors reverted.
• Bytecode is well under limits and a reachable-opcode scan matching the protected test's algorithm found no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Manifest uses only schema keys, an empty constructorArgs list that matches the constructor, a totalSupply equal to what the constructor mints, lowercase addresses and a 12-character contract name.
• Static-analysis lead from aderyn about a large numeric literal is a compile-time constant that evaluates to exactly 1e27, confirmed by the supply assertion.

The project's own 51 tests pass with the documented fuzz seed. The scratch test and the downloaded archive were removed, so the working tree contains only the findings file.