The Newton Swarm launch is implemented, tested and documented. All checks pass with the protected foundry.toml untouched.

Delivered

• src/SNEWT.sol: plain ERC-20, "Newton Swarm" / SNEWT, 18 decimals, mints the full 1e27 units to its deployer. No mint, owner, pause, fee or upgrade path.
• src/SNEWTHook.sol: immutable hook taking $poolManager and $token. The treasury is a compile-time constant. Address mask 0x20CC (beforeInitialize, beforeSwap, afterSwap, both swap return deltas), validated in the constructor without any external call. Creation code is 7.4 KB.
• launch.json with exactly the keys the task lists, and a rewritten README.md covering mechanics, deployment parameters, operational duties, assumptions, and the earlier logo work.
• Dependencies vendored as ordinary files under vendor/ (v4-core, forge-std, solmate's Owned), imported by relative path because the protected config has no libs and forbids a remappings file. Upstream commits are recorded in vendor/*/COMMIT.

Fee mechanics as built

• Fee is feeNow() bps of the IMD that moved through the pool: 4000 bps at initialization, linear to 300 bps over 60 minutes, then 300 forever. LP fee stays a static 1.25%.
• Buy exact-output and sell exact-input take the fee in afterSwap on the unspecified IMD side. Buy exact-input and sell exact-output reserve it in beforeSwap, then afterSwap scales it by the filled fraction and refunds the rest to the swap sender as an ERC-6909 claim.
• Fees accrue as the hook's ERC-6909 claim, so the first buy on a SNEWT-only pool works. sweep() is permissionless and delivers everything to the treasury. Views: feeNow, openedAt, pending, collected, swept.
• beforeInitialize accepts one pool only: contains the token, fee 12500, spacing 60. Oversized amounts revert with UnrepresentableFee, per the accepted domain.

Verification

Check	Result
forge build	clean, no warnings
forge test (offline)	118 passed, 0 failed, fork suite skipped
Fork suite with ROBINHOOD_RPC_URL set	8 passed against the real PoolManager and real IMD
forge fmt --check	passes, also with src test vendor explicit

The hook suite runs twice, with SNEWT as currency0 and as currency1, and covers the four swap shapes at opening, mid-decay and standing fee, price-limited partial fills for all four, a token-only fresh pool, sweep paths, reentrancy, the revert domain, and a fuzzed random sequence checking pending == collected − swept.

Points to note

• The task text required writing launch.json, while the background reference says the manifest step writes it. I followed the task and wrote a complete one.
• The fee basis for "same pattern as live launch #909" is my definition, since the brief gave no arithmetic. It is documented in the README under assumptions.
• On a sell exact-output with a far price limit, the reservation can exceed the fill, so the router's IMD ERC-20 delta goes negative while the refund claim covers it. This is tested and documented as a router consideration.
• Nothing was committed: the branch is a detached HEAD and prior work arrived via automated commits, so the files sit in the working tree as ordinary files for the submission step.

The findings file is present and excluded by the harness's own rule, as intended. Work is complete.

Summary

I added two test files and one fixture tweak under test/, verified the whole suite, and recorded one informational finding. No defect in the hook was found.

What was delivered

• test/SNEWTHook.invariant.t.sol: handler-based invariant suite. The handler drives random bounded sequences of all four swap shapes (with and without price limits, by three actors), time warps, permissionless sweeps, claim gifts to the hook, claim redemptions back to IMD, and liquidity adds/removes. Reverts fail the run. Nine invariants hold after every call on two full deployments at once (SNEWT as currency0 and as currency1): pending + swept equals collected + gifts; the treasury holds exactly what was swept; the fee never exceeds the rate on what actually filled; every outstanding claim is backed by IMD in the PoolManager; the fee curve matches the specified formula; pool identity and the static 1.25% LP fee never change; the hook never holds SNEWT, ERC-20 IMD or ETH; the fixed supply is conserved; refunds are fully accounted for.
• test/SNEWTHook.edges.t.sol: failure paths the existing suite did not reach. Swaps on an initialized but empty pool (no fee, full reservation refunded), a swap on an uninitialized pool with this hook, the largest representable exact-input buy and the smallest unrepresentable one, the fee at every second of the opening hour, timestamp versus block number, a router that does not forward claims, an exact-output sell whose fill is below the reservation, a paired token that blocks the treasury (sweep reverts, swaps continue), and sweeps from the treasury and from a contract.
• test/utils/MockERC20.sol: transfer made virtual so the blocking-token fixture can override it.

Verification

Check	Result
forge build	clean
forge test (offline)	147 passed, 0 failed, 1 skipped (fork suite without RPC)
Invariants, three fuzz seeds	128 runs × 40 depth each, 0 reverts, all pass
Fork suite against Robinhood Chain RPC	8 passed
forge fmt --check test/	clean

Finding recorded in .imd-findings.json, severity info, no fix required. Reserved-side partial fills refund to the PoolManager caller, which is the router, and an exact-output sell that fills below its reservation leaves the swapper with a negative IMD delta that the router must settle. Both follow from the brief's prescribed design and are covered by tests. Integrators need a claim-aware router for price-limited reserved-side swaps.

One caveat worth knowing. Forge 1.8.5 ignores inline forge-config comments on functions inherited from an abstract base. The existing unit suite uses that pattern, so its fuzz run counts fall back to the default of 256 rather than the 512 and 64 written in the file. The suite still passes in about three seconds. My invariant suite avoids the pattern by deploying both currency orderings inside one concrete contract.

The review is complete and the findings file is written at .imd-findings.json.

Scope covered. I audited SNEWTHook and SNEWT against the Pashov Access Control, Trust Gap and Asymmetry guides: the full permission map (every callback, sweep, unlockCallback, the constructor), the two fee paths side by side (reserved-side vs. unspecified-side, full vs. partial fill, buy vs. sell), every storage variable's writers and readers, the manifest against the constructor and getHookPermissions, and the vendored PoolManager's delta plumbing that the hook relies on. The full suite of 147 tests passes, and the protected hook and token floors are satisfied by inspection.

Findings (2):

• Medium, src/SNEWTHook.sol:346. The partial-fill refund on the reserved shapes (exact-input buy, exact-output sell) is minted as an ERC-6909 claim to the PoolManager's caller, which is the router. The README says any router works for full fills, but a full-limit swap still fills partially when the output side runs out of liquidity, which is the launch state. Measured on a SNEWT-only band with a Universal-Router-shaped router: a buyer sending 1,000,000 IMD paid 704,148, the hook kept 167,373, and 118,341 IMD sat stranded in the router. The claim mechanism itself is what the brief mandates, so the actionable part is the inaccurate guarantee and integrator guidance.
• Low, src/SNEWTHook.sol:218. beforeInitialize accepts any initializer and any paired currency and then locks forever. IMD's address is known but not pinned. If the hook ever has code before the factory's initialize, anyone can bind it to SNEWT/junk and the real pool reverts AlreadyOpened. Within the atomic factory flow the precondition is not met, so this is defense in depth.

Coverage. All 28 listed entry points have a row, none unreached. The two hook callbacks above are marked finding; the rest of the hook, the token, and the PoolManager surface hold. Three invariant rows record the zero-net hook delta, the manifest-to-code match (mask 0x20CC, notes 3,164 chars), and the absence of owner, setter, delegatecall or dynamic fee.

Not reached. Nothing in my area was left unexamined. The fork rehearsal against Robinhood Chain is skipped here with no network, as the repo intends.

The findings file is in place at the repository root, excluded from git by the harness as intended, and no source or test file was changed.

Review result: economics audit of SNEWTHook (Economic Security, Invariant, Flow Gap guides)

Outcome. No critical, high or medium defects. The hook's fee economics hold under every lens I applied. I report one low finding and one informational note, both in .imd-findings.json with reproductions, plus 32 coverage rows (all 28 listed entry points, four invariants and the manifest).

What I verified

• Fee definition is consistent across all four swap shapes and both currency orders. The fee is always feeNow() basis points of the IMD the pool itself moved. Reserved shapes (exact-input buy, exact-output sell) size the reservation so that reserved / expected == bps / BPS, and afterSwap scales it by moved / expected on partial fills. Unspecified shapes charge floor(moved * bps / BPS) from the real BalanceDelta. Rounding deviations are bounded at 1 wei and do not compound.
• Hook delta conservation. Mints in afterSwap (fee + refund) exactly equal the hook delta credited after the callback, so the hook never ends a swap with a nonzero delta and every IMD claim is backed by IMD swappers settled. The existing invariant suite confirms this over 5,120 random calls.
• Live-chain behaviour. I ran the fork suite against the real Robinhood PoolManager and real IMD token. All 8 tests pass: initialize, four swap shapes, partial-fill refunds and a sweep to the real treasury. IMD is not fee-on-transfer and does not block the treasury.
• Sweep. Permissionless, checks-effects-interactions, burn and take of the same amount, cannot nest inside another unlock, and a blocked treasury stalls only sweep, never swaps.
• No privileged roles, no setters, no path for anyone to move the hook's claims. The hook never approves or sets an operator on the PoolManager.
• Manifest. Keys, constructor args, permissions, mask 0x20CC, lowercase addresses and 3,164-character notes all check out.

Findings

1. Low. Partial-fill refund goes to the router, not the user. The refund claim is minted to sender, the PoolManager's caller. Routers that are not ERC-6909-aware (Universal Router shape) strand it. Concrete run on this tree: a 10,000 IMD exact-input buy at the opening fee, stopped by a near price limit, filled 506 IMD, the hook correctly kept 203, but 2,655 IMD of refund sat at the router and the user's effective fee on the fill was 564%. The reverse shape, an exact-output sell whose fill is below the reservation, leaves the seller with a negative IMD delta and reverts in standard routers. The authors document this in the README, so I rated it low and attached a failing test anyway. Suggested fix within the spec's claim-refund design: accept an optional refund recipient in hookData, falling back to sender.
2. Info. beforeInitialize accepts any initializer and any paired currency. Safe only because the factory deploys and initializes atomically. If that flow ever split, anyone could open SNEWT against a different token first and brick the real pool with AlreadyOpened.

Not covered. The Robinhood sequencer's timestamp behaviour on the decay curve and the Universal Router's exact bytecode on Robinhood Chain were reasoned from the canonical v4-periphery source, not executed on a fork.

The review is complete and the report is written to .imd-findings.json with no tracked file changed.

Outcome. I found no critical, high or medium defect in the control flow of SNEWTHook. The suite the author shipped passes in full here: 146 local unit and fuzz tests, the nine invariants at 128 runs by depth 40 with fail-on-revert, and all 8 fork tests against the live Robinhood Chain PoolManager and IMD token, which I ran over the network today.

What I traced. For my three guides I walked each swap shape from PoolManager.swap through the vendored Hooks.beforeSwap and Hooks.afterSwap into the hook and back into delta accounting. The hook reads the raw pool delta before the manager subtracts the hook's share, reserves and reconciles so that kept plus refund always equals the reservation, and nets its own transient delta to zero on every path. The sweep path is reachable only through the hook's own unlock call, follows checks before interactions, and a failing treasury transfer never touches swaps. The manifest is schema-valid, constructor order and permission bits match, and the notes string is well under the limit.

Findings reported.

• Low. The partial-fill refund claim is minted to the PoolManager's caller. Routers that settle like the Universal Router cannot move ERC-6909 claims, so a liquidity-exhausting exact-input buy strands the refund. With a 10,000 IMD buy on a thin pool the swapper lost about 2,846 IMD to the router while the pool filled only 28 IMD. An exact-output sell that fills below its reservation reverts in such routers instead of partially filling. This is the mechanism the spec prescribes, so I framed the recommendation as documentation and routing guidance rather than a code change.
• Info. The FeeTaken event derives its direction from the pool delta, so a zero-fill buy is logged as a sell. Accounting is unaffected.

Coverage. All 28 listed entry points have a row, plus rows for the key invariant, the manifest and the periphery libraries. One row is honestly unreached: whether the live IMD token's owner can block transfers to the treasury, which would only stall sweep() while swaps continue.

Two scratch tests under test/scratch/ back the numbers in the report and can be discarded.

The review is complete. The findings file is written at the repository root and validated, and no source file was changed.

What I covered

I audited src/SNEWTHook.sol against the Pashov Math Precision, Boundary and Numerical Gap guides: every division and rounding direction in _reservedFee, _charge, _reconcile and feeNow, every int128 downcast and overflow intermediate, the four swap shapes on full and partial fills, the zero-fill and dust fast paths, and the delta plumbing through v4's Hooks.beforeSwap/afterSwap and PoolManager.swap. The core arithmetic holds: full fills charge exactly the fee rate on the IMD leg, partial fills scale the kept fee by the filled fraction, and the hook's delta nets to zero on every path. The delivered unit, fuzz, edge and invariant suites all pass locally (157 tests, fork suite skipped offline). I also confirmed the manifest's keys, permission list, constructor args and notes length.

Findings written to .imd-findings.json (4 findings, 33 coverage rows, all 28 listed entry points answered)

• Medium. The partial-fill fee refund is minted as an ERC-6909 claim to the PoolManager's caller, the router. A delta-only router of the V4Router/Universal Router shape cannot move claims, so the refund is stranded and the user overpays by reserved - kept. Measured on a launch-like one-sided pool: a 1,000,000 IMD exact-input buy that exhausted liquidity left 145,224 IMD stranded, a 14.5% overpayment. The README acknowledges the router-claim shape, so the finding is about measured impact and the fact that the launch cannot enforce claim-aware routing. The brief mandates claim refunds, so I listed the design alternative (take the fee on the unspecified side in afterSwap and convert in-callback) and the documentation fallback.
• Low. An exact-output sell whose fill is below the reservation gives the seller a negative IMD delta. A seller holding no IMD, or any delta-only router, cannot complete the trade, which is likely during the opening hour when the reservation is 40% and the pool holds only buyers' IMD. The accounting is sound and a claim-burning router can settle it.
• Info. Reserved-side fees round up to a whole wei. A 2-wei exact-input buy keeps 100% of the 1-wei pool leg. Dust-level, non-compounding, in the hook's favour.
• Info. The hook's revert domain is narrower than the brief's and v4's. Specified amounts above about 2.4e38 wei revert UnrepresentableFee with a price limit even though a hookless pool fills them. Unreachable with any plausible IMD balance.

No critical or high findings, so no proof files were required. The scratch probes that produced every number sit under test/scratch/ and pass alongside the delivered suite.

What I could not reach

Fork behaviour against the real IMD token and PoolManager on Robinhood Chain needs network access, which this machine does not have. The fork suite is still owed a live run.

The review is complete. The findings file is written at the repository root with six findings and a 30-row coverage record, and no tracked file was changed.

Outcome. The code is sound in its own accounting. Every specialist finding reproduced, and all four areas reported the same root cause, which I merged into one medium finding plus one low companion. I found nothing new of medium or higher after my own pass over the hook, the token, the manifest, and the vendored v4-core, which I diffed against upstream at the pinned commit and found byte-identical apart from one import path.

Findings kept:

• Medium, refund stranded in delta-only routers. For exact-input buys and exact-output sells the hook reserves the full-fill fee in beforeSwap and mints the unused part as an ERC-6909 claim to the PoolManager's caller, which is the router. Universal Router style routers never move their own claims, so the user pays the whole reservation on a partial fill. This is not limited to price-limited swaps as the README claims: a full-limit buy that exhausts the launch pool's SNEWT-only band fills partially. Reproduced locally with alice paying 704,148 IMD against a correct cost of 585,807 IMD, 118,341 IMD stranded in the router. I attached my own proof test, which fails now and passes with either a hookData refund recipient or no specified-side reservation. The specialist's proof also fails for the stated reason.
• Low, exact-output sell below the reservation. The seller's IMD delta goes negative, so a seller with no IMD or a TAKE_ALL router cannot complete a partial sell. Same root cause, different consequence, reproduced.
• Four info items: unpinned paired currency and initializer, unreachable in the atomic factory flow; zero-fill buys logged as sells in the event; dust rounding keeping up to 100% of a 1-wei fill; revert domain narrower than the brief's wording.

Verification done: full suite passes (147 tests, invariants at 128 runs), the fork suite passes against live Robinhood Chain with the real PoolManager and IMD, and every finding's reproduction ran in test/scratch on this tree.