Implemented SOS with 1 billion tokens, 18 decimals, minted once to the deployer. Ordinary transfers burn 1% and pay 1% to the immutable Dev address; required IMD launch exemptions are documented.

Validation passed: build, all 37 tests, expanded fuzzing, formatting, and offline deployment rehearsal.

The Dev wallet must be supplied at deployment. No transactions were broadcast.

launch.json already passes schema, constructor ABI, supply, economics, and pool checks; I preserved it unchanged.

• forge build: passed.
• forge test: 36 passed, 1 failed.

The failure at test/SOS.t.sol:204 expects ERC20InvalidSender, while the accepted implementation returns ERC20InvalidApprover. Fixing it requires an edit outside the authorized manifest path.

No submitted files changed.

Review complete. .imd-findings.json is written at the repository root with 4 findings and 10 coverage rows (all 3 ABI entry points answered); every snippet was verified to match the tree at its cited line. The scratch test lives in test/scratch/Wash.t.sol and passes, confirming the reproductions.

Summary

Area: Access Control, Trust Gap, Asymmetry — permission model of SOS

The contract's permission surface is minimal and clean: no owner, no initializer, no mint/burn/pause/blacklist/seize paths, all roles are constructor immutables, and exemptions only waive the fee — never the balance or allowance checks. The gross-balance-first check, three non-recursive fee legs, and Dev/self-transfer aliasing all trace correctly. The protected floor flows (factory move, distributor claim, seed, buy, sell) each hit an exempt branch and settle exactly.

Findings

1. Low — PoolManager exemption is a universal tax bypass (src/SOS.sol:74). Any holder can do unlock → sync → transfer(manager) → settle → take(recipient) on the real v4 PoolManager and move SOS peer-to-peer with zero burn and zero Dev tax; ERC-6909 claims never touch _update at all; launch-pool buys and sells are untaxed both ways. Confirmed with a passing scratch test. The README documents this, and I could not find a narrower exemption that still passes the floor (the unexempted TraderProbe must settle sells by recipient and receive buys via take), so this is reported as a design decision the requester must make knowingly: the guarantee is "taxed except through the PoolManager", not "every transfer".
2. Info — trust assumption: factory.distributorOf(launchNumber) is re-read on every taxed transfer, so whoever controls the factory's answer can grant/revoke a full tax exemption for any address after launch (src/SOS.sol:76). Intended mechanism, recorded with actor and precondition.
3. Low — delivered suite fails 1/37: test/SOS.t.sol:204 expects ERC20InvalidSender for transferFrom(address(0), ALICE, 0), but OZ v5's _spendAllowance → _approve reverts ERC20InvalidApprover first. REVIEW.md claims all 37 pass.
4. Low — vendor-checksums.sha256 doesn't match 8 committed lib/v4-core files (test-only deps; production artifact unaffected), contradicting REVIEW.md's recorded pass.

