Implemented Prism Riot (PRIO): 1 billion tokens, 18 decimals, minted once to the deployer. Dependencies are vendored, with deployment and operational documentation included.

Validation passed:

• forge build
• forge test: 32 tests
• forge fmt --check
• Fresh offline tests with an empty environment and four threads

The platform’s protected launch integration remains for its separate harness.

Created launch.json with the exact supply, pool settings and economics. Constructor arguments match the compiled ABI.

forge build succeeded; all 32 tests passed. Only launch.json is changed for submission.

The review is complete. The findings file is written and parses, and no tracked file was changed.

Outcome: no defects found. The token is a plain, unmodified OpenZeppelin v5.0.2 ERC-20 with no constructor arguments, a single mint of exactly 10^27 minor units to the deployer, and no privileged entry points.

What I verified in my area (Execution Trace, Periphery, First Principles):

• Execution trace of all three entry points. Each of approve, transfer and transferFrom reverts atomically on zero addresses, insufficient balance or insufficient allowance, with no partial state writes, no external calls and no callbacks. The max allowance sentinel skips the decrement, which is standard and documented in the README.
• Periphery. The five vendored OpenZeppelin files are byte-identical to the pinned upstream commit, so the base contract hides nothing. There are no git submodules.
• First principles on the constructor. The supply literal that aderyn flagged computes to exactly 10^27, which matches 1,000,000,000 tokens at 18 decimals. Because the token has no transfer rules, every launch flow in the protected harness moves exactly what it says.
• Floor requirements. The compiled ABI contains only the three state-changing functions plus views. An independent opcode scan of the 1752-byte runtime found no DELEGATECALL, CALLCODE or SELFDESTRUCT. The contract name is 9 characters. Build, 32 tests and formatting all pass.

The coverage record has six rows: one holds row for each listed entry point, plus rows for the constructor, the fixed-supply and no-privileged-control invariant, and the opcode and size invariant. Nothing was left unreached.

One note for the manifest step rather than the author: the README states the launch chain as Ethereum chain ID 1, which I could not check against this launch's network configuration since no network.json is in the tree. That is documentation only and does not affect the code.

The findings file is in place and excluded by the repository's own git exclude rule, the scratch test is removed, and the working tree has no stray files.

Result: no defects in the Access Control, Trust Gap or Asymmetry area. The findings file holds an empty list and a coverage record answering all three listed entry points plus the constructor and four invariants.

What was checked

• src/PrismRiot.sol is sixteen lines: an unmodified OpenZeppelin v5.0.2 ERC-20 whose constructor mints the whole supply once to the caller. The ABI exposes exactly three state-changing selectors and seven views, nothing else.
• All five vendored OpenZeppelin files hash identically to the upstream v5.0.2 commit, so no local edit to the transfer, approve or allowance paths exists.
• Permission model: the only guard anywhere is the identity of the caller. No owner, initializer, minter, pauser, blacklist, seize, upgrade, forwarder, delegatecall or selfdestruct exists, so there is no privileged actor to form a trust gap and no weaker-guarded writer of any storage slot.
• Asymmetry: the transfer and transferFrom paths share the same internal function and the same zero-address and balance checks. Approve and allowance spending differ only in the Approval event, which is upstream v5 behaviour the README documents.
• The existing suite of 32 tests, including the 256-sequence invariant run, passes. A scratch probe I ran and removed confirmed that a stranger and the factory cannot spend a holder's balance, an appended ERC-2771 style sender suffix is ignored, ETH sent to the token reverts, and no mint or initialize selector grows supply.

Trust notes, not defects. The standard ERC-20 approve race and the absence of an Approval event during allowance spending are design properties of the chosen base contract. Tokens sent to the token address are unrecoverable by design since there is no admin.

Not covered. No launch manifest exists in the tree yet, so manifest review was not possible and is not required at this stage. Pool seeding and swaps belong to the network's protected harness and were not simulated here.

Review complete. The findings file is valid JSON with one informational entry and nine coverage rows, and no tracked file was changed.

Outcome: the math in Prism Riot holds. The token is a 16-line wrapper over unmodified OpenZeppelin v5.0.2 ERC20, and nothing in the Math Precision, Boundary or Numerical Gap checklists produces a loss or a broken guarantee.

What I verified

• Supply constant. The constant evaluates to 1e27, checked independently against three other spellings, and the whole-token count derived from decimals() is exactly one billion with no remainder. The 10% / 88% / 2% launch splits divide with zero modulus and no intermediate overflow.
• Inherited arithmetic. The only subtractions are guarded by explicit less-than reverts, and the unchecked additions are bounded by the fixed supply. Mint and burn branches are unreachable after construction, so the sum of balances stays equal to the total supply.
• Boundaries. Zero, full-balance, max, and max-minus-one amounts, self-transfers at full balance, zero addresses on every side of every entry point, ETH sent to the contract, and unknown selectors all behave as the README states. All five vendored OpenZeppelin files hash identically to upstream v5.0.2.
• Test runs. The project's existing suite passed in full (32 tests, including the fuzz and invariant runs), and my scratch test under test/scratch/ confirmed each boundary claim above.

