Implemented CONDITIONALS (CONDITION) with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer.

Included vendored dependencies, deployment and operations documentation, and success, failure, fuzz, and invariant tests.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed: 29 tests using the requested fuzz seed.
• forge fmt --check passed.

I wrote launch.json for the CONDITIONALS (CONDITION) launch. The project builds and all 29 existing tests pass with the required fuzz seed. I couldn't commit it, because git has no author name or email set on this machine and I didn't want to change its configuration. So the file is sitting uncommitted in the working tree, and it's the only file I changed.

What the manifest says:

• Token: the contract in src/ConditionToken.sol is named ConditionToken. Its constructor takes no arguments, so constructorArgs is []. It returns the name CONDITIONALS, symbol CONDITION and 18 decimals.
• Supply: totalSupply is "1000000000000000000000000000", which is exactly what the constructor mints once to the deployer (1_000_000_000 * 10**18).
• Application contracts: contracts is [], because the accepted code contains only the token.
• Pool and economics: both are copied exactly from the brief: the IMD pair token address, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object.
• Notes: a short description of the token. It has no owner, no admin functions, cannot mint more, and charges no fee or burn on transfer.

The file is valid JSON and has only the fields the schema allows. I couldn't run the two protected check files (Owners.protected.t.sol and Token.protected.t.sol) here: they import src/LaunchLiquidity.sol, which isn't in this repository, and they read values from environment variables that the verifier sets.

The permissions review of the CONDITIONALS token found no defects. The findings file holds an empty findings list and seven coverage rows, all holds.

Scope

Files read: src/ConditionToken.sol (16 lines), the five vendored OpenZeppelin files, both project test files, both protected tests, and the Pashov Mindset plus the Access Control, Trust Gap and Asymmetry guides. Nothing in the assigned area was left unreached.

Severity counts: 0 Critical · 0 High · 0 Medium · 0 Low

What was checked

• Permission model. The contract declares one constant and one constructor. No owner, role, modifier, initializer, setter, mint, burn, pause, blacklist, freeze or seize path exists. The compiled ABI exposes only the nine ERC-20 functions plus the supply constant.
• Inherited code. Every vendored OpenZeppelin file was diffed against the upstream v5.4.0 tag and is byte-identical. No override of _update, _approve or any guard exists. Context returns plain msg.sender, so no forwarder can spoof a caller.
• Entry points. transfer moves only the caller's balance and rejects the zero address. transferFrom requires allowance from every caller, including the deployer and the holder itself, and does not decrement an infinite allowance. approve writes only the caller's own allowance row. All three were traced through _transfer, _update and _spendAllowance with the revert paths confirmed.
• Asymmetry. Both transfer paths share the same balance writes. The only difference is that spending an allowance emits no Approval event, which is documented OpenZeppelin v5 behaviour and stated in the README.
• Trust Gap. With no privileged actor and no economic formula, there is no seam where authorization and economics interact.
• Launch floor. The constructor mints exactly 10^27 base units to msg.sender, which is the factory. The runtime bytecode contains no CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT opcode. The existing 29 tests and the invariant suite pass, and forge fmt --check is clean.
• Static analysis leads. Slither reported nothing. Aderyn's large-literal warning resolves to the correct supply value and is not a defect.

Observations (non-blocking)

• A zero-value transferFrom succeeds without allowance and emits a Transfer event naming any from address. This is standard ERC-20 and OpenZeppelin behaviour, so it is not reported as a finding.
• The standard ERC-20 approve race applies, as the README already documents.
• No launch.json exists yet. When written, the token entry needs an empty constructorArgs list and a totalSupply of 1000000000000000000000000000.

The review is complete. The findings file is written and validated, and the working tree holds no changes of mine beyond it.

Result: no defects found in the math area. The token at src/ConditionToken.sol is a 16-line fixed-supply wrapper over the unmodified OpenZeppelin v5.4.0 ERC-20. It has no fee, tax, burn, mint, scaling, division, cast, or external call, so most failure modes in the Math Precision, Boundary and Numerical Gap guides have no surface to attach to. What remained, I checked directly:

• Supply constant. The literal aderyn flagged folds at compile time to exactly 10^27, and that constant appears in the deployed bytecode. It matches the task's 1,000,000,000 tokens at 18 decimals with no truncation or overflow.
• Transfer arithmetic. The balance check precedes every unchecked subtraction, and receiver additions are bounded by the fixed supply. Probed inputs were 0, 1 wei, the full balance, supply plus one, and max uint, each giving the exact expected revert or result.
• Allowance boundaries. Max is infinite, max minus one is finite and decremented, an allowance equal to the amount goes to zero, and a failed transfer leaves the allowance intact.
• Launch split arithmetic. The 10/80/10 percent splits of 10^27 have zero remainder and the intermediate product cannot overflow, so every launch flow arrives whole.
• Boundaries. No payable, receive or fallback exists. ETH and unknown selectors revert. Reachable runtime code contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Verification run on this machine: forge build succeeded, the project's 29 tests passed including the stateful invariant suite, formatting check passed, and my 17 scratch probes passed before I removed them. The vendored OpenZeppelin files match the upstream v5.4.0 text.

The coverage record answers all three listed entry points as holding, plus rows for the constructor and three invariants. Nothing in my area was left unreached. Out of my area, I noted no severe issue either. The static-analysis lead was style only.

The findings file is in place and excluded from git by the repository's own exclude list, which is the intended arrangement. The scratch directory is gone and the source tree is unchanged.

Result

No defects found. The review of the control-flow area is written to .imd-findings.json with an empty findings list and nine coverage rows, all holds.

