The Conditionals (COND) token is built, tested, documented and committed on main as commit 589fc8c.

What was delivered

• src/ConditionalsToken.sol: a fixed-supply ERC-20 on unmodified OpenZeppelin ERC20 v5.4.0. Name Conditionals, symbol COND, 18 decimals, 10^27 minor units minted once to msg.sender in the constructor. No constructor arguments, no owner, no mint, pause, blacklist, fee, upgrade, delegatecall or selfdestruct, so it meets every item in the pinned protected floor.
• foundry.toml: solc pinned to 0.8.26, bytecode_hash = "none", optimizer on, ffi off, no fs permissions, remappings inline.
• lib/: forge-std v1.11.0 and the five OpenZeppelin files ERC20 needs, committed as plain files with licences. No submodules, no nested git metadata.
• script/DeployConditionals.s.sol: a reference script whose deploy() holds the whole logic and is called directly by a test. It reads no environment.
• test/ConditionalsToken.t.sol: 31 tests covering metadata, exact supply, minting to an EOA and through CREATE2 from a factory stub, transfer and transferFrom success and failure paths with exact error selectors, the launch flows arriving whole, the full admin-selector sweep from a stranger and the deployer, bytecode opcode scan, EIP-170 size, and four fuzz tests for supply conservation and allowance handling.
• README.md: behaviour, deployment parameters for the Robinhood Chain launch, an empty "After launch" section since nothing is configurable, assumptions, operational responsibilities and security notes.

Verification results

Check	Result
forge build (clean, offline)	passes
forge test with the verifier's fuzz seed	31 passed, 0 failed
forge fmt --check	passes

Not run: Slither is not on this machine. The contract adds only three constants and a decimals() override on top of OpenZeppelin's ERC20, so none of the six rejecting detectors have code to match. The README states this.

Nothing is left open for the requester. The brief fixed every value, and the token has no owner-settable settings.

Done. I wrote launch.json for the Conditionals (COND) custom token launch, and it is the only changed file.

What the manifest describes, matching the accepted tree:

• Token is the Solidity contract ConditionalsToken, name Conditionals, symbol COND, 18 decimals. Its constructor takes no arguments, so constructorArgs is empty.
• totalSupply is the contract's TOTAL_SUPPLY constant, one billion tokens in minor units, minted once to msg.sender.
• Application contracts list is empty. The accepted tree contains only the token and its deploy script, so nothing else is named.
• Pool and economics are copied exactly as the launch gives them: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's verbatim economics object.
• Notes describe the token's fixed supply, lack of any privileged or fee logic, and the absence of application contracts and initialization calls.

Verification results:

• A script check confirmed the JSON parses, uses only the schema's six top-level keys, and that the supply string equals the contract constant. Notes are well under the character limit.
• The build compiled cleanly with solc 0.8.26.
• All 31 existing tests passed with the verifier's fuzz seed.
• Git status shows launch.json as the only new file. No configuration, library or workflow files were touched.

The review is complete. The math, boundary and numerical-gap passes found no defects in the Conditionals token, and .imd-findings.json holds an empty findings list with nine coverage rows.

What was checked

• Source and dependency integrity. The token is 41 lines over OpenZeppelin ERC20. All five vendored library files are byte-identical to the upstream v5.4.0 tag, so the arithmetic under review is the audited OpenZeppelin path, not a modified copy.
• Math Precision. The only arithmetic in the project's own code is the compile-time supply constant, which evaluates to exactly 10^27. There is no division, fee, scale conversion or narrowing cast anywhere, so none of the rounding, truncation or downcast failure modes apply. The library's unchecked subtractions are guarded by the balance compare, and the unchecked additions are bounded by the one-time mint.
• Boundary. The contract makes no external calls, has no payable function, no receive or fallback, and decodes no bytes. The only sentinel branches are the library's zero-address checks, which revert on both sides as intended. Scratch tests probed amount zero, the whole supply, supply plus one, max uint, allowance of max minus one, allowance exactly equal to the amount, allowance above balance, self-transfer and transferFrom with from equal to to.
• Numerical Gap. The supply conservation invariant is exact because no precision is ever lost. The launch's ten, eighty and ten percent split of the supply divides with zero remainder, so no dust is stranded at the factory.
• Static-analysis lead. The aderyn large-literal note at line 30 is style only; the literal is correct and matches the brief.

Coverage. All three listed entry points are recorded as holds, with six additional rows for the supply, conservation, decimals, boundary, dependency and static-analysis checks. The existing 31-test suite passes. The scratch tests I wrote were removed, and no repository file was changed.

The economics review of the Conditionals (COND) token found no defects. The findings file is written with an empty list and seven coverage rows, and nothing else in the tree was changed.

What the code is. src/ConditionalsToken.sol is 41 lines: three constants, a constructor that mints the whole supply to msg.sender, and a decimals override. Everything else is OpenZeppelin ERC20 v5.4.0, and I confirmed the five vendored files are byte-identical to upstream by hash comparison.

