Implemented ConditionalsIMD (CONDITIONAL): 1 billion tokens, 18 decimals, minted once entirely to the deployer. No administrative or additional minting powers.

Dependencies are vendored; deployment parameters, assumptions, and responsibilities are documented.

Verified with Solidity 0.8.26:

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

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

forge build succeeded. All 38 tests passed with the supplied fuzz seed. Only launch.json is changed for submission.

I found no math defects. .imd-findings.json holds {"findings":[]} and a coverage row for each of the three entry points, all marked holds.

What I reviewed. src/ConditionalsIMD.sol is a plain OpenZeppelin v5.1.0 ERC20. Its only code is a constant INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18 and one _mint(msg.sender, INITIAL_SUPPLY) in the constructor. I traced approve, transfer and transferFrom through the library's internal functions. I also downloaded the five vendored library files from the upstream v5.1.0 tag, and they are byte-identical.

Math Precision guide.

• There is no division, rounding, scaling between units, narrowing cast, shift or bitmask anywhere in the code.
• The constant works out to exactly 10^27, which matches the 1,000,000,000-token supply with 18 decimals, and decimals() returns 18.
• The two subtractions that skip overflow checks can't wrap, because each one is preceded by a check that reverts first (balance below the amount, or allowance below the amount).
• The unchecked additions to a receiver's balance can't overflow, because no balance can exceed the total supply, and the supply is fixed after the constructor.

Boundary guide.

• Amounts of 0, 1 wei and the whole supply move exactly. One unit over a balance or allowance reverts.
• Sending to or approving the zero address reverts.
• A maximum (type(uint256).max) allowance is never reduced, which is the library's intended behaviour.
• There are no external calls, payable functions, special-address branches or byte decoding to check.

Numerical Gap guide. No value is computed, so there are no seams. The total supply always equals the sum of balances, and nothing after deployment can mint or burn.

Static analysis lead. Aderyn flagged a large numeric literal at line 10. I checked it: the value is correct and nowhere near the uint256 limit, so I didn't report it.

Checks run. forge test passes all 38 existing tests, including the invariant test against an independent ledger (128 runs, 8,192 calls). I wrote no proof tests because there was nothing to reproduce. Nothing in my area was left unreached. Other areas, such as the launch's pool and distributor flows, were not my assignment. Since the token has no special transfer rules, nothing in my area affects them.

No files in the repository were changed; git status is clean.

The review is complete. The findings file holds an empty findings list and a coverage record, which is the honest result for this code.

Outcome: no defects found. ConditionalsIMD is a 17-line wrapper over OpenZeppelin v5.1.0 ERC20 that mints 10^27 minor units to msg.sender once and adds nothing else. Every path in my three guides was traced and holds.

What I checked, by guide

• Execution Trace. Followed transfer, transferFrom and approve from entry to storage through the vendored ERC20 implementation. Zero-address checks, the balance check before the unchecked subtraction, allowance consumption, the unlimited-allowance branch, and revert atomicity all behave as the README states. There are no external calls, callbacks, sentinel branches, payable paths or bytes decoding.
• Periphery. Downloaded the OpenZeppelin v5.1.0 tarball and byte-compared all five vendored files. They are unmodified and the archive hash matches DEPENDENCIES.md. Context uses plain msg.sender, so there is no meta-transaction path.
• First Principles. The constructor takes no arguments and mints to the immediate caller, so under CREATE2 the factory receives the whole supply. No mint, burn or admin selector exists in the ABI. A reachable-opcode scan of the compiled runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT or outbound CALL. Storage holds only the five standard ERC20 slots.

Checks run

• Project suite with the pinned fuzz seed: all 38 tests pass, including the stateful invariant run.
• Formatter check passes.
• Seven scratch probes of my own for CREATE2 deployment, repeated pulls against one allowance, max allowance survival, value rejection and storage layout. Six passed. The one failure was a wrong expectation in my probe about which custom error a transfer from the zero address raises. It reverts either way, so this is not a defect. The scratch directory has been removed.

Static-analysis lead. The aderyn "large numeric literal" note on the supply constant is style only. The suite asserts the literal equals 10^27, the manifest's totalSupply in minor units.

Coverage. All three listed entry points are marked holds, plus five invariant rows covering supply constancy, absence of privileged roles and dangerous opcodes, unmodified dependencies and metadata matching the brief. The launch manifest is out of scope here since the repository does not include a launch.json.

The review is complete. The findings file holds an empty findings list and eight coverage rows, and the scratch directory is removed.

Result: no defects found in the assigned area. ConditionalsIMD is a 17-line contract that inherits unmodified OpenZeppelin v5.1.0 ERC20 and mints exactly 10^27 units to msg.sender once in the constructor. It has no owner, mint, burn, pause, fee, exemption list, external call or payable path.

What I verified:

