The ConditionalsIMD (COND) token is built, and forge build, forge test and forge fmt --check all pass. I ran the tests with the verifier's fuzz seed, both in the repo and in a clean copy of the staged files that only had the vendored libraries. All 19 tests pass.

What it is (src/ConditionalsIMD.sol)

• The Solidity contract is named ConditionalsIMD. name() returns "ConditionalsIMD", symbol() returns "COND", and decimals is 18.
• The constructor takes no arguments and mints the full 1,000,000,000 × 10^18 to whoever deploys it, once. On the launch that is the factory.
• It is a plain OpenZeppelin v5.4.0 ERC-20. It has no other way to mint, no owner, no pause, blacklist, freeze, burnFrom or upgrade, and no fee or burn on transfer. Every transfer moves exactly the amount asked, so the token doesn't need to exempt the factory, distributor or pool manager.

Files

• Config: foundry.toml pins solc 0.8.26 with bytecode_hash = "none", the optimizer on and no ffi or file access.
• Libraries: forge-std v1.11.0 and OpenZeppelin v5.4.0 are vendored as plain files in lib/, not as submodules.
• Tests: test/ConditionalsIMD.t.sol checks:
  • the name, symbol, decimals and supply;
  • that the deployer gets the whole supply, including when a factory deploys with CREATE2;
  • exact transfers and allowances;
  • failures: low balance, low allowance, sending to the zero address, approving the zero address;
  • that none of the usual mint or admin calls exist;
  • an opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT;
  • two fuzz tests that check the supply never changes and allowances are spent exactly.
• Script: script/DeployConditionalsIMD.s.sol is a deploy script for local or test networks only. Its deploy() function is tested directly.
• README: it covers the deployment settings (no constructor arguments, the exact supply, compiler settings, no extra contracts), the assumptions and who is responsible for what. Under "After launch" it says there is nothing to set.

Things to know

• Nothing is committed. The files are staged. Git has no author identity on this machine and the brief doesn't ask for a commit, so I didn't set one up. The ignored items are test/scratch/, the build output and a .gitmodules file inside the OpenZeppelin folder that the sandbox wouldn't let me delete. It isn't staged, and there are no submodules.
• The launch floor tests weren't run here. The provided files depend on harness pieces that aren't in this repo (LaunchLiquidity, PoolInitializationGuard, HookFlags, test/floor/OwnerChecks.sol, v4-core). I covered the same points in my own tests instead: whole supply to the factory, flows that arrive whole, no mint or freeze paths, and the opcode scan. The pool seed and swap haven't been run against a real Uniswap v4 pool manager.
• No launch.json. I didn't write one, as instructed. That is the manifest step's job.
• Not run: Slither isn't available here, so it was never run. The token has no custom code beyond the constructor, so none of the six blocking detectors should apply.

Nothing in the brief needed refusing.

The math audit of ConditionalsIMD (COND) found no defects. .imd-findings.json has an empty findings list and a coverage row marked holds for each of the three entry points, plus two rows for supply invariants.

What I covered (math precision, boundaries and numerical gaps):

• The contract itself: src/ConditionalsIMD.sol is a standard OpenZeppelin v5.4.0 ERC20. It adds nothing to the transfer path: no fees, burns, rounding, type conversions, custom unchecked code or changes to the transfer logic.
• Supply constant: TOTAL_SUPPLY = 1_000_000_000 * 10 ** 18 is 1e27, far below the uint256 limit, and is fixed at compile time. Aderyn's low-severity "large numeric literal" warning at line 17 is a style note, not a defect.
• Supply invariants: the only mint happens once in the constructor, and there is no burn or mint function anyone can call, so totalSupply stays exactly 1e27 forever. Balances always add up to totalSupply, because every transfer subtracts and adds the same amount.
• transfer / transferFrom: I read the vendored library code for these. Each unchecked subtraction comes after a check that it can't go below zero, and the unchecked addition can't overflow because no balance can exceed the 1e27 supply. Every transfer moves exactly the amount requested, including transfers to yourself and zero-value transfers. An allowance of the maximum uint256 value never decreases, which matches the library's documented behaviour.
• approve: it stores the value as given and contains no arithmetic.
• Tests: the project's 19 existing tests pass. Slither reported nothing.

What I didn't do: with no finding to prove, I wrote no extra test files. The other three specialists' areas (permissions, economics, control flow) are outside my scope. A clean review shows no math defects turned up; it doesn't prove the code has none.

I found no defects in the permissions area of ConditionalsIMD (COND), so .imd-findings.json has an empty findings list and five coverage rows, all marked holds. No source files were changed.

What the token is: src/ConditionalsIMD.sol is a plain OpenZeppelin v5.4.0 ERC20. The constructor takes no arguments and mints exactly 1,000,000,000 × 10^18 once, to the deployer. There is no owner, role, receive/fallback, external call or library call.

How I checked it:

