Clean rebuild, tests, and fmt check all pass. The vendored libraries are plain files with no nested .git directory, and git sees everything as regular untracked content for the harness to pick up.

Delivered: the JURY token as a root Foundry project, with all checks passing.

What was built:

• src/JuryToken.sol is the token. The Solidity name JuryToken is the manifest's contract name, within the 32-character limit, while name() and symbol() both return JURY.
• It inherits OpenZeppelin's ERC20 unchanged and mints the whole supply once to msg.sender in a no-argument constructor. The supply is 1,000,000,000 with 18 decimals, held as the public constant TOTAL_SUPPLY.
• There is no owner, mint, burn, pause, blocklist, fee or ether handling. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT, which my tests check the same way the protected floor does.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", and keeps ffi off with no filesystem permissions.
• forge-std v1.9.7 and the five OpenZeppelin v5.1.0 files ERC20 needs are vendored under lib/ as ordinary files with their licences.
• script/DeployJuryToken.s.sol is a local rehearsal script. Its deploy() function reads nothing from the environment and is tested directly.
• README.md documents assumptions, the manifest values the launch step will use, build settings, operational responsibilities, and states that nothing needs setting after launch.

Verification, run from a clean build with an empty environment and the verifier's fuzz seed:

Check	Result
forge build	passes
forge test	26 passed, 0 failed
forge fmt --check	passes

The tests cover metadata, the single constructor mint from both an EOA and a contract deployer with its Transfer event, transfer and transferFrom success paths, the failure paths for insufficient balance, zero receiver, zero spender and missing or exceeded allowance, the absence of any mint or admin entry point for both a stranger and the deployer, that the deployer cannot move a holder's balance, and fuzzed supply conservation.

Nothing was left out. The launch manifest is not written, as the brief requires, and nothing was deployed or signed.

Created launch.json for JuryToken with the exact supply, empty constructor arguments, no application contracts, and the supplied pool and economics values.

Validation passed against the compiled constructor ABI. forge build succeeded; all 26 tests passed with the supplied fuzz seed. Only launch.json changed.

The review is complete. No defects were found in the Math Precision, Boundary or Numerical Gap areas, and .imd-findings.json holds an empty findings list with a full coverage record.

What the code is. src/JuryToken.sol is OpenZeppelin v5.1.0 ERC20 with a no-argument constructor that mints a compile-time constant of one billion tokens at 18 decimals to the deployer. It adds no arithmetic, no external calls, no payable path, no owner and no override of _update. The three guides' failure modes (rounding direction, zero-rounding, overflow of intermediates, decimal mismatch, downcasts, non-standard token returns, msg.value mismatches, sentinel branches, bytes decoding) have no code to attach to.

What I executed. The project's own 26 tests pass. I wrote and ran a scratch suite of 18 boundary probes, then deleted it since no finding needed a proof. It confirmed:

• The supply literal on line 23 evaluates exactly to 1000000000000000000000000000, which answers the aderyn large-literal lead. It fits below 2^96, so the Uniswap v4 uint128 liquidity path cannot truncate it.
• Transfers of zero, the exact balance, balance plus one and max uint behave as OpenZeppelin specifies. Self-transfers and self-transferFrom do not double a balance. The sum of balances equals supply after fuzzed and repeated transfers.
• Allowance at max uint is never decremented, at max minus one it is decremented, and an allowance shortfall reverts before the balance check.
• Ether and unknown selectors revert since there is no receive or fallback.
• The launch split at this supply is exact with no dust: 10 percent, 88 percent and the 2 percent remainder sum to the supply.

Coverage. All three ABI entry points are marked holds, with five extra invariant rows for the constructor mint, supply conservation, launch split arithmetic, boundary classes and decimals. Nothing in my area was left unreached. One note outside my area, not reported as a finding because the README already documents it: tokens sent to the token's own address are stuck, which is standard ERC-20 behaviour.

The review is complete and found no defects. The findings file at .imd-findings.json holds an empty findings list and eight coverage rows. The working tree is otherwise clean.

