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

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

Passed forge build, all 31 local tests—including fuzz and invariant tests—and forge fmt --check.

The review is complete and the findings file is written. The economics audit of the CONDITIONALS (COND) token found no defects.

What was reviewed. The token at src/ConditionalsToken.sol is a 16-line contract inheriting OpenZeppelin v5.0.2 ERC-20 with one constructor mint of 1e27 base units to msg.sender. It adds no overrides, roles, fees, hooks or external calls. I confirmed the five vendored OpenZeppelin files are byte-identical to upstream at the pinned commit, so the inherited transfer and allowance logic is the canonical one.

Checks performed against the three guides:

• Economic Security: no external dependency, oracle, price or fee path exists. ERC-20 behaviour verified at the boundaries the guide names (zero amount, full balance, uint256 max, self-transfer, zero-address sender, receiver and spender). The missing Approval event on transferFrom is OpenZeppelin v5 behaviour the EIP permits and the README documents.
• Invariant: supply is fixed at deployment with no mint or burn selector in the ABI. Balance conservation, allowance coupling and atomic rollback hold under the project's 31 unit and invariant tests plus my own scratch test, which also probed eight admin-style selectors from the factory address with no effect.
• Flow Gap: the launch flows from factory to distributor, pool manager and remainder address, then claims and buy/sell against the pool manager, move exact amounts. The deployed runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT and rejects ETH.

Coverage. All three listed entry points are marked holds, with three additional invariant rows. The full Uniswap v4 seed and swap was not run locally since v4-core is not vendored, but the token has no code path that could tax or revert it. Slither reported nothing and the aderyn large-literal lead is the intended supply constant.

The scratch test directory was removed, leaving the tree unchanged apart from .imd-findings.json.

The review is complete. The math audit of the CONDITIONALS token found no defects, and the findings file records an empty list with full coverage.

What was reviewed. The token at src/ConditionalsToken.sol is 16 lines: it inherits OpenZeppelin ERC20 v5.0.2 unchanged and mints a constant supply to the deployer in the constructor. I checked it against every failure mode in the Math Precision, Boundary and Numerical Gap guides, plus the Senior Auditor's Mindset.

Why it holds.

• No arithmetic of its own. The only math is the compile-time constant for the supply, which is exactly 10^27 and matches the README and manifest supply in minor units. Decimals are the OpenZeppelin default of 18.
• Inherited math is sound. Every unchecked subtraction in the vendored ERC20 is guarded by a strict comparison just before it, and every unchecked addition is bounded by total supply. I traced the infinite-allowance sentinel, allowance one below the sentinel, self-transfer, self-transferFrom, 1 wei, full supply and maximum uint256 inputs, and drove them in a scratch Foundry test. All behaved as the standard specifies.
• No boundaries to break. The disassembled runtime has no external call, delegatecall, callcode, create or selfdestruct, no payable path, no bytes decoding, and only zero-address sentinel checks that revert.
• No numerical seams. There is no division anywhere, so the sum of balances equals total supply exactly. The launch's 10/70/20 split of 10^27 divides without remainder.
• Dependencies verified. All five vendored OpenZeppelin files are byte-identical to upstream commit dbb6104 and match the recorded checksums.

Leads dismissed. The aderyn large-numeric-literal line points at the intended supply constant and is not a defect. Slither reported nothing. The repository's own 31 tests, including the stateful invariant suite, pass under the pinned fuzz seed.

Outside my area. The pool price derived from the launch economics lands inside Uniswap v4's valid sqrt-price range for either currency ordering. No privileged or supply-growing entry point exists in the compiled ABI.

The findings file holds ten coverage rows, one for each of the three entry points and seven for invariants and boundaries checked. The scratch test and build artifacts were removed, and no reviewed file was changed.

The review is complete and .imd-findings.json is written with one informational finding and nine coverage rows. No files in the tree were changed, and the scratch test I used was removed.

What I reviewed. The token is a 16-line wrapper over the vendored OpenZeppelin v5.0.2 ERC-20 that mints the whole supply to the deployer in the constructor. I checked it against the Execution Trace, Periphery and First Principles guides, plus the Mindset and the protected floor tests, and ran the project's unit, fuzz and invariant suites, which all pass.

Result for the token itself: no defects. All three entry points hold.

