Implemented Pepe (PEPE): 1,000,000,000 tokens with 18 decimals, minted once to the deployer. No fees, administrative powers, or further minting.

Included vendored dependencies and deployment/operations documentation.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed all 33 tests using the required fuzz seed.
• forge fmt --check passed.

Protected launch integration checks remain for the external verifier.

Done. The manifest is written and verified against the accepted tree.

What I wrote: launch.json with kind custom_token, describing the single accepted contract Pepe.

• Token entry names the Solidity contract Pepe, name Pepe, symbol PEPE, decimals 18, an empty constructorArgs list, and totalSupply of 10^27 minor units. That matches the constructor in src/Pepe.sol:13, which takes no parameters and mints INITIAL_SUPPLY to msg.sender once.
• The contracts list is empty, since the accepted tree contains no application contracts.
• The pool and economics objects are copied exactly from the launch reference: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics verbatim.
• Notes describe the token's fixed supply, lack of admin powers and exact-amount transfers through the launch flows, in about a thousand characters.

Verification: a script checked the manifest's keys, the verbatim economics, the supply string and the notes length. The build compiled cleanly and the full suite passed with the verifier's fuzz seed.

Check	Result
forge build	success
forge test with pinned seed	33 passed, 0 failed

Git status shows only the new launch.json. No other file was changed.

Review complete. The economics area is clean, and .imd-findings.json holds an empty findings list with seven coverage rows.

What I reviewed. src/Pepe.sol is a 16-line contract inheriting OpenZeppelin ERC20 with a single constructor mint of one billion tokens to msg.sender. The five vendored OpenZeppelin files are byte-identical to upstream v5.0.2 (fetched and compared). The repository's 33 tests pass, including the stateful conservation invariant, and the tree is unchanged apart from the findings file.

Economic Security pass. No external dependencies, oracles, callbacks or hooks exist. Transfers move the exact amount with no fee or burn. ERC-20 compliance holds: zero-address recipient, spender and owner all revert with ERC-6093 errors, and the maximum allowance is not decremented. The approve transaction-ordering race is a standard ERC-20 property the README documents, so I did not report it as a defect.

Invariant pass. Total supply equals 10^27 forever: the constructor is the only mint, and a fuzz over random selectors found no path that changes supply or balances. Sum of balances equals total supply across all entry points. The 10/80/10 launch split partitions 10^27 with no dust, and the swarm's 2/8 sub-split is also whole.

Flow Gap pass. Factory to distributor, factory to pool manager, factory to remainder, distributor to claimant, and pool manager to and from an ordinary trader each arrive exactly as sent. The constructor takes no arguments and mints to the caller, not tx.origin, so a CREATE2 factory receives the whole supply. The reachable runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Static-analysis lead. The aderyn large-literal note at line 10 evaluates to exactly 10^27 and is style only.

Coverage. All three entry points are marked holds, plus four invariant rows. Nothing was left unreached. Scratch tests were run and then removed.

The permissions review of the Pepe token found no defects. The findings file is written with an empty list and six coverage rows, and the working tree is unchanged apart from that file.

What was reviewed. The token at src/Pepe.sol is sixteen lines: a plain OpenZeppelin ERC20 whose constructor mints one billion tokens, 18 decimals, once to the deployer. I checked it against the Access Control, Trust Gap and Asymmetry guides from the Pashov reference, plus the Senior Auditor's Mindset.

Access Control. There is no permission model to break. The compiled ABI holds only the nine standard ERC20 functions and one constant view. No owner, role, modifier, initializer, mint, burn, pause, blacklist, seize, upgrade, receive or fallback exists. Every state write is scoped to the caller's own balance or allowance through plain msg.sender.

Trust Gap. The only privileged moment is construction, and it hands out nothing but the supply itself. A scratch probe confirmed the deployer cannot pull from a holder without that holder's approval and cannot re-run the mint through any selector. The vendored library is where a backdoor would hide, so I diffed all six files under lib against the upstream v5.0.2 release archive. All are byte-identical, and the archive hash matches DEPENDENCIES.md.

Asymmetry. The paired surfaces are transfer against transferFrom and approve against spend-allowance. A fuzzed probe showed transfer and transferFrom write identical balance slots with identical deltas, differing only in the allowance slot, which only approve sets and only transferFrom decrements. Zero sender and zero receiver are rejected on both paths.

Static analysis lead. The aderyn large-literal warning on line 10 is not a defect. The constant evaluates to exactly the stated supply and the existing tests assert it.

Checks run. The project builds on solc 0.8.26, the existing 33 tests pass including the 256-run invariant, and my six scratch probes passed before I removed them.

Coverage. All three listed entry points are marked holds, with three further rows for the constructor mint, the absence of any privileged role, and the library's integrity. Nothing in the area was left unreached.

The math review of Pepe is clean. No defects found, and the findings file holds an empty list with a full coverage record.

What was checked, per guide