What I checked against the three guides, all holding:

• Economic Security. No external dependency, oracle, callback, or ether path. No fee, tax, rebasing, pause, or blacklist, so no "assumed versus received" gap exists. Sentinel inputs revert: transfer to the zero address and approve of a zero spender. The ERC-20 approve race is present and reproduced, but it is the standard v5 semantics the README documents, not a defect.
• Invariant. Sum of balances equals totalSupply equals 1e27 after fuzzed 40-step random transfer chains. Supply can neither grow nor shrink: the only mint is the constructor, there is no burn, and burn-to-zero reverts. Self-transfer is a no-op. Constants match the manifest: 18 decimals, supply 1000000000000000000000000000, no constructor arguments, contract name 17 characters.
• Flow Gap. The 10/80/10 launch split leaves the factory at zero and arrives whole at each destination. A PoolManager stand-in doing a low-level take and a sync/settle-style balance delta both move exactly the stated amount, so the seed, a buy, a sell, and a distributor claim all deliver in full.

Leads from static analysis. Slither reported nothing. Aderyn's large-numeric-literal line is the readable supply constant and is not a defect.

Coverage. All three entry points (approve, transfer, transferFrom) are marked holds, with four additional invariant rows. Nothing was left unreached. The project's 31 tests pass, and my 5 scratch tests passed before I removed the scratch directory.

One open item outside my area, not a finding. The build uses solc 0.8.26 with its default cancun target, so the bytecode contains PUSH0. That is fine on any current Arbitrum Orbit chain, and I had no chain evidence suggesting otherwise, so I did not report it.

I tested the Conditionals (COND) token and found no defects, so there is no .imd-findings.json. forge build succeeds and forge test passes all 55 tests (the 31 already there plus 24 new ones) using the verifier's fuzz seed.

What the contract is: src/ConditionalsToken.sol is plain OpenZeppelin ERC20 v5.4.0. The vendored copy's transfer, allowance and approval code is the standard library, and the token only adds three constants, a constructor that mints 10²⁷ (one billion with 18 decimals) to the deployer, and a fixed decimals() of 18. It has no owner, mint, burn, fee, pause or way to receive ether. The edge cases I tried all behaved the way the standard library should.

New: test/ConditionalsToken.invariant.t.sol

• A test contract makes random sequences of calls across six accounts: the deployer, a distributor stand-in, the remainderTo address and three others. Alongside the token it keeps its own record of every balance and allowance.
• It also makes calls that must fail: sending more than the balance, sending to the zero address, spending beyond or above an allowance, approving the zero address, and sending ether. For each it checks that the call reverts with the exact expected error and changes nothing.
• After every call it checks seven rules:
  • the total supply never changes;
  • the six accounts' balances add up to the whole supply;
  • every balance matches the independent record;
  • every allowance matches the independent record;
  • no call that should fail succeeded or failed with the wrong error;
  • the token never holds ether;
  • the name, symbol and decimals never change.
• It ran 256 sequences of 64 calls each (16,384 calls), with no unexpected reverts. Each of the nine call types ran about 1,800 times, so every rule was checked against real activity.

New: test/ConditionalsToken.edges.t.sol (20 unit tests and 3 fuzz tests at 1,000 runs) covers inputs the existing suite didn't:

• Zero address: the zero address as sender or approver; pulling from the zero address, including with an amount of 0, which reverts with ERC20InvalidApprover.
• Error order: when a pull has both no allowance and a zero-address receiver, the allowance error is the one reported.
• Self pulls: a holder needs an allowance to pull from their own account, and pulling to the same account spends allowance but keeps the balance.
• Approvals:
  • approve replaces the old allowance rather than adding to it, and approving 0 revokes it;
  • an allowance only works in the direction it was given;
  • an allowance can exceed the balance, but a pull is still capped by the balance;
  • an allowance of max − 1 still goes down, and an exact allowance is fully used up.
• Logs and deployments:
  • a pull emits only a Transfer log;
  • separate deployments don't share balances;
  • unknown functions revert.

The two files are staged but not committed: git commit failed because no git author name or email is configured on this machine. I didn't set one, since that is the machine's configuration. Whatever uploads this run needs to commit them, or set an identity and run the commit.

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 nine-row coverage record.

What was reviewed

• src/ConditionalsToken.sol is a 41-line wrapper over OpenZeppelin ERC20 with a constructor mint and a decimals() override. The compiled ABI has exactly three state-changing selectors: approve, transfer and transferFrom.
• The five vendored OpenZeppelin files hash identically to upstream v5.4.0, so every entry point runs unmodified library code.
• The project builds on solc 0.8.26 and its 31 tests pass. Formatting is clean.

Access Control pass. There is no role, modifier, initializer, proxy, delegatecall, selfdestruct, receive or fallback. Every storage slot has exactly one writer path per entry point, and each is keyed on the caller: balances move only from msg.sender or from an account that approved msg.sender, and allowances are written only in the caller's own row. The deployer keeps no power after the constructor returns.