What the token is. A 16-line contract inheriting OpenZeppelin ERC-20 v5.4.0 with no overrides. The constructor takes no arguments and mints one billion tokens at 18 decimals to the deploying address once. It exposes only the three standard state-changing functions and the standard views.

What I checked, by guide:

• Execution Trace. Traced approve, transfer and transferFrom through OpenZeppelin's internal functions to the storage writes and events. Zero-address sentinels revert on every path, the infinite allowance is left untouched, failed delegated transfers revert atomically, and no function makes an external call or has a reentrancy surface. The zero-value transferFrom that needs no allowance only emits an event with no balance effect, which is standard behaviour.
• Periphery. Hashed the five vendored OpenZeppelin files against the upstream v5.4.0 tag archive downloaded from GitHub. All match byte for byte, and the archive hash matches DEPENDENCIES.md. Message sender resolution never uses tx.origin.
• First Principles. The mint amount equals the stated supply exactly. Storage holds only the five ERC-20 slots, so no owner, pause, blacklist or minter state exists anywhere. The compiled ABI has no mint, burn, initializer, receive or fallback. A reachable-opcode scan of the runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, CREATE, PUSH0 or transient storage, so the protected floor tests should pass on this artifact.

Checks run. Build, the full project suite with the README's fuzz seed, and formatting check all passed. A temporary scratch test replaying the launch distribution flows, the opcode scan and ETH rejection also passed and was then deleted.

Not reached. No live Uniswap v4 pool seed or swap, since the protected harness depends on v4-core which is not vendored here. The token has no pool-specific code, so nothing in this area depends on that result.

The aderyn large-numeric-literal lead is a style note on a compile-time constant and was not reported.

I added two test files to the existing suite. forge test passes with the verifier's fuzz seed: 50 tests across 4 suites, none failing or skipped. I found no defects, so there is no .imd-findings.json. I haven't committed anything.

The token (src/ConditionToken.sol) is a plain OpenZeppelin v5 ERC-20. It mints exactly 1,000,000,000 × 10¹⁸ once to msg.sender and has no admin, mint, burn or pause functions. The earlier contributor's 29 tests were already sound, so I added to them rather than rewriting.

test/ConditionToken.model.invariant.t.sol (256 runs, about 16k calls):

• Handler: tests random sequences across six actors: the deployer, a distributor, a pool manager, two users and the token's own address. Unlike the existing handler, it also makes calls that should fail: overdrafts, zero-address recipients and spenders, missing or used-up allowances, and random calldata. Each call is checked against a separate record of expected balances and allowances, including the exact error it should revert with.
• Invariants:
  • Every balance and allowance matches the expected record.
  • All balances add up to the fixed supply.
  • totalSupply never changes, even after random calldata.
  • No spender ever moves more than it was granted.
  • Name, symbol and decimals never change.
• Check that the handler works: a plain test drives it step by step to confirm it really produces both successful and failing calls, so the invariants aren't passing on nothing.

test/ConditionToken.launch.t.sol (19 tests):

• Launch flow: a stand-in factory deploys the token with CREATE2 and splits the supply in one call: 10% to the distributor, the pool share, and the rest to the requester. It checks the predicted address and that every amount arrives exact. A fuzz test covers every pool share up to 90%. Equal claims from the distributor arrive whole, an overpaying batch reverts completely, and the same salt can't be deployed twice.
• Bytecode and calls: the reachable runtime code has no DELEGATECALL, CALLCODE or SELFDESTRUCT. The token refuses ETH. Unknown function selectors change nothing. transfer, approve and transferFrom return a proper true value.
• Edge cases:
  • Moving 1 wei and the last wei, and trying to transfer the maximum uint256.
  • An allowance of max − 1 still counts down; spending an allowance emits no Approval event.
  • An approval only works for that spender and that owner; an allowance larger than the balance is still limited by the balance.
  • Fuzzed approve, chained transfers, and an unlimited allowance that never goes down.

One thing to know, which is standard ERC-20 behaviour and not a defect: tokens sent to the token contract's own address are accepted and can never be recovered, though they still count toward the supply. A test documents this.

The review is complete and the findings file is in place with a clean result.

Outcome: no defects found in the economics area. The file .imd-findings.json holds an empty findings list and seven coverage rows, one for each of the three listed entry points plus four invariants I checked.

What the token is. ConditionToken is a plain OpenZeppelin v5.4.0 ERC-20 with one constructor that mints 10^27 base units to msg.sender. There is no _update override, no owner, no mint, burn, pause, blacklist, hook, receive or fallback. The compiled ABI is exactly the standard ERC-20 surface plus the INITIAL_SUPPLY getter.

How I checked it against the three guides:

• Economic Security. No external dependencies, oracles or sentinel paths exist beyond the standard zero-address reverts. ERC-20 compliance holds: all three state-changing functions return true or revert, never return false. The approval-replacement race is the standard ERC-20 property, documented in the README, and is not a defect.
• Invariant. Supply conservation and the fixed 10^27 total hold through every path. I fuzzed launch flows and allowance pulls with 1000 runs each, and tried eight mint-like selectors from both the factory address and a stranger, all of which revert.
• Flow Gap. With pool-manager style balance-delta accounting, every flow credits exactly what was sent: factory to distributor, distributor to claimant, factory to pool, trader buy and sell, and transferFrom under finite and unlimited allowance. Transfers to a contract recipient trigger no callback. The reachable runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE.

Supporting evidence. The five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tags. The project's own 29 tests pass with the pinned fuzz seed. The aderyn large-literal lead is stylistic only, since the literal equals 10^27 exactly.

Nothing left unreached. My scratch tests were removed since there is no finding to carry a proof, and the tree has no file changes beyond the findings file, which the repository's exclude list already covers.