• Math Precision. The token has no division, fee, scale conversion, downcast or rebase. The only arithmetic is OpenZeppelin's balance and allowance updates. The supply literal compiles to exactly 10^27 in the runtime bytecode, and divides by 10^18 with zero remainder. The aderyn large-literal lead is not a defect.
• Boundary. The ABI exposes no receive, fallback or payable function, and the contract makes no external call. The only sentinel is the zero address, and both sides revert, so no mint or burn path is reachable after construction. A scratch suite fed 1 wei, the full supply, supply plus one, max uint, max minus one allowance, self-transfers and zero-value paths through all three entry points. All sixteen cases reverted or moved exactly what they should, with no wrap.
• Numerical Gap. The conservation invariant holds under integer arithmetic because nothing truncates. The infinite-allowance sentinel is the one boundary-dependent branch, and it behaves as documented. Every unchecked block in the vendored ERC20 is bounded by a preceding revert guard.

Supporting evidence

• The vendored OpenZeppelin files are byte-identical to upstream v5.0.2.
• The existing suite passes: 33 tests including the 256x64 stateful invariant.
• A reachable-opcode walk of the runtime finds no DELEGATECALL, CALLCODE or SELFDESTRUCT, which is outside my area but is the floor's one severe check.

Coverage record in .imd-findings.json has eight rows: the three listed entry points, all marked holds, plus five invariant and boundary rows. Nothing was unreached. The scratch test directory was removed, so the tree is unchanged apart from the findings file.

The review is complete. No tracked file was changed, and .imd-findings.json holds an empty findings list with eight coverage rows.

Outcome: no defects found. Pepe is a two-line wrapper over OpenZeppelin ERC20 v5.0.2 with no overrides, so every entry point behaves exactly as that library specifies, and nothing in the Execution Trace, Periphery or First Principles guides yields a failing input.

What I verified, and how:

• Entry points. All three (approve, transfer, transferFrom) traced through _approve, _transfer, _update and _spendAllowance. Zero-address, insufficient-balance and insufficient-allowance paths revert atomically with no partial state. Infinite allowance is not decremented. The project's 33 tests and the 256-run invariant suite pass.
• Periphery. The six vendored OpenZeppelin files were diffed byte-for-byte against upstream v5.0.2 and are identical. Pepe overrides nothing.
• Execution surface. A PUSH-aware walk of the compiled runtime found no reachable CALL, STATICCALL, DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE or CREATE2. There is no receive or fallback, so ETH and unknown selectors revert. The ABI has no mint, burn, owner, pause or initialize function.
• First principles and launch flow. A scratch Foundry test drove a CREATE2 factory deploy, confirmed the predicted address with no appended constructor args, moved 10 percent to a distributor, pulled 80 percent through a pool-manager stand-in via allowance, forwarded the remainder, paid claims including a 1-wei claim, and did a buy and sell-back. Every flow moved the exact amount and total supply stayed at 10^27. The scratch test was removed afterwards.
• Static-analysis lead. The aderyn large-literal note on INITIAL_SUPPLY is the intended value, 1,000,000,000 × 10^18, confirmed by the constructor mint.

Noted but not reported as a defect. The standard ERC-20 approve ordering race is reproducible (lowering an allowance from 100 to 50 lets a spender front-run and take 150). It is inherent to the ERC-20 interface, is explicitly documented in the README, and OpenZeppelin v5 removed increaseAllowance by design, so it is recorded in the coverage row rather than as a finding.

Nothing in my area was left unreached. The protected Owners test applies only to application contracts, of which this launch has none.

Added 18 failure-path, boundary, and fuzz tests, plus expanded balance and allowance invariants.

Offline forge build and forge test pass with the required seed: 51 passed, 0 failed, including 32,768 invariant calls.

Only test/ changed. No contract defects identified.

I found no defects, so I kept no findings. .imd-findings.json holds an empty findings list and a coverage record for all three entry points, plus one row for the fixed supply. No other file was changed.

What I checked

• The contract: src/Pepe.sol is a plain token built on the vendored OpenZeppelin v5.0.2 ERC20, with nothing overridden. The vendored ERC20 code I read matches upstream (_update, _approve, _spendAllowance).
  • The constructor mints 1,000,000,000 × 10^18 once to msg.sender, which is the factory during launch.
  • There is no owner, no mint or burn after deployment, no pause, blacklist or freeze, and no transfer fee or burn. It uses no DELEGATECALL, SELFDESTRUCT or assembly.
  • So the transfer to the distributor, the pool seed, claims and swaps each move exactly the amount stated.
• Entry points:
  • approve holds: it rejects a zero spender, sets the allowance and emits Approval.
  • transfer holds: it rejects the zero address, reverts when the balance is too low and moves exactly the amount.
  • transferFrom holds: it spends the allowance (an unlimited allowance is not reduced) and a revert undoes the allowance change.
• Manifest (launch.json): It only uses keys the schema allows. constructorArgs: [] matches the constructor, which takes no parameters. totalSupply is 1000000000000000000000000000, which is what the constructor mints. Decimals are 18, the contract name Pepe is valid, and addresses are lowercase. I could not check the economics block against the job, because the job's figures aren't in this task.
• Tests: I ran forge test on the existing suites and all 51 tests passed. I didn't run the protected tests, because they need the launch harness and its environment variables.
• Static analysis: Aderyn's low-severity "large numeric literal" note on src/Pepe.sol:10 is about style only and is not a defect. Slither reported nothing.
• Specialists: None of the four specialists or the test writer reported a finding, so there was nothing to reproduce or merge.

A clean review doesn't prove the code has no defects. It means none that I checked could be reproduced.