I built the ConditionalsImd (COND) token as a Foundry project at the repository root. forge build, forge test (35 tests, using the verifier's fuzz seed, after a clean rebuild) and forge fmt --check all pass with solc 0.8.26.

The token (src/ConditionalsImd.sol, contract ConditionalsImd)

• It's a standard ERC-20 built on OpenZeppelin v5.1.0. Name ConditionalsImd, symbol COND, 18 decimals.
• The constructor takes no arguments and mints all 1,000,000,000 COND once to the deployer, which at launch is the IMD factory.
• Nothing can create more tokens later, and there is no owner, admin, pause, blacklist, burn, upgrade path or fee on transfer. Every transfer moves exactly the amount it names, so the 10% / 70% / 20% launch split (swarm, pool, requester) arrives whole.
• The deployed code contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, and no unlinked libraries.

Tests

• test/ConditionalsImd.t.sol (34 tests):
  • Success: name, symbol, decimals and supply; the mint to the deployer, including when a contract deploys the token the way the factory does; the exact launch split and a distributor claim; transfers, approvals and transferFrom.
  • Failure: sending more than a balance or allowance, sending to the zero address, approving the zero address, the deployer trying to pull a holder's tokens, and sending ETH to the token.
  • No admin powers: none of 16 common admin calls works.
  • Fuzz: total supply stays the same, allowances are spent exactly, and any three-way split of the supply arrives exactly.
• test/ConditionalsImd.invariant.t.sol: across random transfers and approvals, the supply never changes and holders' balances always add up to it.

Other files

• foundry.toml pins solc 0.8.26 and bytecode_hash = "none". It doesn't enable ffi or filesystem access.
• forge-std v1.9.7 and OpenZeppelin v5.1.0 are copied into lib/ as ordinary files, not submodules. I downloaded release archives because git clone was blocked from writing inside the clones' .git folders.
• README.md documents the token, the deployment values for the manifest step (but there is no launch.json), the payout split, the assumptions, who is responsible for what after launch, and known ERC-20 caveats. The "After launch" section says there is nothing to set.

Not done

• Slither and Mythril weren't available here, so they weren't run.
• I couldn't run the two provided protected tests locally. They depend on Uniswap v4 code and launch files the verifier supplies, which aren't in this repository.

The work is committed as 5068a36 on a new branch, cond-token. HEAD points to it; main still holds only the "Empty workspace" commit.

I found nothing to report in the permissions review of ConditionalsImd (COND): no Access Control, Trust Gap or Asymmetry defect I could reproduce. I wrote .imd-findings.json with an empty findings list and one coverage row for each of the three entry points, all marked holds, plus three rows for invariants I checked. No other files were changed, and the existing test suite passes (35 tests, 0 failing).

What I checked

• The token: src/ConditionalsImd.sol is a plain OpenZeppelin v5.1.0 ERC20. Its constructor makes one call, _mint(msg.sender, TOTAL_SUPPLY) with 1,000,000,000 × 10¹⁸. It doesn't override _update, _approve or _spendAllowance, has no owner, admin role, pause, blacklist, fee or exemption list, and never exposes _mint or _burn after deployment.
• The library code it inherits: I read transfer, approve, transferFrom, _transfer, _update, _approve and _spendAllowance in the vendored copy of OpenZeppelin, and they look like the standard 5.1 code. lib/ isn't under git here, so I couldn't diff it against upstream; that rests on reading the code.
• Access Control: the contract's interface has only three functions that change state. Each one acts only on the caller's own balance or allowance, and transferFrom checks and spends the allowance before moving anything. After deployment the factory has no extra power beyond the tokens it holds.
• Trust Gap and Asymmetry: every transfer goes through the same _update, with no special case for any sender or recipient. The factory, the distributor, the pool manager and ordinary holders are treated the same, buys and sells behave the same, and every transfer moves exactly the amount it names.
• Static analysis: aderyn's one note (a large number written out at line 18) is just how the supply constant is spelled and isn't a defect. Slither reported nothing.

What I left out

• The approve front-running race: a spender can use an old allowance before a new one replaces it. That's how the ERC-20 standard itself works, not a defect in this code, and it can't be shown failing on this token specifically.
• Unlimited allowances: OpenZeppelin deliberately doesn't reduce an allowance of the maximum value when it's spent.

What I couldn't reach

• The supplied protected tests (Token.protected.t.sol, Owners.protected.t.sol) import pool and factory code that isn't in this tree, so I read what they check but couldn't run them.
• I didn't do the math, economics or control-flow passes in depth. They belong to the other three reviewers, and with no custom logic in the token there is little for them to cover.

I found no defects in the economics area for ConditionalsImd (COND). .imd-findings.json has an empty findings list and a coverage record of 6 rows: all three entry points listed, plus three for invariants and economics. Every row says holds. I changed no repository files, and the scratch test I used was deleted afterwards.

The token. src/ConditionalsImd.sol is the unmodified OpenZeppelin v5.1.0 ERC20 (the vendored copy is unchanged). The only mint is in the constructor: 1_000_000_000 * 10 ** 18 to msg.sender. It has no constructor arguments, no owner, no fee, burn or transfer hook, no external calls, and no receive or fallback.

How I covered the three guides:

• Economic Security: the token depends on no other contract and no price oracle, so there is no outside failure that could block anything. There is no fee-on-transfer, rebasing or pause behaviour. Transfers and approvals to address(0) revert rather than silently succeeding, and no fee formula exists to push to zero or to its maximum. The approve front-running race (an approved spender can spend the old allowance before a change lands) is part of the ERC-20 standard itself, so I noted it in the approve row rather than reporting it as a defect.
• Invariant: the sum of balances always equals the total supply of 1e27. Only the constructor creates tokens and nothing destroys them. Allowances go down by exactly the amount spent, except the maximum value, which never decreases. A short balance or allowance reverts before any state changes.
• Flow Gap: each leg of the launch moves exactly the amount it names: factory → distributor (10%), distributor → claimants, factory → PoolManager seed (70%), swaps in both directions, and the remainder (20%) to remainderTo. Nothing in the token can make a leg arrive short.

Checks run:

• The project's existing suite: 35 tests, all passing.
• My own fuzz test of transfer, transferFrom and self-transfer: 5,000 runs, all passing. It confirmed balances move by exactly the stated amount, allowances behave correctly, and the conservation and fixed-supply invariants hold.
• A unit test confirming that overspending and zero-address calls revert.

Not checked: I couldn't run the protected floor tests, because they need the IMD harness files and environment settings that aren't in this tree. I also couldn't verify the IMD pair-token address on chain 1, since no network.json was provided. The aderyn note about a large numeric literal at line 18 is just the supply constant and isn't a defect.

launch.json is written and verified. It is the only new file, and nothing else in the tree changed.

What the manifest says

• Kind is custom_token, with the token contract ConditionalsImd, name ConditionalsImd, symbol COND, 18 decimals.
• Constructor arguments are empty, matching the accepted source, whose constructor takes nothing and mints once to msg.sender.
• totalSupply is 1000000000000000000000000000, which equals the contract's TOTAL_SUPPLY constant.
• contracts is an empty list, since the accepted tree has no application contracts.
• pool is the launch's own: IMD as paired currency, fee 12500, tick spacing 60, the one-to-one initialPrice as provenance.
• economics is the requester's object copied verbatim.
• notes describe only the one contract present, at 1,226 characters.

Checks run

• A schema check confirmed only the allowed keys, correct types, lowercase addresses, and byte-for-byte equality of economics with the job's text.
• forge build compiled cleanly, and the ABI shows a parameterless constructor.
• forge test with the verifier's fuzz seed passed all 35 tests across both suites.

The review is complete with no defects found. The findings file holds an empty list and a seven-row coverage record, and the working tree is unchanged.

What was reviewed. The token at src/ConditionalsImd.sol is a 23-line wrapper over OpenZeppelin ERC20 with a single constructor mint and three constants. I ran the three assigned passes against it.

• Execution Trace. Traced approve, transfer and transferFrom from entry to storage. There are no external calls, callbacks, sentinels with special paths, or partial-update windows. The allowance spend runs before the balance check and a later revert unwinds it atomically. A scratch test confirmed self-transferFrom, to-equals-from, overwrite-on-reapprove and unknown-selector behaviour, then was removed.
• Periphery. The five vendored OpenZeppelin files the token compiles against are byte-identical to upstream v5.1.0, checked by hashing and diffing against the tagged GitHub sources. Context returns plain msg.sender.
• First Principles. The constructor mints exactly 1e27 to msg.sender once, which is the factory under CREATE2. Name, symbol, decimals and supply match the brief. The ABI has no hidden entry points, no receive or fallback, no immutables and no link references.

Leads checked and dismissed. The aderyn large-literal line is exactly 1e27 and harmless. Slither reported nothing. The ERC-20 allowance race is inherent to the interface and documented in the README, so it is recorded in the approve coverage row rather than as a finding.

Verification. The project's own 35 tests and the invariant suite pass. All three listed entry points have a holds row with a one-line reason, plus rows for the constructor, the vendored base, the compiled surface and the launch-flow invariant.

The review is complete. The math audit of ConditionalsImd found no defects, and the findings file holds an empty list with eight coverage rows.

What I checked

• Source: the token is 23 lines, a plain OpenZeppelin v5.1.0 ERC20 with a constructor mint of the constant supply. The ABI exposes only approve, transfer and transferFrom as state-changing entry points. No external calls, payable paths, receive or fallback, bytes decoding, or link placeholders exist.
• Dependency integrity: the vendored OpenZeppelin files are copied as plain files, so I fetched the upstream v5.1.0 tag and compared. All five relevant files are byte-identical. The arithmetic under review is unmodified upstream code.
• Math Precision: the supply constant is a compile-time checked product equal to 1e27, far below the uint256 limit. The only divisions in the system are the launch split legs, and 10%, 70% and 20% of 1e27 are exact with no dust. The unchecked additions in _update and _spendAllowance are guarded by the preceding checked comparisons, and the balance addition cannot wrap because nothing mints after construction.
• Boundary: I wrote and ran nine probes covering self-transferFrom with a finite allowance, zero-value transferFrom with zero allowance, transferFrom with the zero address as sender, infinite allowance against an insufficient balance, allowance of max minus one, max-uint transfer from an empty account, a fuzzed transfer chain, and ETH or unknown-selector calls. All passed as the spec requires.
• Numerical Gap: the conservation invariant and the fixed-supply invariant hold on every path since only _update touches balances or supply. The project's own invariant suite also passes under its fail-on-revert profile.

Static analysis leads: Slither reported nothing. Aderyn's large-numeric-literal line is a style note on an exact, tested value and is not a defect.

Tree state: my scratch test directory was removed after running, and the working tree is clean apart from the findings file. No repository file was modified.

Added failure-path tests, fuzz properties, and stateful balance/allowance invariants. Only test/ files changed.

Validation passed: forge build and full forge test with the required seed—58 tests, zero failures or skips. The new invariant campaign completed 32,768 calls.

No contract defects found.

The review is complete and .imd-findings.json is written. The token has no defects. No tracked file was changed.

What the specialists reported. All four areas and the independent tester reported no findings, so there was nothing to reproduce or merge. I treated their clean coverage as leads and traced every entry point myself.

What I verified

• The token is a 23-line wrapper over OpenZeppelin v5.1.0 ERC20 with one constructor mint to msg.sender and no overrides. The compiled ABI has only approve, transfer and transferFrom as state-changing functions, plus views and three constants. No receive, fallback, mint, burn, owner, pause or upgrade path exists.
• All five vendored OpenZeppelin files hash identically to the upstream v5.1.0 release, so the inherited transfer, allowance and failure paths are the audited ones.
• The constructor takes no arguments, calls nothing external, and the creation and runtime code are far below the CREATE2 size limits. The existing CREATE2 deployer test and runtime opcode scan pass.
• The manifest is schema-valid and agrees with the code on contract name, decimals, empty constructor arguments, total supply and economics.
• The full test suite builds and passes: 58 tests across four suites, including fuzz and invariant campaigns.

Findings written

1. Info only. The README at line 38 says the repository ships no launch.json, while one is present and consistent with the README's own table. A stale sentence, not a code or manifest defect, so it carries no proof.

Coverage record. All three entry points are marked holds with the traced checks and failure paths, plus five invariant rows covering fixed supply, exact launch flows, forbidden opcodes and deployability, dependency integrity, and manifest consistency.

Limit. The protected launch harness depends on Uniswap v4 core and launch libraries that are not in this tree, so its seed-and-swap path was traced by reading rather than executed.