Implemented the hook, standard DCA token, NFT/oracle lifecycle, vendored dependencies, and deployment documentation.

Verified: forge build, all 67 tests, and forge fmt --check pass.

Router restrictions apply in the hook; wallet transfers remain unrestricted. Required owner settings and assumptions are documented in README.md.

The review found no permission bypass: no unprivileged caller can take the hook's ETH, IMD, FWA claims or NFTs, or set a winner. It did find four defects in the award design and one note on owner trust. All are in .imd-findings.json with a coverage row for each of the 33 entry points. I changed no other files. The existing suite passes (67 tests), and I checked that every snippet matches its cited line. None of the findings is high or critical, so none carries a Foundry proof. Each has a step-by-step reproduction instead.

Findings

1. Medium: anyone can burn the hook's IMD with repeat picks (src/NFTAwards.sol:319). After an empty answer, anyone can call pick() again right away, but it asks about the same fixed block window, so it always gets the same empty answer. Each repeat spends 0.5 IMD of the shared budget, which can starve other NFTs' picks. Whoever calls claim() or FWA's finalizeUnsettled also chooses the block that ends the window, so they can end it after a quiet stretch. That NFT then stays undeliverable until the owner widens lossWindowBlocks, which changes the window for every NFT.
2. Medium: the ranking can be won by splitting a trade across two wallets (src/DCAHook.sol:217). Trades are credited to whoever sent the transaction, and DCA transfers freely. Buying from wallet A, transferring the DCA to wallet B and selling from B records A's full buy as FWA put in. It costs about 4.5% in fees, so A beats an honest wallet that put in less than A's gross buy. Fixing this needs a decision about how the ranking treats DCA that leaves a wallet.
3. Low: the router lock only covers swaps (src/DCAHook.sol:157). No liquidity callbacks are enabled, so anyone can place a one-sided "range order" position and remove it after other trades cross it. That trades DCA for FWA with no approved router, no 1% hook fee and no Trade event.
4. Low: setDistributor is an owner power the brief doesn't list (src/DCAHook.sol:94). The owner can admit routers FWA hasn't approved, but can't remove ones FWA has.
5. Info: owner trust assumptions (src/NFTAwards.sol:254). The owner can choose winners by setting both the intake and the signer, and can redirect all hook ETH through setFWAPool. The window length is read when pick() runs rather than when the NFT arrives, and it can be set to 1 block. If the owner renounces, the fixed sell price bound can never be updated, so fee conversion can stop for good.

Findings 1 and 2 follow directly from the brief (retry after an empty answer, credit to the transaction sender), so fixing either means changing the design, not just the code.

Coverage: I checked the Access Control, Asymmetry and Trust Gap guides against every entry point. The hook callbacks, quoteFWA, convertFees, unlockCallback, the oracle callback's checks on caller, request and signature, onERC721Received (including spoofed direct calls), the buy/claim/sync/refund/recover paths and all owner setters behave as intended.

I did not cover delta and fee arithmetic beyond what the access paths touch, or the oracle body's format (other specialists' areas). Slither and Aderyn leads were checked and none led to a finding. Also unverified: whether the launch manifest can encode the hook's PoolKey constructor argument; there is no manifest yet.

The review is complete. The findings file is at the repository root (it is excluded from git by a global ignore rule, as the .imd/ inputs are, but it is present and readable), the scratch tests are removed, and no source or configuration file was changed.

Outcome: the fee arithmetic holds; two low findings, no critical or high.

What I traced in my area (Math Precision, Boundary, Numerical Gap):

• Fee math, all four swap modes and both currency orders. For specified-FWA swaps the probe fee is exactly 1% on a full fill (for X = 100k + r the exact-input fee is k; for X = 99k + r the exact-output fee is k, so the cap never bites) and 1% of the actual fill on a partial fill. Unspecified-side fees are floor(gross/100) on sells and floor(in/99) on buys. The Trade value equals the trader's net FWA movement in every case. Rounding is down to one minor unit, which is dust and documented.
• Flash accounting. Mint-before-credit in afterSwap, burn/swap/remint in the nested sale, and the ETH take-or-mint all net the hook's deltas to zero. The existing stateful invariant confirms this.
• External-call boundaries. The FWAV2 acquisitions and listings tuples, the FWA token's isDistributor, and the market hook's exact-input-only rule all match the live ABIs in the reference. The oracle body is valid JSON with the pinned recipe under 512 characters.

Findings written:

1. Low, setETHFWAPool key validation. The fee bound of 1,000,000 rejects Uniswap v4's dynamic-fee flag (0x800000), a key the PoolManager accepts. If FWA migrates its market to a dynamic-fee pool, the owner cannot follow it and every fee stays an FWA claim forever. Reproduced with a scratch test.
2. Low, conversion gas threshold. The nested sale runs only when more than 700k gas remains at afterSwap. Measured against the repository's market mock, the swap succeeds from about 600k gas but converts only at about 909k or more. Because the cheaper deferred path succeeds, gas estimators return the low figure, so wallet-submitted trades leave the fee as a claim rather than ETH in the paying transaction, contrary to the brief's stated guarantee.