Asymmetry pass. The paired writers of the allowance mapping, approve and the internal spend path, validate the same zero-address conditions and differ only in event emission, which is OpenZeppelin's documented v5 behavior. Transfer and transferFrom share one internal path, so neither branch skips a check the other runs. The mint and burn branches of the balance update are unreachable from the public surface because both zero-address sides are rejected first, keeping total supply constant.

Trust Gap pass. The token has no settable parameter, fee, price or recipient, so no seam between authorization and value flow exists. The only trust assumption is the launch design itself: the factory holds the full supply at deployment and distributes it.

Verification run. Beyond reading, I executed a scratch Foundry probe of seven tests covering third-party allowance spending, factory residual power, zero-address actors on all three entry points, self-transferFrom, event asymmetry and a fuzz over supply constancy. All passed, and the scratch directory was removed afterwards.

Static analysis leads. Slither reported nothing. Aderyn's low-severity large-numeric-literal note on line 30 is a compile-time constant equal to the manifest supply and is style only.

Not reached. Nothing in the assigned area was left unexamined. The x-ray deployment-phase and Trail of Bits inventory items were also checked. The deploy script's run() broadcasts from whatever signer forge is given, which the README documents as a local reference only and is outside the launch path.

The review is complete and the findings file is written and validated.

Outcome: no defect found in the control-flow area. The token is a 41-line wrapper over an unmodified OpenZeppelin v5.4.0 ERC20, and every entry point behaves as the README and manifest state. .imd-findings.json holds one informational note and nine coverage rows.

What I checked, by guide:

• Execution Trace. Traced approve, transfer and transferFrom through _approve, _transfer, _spendAllowance and _update. Allowance is spent before the balance check and both revert atomically. The max-uint allowance sentinel is never decremented and max-1 decrements normally. There are no external calls, hooks or partial writes, so a hostile receiver cannot reenter or block a transfer.
• Periphery. All five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tag. An opcode scan of creation and runtime bytecode found no CALL-family, DELEGATECALL, CALLCODE or SELFDESTRUCT. The runtime does use PUSH0 and MCOPY, so I ran a PUSH0+MCOPY init-code eth_call against a public Robinhood Chain RPC (chain id 4663). It executed, and ArbSys reports a Cancun-capable ArbOS.
• First Principles. The constructor mints exactly 1e27 to msg.sender, not tx.origin, under both CREATE and CREATE2. That equals the manifest's totalSupply string. No mint, burn, owner, pause or rescue path exists in the ABI. The aderyn large-literal lead evaluates to the correct value and is style only.

The one finding (info). approve carries the standard ERC-20 allowance race: approve 100, spender front-runs 100, owner approves 50, spender spends 50 more, 150 total. This is inherent to the standard and the author's declared v5 semantics, so it is recorded as a holder trust note, not a defect. No change is needed for launch.

Verification. The project's 31 tests pass. I confirmed each traced claim with seven scratch tests, all passing, then deleted test/scratch/ so the tree is as I found it.

Not reached. The protected floor test could not be run locally because it needs v4-core and the launch harness, which are not vendored. The project's own launch-flow test covers the same transfers.

Sources:

• Chainstack: What is Robinhood Chain
• NodeFlare Robinhood Chain RPC endpoint
• Chainstack Robinhood tooling

Review complete. The Conditionals token has no defects; the findings file holds one info-level trust note and a full coverage record.

What I checked

• The token is a 41-line wrapper over OpenZeppelin ERC20 with a no-argument constructor that mints 1e27 to msg.sender and a decimals() override returning 18. It adds no other code.
• All five vendored OpenZeppelin files hash byte-identical to upstream v5.4.0, fetched from GitHub for comparison. The specialists' claim of an unmodified base is confirmed.
• The build succeeds and all 55 project tests pass. My scratch tests confirmed supply, metadata, ether rejection, allowance scoping and code sizes, then were removed.
• Deployability holds: no constructor arguments, no external calls in the constructor, creation code and runtime far under the protocol limits, and the manifest uses only schema keys with the exact supply.

Specialist findings

• Four specialists and the tester reported nothing. The flow specialist reported the standard ERC-20 approve overwrite race as info. I reproduced it: approve 100, spend 100, approve 50, spend 50 leaves the sink with 150. It is the behaviour of the ERC-20 standard itself and of every OpenZeppelin v5 token, so I kept it as an info trust note, not a defect, with the reproduction and the exact line in the vendored ERC20.sol. No merge was needed since it was the only finding.
• The aderyn large-numeric-literal lead is the supply constant written with underscores and a power of ten. It equals the manifest value exactly and is not a defect.

Coverage

All three entry points are answered: approve points to the info note, transfer and transferFrom hold. Three invariant rows cover fixed supply, factory deployability and exact launch flows.

The working tree is unchanged apart from the required .imd-findings.json.