Done. The Conditionals (COND) token is built, tested and documented as a root-level Foundry project.

What was delivered

• src/ConditionalsToken.sol: an unmodified OpenZeppelin v5.4.0 ERC-20 whose constructor mints the whole supply to msg.sender. Name Conditionals, symbol COND, 18 decimals, supply 1,000,000,000 tokens. No constructor arguments, no owner, no mint, no pause or blocklist, no tax, no external call in the constructor. The Solidity identifier is 17 characters, within the 32-character launch limit.
• test/ConditionalsToken.t.sol: 33 tests covering metadata and supply, success and failure paths of transfer, approve and transferFrom with the exact custom errors, the launch flows arriving whole, every mint and privileged-call signature the protected floor probes, the floor's runtime opcode scan, and five fuzz tests for conservation of supply.
• script/DeployConditionalsToken.s.sol: a deploy function with no configuration and no environment reads, which the tests call directly.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none" and cbor_metadata = false, disables ffi and grants no filesystem permissions. remappings.txt points at the vendored libraries.
• lib/: forge-std v1.11.0 and the five-file ERC-20 subset of OpenZeppelin v5.4.0, copied as plain files with their licences and a lib/README.md recording versions. No git submodules.
• README.md: behaviour, assumptions, deployment parameters, an empty "After launch" section since nothing is settable, operational responsibilities, and build instructions.

Verification

All of forge build, forge fmt --check and forge test pass, with the test run done in an empty environment using the verifier's fuzz seed. A scratch test also confirmed the token deploys through CREATE2 from a factory stand-in with the full supply held at the factory, and the built runtime contains no metadata hash. Slither was not available on this machine and was not run.

Not done, by design

No launch.json was written, nothing was committed to git, and no deployment or broadcast was performed. Those belong to the manifest and launch steps.

Created launch.json with the exact supply, economics, pool settings, and empty constructor/application arrays. Only this file changed.

JSON and source consistency checks passed. Both forge build and forge test were attempted but failed because the installed Solidity compiler returned Permission denied (os error 13).

Review complete. The permissions area (Access Control, Trust Gap, Asymmetry) of the Conditionals token has no defects, and .imd-findings.json holds an empty findings list with eight coverage rows.

What I checked

• Access control. The compiled ABI exposes exactly three state-changing functions: approve, transfer and transferFrom. There is no owner, minter, pause, blocklist, burnFrom, initializer, receive or fallback. Empty and unknown calldata revert, and non-payable calls refuse ether.
• Trust gap. No privileged actor exists after the constructor, so there is no seam between authorization and economics to exploit. The deployer holds the supply by design and has no standing over other holders. A pull from a holder by the factory, by the token itself, or by the holder without self-approval all revert with ERC20InsufficientAllowance.
• Asymmetry. transfer and transferFrom produce identical post-state for the same from, to and value. Allowances are written only in the caller's own row, spent exactly once, and are not replayable. There is no fee, burn or exemption branch, so launch flows to the distributor, pool manager and remainder address arrive whole.
• Dependencies. All five vendored OpenZeppelin files hash identically to the upstream v5.4.0 tag. Context returns plain msg.sender with no forwarder path.
• Static-analysis lead. The aderyn large-literal note at line 25 is a compile-time constant equal to the manifest supply. Not a defect.

Verification run

Suite	Result
Project tests, default and verifier fuzz seed	33 passed
Scratch permission probes, six tests incl. fuzz	6 passed

The scratch tests were removed after running, and no tracked file was changed.

Outside the area I found nothing severe to report. The only observation is a design trait rather than a defect: a plain ERC-20 approve carries the standard front-running race on allowance changes, and no permit or increase/decrease helpers exist. That matches the requester's stated intent of an unmodified OpenZeppelin ERC-20, so I recorded it here and not as a finding.

The review is complete. The findings file at .imd-findings.json reports no defects and covers all three entry points.

Outcome: ConditionalsToken is a clean fixed-supply ERC-20. Nothing in the control-flow area fails, and I found no severe defect outside it either.

What I checked, by guide:

• Execution Trace. Traced approve, transfer and transferFrom from entry to final storage write. Zero-address sentinels revert before any state change. Spending allowance before the balance check is rolled back atomically on revert. Infinite allowance is not decremented and max minus one is. No payable, fallback or receive path exists, so value and unknown selectors are refused.
• Periphery. All five vendored OpenZeppelin files hash identical to upstream v5.4.0, so Context returns the raw msg.sender and no meta-transaction sender extraction exists. The compiled ABI has exactly three non-view functions and the runtime code contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• First Principles. The constructor mints the exact manifest supply to its direct creator, takes no arguments and makes no external call. Self-transfers, whole-balance transfers, max-uint amounts, short calldata and a contract deployer all behave as specified. Supply is conserved under fuzzing across transfer and transferFrom interleavings.

