Implemented COND with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer. Includes standard ERC-20 transfers and approvals, vendored dependencies, and documented deployment assumptions and responsibilities.

Validation passed with Solidity 0.8.26:

• forge build
• forge test: 33 passed using the specified fuzz seed
• forge fmt --check

Tests cover success, failure, launch transfers, and supply/accounting invariants.

I wrote launch.json for the Conditionals (COND) launch, and it's the only file changed. forge build succeeds and forge test passes all 33 tests, run with the job's fuzz seed. I haven't committed it; it's sitting as a new file in the working tree.

The protected checks you gave me didn't run here. They import contracts that aren't in this repository (src/LaunchLiquidity.sol, src/PoolInitializationGuard.sol, src/HookFlags.sol) and need launch settings like the factory and pool manager addresses from the environment. So the 33 passing tests are only the repository's own tests. I checked the manifest itself only by confirming it is valid JSON and by reading it against the schema rules.

What the manifest says:

• Token: the contract is ConditionalsToken (from src/ConditionalsToken.sol), named "Conditionals", symbol "COND", 18 decimals.
• Constructor arguments: none. The constructor takes no parameters, so constructorArgs is an empty list.
• Total supply: "1000000000000000000000000000", which is exactly what the constructor mints once to the deployer (1,000,000,000 × 10^18).
• Other contracts: none. The accepted code has only the token, so contracts is empty.
• Pool: pair token 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tick spacing 60, and the one-to-one starting price 79228162514264337593543950336.
• Economics: copied exactly from the brief.
• Notes: a short description saying the token has a fixed supply, no owner, no tax and no extra contracts, plus the project site.

The review found no defects. The findings file at .imd-findings.json holds an empty findings list and seven coverage rows, and the working tree is otherwise unchanged.

What the token is. src/ConditionalsToken.sol is a 17-line contract: it inherits the vendored OpenZeppelin v5.0.2 ERC-20 and mints 10^27 base units to the deployer in the constructor. There is no owner, mint, burn, tax, hook, callback, or external call.

Execution Trace pass. I traced all three entry points to their final state in the inherited code. Transfer checks the receiver and balance before an unchecked subtract and exact credit. TransferFrom spends allowance first and then moves balance, and I confirmed a failed transfer restores the allowance. Infinite allowance is the only sentinel path and it skips nothing the standard requires.

Periphery pass. Every vendored OpenZeppelin file matches the upstream commit byte for byte by SHA-256. Decimals are hardcoded to 18. A reachable-opcode scan of the runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, or STATICCALL.

First Principles pass. The supply constant equals the specified 10^27, the mint goes to msg.sender under CREATE2 from a factory-like contract, and the launch flows move exact amounts. The project site describes IMD mechanics only and names no COND transfer rules, so the plain fixed-supply token matches the brief.

Checks run. Build, the project's 33 unit, fuzz and invariant tests with the pinned seed, and format check all pass. The one aderyn lead was the large numeric literal, which is style only. The standard ERC-20 approve race exists here as in every unmodified ERC-20 and is documented in the README, so I did not report it as a defect.

Not covered. The protected launch harness needs the network's Uniswap v4 fixtures, which are not in this tree, so the full seed-and-swap path was exercised only through the project's own pool-address transfer test.

The findings file is in place and is excluded from git by the repository's own exclude rule, which is expected for a review. Scratch files are gone and the tree is otherwise untouched.

Result: no defects found. The Conditionals token is an unmodified OpenZeppelin v5.0.2 ERC20 with a single constructor mint of 10^27 base units to the deployer. Nothing in the Economic Security, Invariant or Flow Gap guides applies to a failing path in this code.

What I verified for the economics area:

• Vendored dependency integrity. All five OpenZeppelin files hash identical to upstream commit dbb6104 (v5.0.2), so the transfer and allowance logic is the audited library code.
• Supply invariant. The constant equals exactly 1,000,000,000 × 10^18. The ABI exposes only the standard ERC20 functions plus the constant getter. No mint, burn, owner, initializer, pause or blacklist selector exists, and the internal mint and burn helpers are unreachable after construction.
• Launch flows arrive whole. A scratch test of the factory split (10% distributor, 50% pool manager, 40% remainder to the requester address), a full claim out of the distributor, and a buy and sell round trip through a pool-manager address moved exactly the stated amounts with the sum of balances staying at 10^27. A 1,024-run fuzz of two-hop transfers confirmed conservation.
• No periphery seams. The token makes no external calls, has no hooks, callbacks, receive or fallback, and no payable function. A reachable-opcode scan of the 1,752-byte runtime found no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Project tests. The repository's 32 unit and fuzz tests and two invariants (8,192 handler calls) pass with the pinned seed.

Coverage record: all three listed entry points are marked holds, plus three invariant rows (fixed supply, conservation and whole launch flows, no privileged hand or forbidden opcodes). Nothing was left unreached.

One note for the manifest step, not a defect: the constructor takes no arguments, so constructorArgs for the token must be an empty list and totalSupply must be 1000000000000000000000000000.

I fixed the failing check, and forge test now passes: 48 tests, 0 failures, with the verifier's fuzz seed and with two other seeds.

Cause: the bug was in the test, not the token. In the open-holder invariant suite, the fuzzer chose the invariant test contract itself (0x7FA9…1496) as a recipient. That transfer is legal and the handler counted it correctly. But the same invariant also requires that the test contract holds 0 tokens, so it failed with 79 != 0.

Fix: only test/ConditionalsToken.edges.t.sol changed. OpenHolderHandler now takes the test contract's address in its constructor. When the fuzzer picks that address, the zero address or a forge-std cheatcode or console address as a recipient or spender, the handler sends to the token contract instead. The invariant itself is unchanged and just as strict: the recorded holders own exactly the fixed supply, and the zero address and the test contract hold nothing.