What I reviewed. JURY is a 29-line contract that inherits OpenZeppelin ERC20 unchanged and mints one billion tokens with 18 decimals to the deployer in the constructor. I applied the Access Control, Asymmetry and Trust Gap guides from the Pashov reference, plus the launch floor in the protected token test.

What held, by guide:

• Access control. The compiled ABI exposes exactly three state-changing functions: approve, transfer and transferFrom. Each acts only on the caller's own balance or allowance. There is no owner, role, modifier, initializer, proxy, receive, fallback, delegatecall or selfdestruct. Selector probes for mint, burn, burnFrom, permit, DOMAIN_SEPARATOR, trusted forwarder and increaseAllowance all revert from the deployer and from a stranger.
• Asymmetry. The approve and spend pair mirrors correctly, infinite allowance is never decremented, transfer and transferFrom share one _update path with no fee or exemption branch, and a full self-transfer conserves balance and supply. The decimals getter and the TOKEN_DECIMALS constant agree at 18 by separate literals, so the manifest supply of 1e27 matches.
• Trust gap. The only privileged position is the deployer holding the whole supply, which is the launch design where the factory distributes. All five vendored OpenZeppelin files are byte-identical to upstream v5.1.0, and the sender context is plain msg.sender with no forwarder.

Checks run. The project's 26 tests pass, including with the verifier's fuzz seed, and forge fmt --check passes. My four scratch probe tests passed and were removed. Slither reported nothing. Aderyn's large-numeric-literal line at src/JuryToken.sol:23 is a style note on the supply constant, which evaluates correctly to 1e27.

Not covered. Whether Robinhood Chain accepts Cancun-target bytecode is outside my area and the chain table was not supplied, so I did not assess it. No launch.json exists in the tree yet, so there was no manifest to validate beyond the README's stated values, which are consistent with the contract.

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

Outcome: the JURY token is clean in the assigned area. It is OpenZeppelin ERC20 v5.1.0 inherited unchanged, with a single constructor mint of 1e27 minor units to msg.sender and no other function beyond the standard surface and four constant getters. I found no defect that loses funds, breaks a launch flow, or lets anyone grow the supply or move a holder's balance.

What I verified

• Execution trace: traced approve, transfer and transferFrom through OpenZeppelin's _approve, _spendAllowance, _transfer and _update. Zero-address sender, receiver and spender revert, insufficient balance and allowance revert, infinite allowance is not decremented, and there are no hooks, callbacks or external calls.
• Periphery: the vendored OpenZeppelin subset hashes byte-identical to upstream v5.1.0 for all five files. Context returns plain msg.sender.
• First principles: the supply constant computes to exactly 1,000,000,000 × 10^18, the constructor takes no arguments and mints once, and the ABI exposes no mint, burn, owner, pause or upgrade path. The reachable-opcode scan shows no DELEGATECALL, CALLCODE, SELFDESTRUCT or CALL.
• Deployment target: the cancun build uses PUSH0 and one MCOPY. An eth_call with state override on chain 4663 executed both, and the README's pair-token address returns symbol IMD with 18 decimals.
• Tests: the project's 26 tests pass under the verifier's fuzz seed and forge fmt is clean.

Reported: one info-level finding, the inherent ERC-20 approve overwrite race. A spender who front-runs an allowance reduction moves old plus new amounts. I reproduced it with concrete values in a scratch test, and stated plainly that it is a property of the standard, does not touch the launch flows, and need not block anything.

Not executed here: the protected seed-and-swap harness depends on v4-core and LaunchLiquidity, which are not in this tree. Since the token has no tax, exemption or hook logic, those assertions reduce to plain transfers, which the project tests cover.

Coverage rows answer all three listed entry points plus six invariants.

The findings file is in place and the tree is otherwise untouched. Nothing else is needed from the machine; here is the recap.

Result: no defects found in the economics area

.imd-findings.json holds an empty findings list and seven coverage rows, all holds. The JURY token is a fixed-supply ERC-20 with one constructor mint and no logic of its own, so the Economic Security, Invariant and Flow Gap checklists collapse to a small set of concrete questions, each of which I verified rather than assumed.