Coverage: all 33 listed entry points have a row, 31 holds and 2 finding, plus two invariant rows. Nothing was left unreached. Leads I could not close offline and did not report: whether FWA changes an acquisition's status after settlement (which would make syncRequest and hence recoverNFT unusable for a stuck delivery), and whether a non-receiver-calling ERC-721 could ever be whitelisted by FWA.

The review is complete. The findings file is at the repository root, no source files were changed, and the harness excludes both the findings file and my scratch tests from git as intended.

Outcome

I audited the economics of the DCA hook against the Economic Security, Invariant and Flow Gap guides, with the FWA V2 and oracle-consumer references as the dependency model. The swap-fee accounting is sound. The defects I could substantiate are in the award pipeline and in how accumulated fee claims get sold.

Findings written to .imd-findings.json (5 findings, 35 coverage rows, 1 proof):

1. Medium. pick() can be repeated immediately after an empty oracle answer. A position's window is fixed by its arrival block, so an empty answer repeats forever, and each re-ask spends 0.5 IMD of the hook's budget. Anyone paying only gas drains the whole IMD balance. The proof test in test/scratch/PickDrain.t.sol fails on the current code (5 IMD spent instead of 0.5) and passes once a cooldown applies to answered-empty requests.
2. Low. Accumulated FWA claims are sold in one shot down to the absolute owner bound, and any dust swap triggers the sale. Measured on the test market with the bound 10% under spot and 100 FWA piled up: a just-in-time liquidity sandwich cuts the hook's proceeds from 99.0 to 91.3 ETH and nets the attacker about 6.9 FWA. The brief mandates the owner bound, so this is a bounded design leak, but the permissionless trigger and unbounded accumulation make the gap fully extractable.
3. Low. The ranking window ends in whatever block a permissionless claim() lands in, so the award can be bought with a one-block round trip costing roughly 4.5% of the leader's net sum. This follows the brief's definitions, so it is an incentive issue for the requester to decide on.
4. Info. DCA is an unrestricted ERC-20, so trades on any other pool bypass the fee and the ranking. The brief contradicts itself here and the implementation documented its choice.
5. Info. The hook constructor takes a PoolKey struct, which the manifest schema may not be able to express. This is outside my area and flagged as a lead for the manifest step.

What held. Fee math on all four swap modes including partial fills, the mint/burn/remint delta cancellation, the self-only probe, the ETH-claim fallback, the oracle callback authentication, NFT registration keys, and every owner setter. The repository's own 67 tests pass as a baseline.

Not reached. Whether FWA's real recoverStuckNFT and finalizeUnsettled use a safe transfer (the arrival-block pipeline depends on it) cannot be verified offline, so it is noted in the coverage row rather than reported.

Everything validates: both snippets match the tree, no tracked files changed, and the findings file is in place. The review is complete.

Review result

Scope covered: Execution Trace, Periphery and First Principles passes over DCAHook, NFTAwards, OracleAttestation, DCAToken, the interfaces and HookFlags. I traced every swap mode (exact-in/out buy and sell, both currency orderings, partial fills, tiny amounts), the nested fee sale and its rollback paths, flash-accounting deltas, the NFT acquisition/claim/pick/deliver pipeline including pool and intake migrations, the oracle callback, and all owner setters. The vendored oracle library matches the canonical reference byte for byte. The existing 67 tests pass. Coverage rows are written for all 33 verifier entry points plus two invariants, all holds except afterSwap.

Finding 1 (medium, with Foundry proof): src/DCAHook.sol:221. The fee conversion is gated on gasleft() > 700_000 inside afterSwap, and when the gate fails the swap succeeds anyway with the fee left as an FWA claim. The gate is miscalibrated by roughly 3x.

Since the cheap path never reverts, standard gas estimation lands in the skip band, so in practice fees are never sold for ETH in the paying swap, contrary to the brief. Amplifiers: any trader can keep fees in FWA for free, and a searcher can later trigger the batched sale with ample gas and sandwich the whole accumulated balance down to the owner's bound. Suggested fix: revert on insufficient gas instead of deferring (keep deferral only for nested-sale reverts), and size CONVERSION_GAS to the real cost. The proof under test/scratch/ConversionSkippedByGas.t.sol fails now and passes with that fix.

Finding 2 (low): src/DCAHook.sol:68. The constructor takes a PoolKey struct, which the manifest's flat constructorArgs schema has no documented way to encode. Dropping it in favour of the existing setETHFWAPool setter removes the launch risk at no behavioural cost, since conversions cannot run before the owner sets a bound anyway.

Not reachable offline: whether the real FWAV2 delivers NFTs with operator equal to the pool (the receiver callback requires it), whether head is a valid oracle body key (the brief mandates it), and the real router adapters' presence in FWA's distributor registry.

Added failure-path tests, 1,000-run fuzz tests, and two stateful invariant campaigns. Only test/** changed.

Validation: forge build passed; forge test passed 114 tests, with zero failures or skips.

No confirmed implementation defects found. External FWA/Intake integrations use offline mocks; no live fork was run.