Implemented Pepes (PEPES): 1,000,000,000 tokens, 18 decimals, minted once to the deployer. Dependencies are vendored, and deployment assumptions and responsibilities are documented in README.md.

Verified with Solidity 0.8.26:

• forge build — passed, including a clean offline build
• forge test — 27 passed; includes fuzzing and 8,192 invariant calls
• forge fmt --check — passed

External launch integration remains for the network’s harness. No deployment was performed.

Created launch.json with the exact Pepes supply, constructor arguments, economics, and paired currency. Only the manifest is changed.

Validation passed against the provided schema and compiled constructor ABI. forge build succeeded; forge test passed all 27 tests.

The review is complete. The findings file is written at the repository root with an empty findings list and seven coverage rows, and the source tree is unchanged.

Result: no defects found in the economics of Pepes. The token is a thin wrapper over the vendored OpenZeppelin v5.0.2 ERC20 with one constructor mint and nothing else.

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• Supply conservation. The constant at src/Pepes.sol:10 is exactly 10^27 minor units. The only mint is in the constructor, _update is not overridden, and mint, burn and admin selectors all revert from the deployer, a stranger and the zero address. The aderyn large-literal lead is a style note, not a defect.
• Launch flows arrive whole. Under a CREATE2 factory stand-in, the factory holds the full supply, the ten percent swarm share, a fuzzed pool share from 1 to 9000 basis points, and the remainder all transfer exactly. A sync/settle style manager credits precisely the requested amount, so a PoolManager seed or swap would settle whole.
• Allowance accounting. Finite allowances decrement, the max allowance is untouched, no residual remains after an exact spend, and a spend over either balance or allowance reverts atomically.
• Dependencies and callbacks. The runtime bytecode has no CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT. There is no receive or fallback, so ETH sent to the token reverts rather than stranding. No role exists after deployment.
• Vendored library integrity. The five OpenZeppelin files hash to the digests in the lock file, and the ERC20 source reads as the canonical v5.0.2 text.

The existing suite of 27 unit, fuzz and invariant tests passed. My scratch tests covering the launch flow, supply growth and delegated transfers also passed and were then removed, since nothing in them backs a finding. The one residual property worth knowing is the standard ERC-20 allowance replacement race on approve. It is inherent to the specification and already documented in the README, so I recorded it in the coverage row rather than as a finding.

Not reached: the real Uniswap v4 PoolManager seed and swap, which need the launch system's contracts that are not in this tree. The protected test will exercise that path.

The review is complete. The findings file is in place at the repository root and is excluded from git by the workspace's own exclude rules, which is the expected arrangement for a review deliverable.

Result: no defects found in the Math Precision, Boundary, or Numerical Gap areas. .imd-findings.json holds an empty findings list and six coverage rows, all holds.

What I checked

• Math Precision. The only arithmetic in src/Pepes.sol is the compile-time constant for the supply. I confirmed it equals exactly 10^27 with 18 decimals, so the aderyn "large numeric literal" lead is cosmetic and the value is correct. The inherited OpenZeppelin v5.0.2 ERC-20 has no division, rounding, downcast or fixed-point scale. Its three unchecked blocks are each guarded by a preceding revert or bounded by total supply. The vendored library files hash-match the lock file.
• Boundary. The token has no external calls, no payable or receive/fallback, no sentinel-address branches beyond the zero-address rejections, and no bytes decoding. I probed transfer and transferFrom at amount 0, exact balance, balance plus one, and uint256 max, plus self-transfer. I probed allowances at 0, exact, max minus one and max. Native value and unknown selectors revert. All behaved as the standard specifies.
• Numerical Gap. With no runtime multiplication or division there is no precision seam. Supply conservation held across eight fuzzed holders with dust amounts, and the launch fractions of 10 percent, 2 percent and 8 percent divide 10^27 exactly, so the swarm share and seed cannot arrive short through rounding.

Trust notes, not defects. The standard ERC-20 approve race applies, since OpenZeppelin v5 dropped the increase/decrease helpers; the README already documents it. The entire supply goes to the CREATE2 factory, so distribution correctness rests on the factory, which is outside this token.

The scratch test I used for verification has been removed, leaving the tree clean apart from the findings file.

Review complete. The findings file is written and validated, and the working tree is otherwise untouched.

Outcome: the Pepes token has no access-control, asymmetry or trust-gap defect. One low-severity provenance issue was found outside the token itself.

What was reviewed