Static-analysis leads. Slither reported nothing. Aderyn's large-literal note on line 25 is the compile-time supply constant, which evaluates to the manifest value exactly, so it is not a defect.

Trust notes, not findings. The standard ERC-20 approve race applies, as it does to every OpenZeppelin token. The deploy script is for local use only and the launch does not run it.

Verification. The project's 33 tests pass, formatting is clean, and my 14 scratch probes passed before I removed the scratch directory. The working tree is unchanged apart from the findings file.

The review is complete. The findings file is in place, the working tree is otherwise unchanged, and the scratch tests have been removed.

Result: no defects in the math area. The file .imd-findings.json holds an empty findings list and seven coverage rows, all holds.

What the token is. One contract, ConditionalsToken, inheriting the OpenZeppelin v5.4.0 ERC-20 with a no-argument constructor that mints the fixed supply to the deployer. I confirmed the five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 release, so the arithmetic under review is exactly OpenZeppelin's.

Math Precision pass. The contract contains no division, no downcast, no scale conversion and no fee or share formula. The supply constant evaluates exactly to 10^27 at compile time under checked arithmetic, which I confirmed with BigInt, and it fits in 90 bits. The unchecked subtraction in _update is guarded by the preceding balance check, and the unchecked additions are bounded by total supply. The aderyn large-numeric-literal lead is that constant and is not a defect.

Boundary pass. There are no external calls, no payable function, no receive or fallback, and no bytes decoding. The only sentinel branches are the zero-address checks, and I walked both sides of each. A scratch test exercised transfers of zero, the whole balance, supply plus one, max uint256, self-transfer of the whole balance, allowance at exactly the amount, max minus one and max, transferFrom with from equal to to, and a zero sender. Every case reverted or succeeded as the standard specifies.

Numerical Gap pass. The two invariants, sum of balances equals total supply and total supply never changes after construction, hold under fuzzed multi-hop transfer chains, and no mint or burn is reachable after the constructor.

Coverage. All three listed entry points (approve, transfer, transferFrom) are holds, plus rows for the supply invariant, the constructor behavior against the protected launch floor, the boundary enumeration, and the static-analysis lead. The project's own 33 tests and forge fmt --check pass. Slither and Mythril were not run here; only Foundry was available.

I added invariant tests and edge-case tests for the Conditionals (COND) token, and found no defects. forge build succeeds, and forge test with the verifier's fuzz seed passes all 47 tests: the 33 that were already there, 13 new edge-case tests and 1 invariant suite. Nothing is committed yet.

The contract: src/ConditionalsToken.sol is the unchanged OpenZeppelin v5 ERC-20. It mints 1,000,000,000 × 10¹⁸ to the deployer once, in the constructor, and has no owner, mint, pause, blocklist, tax or upgrade path. Because nothing failed, I did not write .imd-findings.json.

Invariant tests (test/ConditionalsToken.invariant.t.sol):

• Setup: a handler drives the token with six accounts, one of which is the token contract itself. It keeps its own record of what every balance and allowance should be after each call.
• Normal calls it makes: transfer, transfer of a whole balance, approve (including the maximum value), transferFrom, and a send followed by sending the same amount back. After each one it checks the exact amounts that moved.
• Failing calls it makes: sending more than the balance, sending to address zero, approving address zero, pulling more than the allowance, and pulling more than the balance. Each must revert with the exact expected error.
• What must hold after every sequence:
  • the supply never changes;
  • balances add up to the supply;
  • balances and allowances match the handler's record;
  • no failing call ever had an unexpected outcome;
  • nothing ends up at address zero, the handler or the test contract, and the token never holds ETH;
  • name, symbol and decimals stay the same.
• Settings: 256 runs at depth 64, set in the test file. The tests are also set to fail on any handler revert, so a broken check inside the handler can't be silently skipped. The seeded run made 16,384 calls with 0 reverts.
• Check on the harness: I ran a copy with a deliberately wrong record and the invariants failed. So the checks really do catch errors.

Edge-case tests (test/ConditionalsToken.edges.t.sol):

• An owner needs an allowance even to transferFrom their own account.
• A zero-amount transferFrom needs no allowance.
• Pulling from address zero reverts.
• Spending an allowance emits only the Transfer event, not an Approval.
• The whole supply can move through a maximum allowance, which is never reduced; an allowance one below the maximum is reduced normally.
• Approving zero takes the allowance away.
• A failed pull leaves the allowance and balances unchanged.
• Tokens sent to the token contract are kept there, not burned.
• Sending to yourself more than you hold reverts, and so does sending the maximum possible amount.
• Two fuzz tests, 1,000 runs each: approve always sets the exact value, and sending tokens and back restores both balances.

The economics audit of Conditionals (COND) found no defects. .imd-findings.json has an empty findings list and 10 coverage rows: all 3 listed entry points and 7 extra rows for invariants, flows and dependencies, all holds. No repository files changed, and all simulations ran in temp directories that I've since removed.

