Implemented the responsive site in site/ and complete static export in dist/, including live data, logo overrides, and address copying.

• Typecheck and 10 interaction tests passed.
• Foundry: 21 passed; optional live fork skipped without RPC.
• Bundle: 7,752,332 bytes, within 8 MiB.

Design, validation, screenshots, and preview/publishing instructions are documented.

Verified the existing SPEPEToken and exact launch.json match the brief. Added three factory smoke tests and updated documentation; protected files remain unchanged.

Checks passed: forge build, forge test, and forge fmt --check.

Result: 24 passed, 0 failed, 1 skipped. Live fork verification remains outstanding because no RPC was configured.

The suite is complete and verified. Final forge test result: 63 passed, 0 failed, 1 skipped (the RPC-guarded fork test), with forge fmt --check clean and only paths under test/ touched.

What I added, on top of the 24 existing tests from earlier contributors, which I left untouched:

• test/SPEPETaxRules.t.sol: 22 adversarial unit and fuzz tests on the transfer rule. Fuzzed over arbitrary sender, recipient and spender addresses so the tax depends only on the manager being the source. Exact Transfer event counts and order for a buy, a sub-threshold buy, a sell and a wallet transfer. Revert atomicity when the fee leg alone exceeds the manager balance, on overdrafts, on zero recipients and on self-transfer overdrafts. Deployer independence from tx.origin and across two deployments. The fixed addresses are shown to be baked into runtime code and absent from storage, and 22 privileged function names fail from both deployer and stranger while the holder still holds and can still move.
• test/SPEPEClaimsAndFees.t.sol with test/support/ClaimsHarness.sol: 15 real v4 integration tests the plain harness could not reach. Round trips with the maximum protocol fee on top of the 1.25% LP fee, including a 500-run fuzz. Collecting SPEPE protocol fees is an outbound manager transfer and pays the tax, while paired-currency collection is untouched. Buy output kept as ERC-6909 claims defers the tax until redemption, and partial redemptions each pay their own fee, so claims cannot bypass the rule. Outputs taken to a third party, to the tax wallet, and to the manager itself. A take-and-repay flash loan settles in full and costs exactly the tax, and one without funds for the fee reverts cleanly.
• test/SPEPETaxLedgerInvariant.t.sol: a ghost-ledger invariant campaign over six actors including the manager and tax wallet, with handler actions for transfers, delegated transfers, overdrafts and over-allowance attempts caught via try/catch. Invariants: tax wallet balance equals what the rule charged, gross debited equals net plus tax, supply conserved, parameters unchanged. A second campaign targets the token's raw ABI from five senders with reverts allowed. A scratch check confirmed the handler reaches every path.

No defects found, so no findings file was written. Two spec-conforming behaviours are worth knowing and are already documented by the earlier contributors: every outbound manager transfer is taxed, which includes liquidity withdrawals and protocol-fee collection, and the fee floors per transfer so amounts under 50 minor units pay nothing, a dust-level effect at 18 decimals.

Still owed: the live Robinhood Chain fork run. It needs ROBINHOOD_FORK_URL and ROBINHOOD_FORK_BLOCK set by an operator, since this environment and the verifier have no network. I did not commit, matching the harness's own per-task commits.

I found no defects in the permissions area, so .imd-findings.json holds an empty findings list plus coverage rows. The existing test suite passes: 63 passed, 0 failed and 1 skipped. I changed no project files.

Access control:

• src/SPEPEToken.sol adds nothing on top of the OpenZeppelin v5 ERC20 it inherits. There is no owner, no admin and no setters.
• The tax rate, POOL_MANAGER and TAX_WALLET are all fixed constants.
• No external function can mint or burn. The constructor mints all 1e27 units to msg.sender once.
• There is no selfdestruct, delegatecall or proxy.

Trust gaps and asymmetries:

• Who is taxed: the override taxes only transfers where from == POOL_MANAGER and to != POOL_MANAGER. Sells, pool seeds and wallet-to-wallet transfers move the full amount.
• Tax amount: the tax is floor(value/50), sent to the fixed wallet, and the buyer gets the rest.
• Uniswap v4 balances: the PoolManager is debited the full amount, so v4's settlement accounting balances.
• transferFrom: it charges the allowance on the full amount and then follows the same transfer path. The PoolManager never approves anyone, so no one can trigger the tax through an allowance.
• Liquidity withdrawals: these are also taxed. That follows the spec, which taxes every transfer out of the PoolManager, and launch.json notes it.

Manifest: launch.json uses only the schema's keys. It has empty constructorArgs for the no-argument constructor, a totalSupply of 1e27, the economics copied exactly, and lowercase addresses.

Coverage: all three entry points (approve, transfer, transferFrom) are recorded as holds, along with two invariant rows for "no owner or minting after deploy" and "manifest matches the token".

Static analysis: the aderyn large-numeric-literal line is style only and not a defect.

The fork swap tests on the live chain could not run here because there was no network, so the real swap behaviour on chain is still unchecked.

The findings file validates, the quoted snippet matches line 23 of the token, and the working tree is clean apart from the ignored findings file and scratch test.

Result: one low-severity economic finding, no critical or high defects, and all three entry points marked holds in .imd-findings.json.

What I found

• Tax bypass via ERC-6909 claims (low). The 2% creator tax only fires when SPEPE leaves the PoolManager as an ERC-20 transfer. A trader who keeps the buy output as ERC-6909 claims and later sells by burning those claims completes a full round trip without the tax wallet ever receiving anything. My scratch test reproduces it with the vendored v4 core: 1 IMD buys about 982,150 SPEPE gross, the sell returns 0.975 IMD, and the tax wallet stays at zero where the rule would have charged about 19,643 SPEPE. This is consistent with the authoritative mechanic's definition of a buy as a transfer from the PoolManager, so it is a limitation of the agreed enforcement point rather than an implementation slip. The token alone cannot see claim mints, so closing it would need a hook, which is outside the requested design.

What held under the Economic Security, Invariant and Flow Gap guides

• Supply is conserved at exactly 1e27 and minted once to the constructor caller.
• Both tax legs are internal OpenZeppelin updates, so reverts are atomic and the tax-wallet ledger matches floor(amount/50) per outbound manager transfer.
• Every launch flow arrives whole: factory to distributor, distributor claims, the single-sided seed, and sells into the pool. Uniswap v4 settle and flash accounting balance across take, claims, third-party recipients, flash loans, protocol-fee collection, and liquidity withdrawal.
• The manifest matches the schema and the job's pool and economics values verbatim.
• Taxed liquidity withdrawals, taxed protocol-fee collection, gross exact-output quotes, and sub-50-unit rounding are documented consequences of the agreed rule, recorded as trust assumptions.

Not reached: the live Robinhood fork swap test, which has no RPC here and remains owed to the verifier.

The findings file is written and valid, the snippet matches the source lines exactly, and the only files I created are the review output and the scratch test. The review is complete.

Result: no defect of material severity in the math, boundary or numerical-gap area. The findings file holds one info-level note and ten coverage rows covering all three listed entry points.

What I checked

• The tax formula value / (10000 / 200) is exactly floor(value/50). It cannot overflow, value - tax cannot underflow, and a max-uint or over-balance input reverts on the fee leg before any state changes.
• Against the real Uniswap v4 PoolManager built at the fixed address, I ran a scratch test for the edges the shipped suite does not touch: a 49-unit exact-output buy, one swap taken in twenty 49-unit chunks, the ERC-6909 claims path, a take sent to the tax wallet, and manager-balance conservation across buy and sell. All behaved consistently with the spec.
• launch.json arithmetic holds: the supply equals the mint, the price literal is floor(2^96/1000), and it yields the 1000 IMD opening cap.

The one note (info)