One informational note, not a code error. A zero-value transferFrom from any caller emits a Transfer(from, to, 0) log for an arbitrary holder with no allowance. This is the standard address-poisoning primitive, but it is mandated by ERC-20, is OpenZeppelin's design, and the README and the project's own tests already treat it as intended. I recorded it at info severity with an exact reproduction so the author can consciously accept or override it.

Coverage. All three listed entry points have rows: approve and transfer hold, transferFrom carries the info note. One row is marked unreached: the Uniswap v4 seed and swap path, which needs platform contracts absent from this repository. The token has no transfer hooks, so no token-side math participates in it.

Added 19 edge-case and fuzz tests, and expanded stateful invariants for failure rollback, allowance isolation, supply conservation, and transfer liveness.

Offline forge build and forge test passed: 51 tests, including 32,768 randomized handler calls.

Only test/ changed. No implementation defects found.

The review is complete and .imd-findings.json is written at the repository root with an empty findings list and a 16-row coverage record. No tracked file was changed, and the scratch test directory was removed after use.

Outcome: no defects found in the Economic Security, Invariant or Flow Gap areas. Prism Riot is a 16-line wrapper over an unmodified OpenZeppelin v5.0.2 ERC-20 that mints exactly 1e27 units to msg.sender once in the constructor, with no constructor arguments, no owner, and no mint, burn, pause, blacklist, fallback or receive paths. Every failure mode in the three assigned guides was checked against the code and none was reachable.

What I verified, by reading and by executing scratch tests that have since been deleted:

• Supply and mint. The constant equals the brief's 1,000,000,000 tokens at 18 decimals. Under CREATE2 from a factory stub, the factory holds the whole supply and the transaction origin holds nothing.
• Conservation. Sum of balances stayed equal to total supply under the repository's stateful invariant suite and a 512-run fuzz of my own. Total supply can neither grow nor shrink, because minting is constructor-only and both transfer paths reject the zero address.
• Launch flow with this launch's own economics. The 10% swarm leg, the 88% pool leg and the 2% remainder leg each arrive whole, with no dust since 1e27 divides evenly by 10,000 basis points. A claim empties the distributor exactly. A mirrored Uniswap v4 sync, transfer, settle sequence credits exactly the transferred amount on both the buy and sell legs.
• No privileged hand. The factory cannot pull from a holder without allowance, and the holder can still transfer afterwards. The ABI contains only the three state-changing entry points the verifier listed.
• Dependency integrity. All five vendored OpenZeppelin files and the license are byte-identical to upstream commit dbb6104, which the v5.0.2 tag resolves to. Runtime is 1,752 bytes with no DELEGATECALL, CALLCODE, SELFDESTRUCT or unlinked libraries.
• Static analysis leads. Slither reported nothing. Aderyn's large-literal note points at the correct supply constant and is not a defect.

Two items are recorded as unreached rather than claimed: the real Uniswap v4 PoolManager seed and swap under the protected harness, whose v4-core and launch-library dependencies are not in this tree, and confirmation that the target chain supports the Cancun opcodes the runtime uses, since no network file or chain table was supplied. The approve race is noted in coverage as the standard ERC-20 property the README already documents, not as a finding.

Review complete. The findings file is written at .imd-findings.json and the working tree is otherwise unchanged.

Outcome: the token is a plain, unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint, and no defect that would block the launch reproduces. One specialist note survived as an info-level accepted risk.

What I verified against the code:

• Vendored dependencies are genuine. All five OpenZeppelin files hash byte-identical to upstream commit dbb6104 (v5.0.2). No git submodules exist in the tree.
• Full suite passes. The project's own tests pass, including fuzz and the stateful invariant run.
• Supply and deployment. The constructor mints exactly 10^27 units to msg.sender. The manifest's totalSupply, empty constructorArgs, decimals and contract name all match. Creation and runtime bytecode are well under the size limits, with no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The compiled ABI exposes only approve, transfer and transferFrom as state-changing entry points. There is no owner, mint, burn, pause or freeze surface.
• Static-analysis lead. The aderyn "large numeric literal" line is the supply constant, which evaluates to exactly 10^27. Style only.

Specialist findings settled:

• audit_math, zero-value transferFrom emits a Transfer log without allowance. Reproduced with a scratch Foundry test: an unapproved caller running transferFrom(alice, bob, 0) returns true and emits one Transfer(alice, bob, 0) while balances and allowance are unchanged, and the same call with value 1 reverts. This is ERC-20-mandated and documented in the README, so I kept it as info. No revision needed.
• Economics, permissions, flow and the test writer reported nothing, and my own pass found nothing beyond the above.

Coverage: all three entry points answered, with approve and transfer holding and transferFrom tied to the info finding. Three extra rows record the fixed-supply, deployability and static-analysis checks.