• Library copy is unchanged: I downloaded the upstream v5.4.0 versions of ERC20.sol, IERC20.sol, IERC20Metadata.sol, Context.sol and draft-IERC6093.sol. The copies vendored in lib/ are byte-for-byte the same, so the access logic is stock OpenZeppelin.
• Entry points: the compiled ABI has only three functions that change state: approve, transfer and transferFrom. That matches the verifier's list.
• Build and tests: the project builds, and its own 19 tests pass.

The three guides:

• Access Control: there are no privileged roles, no unprotected initializer, and no way to mint after deployment. Only the owner of an allowance can set it. transferFrom checks and spends the allowance before moving anything.
• Trust Gap: the constructor gives no roles to anyone. Nothing is exempt from transfer rules and there is no fee, so the factory's payout, the distributor's claims and trades through the pool manager all move the exact amount requested. Nothing a privileged caller does can move, freeze or mint a holder's tokens.
• Asymmetry: transfer and transferFrom share the same balance logic. A maximum (type(uint256).max) allowance is never reduced as it is spent, which is how OpenZeppelin is designed to work. The known race when changing a non-zero approve is a property of the ERC-20 standard rather than a defect here, so I didn't report it.

Not done:

• I didn't run the protected floor tests. They need the network's own harness (v4-core, LaunchLiquidity and launch settings), which isn't in this repository.
• I wrote no proof tests, because there were no findings that needed one.
• The static-analysis lead (aderyn's "large numeric literal" at line 17) is just the supply constant, 1_000_000_000 * 10 ** 18, and is not a defect.

Done. launch.json is written and is the only changed file.

What the manifest says

• kind is custom_token. The token entry names the Solidity contract ConditionalsIMD, with name ConditionalsIMD, symbol COND and 18 decimals.
• constructorArgs is empty, because the accepted constructor in src/ConditionalsIMD.sol takes no parameters and mints the whole supply to msg.sender.
• totalSupply is the exact minor-unit value the constructor mints, matching the TOTAL_SUPPLY constant in the source.
• contracts is empty. The accepted tree has no application contracts, only the token, a deploy script and tests.
• pool and economics are copied verbatim from the launch reference: IMD as paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.
• notes describes the token's fixed supply, plain transfers, absence of any admin role, and that no application contracts ship with it. It is well under the 4000 character limit.

Verification

• A script parsed the manifest and confirmed only schema keys are present, the supply string equals one billion times ten to the eighteenth, and pool and economics match the job's values exactly.
• forge build compiled cleanly and forge test with the verifier's fuzz seed passed all 19 tests.
• git status shows launch.json as the only new file. No configuration, lib, or other file was touched.

The review is complete and .imd-findings.json holds an empty findings list with a full coverage record. The working tree is clean apart from that file.

Outcome: no defects found in the economics area. The token is a 22-line wrapper over OpenZeppelin v5.4.0 ERC20 with no transfer override, no owner, and no mint or burn path after the constructor.

What I checked and how:

• Dependency integrity. The five vendored OpenZeppelin files the token compiles against hash identically to upstream v5.4.0, so the ERC20 logic is the audited library code.
• Economic Security. No oracles, fees, caps, sentinel paths or external calls exist. ERC-20 compliance holds: the three entry points return true, revert on failure, and reject the zero address.
• Invariant. I ran a forge invariant campaign with random transfer, approve and transferFrom calls over a launch-like 10/80/10 split. Sum of balances equals total supply and total supply stays at one billion tokens across all runs.
• Flow Gap. Every launch flow moves exactly the requested amount, so the swarm share, pool seed, remainder, distributor claims and trader swaps all arrive whole. The empty constructor matches the empty manifest arguments.
• Static-analysis lead. The aderyn large-literal note is style only. The literal is the exact supply the README states.

Coverage rows mark all three ABI entry points as holds, plus three invariant rows. One row is unreached: the protected launch harness imports v4-core files not in this tree, so I read it and reasoned about it but could not execute it. The project's own 19 tests pass.

The control-flow review of ConditionalsIMD found no defects. The findings file is written with an empty list and eight coverage rows, and the working tree is clean.

What I reviewed. The token is a 22-line contract: an OpenZeppelin v5.4.0 ERC20 whose constructor mints the whole supply to the caller once. It adds no transfer logic, no owner, no receive or fallback. I made the Execution Trace, Periphery and First Principles passes myself, after reading the Senior Auditor's Mindset.

Periphery. The five OpenZeppelin files compiled into the token are byte-identical to the upstream v5.4.0 release, checked by diffing against the tagged sources. The compiler metadata lists exactly those five plus the token source, so nothing else reaches the bytecode.

Execution Trace and First Principles. Every entry point was traced for parameter divergence, sentinel values, stale reads, partial updates and approval residuals, then executed in a scratch Foundry test covering:

• CREATE2 deployment from a contract credits that contract, not the transaction origin, which is the factory's situation.
• Self-transfer and transferFrom with from equal to to, under both finite and infinite allowance, conserve balances.
• Zero-value, over-balance, over-allowance, zero-address and max-uint inputs revert or succeed exactly as the standard specifies.
• A 2000-run fuzz holds the sum of balances equal to total supply.
• Ether sent to the token is refused, and no admin selector exists.

Static-analysis leads. Slither reported nothing. Aderyn's large-literal note on line 17 is the supply constant, which evaluates to the correct 1e27.

Not a finding. The ERC-20 approve front-running race is inherent to the standard and recorded as a trust note in the coverage, not as a defect.

Coverage. All three listed entry points are marked holds, with five extra rows for the constructor mint, the no-growth and no-privileged-hand invariant, the launch-flow exactness invariant, library authenticity and the approve-race note. Nothing was left unreached.

I added 33 tests in two new files. The full suite passes: forge build is clean, and forge test with the verifier's fuzz seed ran 52 tests (the 19 already there plus mine) with no failures. The earlier contributor's test/ConditionalsIMD.t.sol is untouched, and I changed nothing outside test/.

test/ConditionalsIMD.invariant.t.sol runs random call sequences against the token: 256 runs of 64 calls each. A handler contract makes calls as five accounts, including the deployer. It keeps its own record of what every balance and allowance should be. Some of its calls must succeed (transfer, approve, transferFrom). The rest must fail: overspending a balance or allowance, sending to the zero address, approving the zero address, and calling mint, burn, burnFrom, pause, blacklist, freeze, seize and transferOwnership. The handler checks that each failing call gives the exact error expected and changes nothing. After every call these must hold:

• The total supply is still exactly 1,000,000,000 × 10¹⁸.
• The five accounts together hold the whole supply, and the zero address, the token and the handler hold none.
• Every balance and allowance matches the handler's record.
• No call that should have failed succeeded, and none that should have succeeded failed.
• The name, symbol and decimals are unchanged.

A plain test also drives every handler function once, so the random runs can't pass without the handler doing anything.

test/ConditionalsIMD.edges.t.sol covers edge values and failure cases:

• Amounts: the whole supply in one transfer, the supply plus 1 wei, the maximum possible amount, and a single wei.
• Zero address: as sender, approver, transferFrom owner (with a zero and a non-zero amount) and receiver.
• Allowances: a new approval replaces the old one rather than adding to it, approving zero revokes, allowances are per spender, and the owner needs an allowance even to use transferFrom on their own tokens. Also the maximum minus one being spent, spending an allowance down to exactly zero, an allowance bigger than the balance, and a failed transferFrom leaving the allowance as it was.
• Events: transferFrom emits only a Transfer event, with no Approval.
• Unsupported calls: the token rejects ETH, calls to functions it doesn't have, and ETH sent with a normal call.
• Fuzz tests (1,000 runs each): a transfer fails exactly when it is more than the balance, approve accepts any value, a stranger can't move a holder's tokens, and transferFrom moves the exact amount and uses up the exact allowance.

No defects found, so there is no .imd-findings.json. The token is OpenZeppelin v5.4 ERC20 with only a constructor that mints the fixed supply. One of my tests failed at first, and the mistake was mine. For a zero-amount transferFrom where the owner is the zero address, I expected an ERC20InvalidSender error. OpenZeppelin v5 re-records the allowance before it moves any tokens, so ERC20InvalidApprover comes first. The call is still rejected, which is the right behaviour, so I corrected the test.

I didn't install anything. The two new files are not committed; I left the commit to your upload step, as the earlier work arrived as its own imd commit.

The review is complete and .imd-findings.json is written. Nothing else in the tree was changed.

Outcome. The ConditionalsIMD token has no code defect. All four specialists and the test writer reported nothing, and I confirmed that against the code rather than taking it on trust. The only item I report is an info-level stale sentence in the README.

What I verified

• The token is a 22-line contract inheriting OpenZeppelin's ERC20 and minting the fixed supply to the deployer in its constructor. The compiled ABI exposes only the standard ERC-20 functions, three public constants, and the two events.
• The five vendored OpenZeppelin files the token depends on are byte-identical to upstream v5.4.0. I fetched each from the tagged release and compared SHA-256 hashes.
• I traced approve, transfer and transferFrom through the vendored ERC20 source. Zero-address checks, balance and allowance reverts, infinite-allowance handling and atomic revert on failure all behave as intended. There is no hook, fee, burn, external call, owner, pause or upgrade path.
• Creation code is 2,749 bytes and runtime 1,857 bytes, well under the factory's limits. The constructor takes no arguments, so the manifest's empty constructorArgs resolves and CREATE2 deployment puts the whole supply on the factory.
• The manifest uses only schema keys, its totalSupply equals the constructor mint, decimals match, addresses are lowercase, and the contract name is within 32 characters.
• The full project test suite passes, 52 tests including a 256-run invariant campaign. Static analysis leads were a single large-numeric-literal style note, which is not a defect.

The one finding (info). README line 38 says the repository deliberately has no launch.json, but launch.json is committed at the root. The fix is a one-sentence documentation edit.

Coverage. All three listed entry points are marked holds with reasons, plus four extra rows for the constructor mint, launch-flow exactness, forbidden-opcode absence and manifest consistency.