Final build and test pass: 67 tests, 0 failures. The work is complete.

What I delivered (all under test/, nothing outside it changed except the requested findings file):

• test/SHITPAPERToken.v4.t.sol: the launch against a real Uniswap v4 PoolManager built in place at its mainnet address, with a mock IMD at IMD's address so currency ordering matches mainnet. It seeds just under 90% single-sided at the launch.json price with fee 12500 and tick spacing 60, then ordinary traders swap. It checks the seed settles exactly with no fee, exact-input and exact-output buys deliver 97% with 3% kept, the fee event carries the gross amount, a buy taken to a third wallet taxes that wallet, sells settle exactly with no fee, claimed dividends can be sold whole, the pool survives many round trips, and a fuzzed buy-then-sell for any amount.
• test/SHITPAPERToken.fuzz.t.sol: 15 property tests. Fee is exactly 3% floored, sells and wallet transfers pay nothing, transferFrom out of the PoolManager is taxed regardless of spender, pro-rata split on pre-buy balances, buyer earns on pre-buy balance only, pending fee is paid with the next distribution, transfers move future not past dividends, claim pays exactly claimable once, claimFor never pays the caller, excluded accounts never earn and cannot claim, and the ERC-20 failure paths (over-balance, zero receiver, allowance exact and infinite).
• test/SHITPAPERToken.invariant.t.sol: a handler driving buys, sells, transfers, transferFrom, burns, donations to the contract, distributor claims, claim and claimFor over 256 runs of depth 40. Invariants: supply fixed and balances sum to it, eligibleSupply equals the sum of eligible balances, the contract holds at least what it owes and no more than donations plus rounding dust, fees equal distributed plus pending, claimed never exceeds distributed, excluded accounts never earn. I confirmed with a deliberately wrong scratch invariant that the handler reaches distributions and claims.
• test/SHITPAPERToken.edge.t.sol: 25 tests on constants, admin-call rejection, bytecode scan for DELEGATECALL/CALLCODE/SELFDESTRUCT, self and zero transfers, fee-exempt recipients, donations not redistributed, burn address, claimFor(0) reverts, contract holder paid via claimFor, event sequences, 50 tiny distributions staying solvent, a near-whole-pool fee against one wei of eligible supply, and the distributor resolution corners (funded before registration, resolved as sender or recipient, deployer without code, reverting or malformed factory answer, cached once, per-launch-number lookup).
• test/vendor/: Uniswap v4-core src/ at commit 46c6834 and solmate's Owned.sol, vendored as plain files with one relative-import patch, documented in test/vendor/README.md. Required because remappings are protected and the verifier has no network.

Findings. I found no defect in the token; every rule in the brief holds under fuzzing and random sequences. .imd-findings.json records four info-level observations without proofs: the first post-launch buyer gets its own parked fee back on the next distribution, the distributor is an ordinary taxed holder until the factory registers it, buys under 34 wei round to no fee, and routers that forward the quoted amount verbatim will be 3% short.

Still owed: a fork run against live mainnet state. The PoolManager here is the real v4-core bytecode built offline, but IMD is a mock.

launch.json is complete and verified against the accepted implementation. Only that file changed.

What the manifest describes

• Token SHITPAPERToken, name shitpaper, symbol SHITPAPER, 18 decimals, totalSupply 1000000000000000000000000000. That is exactly what the constructor mints to msg.sender.
• constructorArgs $factory, $poolManager, $launchNumber, matching the declared order (address, address, uint64) in src/SHITPAPERToken.sol.
• contracts is an empty list. The accepted tree has no application contracts.
• pool copied from the task: IMD pair address in lowercase, fee 12500, tickSpacing 60, initialPrice "125270724187523965593206900".
• economics copied verbatim from the job.
• Six top-level keys only, no chainId. Notes is one string of about 1200 characters.

What I changed

The manifest from earlier accepted work was already correct, so I kept it and only tightened the notes. The closing sentence now names the constructor signature and states that the factory, not the manifest, seeds the pool and forwards the remainder. The earlier wording about the swarm's share is gone so the notes don't read as an allocation claim.

Checks

• JSON parses, key sets for token, pool and economics match the schema, fee, tickSpacing and decimals are numbers, every uint256 and address is a string.
• forge build succeeds with solc 0.8.26.
• forge test passes 67 of 67 tests across 5 suites, including the in-place Uniswap v4 PoolManager suite and the invariant suite.
• The protected harness requirements all hold in the source: whole supply minted to the deployer, no fee on transfers to the PoolManager or from the factory, no delegatecall or selfdestruct, no owner.

Still owed outside this run: a fork test against live mainnet state, since neither this machine nor the verifier has network access.

The review is complete and the findings file is written. The git status is clean apart from the untracked findings file (it is ignored by .gitignore or shows nothing to change), the scratch directory is removed, and both snippets match the source lines exactly.