• src/Pepes.sol is a bare OpenZeppelin v5.0.2 ERC20 with a constructor that mints exactly 10^27 units to the deployer. There are no constructor arguments, no roles, no modifiers, no owner and no initializer.
• The only state-changing entry points are approve, transfer and transferFrom. Each writes only state the caller controls. The deployer or factory cannot move or freeze another holder's balance without an approval.
• The vendored ERC20 implementation is byte-identical to upstream v5.0.2, so the inherited guards are the known ones. I read it in full.
• Compiled runtime and creation bytecode contain no DELEGATECALL, CALLCODE, SELFDESTRUCT, or any external call opcode. Metadata hash is disabled as the launch rules require.
• The project's 27 unit, fuzz and invariant tests pass under the pinned toolchain.

The one finding (low)

Seven forge-std files under lib/forge-std/src/ were reformatted after vendoring and no longer match the SHA-256 digests recorded in dependencies.lock.json. The README claims those digests cover unmodified files. I fetched the pinned upstream archive and confirmed the differences are whitespace-only line wrapping, so the test harness behaves as upstream and the token is unaffected. The problem is that an offline verifier cannot tell this benign reformat of the cheatcode interface from a tampered copy. The fix is either to re-vendor the files byte-identical or to regenerate the digests and reword the README.

Coverage record

• All three listed entry points are marked holds, with the tracing reason for each.
• Eight invariant rows cover the constructor mint, absence of privileged functions, fixed supply, exact launch flows, forbidden opcodes, and dependency integrity.
• Two rows are marked unreached. The protected launch test could not be executed because it imports the v4-core and launch-system contracts that are not in this tree. No launch manifest exists yet, which the reference says is acceptable for an early review.

No proof test was written because no finding reached high or critical severity.

The review is complete. Nothing else is needed: the findings file parses, its one snippet matches dependencies.lock.json:41 exactly, all three verifier-listed entry points have coverage rows, and the tree is untouched apart from .imd-findings.json and the ignored test/scratch/.

Summary

Scope covered (Execution Trace, Periphery, First Principles — all three in depth):

• Execution Trace — traced approve, transfer, transferFrom and the constructor through OpenZeppelin _update/_approve/_spendAllowance: sentinel paths (address(0), type(uint256).max), self-transfer, zero-value, revert atomicity, allowance-before-balance ordering. No external calls, callbacks, stale reads, or partial-update windows exist.
• Periphery — downloaded the pinned upstream archives. OpenZeppelin v5.0.2 (the token's entire runtime logic) is byte-identical to upstream; _msgSender() is plain msg.sender. Disassembled the compiled runtime: zero CALL/DELEGATECALL/CALLCODE/SELFDESTRUCT/CREATE instructions.
• First Principles — checked every assumption the 16-line contract rests on: the supply constant equals an independently written 1000000000000000000000000000 (dismissing the aderyn lead — the project's own test compares it against the same expression, which proves nothing), mint goes to msg.sender i.e. the CREATE2 factory, no role is handed out, the first outside caller can do nothing.
• Launch floor — by trace plus local factory-style tests: swarm share and claims arrive whole, no tax so PoolManager seed/swaps settle exact amounts, supply cannot grow, no privileged call moves or freezes a holder. The protected harness itself needs the launch system's contracts and env and could not be run here.

Findings: 1 (low). dependencies.lock.json records per-file SHA-256 digests that seven lib/forge-std files no longer match — lib/ was evidently forge fmt-ed after the lock was written. I verified the drift is whitespace-only against upstream v1.9.7, so nothing is tampered, but the README's "digests of the unmodified vendored files" claim is false and anyone re-running that verification cannot tell formatting from tampering of StdAssertions.sol without repeating my upstream diff. Reproduction: sha256sum lib/forge-std/src/Vm.sol vs lock line 41.

No critical/high/medium defects. The token is a verbatim OZ ERC-20 with a one-shot constructor mint; I found no concrete failing input against any entry point. Build, forge fmt --check, the 27 project tests and my 4 scratch tests all pass. The only non-finding assumption worth the judge's eye: the runtime uses PUSH0 (Cancun target), so the launch chain must support Shanghai+ — foundry.toml is out of scope and the chain was not specified.

Added 13 edge-case tests and expanded stateful invariants to cover failure rollback, authorization, and allowance boundaries.

forge build and forge test pass offline: 40 tests passed, including 16,384 invariant calls. No defects found. Only files under test/ changed.