Implemented Conditionals (COND): 1 billion tokens, 18 decimals, minted once entirely to the deployer.

Dependencies are vendored for offline builds. Deployment assumptions and operational responsibilities are documented in README.md.

Verified with Solidity 0.8.26:

• forge build passes.
• forge test passes with the required fuzz seed, including supply invariants.
• forge fmt --check passes.

I found no defects in the Conditionals (COND) token's economics. .imd-findings.json has an empty findings list and six coverage rows, all holds.

What the code is: src/Conditionals.sol is an OpenZeppelin v5.1 ERC20 with nothing added. Its constructor mints 1_000_000_000 * 10 ** 18 once to msg.sender (the factory). The vendored OpenZeppelin ERC20.sol matches the standard v5.1 code for transfer, approve, transferFrom, _approve, _spendAllowance and _update.

The three guides:

• Economic Security: there are no fees, burns, taxes, hooks or price-dependent logic. That means no value can be pulled out, and nothing a privileged account could abuse.
• Invariant: total supply stays at exactly 10²⁷. The only mint is in the constructor, and no public function can mint or burn. The token uses the default 18 decimals. Each transfer subtracts from one balance and adds the same amount to another, and a failed transfer changes nothing.
• Flow Gap: because no transfer charges a fee, every launch flow moves exactly the amount requested. That covers the factory sending the swarm share to the distributor, seeding the pool through the PoolManager, swaps in both directions, and distributor claims. There's no owner, pause, blacklist, freeze, burnFrom, delegatecall or selfdestruct.

The three entry points:

• approve sets the allowance to the exact value and rejects a zero owner or spender. The known ERC20 race when an existing allowance is overwritten applies to every ERC20, not to this code, so I didn't report it.
• transfer moves exactly the amount and reverts cleanly on an insufficient balance.
• transferFrom reduces a finite allowance by exactly the amount and leaves an unlimited (max) allowance unchanged.

Static analysis: the one aderyn lead, a large number at line 10, is just the supply constant, which is correct.

Checks run: the existing forge test suite passed (31 of 31). I didn't run the protected launch tests, because they import v4-core and src/LaunchLiquidity.sol, which aren't in this tree. I modified no project files.

I found no defects in the control-flow area, so .imd-findings.json has an empty findings list and a coverage row for each entry point. No project files were changed; git status is clean, and the findings file is the only thing written.

What I reviewed. src/Conditionals.sol is a plain OpenZeppelin v5.1 ERC20. Its constructor mints 1_000_000_000 * 10**18 to msg.sender once, and the contract overrides nothing. I read the vendored ERC20.sol paths it relies on (transfer, approve, transferFrom, _transfer, _update, _approve, _spendAllowance) and checked them against the three guides:

• Execution Trace: there are no external calls or callbacks, so there is no reentrancy surface. Every failure reverts the whole transaction. Allowance and balance updates are checked first, and the unchecked subtractions are safe because a check precedes each one. A type(uint256).max allowance is never decremented, as intended.
• Periphery: there is no transfer fee, burn or exemption list. The factory-to-distributor transfer, distributor claims, the pool seed and PoolManager swaps (which settle with transfer/transferFrom) all move exactly the amount requested. No constructor arguments are needed, because nothing is exempted.
• First Principles: the supply is fixed, with no mint, burn, owner, pause, blacklist or upgrade path. decimals() returns 18, matching the brief. There is no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Coverage: all three entry points (approve, transfer, transferFrom) are marked holds. I added two invariant rows, one for the fixed supply minted to the deployer and one for 18 decimals.

Static analysis: Slither reported nothing. Aderyn's large-numeric-literal note on line 10 is only a style point and isn't a defect, so I didn't report it.

Tests: the existing project tests pass (31 of 31, including the invariant suite). I did not run the protected floor tests, because they need deployment environment variables this machine doesn't have.

Not reported: the standard ERC-20 approve race, where a spender can use both the old and new allowance if one is changed without first setting it to zero. Every ERC-20 behaves this way, and nothing in the brief asks for anything different, so I don't count it as a defect here.

Created launch.json matching the accepted constructor, exact supply, pool settings, and economics.

Validation passed. forge build succeeded; forge test passed all 31 tests with the supplied fuzz seed. Only launch.json changed.

The permissions review of the Conditionals (COND) token is complete. No defects found in the assigned area.

What was reviewed. The token at src/Conditionals.sol is 16 lines: an unmodified OpenZeppelin ERC20 whose constructor mints the full supply to the deployer. I checked it against the Access Control, Trust Gap and Asymmetry guides, plus the Senior Auditor's Mindset, and against the protected floor tests the launch will run.

Why it holds.