What I verified

• Vendored library is genuine. All five OpenZeppelin files under lib/ are byte-identical by SHA-256 to upstream openzeppelin-contracts v5.1.0, fetched for comparison outside the repository. This was the one place a "plain ERC20" token could hide a defect.
• Conservation invariant. A randomized Foundry invariant run over transfer, approve and transferFrom across eight actors, including the token's own address, kept the sum of balances equal to totalSupply at exactly 10^27. The constructor is the only _mint caller and _burn has no caller.
• Launch flows arrive whole. A factory stand-in deployed the token and moved 10%, 88% and 2% of the supply. The pool leg went through a PoolManager-style sync/settle balance delta and credited exactly what was sent. Distributor claim and trader buy/sell legs also moved exact amounts. The three shares are exact integers that exhaust the supply with no dust.
• Manifest consistency. TOTAL_SUPPLY equals the manifest string 1000000000000000000000000000, decimals is 18, the constructor takes no arguments, and the supply goes to msg.sender, which is the factory in the launch. The aderyn large-literal lead on line 23 reduces to this and is not a defect.
• No dependency or reentrancy surface. The compiled method surface is the nine ERC-20 functions plus four constant getters, with no receive or fallback. The reachable runtime contains no CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE, CREATE2 or SELFDESTRUCT.
• Entry-point boundaries. Zero amounts, whole-balance moves, self-transfers, over-balance and over-allowance attempts, infinite allowance, zero-address receiver and spender, and the absence of an implicit self-allowance all behave as OZ v5 specifies, reverting before any write.

Notes that are not findings

• The reachable runtime contains one MCOPY opcode, emitted by solc 0.8.26 under the cancun target for the string-returning metadata getters. Robinhood Chain is an Arbitrum Orbit chain with Cancun support and the verifier built with this same profile, so I could not show a failure. The compiler target lives in foundry.toml, which is policy-owned.
• Tokens sent to the token's own address are irrecoverable, and the standard ERC-20 approve front-running property applies. Both are standard behaviour the README already documents, and the validation rules exclude them.

The scratch tests I wrote under test/scratch/ were removed after they passed, since no finding carries a proof. The working tree has no changes beyond .imd-findings.json.

Added failure-path, boundary, and fuzz tests plus four-actor invariants covering supply, balances, and allowances.

forge build and offline forge test passed with the supplied seed: 49 tests, zero failures. Invariants exercised 32,768 calls.

Only test/ changed. No implementation defects found.

I found no defects in JURY, so .imd-findings.json has an empty findings list plus a coverage record.

What I checked

• The token: src/JuryToken.sol adds nothing to the standard OpenZeppelin ERC-20 (v5.1.0, vendored). It has no owner, no other privileged functions, no fee or burn on transfer, and no mint after deployment. The constructor mints the full 1,000,000,000 tokens (1e27 minor units) once to the deployer. Because transfers take no fee, the factory's payouts, the distributor's claims and pool trades all move the exact amount.
• The manifest: launch.json matches the code. The constructor takes no arguments and constructorArgs is empty, totalSupply is 1e27, decimals are 18, the contract name is JuryToken, and there are no other contracts. All keys are schema keys, and the token is far below the contract size limits.
• Build and tests: forge build succeeds and forge test passes 49 of 49.
• Static analysis: The aderyn "large numeric literal" warning points at the intended supply constant, so it isn't a defect.

The one specialist finding (dropped): The flow specialist reported an info-level approval race: a spender who sees an allowance change coming can spend both the old and new amounts. That is standard behaviour of every ERC-20 approve, not a bug in this token, and it doesn't touch the launch flows, which move tokens by transfer rather than through user allowances. I didn't keep it.

Coverage: I marked all three entry points (approve, transfer, transferFrom) as holds, plus one row for the supply and manifest check.

No source files changed. The only file written is .imd-findings.json, which git doesn't show as changed.