Findings: none. ConditionalsToken is a plain OpenZeppelin ERC20 that mints 1,000,000,000 × 10¹⁸ COND once to the deployer. It has no owner and no mint, burn, tax or admin functions, so I did not write .imd-findings.json.

The review is complete. The permissions audit of the Conditionals (COND) token found no defects, and the findings file holds an empty list with a full coverage record.

What was reviewed

• The token at src/ConditionalsToken.sol is a 17-line wrapper over OpenZeppelin ERC20: one constructor mint of the full supply to the deployer, nothing else.
• All five vendored OpenZeppelin files are byte-identical to upstream v5.0.2, so the real permission surface is the stock allowance model.
• The compiled ABI exposes only the ten standard ERC-20 selectors plus the supply constant. There is no owner, initializer, receive, fallback, or payable function.

Checks run against the three guides

• Access Control: every balance write goes through one path guarded by either msg.sender or a bounded allowance decrement. Thirty admin, mint, burn, freeze, upgrade, and permit selectors revert from both the deployer and a stranger, and the deployer cannot pull a holder's tokens without allowance.
• Asymmetry: the approve/transferFrom and transfer/transferFrom pairs were diffed. Allowance has one setter and one bounded decrementer, and a failed transfer rolls back the decrement.
• Trust Gap: there is no privileged actor, price formula, or asymmetric economic primitive. The ERC-20 approve race is inherent and documented in the README, so it is recorded as a coverage note rather than a finding. The factory holding the full supply after construction is the launch design and is recorded as a trust assumption.
• An opcode walk of the deployed runtime found no reachable DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE, or external CALL.

Verification

The project's own 33 tests pass, and my scratch probe with four tests, including a 1024-run allowance fuzz, passed before I deleted it. The static analysis lead about a large numeric literal is style only and was not reported.

Output

The file .imd-findings.json contains zero findings and eleven coverage rows: one holds row for each of the three listed entry points, plus rows for the invariants and trust assumptions above. The working tree is clean apart from that file.

Result: no defects in the math area. The findings file at .imd-findings.json holds an empty findings list and eight coverage rows, all holds, covering the three listed entry points and five invariants.

What the code is. The token in src/ConditionalsToken.sol is OpenZeppelin v5.0.2 ERC20 plus one constructor mint of a compile-time constant. There is no division, multiplication, scaling, downcast, external call, payable path, sentinel no-op or bytes decoding anywhere in a value path. That leaves the three guides little to bite on, so I verified the few things a reading alone cannot settle.

What I verified, and how.

• The five vendored OpenZeppelin files are byte-identical to upstream commit dbb6104 (v5.0.2), fetched and compared with cmp. A tampered library was the only place a math defect could hide.
• The supply constant equals 10^27 by three independent routes: python, cast to-wei, and a 1e27 literal in a scratch test. That also closes the aderyn large-numeric-literal lead as a lint, not a defect.
• A scratch suite of 13 tests under test/scratch/MathBoundary.t.sol passes. It covers max-uint and supply+1 transfers reverting on the balance check before any arithmetic, a balance reaching exactly the full supply without wrapping, the infinite-allowance sentinel being exactly max with max-1 decrementing normally, allowance equal to and one short of the value, zero-value transferFrom with zero allowance, self-approval, from-equals-to, value sent to nonpayable entry points reverting, a fuzzed three-way partition conserving supply exactly, and the protected test's reachability scan finding no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The existing suite of 33 tests and the two 8,192-call invariants pass with the README's fuzz seed. Slither reported nothing.

Trust notes, not defects. Tokens sent to the token contract address are unrecoverable, and transferFrom emits no Approval event. Both are documented OpenZeppelin v5 behaviour and the README states them as intended, so I did not report them.

Not done. I changed no project files. The scratch test is my working material and nothing in it is kept. The protected launch tests need the network's v4 harness, which is not in this tree, so I did not run them.

The review is complete. No defects were found, and the findings file records a clean review with full coverage.

Outcome. The four specialists and the tester all reported nothing, and I reproduced that result independently. The findings file holds an empty findings list and seven coverage rows, three for the listed entry points and four for invariants I checked. The working tree is unchanged apart from that file.

What I verified against the code:

• The token is a 17-line contract that inherits OpenZeppelin ERC20 and mints one billion COND to the caller in a parameterless constructor. There is no owner, no mint, burn, pause, blacklist or upgrade path, and the compiled ABI exposes only approve, transfer and transferFrom as state-changing functions.
• All five vendored OpenZeppelin files hash identically to upstream v5.0.2 at the commit DEPENDENCIES.md names, so the ERC-20 logic is the audited library, not a modified copy.
• A scratch test mirroring the protected floor deployed the token via CREATE2 from a factory probe, confirmed the factory holds exactly the manifest supply with 18 decimals, moved the swarm share whole through a distributor and claim, tried 22 common admin selectors from both the deployer and a stranger with every one reverting, and checked allowance semantics including the unlimited case. All passed. The scratch directory was removed afterwards.
• A reachable-opcode scan of the runtime finds no DELEGATECALL, CALLCODE or SELFDESTRUCT. Runtime and creation code are far under the EIP-170 and factory limits, and no metadata hash is appended.
• The manifest uses only schema keys, its empty constructorArgs matches the constructor, and its supply and decimals match the code.
• The project's own 48 tests pass, and the formatter check on project files is clean.

Static analysis leads. Slither reported nothing. Aderyn's low "large numeric literal" line points at the supply constant, which is written as a readable product equal to 1e27 and is not a defect, so it was dropped.