• The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions. There is no owner, role, modifier, initializer, proxy, receive or fallback.
• The internal mint and burn helpers are reachable only from the constructor, so supply cannot grow after launch.
• All five vendored OpenZeppelin files are byte-identical to upstream tag v5.1.0, verified by SHA-256 against the raw GitHub files. No override of the sender or update hooks exists.
• Transfer and transferFrom are symmetric: both go through the same guarded path, and the zero-address owner is rejected on both the approve side and the spend side.
• A deployer-contract test confirmed CREATE2 deployment credits the factory, not the transaction origin. Deployer and strangers cannot move a holder's balance without approval.
• Reachable runtime opcodes contain no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Twenty common admin, mint, burn, pause, blacklist, permit and upgrade selectors all revert with no state change.

Checks run. The project's 31 tests and invariant suite pass with the README's fuzz seed. Five scratch tests covering the points above also passed and were then removed, since there is no critical or high finding to carry a proof.

Trust assumption. The only privileged moment is deployment: the factory holds the entire supply and distributes it off-contract. Afterwards the deployer has the same rights as any holder. This is documented as a coverage row, not a finding.

Output. .imd-findings.json holds an empty findings list and eight coverage rows: one for each of the three entry points, plus rows for the no-privileged-role, single-mint, dependency-integrity, bytecode and initial-holder invariants. No tracked file was changed.

The review is complete with no defects found in the Math Precision, Boundary, or Numerical Gap areas.

What was reviewed. The Conditionals token is a 16-line contract that inherits OpenZeppelin v5.1.0 ERC-20 unchanged and mints a constant supply to the deployer in its constructor. It has no division, scaling, fee, rounding, downcast, external call, payable path, or admin function, so most failure modes in the three guides have no surface to attack. I checked each one that does apply:

• Math precision. The supply constant is exactly 10^27 and equals one billion times ten to the token's decimals. The unchecked subtraction and addition in the inherited transfer path are guarded by a prior balance check and by the fixed total supply, so no wrap is reachable. The aderyn large-literal lead resolves to a correct compile-time constant and is not a defect.
• Boundary. Zero, one, full-supply, and max-uint amounts, self-transfers through both transfer and transferFrom, allowances at zero, max-minus-one and max, zero-address sender, recipient and spender, native value sends, empty calldata, and unknown selectors all behave as the specification states. The runtime contains no DELEGATECALL, CALLCODE, or SELFDESTRUCT on any reachable path.
• Numerical gap. Conservation of supply holds exactly under the project's stateful invariant run and my own fuzzing, since nothing in the code rounds. The ten percent swarm share and every possible pool basis-point share of 10^27 divide with zero remainder.
• Dependency integrity. The five vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 archive, whose hash matches the vendored manifest.

Checks run. The project's own 31 unit, fuzz and invariant tests pass with the documented seed, formatting is clean, and my 11 scratch tests under test/scratch pass. No tracked file was modified.

Output. The findings file at the repository root holds an empty finding list and nine coverage rows: one holds for each of the three ABI entry points and six for the invariants and boundaries I verified. Nothing in my area was left unreached.

Added failure-path, boundary, recovery, and fuzz tests; expanded invariants across 11 handler actions. Only test/ changed.

forge build and forge test pass with the required seed: 48 tests passed, including 32,768 invariant calls. No confirmed defects found.

The review is complete. The Conditionals token is clean: no findings, and all three entry points hold.

What I verified

• The token is a bare OpenZeppelin ERC20 with a zero-argument constructor that mints the full fixed supply to the deployer. There are no owner roles, mint, burn, pause, blacklist, upgrade, fallback or receive paths. The compiled ABI exposes only the standard ERC-20 surface plus the supply constant.
• The vendored OpenZeppelin files are byte-identical to upstream v5.1.0, checked by downloading each file and comparing. No tampering in the inherited transfer, allowance or mint logic.
• The project's own suite passes: 48 tests across unit, fuzz and invariant files, run with the README's fixed fuzz seed.
• Deployment through the factory works under the CREATE2 model: no constructor arguments, no external calls, runtime far below the size limit, and the whole supply lands at msg.sender, which is the factory. The manifest matches the code on contract name, supply, decimals and empty constructor arguments.
• The static-analysis lead from aderyn is a style note on the supply literal, which evaluates to exactly 10^27. Not a defect.

Specialist findings

All four specialists and the test writer reported nothing, so there was nothing to reproduce or merge. I reread the code independently with the auditor checklists and found nothing they missed.

Output

The findings file at the repository root holds an empty findings list and seven coverage rows: one holds row for each of approve, transfer and transferFrom, plus rows for the fixed-supply, deployability and no-privileged-power invariants and the aderyn lead. No repository files were changed.