Economics audit of Conditionals (COND): no defects found, but no tests were run

I found no defects by reading the code, and .imd-findings.json has an empty findings list. Nothing was executed, because every Bash call failed with Sandbox is required but failed to initialize: Failed to create bridge sockets. That sandbox setting is yours to change.

The code reviewed: src/Conditionals.sol is a 16-line contract on top of OpenZeppelin (OZ) 5.1.0's ERC-20, with no overrides. Its constructor mints 10^27 units to msg.sender once. I read the vendored ERC20.sol and Context.sol in full, and the code behaves as OZ's ERC-20 should.

Coverage by guide

Guide	Checked	Result
Economic Security	Dependencies, token misbehaviour, atomic extraction, ERC-20 compliance, sentinel addresses, shared caps, features used against the token	The token has no external calls, oracles, fees, rebasing, hooks or caps. address(0) is rejected as recipient and spender. There is nothing to extract value from.
Invariant	Conservation, state couplings, supply bounds, view against write, timers, emergency modes	The only _mint call is in the constructor and nothing calls _burn. _update moves equal amounts, and a failed transferFrom reverts the allowance spend too. The token has no timers or modes.
Flow Gap	The four seams, and the flows to the distributor, the pool seed and swaps	Each transfer moves exactly the stated amount, with no callback partway through. The token never calls out, so I found no seam to exploit.

Leads I checked and left out

• Aderyn's large numeric literal (line 10): the value is correct at 10^27, so this is only style.
• Zero-value transferFrom: anyone can emit Transfer(victim, x, 0) without an allowance, which can be used for address poisoning. No value moves, and ERC-20 requires zero transfers to be treated as normal.
• approve replacement race: this is standard ERC-20 behaviour and the README already documents it.
• No Approval event on allowance spend: ERC-20 doesn't require it, and the README documents it.

Not verified

• Test suites: the project's unit, fuzz and invariant tests didn't run, and no scratch tests were compiled. The holds rows rest on reading the code, and each one says so.
• Protected tests: they import v4-core, LaunchLiquidity, PoolInitializationGuard, HookFlags and OwnerChecks, none of which are in this tree, so they couldn't run here anyway.
• Live launch path: the actual v4 seed and swaps, the factory and deployer price derivation are marked unreached. Nothing in the token should block them, but that is reasoning, not a test.
• launch.json: it doesn't exist yet, which is expected this early, so there was no manifest to check.
• Dependency hashes: I didn't check the vendored files against dependencies.lock.json, which needs a shell. The match to OZ 5.1.0 is from reading ERC20.sol and comparing it with what I know of that release, not from a byte comparison. I read only the first 30 lines of IERC20.sol and didn't open the other two OZ interface files.

The three listed entry points each have a row. Five more rows cover the invariants and economics I checked, including the unreached one. No helpers were used; I made all three passes myself. The empty findings list is not proof the code is defect-free, so I recommend running forge test and the lockfile hash check once the sandbox works.

The review is complete. The findings file is written and the tree is otherwise unchanged.

Result: no defects in the math, boundary or numerical-gap area. The findings list is empty and all three entry points are marked as holding, with seven coverage rows in .imd-findings.json.

What I checked:

• Source integrity. The token is a 13-line wrapper over OpenZeppelin ERC20. The vendored ERC20 and Context files hash identically to the upstream v5.1.0 tag, so the arithmetic reviewed is the audited upstream code.
• Math Precision. The token has no division, no downcast, no scale conversion and no unchecked block of its own. The supply constant evaluates at compile time to exactly 10^27, which I asserted against the plain decimal literal. The aderyn large-literal lead is cosmetic.
• Boundary. Transfer at exactly the balance passes, balance plus one and max-uint revert with the ERC-6093 error. An allowance of max-uint is infinite, while max-uint minus one is finite and consumed exactly. Both zero-address arms of the internal update function are unreachable from the public entry points, so mint and burn cannot be triggered after construction. There are no external calls, payable paths or bytes decoding.
• Numerical Gap. Conservation of supply holds exactly under any sequence, including self-transfers through an allowance, since every state change is an exact add or subtract of the same value. The project invariant suite and my own fuzz probe both confirmed it.

The existing suite passes with 33 tests. My scratch probes in test/scratch passed 8 of 8 after I fixed a prank-ordering mistake in my own test, and I deleted them since no finding carries a proof. Nothing outside the assigned area turned up as severe, so no out-of-area finding was reported.

Review complete. The findings file is written with no defects and a full coverage record.

Outcome: the Conditionals token has no permission defect in the Access Control, Trust Gap or Asymmetry areas. The contract at src/Conditionals.sol is a 16-line subclass of the vendored OpenZeppelin v5.1.0 ERC-20. It adds only a constant and a constructor that mints the whole supply once to the deployer.

What I checked, against each guide:

• Access Control. The only state-changing entry points are approve, transfer and transferFrom. Each is scoped to the caller through Context's plain msg.sender, which is not overridden and has no meta-transaction forwarder. There is no owner, role, initializer, proxy, pause, blacklist, freeze, seize, burnFrom, receive or fallback. The mint and burn helpers are internal and unreachable after construction, so supply cannot grow and no privileged hand can move or freeze a holder's balance. The deployer gets no bypass: a factory calling transferFrom on a holder without approval reverts with an insufficient-allowance error.
• Trust Gap. No privileged actor, setter, fee, price or recipient exists, so no access-times-economics or access-times-asymmetry seam is reachable.
• Asymmetry. transfer and transferFrom share the same balance-update path and differ only by the allowance check. The missing Approval event on allowance consumption is standard OpenZeppelin v5 behaviour and is disclosed in the README. Zero-value transferFrom without allowance succeeds and emits a zero Transfer, which is standard and intentionally tested by the author, so I did not report it.
• Launch floor. Supply is exactly 10^27 minted to the factory, decimals are 18, the contract name is 12 characters, the constructor takes no arguments, and the vendored library files match upstream line for line. The aderyn large-literal lead evaluates to the correct supply and is not a defect.

Limitation to note. The bash sandbox failed to initialize on every attempt, so I could not run forge build, the existing unit, fuzz and invariant suite, the opcode-scan tests, or the SHA-256 check of the vendored files against the lock file. Every verdict rests on reading the source in full. That is recorded as an explicit unreached row in the coverage record so the judge can weigh it. No scratch tests were written because no critical or high finding was substantiated.

Review complete. The findings file at .imd-findings.json holds an empty findings list and eight coverage rows, all holds.

What was reviewed. The token is a 16-line contract that inherits the vendored OpenZeppelin v5.1.0 ERC20 and mints the full supply once to msg.sender in the constructor. It adds no overrides, no owner, no callbacks, no receive or fallback. I made the three control-flow passes against it and the inherited code:

• Execution Trace. Traced approve, transfer and transferFrom from entry to final storage write. Zero-address sender, receiver and spender all revert before any state change. Debit and credit use the same value, so nothing leaks. The allowance decrement in transferFrom happens before the transfer, but any later revert unwinds it atomically. Self-transfer re-reads storage and leaves the balance unchanged. The mint and burn branches of the internal update function are unreachable after deployment.
• Periphery. Read the five vendored OpenZeppelin files line by line against upstream v5.1.0. Logic, events, custom errors and selectors are unmodified.
• First Principles. The constructor mints exactly 10^27 units, matching the manifest supply, to the immediate deployer, which is the factory under launchCustom. Decimals are the inherited 18. No path can grow supply. The protected floor's admin-selector probes hit no function and revert. Launch flows to the distributor, pool manager and traders move exact amounts with no exemptions needed.

What I could not do. The Bash sandbox failed to initialise on every attempt in this session, so I could not run forge build, forge test, or recompute the SHA-256 values in dependencies.lock.json. Every conclusion above rests on reading the source, not on execution. The coverage rows say so where it matters.

Notes, not defects. The standard ERC-20 approve replacement race and the non-decrementing infinite allowance are inherited OpenZeppelin behaviour and are documented in the README. Aderyn's large-numeric-literal lead is a style note on the supply constant, which is a compile-time checked expression equal to the manifest supply.

Added 17 tests and expanded invariants to eleven randomized actions covering failure paths, allowance boundaries, rollback, and supply conservation.

forge build and all 50 tests pass with the required seed, including 16,384 invariant calls. No defects reproduced. Changes are confined to test/.

Created launch.json matching the accepted Conditionals contract, exact supply, empty constructor arguments, and required pool/economics values.

forge build passed. All 33 tests passed with the supplied fuzz seed. Manifest checks passed; only launch.json is changed for submission.

The review is written to .imd-findings.json with no findings and a full coverage record.

Outcome. The Conditionals token is a bare OpenZeppelin v5.1.0 ERC-20 with a parameterless constructor that mints the fixed supply to msg.sender. No specialist or the independent tester reported a finding, so there was nothing to reproduce or merge. My own pass over the three entry points, the constructor, the bytecode constraints and the manifest found no defect.

Coverage, all traced by reading the source:

• approve only writes the caller's own allowance, rejects a zero spender and returns true.
• transfer moves the exact amount with no fee, burn or exemption, rejects a zero recipient and reverts on insufficient balance.
• transferFrom consumes finite allowances, leaves the max sentinel alone, and reverts atomically so a failed transfer restores the allowance. The deployer has no special path.
• The constructor mints exactly one billion tokens with 18 decimals, matching the manifest's supply, decimals and empty constructor arguments. There is no mint, burn, owner, pause, blacklist, fallback, receive, assembly, DELEGATECALL or SELFDESTRUCT anywhere in the contract or its vendored dependencies.
• The manifest uses only schema keys with correct types, lowercase addresses, and a valid contract name.

One limitation to flag. The Bash sandbox failed to initialize on every attempt in this session, so I could not run forge build or the test suite. Every verdict rests on reading the code, not on executing it. The verdict file records this. Given that the token adds no logic of its own on top of a pinned library, tracing is sufficient here, but the verifier's own run remains the executed confirmation.

The aderyn low about a large numeric literal is the intentional supply constant and is not a defect. The ERC-20 approve race is a standard property, documented in the README, and not a defect of this token.