Added failure-path tests, 1,000-run fuzz tests, independent dividend invariants, and expanded Uniswap v4 coverage under test/.

Validation: forge build passed; forge test reported 41 passed, 0 failed, 2 skipped, including 20,480 invariant calls.

Live mainnet fork verification remains pending RPC configuration. Setup is documented in TESTING.md. No reproducible implementation defects found.

Updated only launch.json, preserving the exact supply, constructor arguments, economics, and required pool settings while clarifying behavior and price provenance.

Validation passed: supplied schema, constructor ABI, and forge build. forge test: 41 passed, 0 failed, 2 skipped. Mainnet fork suites skipped because no RPC was configured.

I found two economic defects and wrote them to .imd-findings.json. I changed no project files; the scratch tests are deleted.

1. High: buy-fee dividends get stuck on the swarm's Merkle distributor (src/SIMDTESTToken.sol:70)

• Cause: the token excludes only the PoolManager, itself, the burn address and the zero address from dividends. The distributor holds 100M tokens from launch, so it counts as an ordinary holder.
• Effect: right after launch it holds almost all of the eligible supply, so it is credited with most of each buy fee. It can never call claim(), and when it hands tokens to Merkle claimants the credit stays behind on it. Those fees are locked in the token contract for good.
• Reproduction: the first buy is 10,000,000 SIMDTEST out of the PoolManager, so the fee is 300,000. Of that, 273,473 (91%) goes to the distributor and only 26,527 to the buyer. After the distributor releases all its tokens, the claimant can withdraw 0 and the 273,473 stays stranded.
• Proof: the finding includes a Foundry test that fails on the current code for exactly this reason.
• Fix: exclude the distributor and the factory. Either take the factory address and launch number as constructor arguments and look up distributorOf(launchNumber), or treat the factory's first recipient as excluded.
• Existing test: test/UniswapV4.t.sol:139 currently asserts that the distributor earns dividends, which builds the bug into the suite. It will need updating with the fix.

2. Medium: large buyers get most of their own 3% fee back (src/SIMDTESTToken.sol:140)

• Cause: the fee is shared out only after the buyer's tokens are counted as eligible.
• Reproduction: a 400,000,000 buy against 100M already eligible pays a 12M fee, then claims 9.54M of it back. The real cost is 0.61% instead of 3%, and the other holders get 2.46M instead of 12M.
• Interaction with finding 1: if the distributor is excluded, nothing is eligible at launch, so the first buyer would get its whole fee back.
• Status: the README describes this ordering as intended, but it contradicts the 3% buy fee paid to holders. No proof test, since only high and critical findings need one.

Coverage record:

• transfer, transferFrom and claim() are marked as findings (#1, with transfer/transferFrom also hitting #2); approve holds.
• Three invariants hold:
  • The supply stays fixed.
  • Claimable dividends never exceed the fee reserve, including overflow bounds.
  • The PoolManager loses exactly the gross amount on buys and receives exactly the amount sent on sells.

Other notes:

• I ruled out other leads: overflow in the dividend index, shortfalls in v4 settlement, and the PoolManager's flash-accounting route. The two static-analysis items (aderyn, low) have no economic impact, so I left them out.
• The project doesn't include forge-std. To run the proof I pointed a command-line remapping at a copy already on this machine; the verifier will need forge-std available the same way.
• The spec's "1.25% (12500)" pool fee conflicts with the required fee 3000 in launch.json. I treated the build requirement as authoritative and didn't report it.

Review complete. The findings file is written and the scratch test is removed; the tree has no tracked changes.

Outcome. One medium finding, one informational note, and coverage rows for all four entry points plus four invariants, in .imd-findings.json.

Medium: the swarm distributor's 10% earns dividends nobody can claim. The token takes no launch addresses and never looks up the distributor, so the MerkleDistributor is an ordinary eligible holder. At launch it holds essentially the entire eligible supply, since the pool and the burn address are excluded. A scratch test on this tree confirmed the split for a first buy of 1,000,000 tokens:

Earned credit stays with an address after its balance leaves, so the distributor keeps that credit even after every contributor claims their tokens. Unless the platform's distributor can call an arbitrary token's claim function, those fee tokens are stranded permanently, and there is no sweep. The brief promises the fee to holders, so this is a broken guarantee rather than a loss to a specific victim. The fix needs a scope decision: accept the factory and launch number as constructor arguments and exclude the distributor, which the launch rules explicitly allow.

Info: every transfer out of the PoolManager is taxed. Liquidity removals and exact-output buys deliver 97% of the accounted amount. This matches the brief's literal definition and the README, so it is recorded as a trust assumption.

What holds. Allowance handling, atomic reverts, the fee-free sell and seed paths through v4 sync, transfer and settle, supply conservation, dividend solvency, the exclusion predicate being identical in accrual and denominator, and the absence of forbidden opcodes. Overflow in the accrual multiply needs cumulative fees above 2^128 wei, which is unreachable. The price tool and manifest provenance check out. Build and all 41 existing tests pass.

Not reached. The real MerkleDistributor and factory source were not available, so the claim that the distributor cannot invoke claim rests on the platform's generic distributor design. The mainnet-fork test file was not run.

The review is complete. The findings file is written and valid, the scratch tests are removed, and the working tree has no stray files (the findings file is excluded by the repo's own git exclude rules, as the harness expects).

Outcome. The token's permission model is sound: no owner, no admin paths, no proxy, and the four entry points guard exactly what they should. The defects I found are all in the dividend eligibility set and in the asymmetry of the PoolManager-based fee rule, which is where the Asymmetry and Trust Gap guides pointed.

Findings written to .imd-findings.json:

1. Medium. Dividends credited to the MerkleDistributor are locked forever. The exclusion set in isDividendExcluded() omits the launch distributor, which holds the swarm's 100M tokens and is the only eligible balance at launch. The first buys' fees are credited almost entirely to it, and since claim() pays only the caller and the distributor has no claim path, those fee tokens stay in the token contract permanently. Reproduced locally: a 1M-token buy credits the distributor roughly 29,712 tokens that nobody can ever release, and a contributor who later claims from the distributor inherits none of it. The launch framework offers $factory, $launchNumber and distributorOf precisely to exempt it, so a minimal fix exists that keeps the design intact.

2. Low. ERC-6909 claim path bypasses the 3% fee entirely. A trader who settles buys with PoolManager.mint and sells with PoolManager.burn never triggers an outgoing PoolManager transfer. Reproduced on a local PoolManager: a full round trip leaves totalFeesCollected at zero, while the same buy via take pays 3%. This matches the brief's literal definition of a buy and is noted in the README, so I reported it as a design asymmetry to confirm, not a code bug.

3. Low. Third-party liquidity removal is taxed as a buy. Adding liquidity is untaxed, removing it via take loses 3% of the LP's own principal to dividends. Reproduced locally. Also consistent with the brief's definition, reported as a user-class asymmetry.

Coverage. All four entry points have rows, plus four invariant rows. approve and transferFrom hold. claim and transfer carry findings. Dividend solvency, no-retroactive-entitlement, the fixed supply, the absence of privileged paths, and the launch flows all hold. Both aderyn leads were cosmetic and did not reproduce as defects.

No critical or high findings, so no proof files were attached. forge-std is not vendored in this repo, which would have blocked a conforming proof had one been needed; worth noting for the author.

The review is complete and written to .imd-findings.json (2 findings, 10 coverage rows, snippets verified against the source lines). The existing 41-test suite passes locally. No project files were changed; only .imd-findings.json and the scratch proof under test/scratch/ were created.

Findings

• High: the Merkle distributor earns and strands dividends. The exclusion list in src/SIMDTESTToken.sol:70 covers only the PoolManager, the token, 0xdead and address(0). The swarm's distributor holds 100,000,000 tokens from launch, is a plain contract with no way to call claim(), and credit survives its transfers out by design. On the first buy of 1,000,000 gross, the 30,000-token fee splits 29,711.8 to the distributor and 288.2 to the buyer, and the distributor's share can never leave the contract. The proof test fails on the current code and passes on a throwaway patched copy that excludes the distributor. The fix needs the launch's constructor arguments (factory, pool manager, launch number) plus a distributorOf lookup, which the launch guide provides for this purpose. The proof's deployment line will need the new arguments once the constructor changes. This is as much an economic defect as a math one, so I reported it despite it sitting partly outside the assigned area.
• Info: buy fee rounds down. Transfers from the PoolManager under 34 wei pay no fee and larger buys underpay by at most 1 wei. Recorded for completeness of the zero-rounding check. The impact is nil and the README documents it.

What held under the Math Precision, Boundary and Numerical Gap guides

• No overflow in the magnified index or credit math: accounts are checkpointed before every balance change, and eligible supply is at least the holder's balance during each distribution, so credit is bounded by total fees times 2^128.
• Solvency holds: index increments and claims both floor, fractional credit is retained, and queued fees stay reserved.
• All sentinel branches (from or to the PoolManager, to the token, to 0xdead, zero and max amounts) behave as documented; launch flows to the distributor and PoolManager are exact.
• Opening price provenance recomputed by integer square root matches both values in launch.json.

Not reached: the mainnet-fork swap test was not re-run (local v4 PoolManager tests pass), and the production IMD token's transfer behaviour was not examined.

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

Outcome: three findings survive, merged from the nine specialist reports. The two specialist proofs and my own tests all ran against a build of this tree.

1. High, distributor stranding (merged from all four specialists). The dividend exclusion set at src/SIMDTESTToken.sol:70 omits the swarm's MerkleDistributor, which holds nearly the whole eligible supply right after launch and has no path to call claim(). Reproduced: a 1,000,000-token first buy credits 29,711.8 of its 30,000-token fee to the distributor. After two buys, full swarm payout, and every claimant claiming, 88,015 of 90,000 fee tokens remain in the contract with no claimant. I attached my own proof instead of the specialists', because theirs asserts the buyer receives the whole fee, which would break if the author also fixes finding 2. Mine passes on a locally fixed copy that takes factory, PoolManager and launch number and excludes the distributor.

2. Medium, buyer self-rebate (audit_economics). The index update at line 140 divides by eligible supply after the buyer's net balance is credited. Reproduced: a 400M-token buy against 100M eligible gets 9.54M of its 12M fee back, an effective fee of 0.61%. With zero prior eligible supply, which is the launch state once finding 1 is fixed, the first buyer gets the entire fee back minus one wei. I recommended fixing both together.

3. Low, address-based fee definition (merged from audit_permissions and audit_flow). Verified on a local v4 PoolManager: a buy and sell settled through ERC-6909 claims pays zero token fee, while an LP removing liquidity receives 3% less than deposited. Both follow the brief's literal definition and need a hook to change, so this is recorded as a trust assumption for the author to confirm.

Dropped: the fee rounding-down note. Thirty-three wei per transfer is not a defect.

Coverage: all four entry points answered. Transfer and transferFrom point to finding 1. Approve and claim hold. Four invariant rows were added for supply, launch flows, dividend overflow and solvency, and manifest consistency. The manifest will need constructor arguments once finding 1 is fixed.

Fixed both dividend defects: factory/distributor balances are excluded, and buys distribute fees using pre-buy balances, queuing fees when no eligible holder exists.

Updated the manifest, documentation, regression tests, and .imd-responses.json. Recorded the advisory as intended transfer-tax behavior.

Passed forge build, forge test, formatting and manifest checks, plus all 12 mainnet-fork integration tests.

Wrote .imd-findings.json: no findings; all four entry points marked holds.

• Distributor dividend stranding: fixed.
• New-buyer fee rebate: fixed.
• Uniswap advisory: reproduced; consistent with the specified transfer-based fee.

Build succeeded. All 51 existing local tests and both adapted primary-proof tests passed. Four mainnet tests skipped because no RPC was configured; the external protected harness was not run.

No production files changed.