• Vendored library integrity. The upstream v5.1.0 archive hash matches DEPENDENCIES.md, and all six vendored OpenZeppelin files are byte-identical to upstream.
• Economic Security guide. There is no external dependency, oracle, price-dependent operation, fee formula or shared cap to break. ERC-20 behavior at boundaries, including zero value, max uint, self-transfer and zero addresses, is standard OpenZeppelin and matches the README.
• Invariant guide. Sum of balances equals total supply forever. The only mint is in the constructor, no burn path exists, and transfers to the zero address revert. A 1,024-run scratch fuzz over eight holders kept the sum exact.
• Flow Gap guide. The token makes no periphery calls, so no seam exists inside it. Every transfer moves exactly the requested amount, so the swarm share, claims, pool seed and swaps cannot arrive short.
• Runtime bytecode. An opcode walk using the protected floor's algorithm found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE in reachable code.
• Static-analysis lead. The aderyn large-numeric-literal note is a style remark. The literal is a compile-time constant equal to the manifest supply.

Coverage rows mark all three entry points, approve, transfer and transferFrom, as holds, plus five invariant rows. The one thing I could not run is the real protected harness with the Uniswap v4 PoolManager, since its sources are not in this tree. That limitation is recorded in the notes field.

The review is complete. No defects found in the assigned area.

Result: .imd-findings.json holds an empty findings list and eight coverage rows, one for each of the three listed entry points plus the constructor and four invariants. Only that file was created; the scratch test I used was removed and the tree is otherwise untouched.

What the token is. ConditionalsIMD is a 17-line contract that inherits OpenZeppelin v5.1.0 ERC20 and mints 10^27 units to msg.sender once in the constructor. The compiled ABI exposes only the standard ERC20 functions and one constant view. There is no owner, initializer, mint, burn, pause, blacklist, hook, receive or fallback, and no delegatecall or selfdestruct anywhere in src or the vendored library.

What I checked against the Access Control, Asymmetry and Trust Gap guides:

• Permission map: every state write is keyed on msg.sender's own balance or allowance row. The deployer, which is the factory in production, holds no authority over other holders after the mint.
• Inconsistent guards: each storage variable has exactly one writer path, so there is no weaker parallel route.
• Paired-function symmetry: transfer and transferFrom both end in the same internal update with identical validation. The only difference is the allowance spend, which is the intended behaviour, and the unlimited-allowance sentinel is standard.
• Trust gap on launch flows: with no fees, burns or exemption list, factory-to-distributor, claim, seed and trader swaps all move exact amounts, which is what the protected floor requires.
• Supply chain: I diffed the five vendored OpenZeppelin files against upstream v5.1.0 and they are byte-identical.
• Static analysis lead: the aderyn large-numeric-literal note is style only. The literal evaluates to exactly the manifest supply.

Verification run: the project's 38 tests pass with the pinned fuzz seed, and seven adversarial access probes I wrote in test/scratch all passed before I deleted them. The approve front-running race inherent to ERC20 is documented in the README and is a known property of the standard, not a defect of this code, so it is not reported.

Added 20 tests and strengthened invariants for failure paths, allowance boundaries, revocation, and balance conservation.

Validation passed:

• forge build
• forge test with the required seed: 58 passed
• 32,768 invariant calls, no unexpected reverts

All changes are under test/. No implementation defects found.

The review is complete and .imd-findings.json is written. No code defects were found.

What was checked

• The token is a 17-line contract: unmodified OpenZeppelin v5.1.0 ERC20 plus a no-argument constructor that mints 10^27 units once to the deployer. The six vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 tarball, whose SHA-256 matches DEPENDENCIES.md.
• All three entry points (approve, transfer, transferFrom) were traced through the OpenZeppelin source and exercised in a scratch Foundry test. Reverts, exact-amount delivery, finite versus unlimited allowance behaviour, and the absence of fees, hooks or external calls all behave as the brief requires.
• Deployment via CREATE2 from a factory contract leaves the whole supply with the factory. Creation and runtime code are far below the size limits, and the reachable runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The ABI exposes only ERC-20 functions and a constant view. There is no mint, burn, pause, blacklist, owner or receive path, so the protected floor's admin probes cannot change supply or freeze a holder.
• The project's own 58 tests pass with the pinned fuzz seed. launch.json matches the code and the schema rules.
• The aderyn "large numeric literal" lead is the intentional supply constant and is not a defect. The four specialists and the tester reported nothing, so there was nothing to merge or drop.

Reported

One info finding: README line 27 says the repository does not supply a launch.json, but the manifest step has since added one to the tree. This is documentation drift with no behavioural effect.

The coverage record marks all three listed entry points as holds, plus four extra rows for the constructor and supply, privileged-entry-point absence, the static-analysis lead, and the manifest. The scratch test directory was removed, so the working tree is unchanged apart from the findings file.