• approve rejects the zero spender, overwrites the allowance, moves no value, and only ever touches the caller's own allowances.
• transfer rejects the zero receiver and insufficient balance before any write, delivers the exact amount with no fee, burn, hook or callback, and is atomic on every revert path.
• transferFrom spends allowance before moving tokens, never decrements an unlimited allowance, and no holder, including the deployer or factory, can pull from another without allowance.
• The constructor mints exactly 10^27 base units to msg.sender with 18 decimals, so a factory deploy credits the factory the whole supply. There is no mint, burn, pause, blacklist, owner, proxy, receive or fallback. A replay of the floor's opcode scan found no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The production library is byte-identical to the pinned upstream OpenZeppelin commit, so the launch flows through the distributor and the PoolManager move exactly what they say.

One informational finding. The vendored forge-std SHA256SUMS does not match seven of the shipped files. The differences are whitespace only and forge-std is test-only, so no deployed bytecode is affected. It contradicts the README's "vendored unchanged" claim and makes the integrity check it describes fail. The fix is to re-vendor those files byte for byte or regenerate the checksum file.

Not reached. The Uniswap v4 seed and swap were not executed locally because v4-core is not vendored; the token-side invariant they depend on, exact transfer amounts, was verified instead. The aderyn large-literal lead was checked and is style only.

I added 2 new test files to the existing suite and found no defects in the token. The full suite passes with the verifier's fuzz seed: 51 tests across 4 suites, none failing or skipped, and the invariant runs had no reverts.

What the token is: src/ConditionalsToken.sol is a plain OpenZeppelin ERC-20 named CONDITIONALS (COND) with 18 decimals. It mints 1,000,000,000 tokens once, to whoever deploys it. It has no owner, no mint or burn, no pause or blacklist, no fee on transfer and no special behaviour.

What was already there and still passes: 30 unit and fuzz tests in test/ConditionalsToken.t.sol and one invariant suite in test/ConditionalsToken.invariant.t.sol. I didn't change either file.

New: test/ConditionalsToken.launch.t.sol (19 tests)

• Deployment:
  • The supply goes to the address that deploys the token, not to whoever signed the transaction (fuzzed over both addresses).
  • Two deployments don't share balances, and the same address can't be deployed twice.
• One-transaction launch: a helper contract deploys the token and hands out the launch shares in a single call: 10% to the distributor, a fuzzed pool share, and the rest to the remainder address. Every amount arrives exactly, and a claim out of the distributor arrives whole.
• Bytecode: the deployed code contains no DELEGATECALL, CALLCODE or SELFDESTRUCT (checked the same way the protected test checks it) and is within the 24,576-byte size limit.
• Admin functions: 16 more admin-style calls are rejected whether the deployer or a stranger sends them. These include mint, unpause, setBlacklist, grantRole, permit, increaseAllowance and upgradeToAndCall. Afterwards the supply hasn't changed and holders can still transfer.
• Call format: transfer, approve and transferFrom each return exactly one 32-byte true. Calls with missing arguments or a malformed address are rejected.
• Edge cases:
  • A transfer one unit over the balance fails.
  • An allowance one below the maximum still goes down when spent, and a spent allowance can't be used again.
  • Approving yourself, and allowances being separate per spender.
  • Tokens sent to the token's own address can't be pulled back out by the deployer.
• Fuzzed: transfers between any two addresses, approvals overwriting earlier ones, and transferFrom failing with the correct error when either the allowance or the balance is short.

New: test/ConditionalsToken.openInvariant.t.sol (invariant tests)

• A handler contract makes random sequences of calls. Recipients include brand-new addresses, the token's own address and the handler. The sequences mix in calls that must fail: overspending, sending to the zero address, and mint, burn, burnFrom and pause attempts.
• Each call is checked against its expected outcome: it must succeed or fail as predicted.
• After every sequence, these must hold:
  • The total supply never changes.
  • Every tracked balance matches a separately kept tally.
  • Those balances add up to the full supply.
  • The zero address holds nothing.
  • Every allowance matches the tally.
  • The token contract holds no ETH.

Because nothing failed, I didn't write .imd-findings.json. I installed nothing and changed nothing outside test/. The two new files are in the working tree but not committed.

Review complete. The findings file is written and validated against the tree.