Outbound manager transfers under 50 minor units pay zero tax, and splitting a take into 49-unit chunks pays none. This is the exact seam the Numerical Gap guide names, so I recorded it with numbers. It is documented in the notes and contract comment, and each avoided unit of tax costs a full take call for a value near 1e-24 IMD, so it is not a loss of funds.

Still owed

The Robinhood mainnet fork swap run skips here because there is no network. That row is marked unreached.

The review is complete. The findings file is written and validated, and the working tree holds no stray files.

Outcome. The SPEPE token contract itself has no defects in my area. I report two periphery findings, both low or informational, in .imd-findings.json with an 11-row coverage record.

What I traced. The single override in src/SPEPEToken.sol routes every balance change. A transfer whose sender is the PoolManager and whose recipient is not pays floor(value/50) to the tax wallet, then the remainder to the recipient. Both legs debit the manager and revert together on a shortfall, so no partial fee survives. Every other path is one plain OpenZeppelin update. Allowances are spent on the gross value. There is no mint, burn, owner, payable or fallback surface, and the runtime has no delegatecall or selfdestruct. The manifest keys, values, address casing and documented ABI all match the order and the compiled output.

Live verification. The network was reachable, so I ran the owed mainnet fork test. It passed against Robinhood Chain at block 84259017 with the real PoolManager and IMD contracts. Chain id 4663, the PoolManager code, and the IMD symbol and decimals all check out. The tax wallet is an active EIP-7702 delegated account, which receives ERC-20 balances without any callback.

Findings.

• Low: vendored-source pin is wrong. Ten v4-core entries in lib/source-sha256.json hold the digests of upstream main, while the tree holds reformatted copies. A whitespace-insensitive diff against upstream shows formatting-only changes, so the test PoolManager is genuine, but the pin cannot prove it and fails when run. The deployed token imports only OpenZeppelin, whose hashes all match.
• Info: stale validation record. REVIEW.md points at an artifacts/checks/ directory that is not in the tree, and both it and README.md report old test counts.

Not covered. No proofs were written because nothing reached high severity. The protected harness's factory-side sources were not available here, so its exact run is still the verifier's.

The review is complete and .imd-findings.json holds the result.

Outcome: no critical, high or medium defects. The token is a 32-line OpenZeppelin ERC20 with one _update override, and every entry point traced as intended. I kept four findings, two low and two info, all reproduced and all merged one-to-one from the specialists. My own pass found nothing the four missed.

Findings kept

• Low, ERC-6909 claims bypass. A buyer who keeps swap output as claims and later sells by burning them never triggers an ERC-20 transfer from the PoolManager, so no tax is paid. My scratch harness reproduced the economics specialist's exact numbers: a 1 IMD round trip moves 982,150 SPEPE gross and pays zero to the tax wallet. This conforms to the literal M1 rule and cannot be closed inside the token without a hook, so it is reported as a known limitation for the requester to accept or redesign.
• Low, hash pins. Ten of 93 entries in the vendored-source pin file do not match the tree. I fetched the ten files from upstream v4-core: the pins are upstream's hashes and the tree copies differ only in whitespace and braces, so the test PoolManager is semantically upstream. The deployed token imports only OpenZeppelin, whose five files match upstream exactly.
• Info, rounding. Buys under 50 minor units pay zero tax and split takes undercount by at most one unit per take. Documented, negligible, already asserted by the author's suite.
• Info, stale documentation. REVIEW.md cites an artifacts/checks/ directory that is absent and both it and README.md report old test counts. The suite now has 64 tests, 63 passing and one fork test skipped offline.

What I verified myself

• Full build on solc 0.8.26 and the committed suite pass offline.
• Manifest keys, types, casing, supply and economics match the schema rules and the order verbatim. The constructor takes no arguments and mints 1e27 to its caller, which satisfies the protected harness.
• Committed ABI equals the compiled ABI: standard ERC20 plus five constant getters, no admin surface, no delegatecall or selfdestruct.
• Coverage record answers all three listed entry points plus three invariant rows.

Still owed by the operator, not a defect: the Robinhood Chain fork test, which skips cleanly without an RPC URL.