fix: tolerate hook-funded input on exact-output swaps

[dianakocsis]

Summary

A v4 hook can pay a swap's input on the caller's behalf. When it covers the cost in full, PoolManager hands the router the requested positive output against an input delta of exactly zero. That state is solvent — the hook settles the debt inside the unlock — and core permits it explicitly:

• Hooks.sol:311 — // the caller has to pay for (or receive) the hook's delta
• IHooks.sol:114 — the afterSwap return is documented as "negative: the hook owes/sent currency"

But it is a shape no ordinary pool produces, where positive output always implied a strictly negative input. V4Router assumed that invariant, so a legitimate fully-sponsored route reverted.

Exact output is the only direction affected, because it is the only one that has to discover its input by reading a delta. Exact input divides by the caller's own amountIn parameter, so it can neither divide by zero nor read the sign that overflows.

The two failures

1. Division by zero. The per-hop price guard computes execution price as output ÷ input. A zero input panics 0x12 — even though the realized price is then infinite and clears every finite bound it is checked against. Hit _swapExactOutputSingle, and _swapExactOutput whenever minHopPriceX36 was non-empty (the multihop guard is gated on array presence, not on each bound's value, so it fired even when that hop's own bound was 0).

2. Zero propagation. The multihop loop runs backwards, feeding each hop's input to the previous hop as its required output. A funded hop propagated zero, and PoolManager.sol:193 rejects amountSpecified == 0 with SwapAmountCannotBeZero, unwinding the whole unlock.

Neither risks funds — the unlock is atomic — but a caller loses gas and the route.

Fix

Three lines:

if (params.minHopPriceX36 != 0 && amountIn != 0)   // skip the division; infinite price clears any bound
if (perHopPriceLength != 0 && amountIn != 0)       // same, multihop
if (amountIn == 0) break;                          // nothing upstream left to produce

Skipping the division is correct rather than defensive: an infinite realized price genuinely satisfies every finite minimum. Breaking is likewise not a shortcut — if a hop consumes nothing, the upstream hops have nothing to produce, and _take/_settle already no-op on zero (DeltaResolver.sol:27,38), so untouched currencies settle cleanly and an amountIn of 0 trivially clears amountInMaximum.

The fill check runs before the zero-input branch, so all-or-nothing still holds: a funded hop that underfills still reverts V4ExactOutputUnfilled.

Scope decisions

Over-funding is deliberately not supported. A hook paying more than the cost leaves a credit on the input currency, which still reverts SafeCastOverflow on the negation, exactly as on main. The surplus has no defined owner in a route — collecting it needs a TAKE-based plan no integrator writes today, and in multihop it can land on an intermediate currency the caller never asked to receive. Relaxing this later is non-breaking; shipping ownership semantics and walking them back would not be. Naming the condition would have meant adding an error to IV4Router for zero behavior change, so the interface is untouched and the reasoning lives on _swapInput instead.

Exact input is untouched. Verified structurally: _swapInput is called only from the two exact-output functions.

Corrected two stale comments. // The output delta will always be positive, except for when interacting with certain hook pools named a case the code does not handle — a hook taking more than the whole output leaves a negative delta and the cast in _swapOutput rejects it. Now documented as unsupported rather than reading like reassurance. Handling it properly is follow-up work.

Tests

10 tests, and each of the three fixes has a test that fails without it (verified by reverting src/V4Router.sol and re-running):

test	fails without fix as
..._withMinHopPrice_succeeds	panic 0x12
..._multiHop_...withPerHopPrices_succeeds	panic 0x12
..._multiHop_...skipsUpstreamHops	SwapAmountCannotBeZero
..._threeHop_hookFundsMiddleHop_...	SwapAmountCannotBeZero
testFuzz_...onlyFullSubsidyClearsPriceBound	panic 0x12

The fuzz test pins the boundary from both sides: with an unsatisfiable price bound, only a full subsidy clears it, because only then is the price infinite. Remaining tests are regression and characterization guards.

MockFullySubsidizingHook absorbs a share of whatever the pool actually charged — the existing DeltaReturningHook returns a preset amount, which cannot land the input on exactly zero. It is exact-output-only by construction (the afterSwap return applies to the unspecified currency, which is the input side only for exact output) and reverts rather than misreporting if misused.

Gas

+26 single-hop, +54/hop multihop, +96 bytes. Exact-input paths unchanged.

Note on the second commit

chore: regenerate stale Quoter gas snapshots is unrelated to this fix. CI runs FORGE_SNAPSHOT_CHECK=true, and the committed Quoter numbers were already stale on the base, so the check failed regardless of this change (confirmed by stashing the router change and re-running — the drift persists, and it moves exactInput entries this PR never touches). Kept as its own commit so it can be dropped or cherry-picked independently.

Question for reviewers

Is the multihop break acceptable? When a hop is fully funded, the upstream hops the caller specified silently do not execute. I believe it is correct — there is genuinely nothing for them to produce, the caller receives their exact output, pays nothing, and no currency is left unsettled — but it is a real behavior change worth arguing rather than waving through. test_exactOutput_threeHop_hookFundsMiddleHop_skipsRemainingHops demonstrates exactly what it does to a longer route.

Secondary: does anyone have a hook that deliberately over-pays? That is the case left unsupported above.

🤖 Generated with Claude Code

[staccDOTsol]

quickquick