Outcome: no permission defects in the CONDITIONALS token. The contract at src/ConditionalsToken.sol is a bare OpenZeppelin 5.0.2 ERC-20 with a single constructor mint of 10^27 base units to the immediate deployer. The compiled ABI has exactly three state-changing entry points, no constructor arguments, no receive or fallback, and no privileged function of any kind.

What I checked, per the three assigned guides:

• Access Control. There is no role, modifier, initializer, proxy, delegatecall or external call. Each storage slot has a single writer path gated by the caller's own identity. The mint credits msg.sender, not tx.origin, so under the factory launch the factory holds the supply. Deployer, origin and strangers all fail to move or approve a holder's balance.
• Trust Gap. No privileged actor, fee recipient, setter, oracle or in-flight value exists, so no access-times-economics seam can form.
• Asymmetry. The approve and spend paths mirror exactly except the omitted Approval event on spend, which the README documents. Both transfer paths share the same validation and writes. Every revert path leaves balances and allowances untouched. The existing invariant suite ran 8192 calls with zero model mismatches, and my scratch tests under test/scratch/ all pass.

One info-level note recorded. The README says forge-std is vendored unchanged with checksums, but seven forge-std files fail the recorded SHA256SUMS. I diffed them against the pinned upstream commit: the differences are formatting reflow only, and forge-std is test-only, so this does not touch the token. The fix is to regenerate the checksum file or restore upstream formatting.

Coverage has nine rows: all three entry points hold, plus rows for the constructor role handout, the absent payable surface, each of the three guides, and the fixed-supply invariant. Nothing was left unreached. The OpenZeppelin files verify against their checksums, the build is clean on Solidity 0.8.26 with bytecode_hash none, and forge fmt --check passes on the delivered sources.

I wrote launch.json for the CONDITIONALS (COND) launch. forge build succeeds and forge test passes 31 of 31 tests with the pinned fuzz seed. Those are the existing token tests, though, so they don't check the manifest. I checked the manifest by reading it against the source and the brief.

What it contains, based on src/ConditionalsToken.sol, the only contract in the tree:

• Token: contract ConditionalsToken, name "CONDITIONALS", symbol "COND", 18 decimals. Its constructor takes no arguments, so constructorArgs is [].
• Supply: the constructor mints 1,000,000,000 × 10^18 to msg.sender once, so totalSupply is "1000000000000000000000000000".
• Application contracts: contracts is [], because the tree has none.
• Pool: paired with IMD at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tickSpacing 60, initialPrice 79228162514264337593543950336 (one to one, recorded but not used to set the price).
• Economics: copied verbatim from the brief.
• Notes: 470 characters (the limit is 4,000) describing the plain fixed-supply ERC-20, which has no owner, admin roles, mint, fees or pause, and stating that the launch deploys no other contracts.

Only the schema's keys are used, and addresses are lowercase.

launch.json is the only change, and it is not committed. The commit failed because git has no author name or email set on this machine, and I didn't change the git config. The file is in the working tree for the upload; if the submission needs a commit, someone will have to set a git identity first.

Review complete. The findings file is written and validated, and no repository files were changed.

Outcome: the token is a plain, unmodified OpenZeppelin v5.0.2 ERC-20 and I found no defect in it. One info-level provenance note is kept, merged from the two specialists who reported the same root cause.

What I verified

• The vendored OpenZeppelin ERC20 and its four dependencies are byte-identical to the pinned upstream commit, so the token's transfer, approve and allowance logic is exactly upstream's.
• The constructor mints exactly the manifest supply to the deployer, there are no owner, mint, burn, pause or blocklist paths, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. Creation and runtime code are far below the size limits.
• All 51 project tests pass, including two invariant suites, and forge fmt --check is clean. The manifest's constructor arguments, supply, decimals, name and symbol match the source.
• The aderyn large-literal lead evaluates to exactly 1e27 and is not a defect.

Kept finding (info): the forge-std SHA256SUMS file records upstream hashes, but seven vendored forge-std files were reformatted, so the integrity check the README points to fails. I reproduced it by running the checksum file and by confirming the files are whitespace-identical to upstream. forge-std is test-only and does not affect the deployed token.

Coverage: all three entry points are marked holds with traced reasons, plus two invariant rows. No proof file was needed since nothing reached medium or above.