What was checked

Token code: ConditionalsToken is OpenZeppelin v5.4.0 ERC20 plus a constructor that mints once. The five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tag.

Economic Security guide

• Token behaviour: no fee, rebase, blacklist or pause exists to misbehave.
• Calls that don't exist: permit, burn, burnFrom, flashLoan, empty calldata and unknown selectors all revert rather than silently succeeding.
• Zero address: transfers to it, approvals for it as spender, and transferFrom(0,x,0) all revert.
• Capacity and atomic extraction: there is no shared cap to starve, and no price-dependent function in the token. In the pool, a buy then sell never made a profit over 256 fuzz runs (1e6 wei to 100,000 IMD in, both currency orders).

Invariant guide

• Supply: the sum of balances stays equal to totalSupply, which stays at 1e27.
• Fuzzing: the invariant fuzz ran 8,192 calls with 0 handler reverts and no violation. That covers exact balances, allowances (including max and max-1), and transfers to self or to the token.
• Static analysis lead: the aderyn literal on line 25 evaluates to exactly 1e27, so it isn't a defect.

Flow Gap guide

• Launch simulation: I ran the exact creation bytecode through the launch against a locally built v4 PoolManager, in both currency orders, at 85% pool share, a 4500 IMD cap and a 12500 fee with tick spacing 60.
• Mainnet fork: the seed, a round trip and a sell-before-any-buy also ran against the real PoolManager and real IMD.
• Result: 10% reached the distributor exactly, the seed stayed within 85%, and the rest reached remainderTo.
• Selling first: selling before any buy returned 0/0 and the seller kept their tokens.

The repository's own suite passed all 33 tests on the verifier's fuzz seed, and forge fmt --check passed.

Coverage limits

• Protected floor tests not run: they need LaunchLiquidity, PoolInitializationGuard, HookFlags and OwnerChecks, which weren't supplied. My simulation used its own seed code, no hook, and a price aligned to my own choice of tick, so the deployer's real price derivation and range are unverified.
• IMD: it worked on the fork at current state and has an owner() (0x047F…54B7). I did not review what that owner can do.
• launch.json: none exists yet, so it wasn't reviewed.
• Other passes: math, permissions and control flow belong to the other specialists; I only touched them where tracing economics reached them.

Leads I rejected

• Remainder and swarm can drain early buyers (trust assumption, not a defect): both allocations are unlocked by the requested economics. In the simulation a buyer put in 100 IMD, then a holder of the roughly 5% remainder sold it all and took out 98.75 IMD. Fixing this would change the economics in the job, which is the requester's decision.
• Script comment is wrong: script/DeployConditionalsToken.s.sol:13 says the caller of deploy() gets the supply, but on a direct call the script contract does (test/ConditionalsToken.t.sol:63 asserts this). run() isn't affected and the launch doesn't use the script, so it's a tooling comment only.
• Transfers to the token's own address succeed and lock the tokens: this only harms the sender, and the README says wrong-address transfers are final.
• approve re-approval race: the spender can take old plus new allowance (100 + 50 = 150 in my test), which is standard ERC-20 behaviour.

I found nothing to report, so .imd-findings.json has an empty findings list and five coverage rows, all marked holds.

What I checked

• Panel input: none of the four specialists or the tester reported a finding. So there was nothing to reproduce, merge or re-rate.
• The token code: src/ConditionalsToken.sol is a plain OpenZeppelin v5.4.0 ERC20. The constructor takes no arguments and mints exactly 1e27 (1,000,000,000 × 10¹⁸) to msg.sender. Nothing is overridden, and there is no owner, mint, burn, fee or pause function.
• The OpenZeppelin library: I read approve, transfer, transferFrom, _update, _approve, _spendAllowance and Context in lib/. They match the unmodified library. Transfers move exactly the amount asked, so the factory's transfers, the pool seed and swaps all arrive in full.
• Deployability: the runtime bytecode is 2,167 bytes, well under the 24,576 limit. Scanning it found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE. decimals() returns 18, as the manifest says.
• launch.json: the token entry matches the code: an empty constructorArgs for the no-argument constructor, the right supply, name, symbol and decimals, and no application contracts.
• What I couldn't check: the job's original economics weren't in front of me. So I could not confirm that the manifest's economics block was copied from the job word for word.
• Tests: forge test passed all 47 tests in the 3 project suites.

Dropped lead: aderyn flagged a "large numeric literal" at src/ConditionalsToken.sol:25. That line is 1_000_000_000 * 10 ** uint256(TOKEN_DECIMALS), the correct supply, written readably. It's a style flag, not a defect.

Coverage rows: all three entry points (approve, transfer, transferFrom) are holds. Two invariant rows are also holds: the supply is fixed and minted once to the deployer, and the contract deploys with no forbidden opcodes.

I changed no tracked files. Building left out/ and cache/, which git ignores.