Outcome: no critical, high or medium defects in src/SHITPAPERToken.sol from the Economic Security, Invariant and Flow Gap lenses. Two economic observations are recorded in .imd-findings.json, both with concrete reproductions I ran in Foundry.

Findings

• Low: first buyer recovers its own fee. Right after launch the eligible supply is zero, so the first buy's 3% fee is parked in pendingDistribution. The next buy pays it out entirely to the first buyer, who then holds 100% of the eligible supply. For a 1,000,000-token first buy, the buyer gets its 30,000 fee back (minus 1 wei) plus the second buyer's fee. The brief says the buyer never shares in its own fee. Impact is bounded and non-compounding.
• Info: dividend sandwich. Instant pro-rata distribution with untaxed sells lets a searcher front-run a large buy, collect part of the victim's fee, claim and exit. With 4.85M eligible, a 20M front-run and a 50M victim buy nets about 600k tokens before pool fees. This is inherent to the mechanics the brief asks for, so it is recorded for the author to accept knowingly.

What held

• Fee only on transfers out of the PoolManager, nothing on sells or the seed, so v4 settlement balances. The repo's own suite exercises this against a real PoolManager built at the mainnet address.
• eligibleSupply stays equal to the sum of non-excluded balances across every writer, including late distributor resolution.
• The contract always holds at least what it owes plus pending. Accumulator arithmetic cannot overflow at any realistic volume.
• claim and claimFor pay only the account itself, revert for excluded accounts, and make no external call beyond a staticcall to the factory.
• Supply is fixed, no owner, no delegatecall or selfdestruct in source or vendored OpenZeppelin files, no submodules, and launch.json matches the brief's keys, values and lowercase addresses.

Coverage: all five entry points have rows (approve, claim, claimFor hold; transfer and transferFrom reference finding 1), plus five invariant rows. Not reached: a fork run against live mainnet and the real factory's distributorOf, which no network here allows. LP liquidity removals are taxed 3% because the brief defines any transfer from the PoolManager as a buy; noted as spec-intended.

The review is complete. The findings file is written at the repository root, the scratch tests are removed, and no tracked file was changed.

Outcome. The arithmetic in the token is sound on every normal path. I found no loss-of-funds defect in the Math Precision, Boundary or Numerical Gap areas. Three items are recorded, two low and one informational, all with reproductions I ran against this tree.

Findings written to .imd-findings.json

• Low, resolution adjustment underflow. When the factory's distributor lookup answers with an address the contract already excludes by constant (the burn address, the PoolManager, or the token itself), the first resolution subtracts that address's balance from the eligible supply although it was never added. With the burn address holding the launch remainder this panics on every transfer forever, bricking the token. With the token's own address it silently corrupts the eligible supply so later sells revert and dividends are over-credited. Precondition is a factory misconfiguration, hence low. Fix is a one-line check that an already-excluded answer is treated as unknown.
• Low, unguarded decode of the factory answer. A 32-byte answer with non-zero upper bytes passes the length check and then reverts inside the decode, on every transfer, contradicting the contract's own claim that malformed answers never revert. Fix is to decode as a word and reject anything above 160 bits.
• Info, fee floor. Buys of 33 wei or less pay no fee, and every buy under-pays by up to 1 wei versus a rounded-up fee. Dust, not compounding, and the existing fuzz suite documents it as intended.

Coverage. All five entry points have rows. Approve, claim and claimFor hold. Transfer and transferFrom hold on every from/to class I traced (mint, buy, sell, seed, wallet, claim, self-transfer, zero value) and carry the findings above. I also recorded four invariant rows: eligible supply equals the sum of eligible balances, the contract always covers what it owes, no intermediate overflow is reachable (worst case accumulator about 2.7e61 with one wei eligible), and the manifest is schema-correct with a plausible provenance price.

Not reached. No fork run against live mainnet state; the vendored v4 PoolManager tests stand in for it. Economics outside my area, such as sandwiching a large buy to capture its fee share early after launch, were noted but not reported since the pro-rata rule is mandated by the brief.

Both paths are intentionally excluded by the repository, so the working tree is clean apart from the deliverable and my scratch directory. The review is complete.

Outcome: no exploitable defect in the permission model. The token has no owner, no admin surface, no mint path after the constructor, and the only external call is a staticcall to the launch factory. The vendored OpenZeppelin files are byte-identical to upstream v5.3.0. All 67 existing tests pass offline, and my five scratch probes confirmed the behaviour I traced.

What I reported in .imd-findings.json:

• Low, view/writer asymmetry. The three dividend views read the cached distributor, while transfers and claims resolve it live from the factory. Between the factory registering the distributor and the first successful transfer, the views say it is taxed and eligible while claimFor already reverts and a PoolManager transfer to it arrives untaxed. No funds are affected. The fix is a view-only resolver so both sides agree.
• Info, launch economics. Right after launch the eligible supply is zero, so a 34-wei first buyer is credited the entire fee of the next buy. This is exactly the pro-rata rule the mechanics spec requests, so I recorded it as a property for the author, not a defect.

Coverage: all five entry points hold, plus seven invariant and trust rows. One lead was deliberately left out of the findings: a factory that answered an already-excluded holder as the distributor would underflow the eligible-supply subtraction and block transfers, but that requires the trusted factory to misbehave. The only check still owed is a fork run against live mainnet state, which cannot run here.

Review complete. The findings are in .imd-findings.json at the repository root, with coverage rows for all five entry points and four invariants. No tracked file was changed, and the scratch tests were removed.

Outcome: the token's fee and dividend control flow is correct against the brief. I found no critical, high or medium defect. Three items are recorded, two low and one informational.

What I traced and confirmed holds

• Buy fee path. The fee fires only when the sender is the PoolManager and the recipient is not exempt. Both legs leave the PoolManager, so Uniswap v4 take and settle balance exactly. Sells, the seed, distributor claims and wallet transfers pay nothing.
• Dividend accounting. The fee is distributed against the pre-buy eligible supply, both sides are checkpointed on pre-transfer balances, and the eligible supply tracks every balance writer. Floor rounding keeps the contract solvent. I checked overflow bounds on the accumulator and per-holder product and they are unreachable.
• Claims. Settle, zero the owed amount, then an untaxed transfer from the contract. Payouts go to the named holder only. Excluded accounts revert.
• Deployment and manifest. The constructor mints the full supply to the factory and calls nothing. The manifest keys, argument order, supply, pool and economics match the brief. Runtime bytecode has no delegatecall or selfdestruct.
• Vendored code. OpenZeppelin ERC20 v5.3.0 is unmodified, committed as plain files, with no submodules.

Findings

1. Low. The distributor lookup hard-codes the selector for a getter keyed by uint64. If the real factory's getter differs, the failure is silent, the swarm distributor stays eligible, and it captures almost all early fees. Anyone can then pay those fees to the distributor, where they are stuck. The protected harness matches the selector, so this holds under the harness. I reported it so the author can confirm it against the deployed factory.
2. Low. If the factory ever names an already-excluded address as distributor, the eligible-supply subtraction underflows. Every transfer, claim and swap then reverts forever. The precondition is a trusted-party misconfiguration, but the fix is a one-line guard.
3. Info. The instantaneous pro-rata snapshot is sandwich-able. A searcher buying ahead of a large buy captures most of that buy's fee. This follows from the brief's mechanics, so it is documented rather than flagged as a deviation.

Not reached. No fork run against live mainnet state, and no test through the Universal Router or Permit2 path. The vendored real PoolManager tests cover direct swaps only. A non-factory liquidity provider withdrawing through the PoolManager pays the 3% fee, which follows the spec but is untested.

The review is complete and .imd-findings.json holds the result. No tracked file was changed; only the findings file and my scratch test under test/scratch/ were created.

Outcome. The token is sound for its launch: the build is reproducible, the supply is minted whole to the factory, settlement with the v4 PoolManager balances exactly, and no entry point loses or freezes funds under the documented factory. The existing suite of 67 tests passes. I kept four findings, none above low, each reproduced with a scratch test that passes against this tree.

Findings kept

1. Low, parked first-buy fee refunded. With nobody eligible after launch, the first buy's fee is parked and then credited at the next buy to the first buyer, who recovers its own fee. This contradicts M1's "buyer never shares in its own fee". Merged from the economics specialist.
2. Low, distributor resolution underflow. If the factory ever names an already-excluded address as distributor, the balance subtraction panics on every transfer, or silently corrupts the eligible supply. Requires a misconfigured factory, so low. Merged from the math and flow specialists.
3. Low, view and writer disagree. Between registration and the first transfer, the view functions report the distributor as taxed and eligible while transfers and claims already treat it as excluded. Merged from the permissions specialist.
4. Info, instant pro-rata snapshot. A front-run buy captures most of a large buy's fee and exits untaxed, and a 34-wei first holder takes the whole next fee. This is the behaviour M1 asks for, recorded for the requester's awareness. Merged from three specialists.

Dropped. The factory-ABI mismatch and the dirty 32-byte word findings rest on a factory interface that contradicts the protected harness, which declares a plain uint64-keyed getter. The 33-wei fee floor is 1 wei of dust in the buyer's favour and is documented as intended.

Coverage. All five entry points are answered, plus four invariant and build rows. Transfer and transferFrom are marked against finding 1 since both share the hook where the refund lives.