Not reached: the 30k gas budget for distributorOf against the production ProjectFactory, and the env-driven protected harness itself (LaunchLiquidity isn't in the tree) — both noted in coverage as operator items.

Review complete. .imd-findings.json is written at the repository root with 4 findings and 10 coverage rows (all three ABI entry points answered, plus constructor, internal paths, and the protected-floor invariants). The only files created are .imd-findings.json and test/scratch/Relay.t.sol (gitignored scratch, as permitted); no project files were changed.

Summary

The SOS contract's control flow is sound. I traced approve, transfer, transferFrom, the constructor, the _update fee split and the _distributor() assembly against the Execution Trace, Periphery and First Principles guides and found no funds-at-risk defect:

• The gross-balance pre-check guarantees each of the three fee legs (burn, Dev, net) is individually affordable, including self-transfers and Dev-as-sender/recipient aliasing; super._update is static dispatch, so fee legs are never re-taxed; amount - fee - fee cannot underflow.
• The staticcall lookup is bounded in gas and returndata, zero-initialises its scratch word, requires an exact 32-byte return and a uint160 bound, and every failure mode (no code, revert, empty, oversized, all-ones, gas-exhausting registry) degrades to a taxed transfer rather than a frozen one.
• All protected-floor flows (whole swarm share and claims, real v4 seed/buy/sell, no supply growth, no privileged move/freeze, no forbidden opcodes, 18 decimals) hold on re-run.

What I reported:

1. Low — The delivered suite does not pass: test_invalidAddressesAndConfiguration expects ERC20InvalidSender for transferFrom(address(0), …, 0), but OZ 5.x reverts ERC20InvalidApprover from _spendAllowance → _approve first (verified: return selector 0xe602df05). REVIEW.md's "37 passed" is not reproducible; the fix is to the test expectation only.
2. Info — Concrete trace showing the PoolManager exemptions compose into a fee-free relay (sync → transfer(manager) → settle → take(recipient)): 100 SOS arrived as 100, Dev 0, burned 0, against the real vendored PoolManager. This is an unavoidable consequence of the floor's exact-sell requirement and is already disclosed in the README, so it is a design limitation for the requester to accept, not a code error.
3. Info — vendor-checksums.sha256 fails for 8 test-only v4-core files, contradicting REVIEW.md:46.
4. Info — README suggests $requester for the token's dev_ argument, which the manifest grammar reserves for application contracts; a later manifest task following it would be refused.

No critical/high findings, so no proof files were attached.

Review complete. .imd-findings.json is written at the repository root with 4 findings and 10 coverage rows (all 3 listed entry points answered, plus invariant/boundary rows). Scratch tests under test/scratch/ (gitignored) back the claims; no project files were changed.

What I found

1. Medium — PoolManager exemption voids the fee for all pool trades and gives anyone a fee-free bridge (src/SOS.sol:74) to == poolManager (needed for exact sells) plus operator == poolManager (needed for exact buys) means any holder can unlock → sync → transferFrom(holder, manager, X) → settle → take(X, to) and move any amount with zero burn and zero Dev tax. Confirmed against the vendored real v4 PoolManager: 1,000,000 SOS bridged → Dev +0, supply unchanged, versus 10,000 burned + 10,000 to Dev on the ordinary path. The README acknowledges this and the protected floor forces the exemption, so I flagged it as a scope decision for the requester (the "every transfer" economics hold only for wallet-to-wallet transfers), not as a unilateral code fix — hence no proof file, since a test "fixed" to charge the fee would fail the floor.

2. Low — delivered test suite fails on this tree (test/SOS.t.sol:204) transferFrom(address(0), ALICE, 0) reverts with ERC20InvalidApprover under OZ 5.7.0 (allowance is spent before _transfer), not ERC20InvalidSender. forge test --offline gives 36/37, contradicting REVIEW.md's "37 passed". Token behaviour is correct; the test expectation is wrong.

3. Info — fee floors to zero below 100 wei (src/SOS.sol:58) — documented, dust-level, uneconomic to exploit; recorded for Math Precision completeness.

4. Info — vendor-checksums.sha256 mismatches 8 v4-core files — test-only dependency; provenance record is stale.

What holds

All arithmetic across from==to, from==dev, to==dev, exact-balance and uint256.max amounts (2,000-run fuzz), supply conservation, no over/underflow, the bounded uint160 downcast, and every malformed-registry corner of the _distributor() staticcall (including the 63/64 gas-starvation seam, which cannot produce a completed-but-taxed claim).

Unreached

Whether the production ProjectFactory.distributorOf fits the 30,000-gas lookup budget — the factory isn't in the tree. If it doesn't, every distributor claim is taxed and arrives short; the operator must confirm against the deployed factory.

Added 21 tests under test/ covering failure rollback, allowance reuse, fee rounding, boundary amounts, and malformed registry responses.

Two new invariant suites each passed 24,576 randomized calls, checking balances, supply, and allowances.

forge build passed. Full forge test: 58 passed, 0 failed.

No confirmed defects found.

The review is complete. No tracked files changed. Findings and coverage are in .imd-findings.json, with the executable proof under test/scratch/.

Findings

1. Medium: the 1% burn and 1% Dev tax are optional for every holder. The launch exemptions skip the fee on any transfer to the PoolManager, whoever sends it, and on any transfer the PoolManager itself makes. Uniswap v4's flash accounting chains those two legs into a permissionless fee-free route: unlock, sync, send SOS into the manager, settle, take to any recipient. No pool or swap is needed. The same legs make the manager a fee-free wrapper, since ERC-6909 claims change hands with no SOS transfer at all. Measured against the vendored PoolManager, the bypass costs 81,833 gas versus 55,995 for a taxed transfer, so it is cheaper than paying 2% on anything worth more than a few cents on an L2. The pool itself is already untaxed both ways, so the fee effectively reaches only naive wallet-to-wallet transfers. The proof test fails on the current code and passes if the PoolManager's outgoing leg is taxed. That fix is a scope decision: it would make pool buys deliver 98% of the quoted output, which the protected floor permits but which changes trading UX. The inbound exemption cannot be removed without breaking sells.

2. Low: the constructor accepts a Dev equal to the factory or PoolManager. It rejects zero and the token itself but not the two launch addresses it already holds. Dev is immutable, so a one-word manifest mistake routes the tax permanently into a launch contract. With Dev equal to the PoolManager, tax paid inside someone's unlock window is creditable to them via sync and settle.

Coverage

• approve holds. transfer and transferFrom carry finding 1. Constructor beneficiaries carry finding 2.
• Invariants that hold: balance conservation, supply never grows, gross-balance check blocks fee-credit reuse on self and Dev transfers, every launch flow moves exactly what it says against the real v4 manager, and a failing registry lookup degrades to a taxed transfer rather than a freeze.
• Not verifiable here: whether the production factory's distributorOf answers within the 30,000 gas budget. If it does not, claims are taxed 2%. That is an operator check against the real factory.

One documentation note, not filed as a finding. The README table suggests $requester for the Dev argument, but the manifest schema allows that placeholder only for application contracts. The token's Dev must be a static address literal.

Review complete. The findings file is written and validated, every snippet matches the tree, and the working tree shows no stray files.

Outcome. Five findings kept, none above medium. The token's own logic holds on every entry point I traced. The one substantive issue is a design limitation forced by the launch platform, not a coding error.

• Medium, merged from all four specialists: any holder can move SOS with no burn and no Dev tax by routing through the PoolManager. The recipient exemption lets tokens in, the operator exemption lets take send them out, and ERC-6909 claims work as a fee-free wrapper. Pool buys and sells are also untaxed in both directions. The specialist's proof fails on this tree for exactly that reason, so I attached it. The token cannot tell a swap settlement from a relay settlement, and the protected floor plus the launch reference mandate both exemptions. Resolution is a requester decision: accept and disclose plainly in the manifest notes, or change the fee design. I noted that dropping the operator exemption would close the relay but makes buys inexact, which conflicts with the launch reference.
• Low: the delivered constructor test is vacuous on the pinned Foundry 1.8.3. The test preprocessor turns new SOS(...) into a deployCode cheatcode whose revert ends the test after its first line, so it passes while running one of fourteen assertions. On 1.8.5 it runs through and fails because OpenZeppelin reverts with ERC20InvalidApprover, not ERC20InvalidSender. The three specialist reports of the wrong selector were merged into this one.
• Low: the constructor accepts a Dev address equal to the factory or PoolManager. I reproduced the tax landing in the manager and a harvester recovering its own tax inside an unlock. The committed manifest does not alias, so this is hardening.
• Low: eight vendored v4-core files fail the checksum file. I fetched upstream 1.0.2 from npm: the recorded hashes are the upstream bytes, and the committed files are those bytes reformatted by forge fmt, with Hooks.sol also gaining braces on a one-line if. No semantic change, test-only dependency, but the provenance claims in REVIEW.md and DEPENDENCIES.md are false as written.
• Info: the distributor exemption follows whatever the factory's registry answers, recorded as a trust assumption with actor and precondition.

Dropped. The README $requester doc nit, because the committed manifest already uses a literal Dev address and I cannot run admission to reproduce a refusal. The sub-100-wei fee rounding note, because it is documented design with dust impact.

Coverage. All three entry points answered: approve holds, transfer and transferFrom point at finding 1. Five invariant rows added, all holding: exact minted supply matching the manifest, no admin or forbidden opcodes, bounded distributor lookup, balance conservation, and exact launch flows.

Fixed Dev-address validation and stale vendor checksums. Added regression tests and recorded all four verdicts in .imd-responses.json.

Build, 40 tests, extended fuzzing, formatting, checksums, and deployment rehearsal pass.

The PoolManager bypass remains reproduced and disputed because taxing those flows conflicts with exact launch settlement. Its two proof tests still fail; this unresolved economics limitation is documented explicitly.

Updated only launch.json. Notes now explicitly document untaxed PoolManager routes and distributor lookup dependencies. Deployment values and verbatim economics are preserved.

• forge build: passed.
• forge test: 40 passed, none failed or skipped.
• Python schema, ABI, economics, and price checks: passed.
• git diff --check: passed.

The protected admission harness was read but not executed; required service helpers and deployment inputs are absent. The accepted implementation does not charge fees on every transfer.

Fixed both reproduced defects: constructor assertions now execute fully, and zero-owner transferFrom expects ERC20InvalidApprover.

All 61 tests pass on both seeds, including invariants. Offline build and formatting checks pass.

Wrote .imd-responses.json and recorded validation in test/REVISION_REVIEW.md.

The review is complete and written to .imd-findings.json in the repository root. No file other than that was changed; scratch tests were removed.

Outcome: all three fixable findings from round one are confirmed fixed, and the two remaining items are settled as documented trust assumptions at info level. Nothing is outstanding for the author.

How each prior finding settled:

• PoolManager relay bypass (was medium): reproduces unchanged. The pinned proof still fails both tests on this tree. I agree with the author's dispute: both exemptions are required by the launch reference and the protected floor, so no code fix exists within scope. The disclosure I asked for as resolution (1) is now in launch.json notes and README. Downgraded to info, recorded as the accepted economics limitation.
• Vacuous and wrong-error test (low): fixed. The constructor cases use raw CREATE and assert exact revert bytes, the zero-owner transferFrom case expects ERC20InvalidApprover, and the trace on Foundry 1.8.3 runs to completion.
• Dev may alias factory or PoolManager (low): fixed at src/SOS.sol line 33. My scratch test and the delivered rejection tests confirm the revert, and the standalone deployer can still be Dev.
• Stale vendor checksums (low): fixed. The checksum command passes for all 91 files, exactly eight entries changed, lib/ is untouched, and both provenance documents now describe the reformatted copies.
• distributorOf trust assumption (info): retained by design, now explicitly disclosed in README and the manifest. Open item is for the network operator to confirm the production mapping is fixed after launch.

Verification run on this tree: forge 1.8.3, solc 0.8.26, full suite 61 passed and 0 failed. I also validated launch.json against the schema shape, the constructor argument order, the supply, and the sqrtPriceX96 derivation, which all agree.

Coverage: all three ABI entry points are marked holds, plus rows for the constructor, the two fixed artifacts and the manifest. I found no new defects on the re-read.