The closed-form optimal split across fee-adjusted constant-product venues

A router earns its existence in one inequality: splitting an order across several pools can return more than sending it to the best single pool. Everything else — discovery, filtering, floors — is machinery around that inequality. This article works out by how much, where the split point is, which pools deserve a leg at all, and when an extra leg stops paying for itself. It is arithmetic you can redo with a calculator, and the worked example below is included precisely so that you will.

One thing has to be said before the mathematics rather than after it: this derivation is not a description of the deployed solver. The shipped solver allocates in proportion to each venue's depth, in a single pass, and quotes the venues once their shares are already fixed. The closed form is what would replace that allocation, and it has not been wired in. Publishing the derivation while implying it is running would be the exact failure this protocol was built to avoid.

What is prior art here, and what is not

The framing belongs to other people. Angeris, Chitra, Evans and Boyd established that routing an order across constant-function market makers is a convex program, and that its optimality condition is the equalisation of marginal prices across the venues that receive flow; a dual-decomposition algorithm for the same problem appears in Diamandis, Angeris, Evans and Chitra. The water-filling reading of that condition is published language, not a metaphor we invented. The two sections that follow are therefore a restatement, included because a paper that hides its foundations is harder to check.

What we have not found attributed to anyone is the specialisation: an explicit closed form for the fee-adjusted constant-product case, and the observation that venues enter the route in descending order of fee-adjusted spot price. The published treatments reach for a convex solver or a one-dimensional search instead. We present it as a corollary and an implementation result — the arithmetic a contract can afford — and not as a theorem. If it turns out to be written down somewhere we did not look, nothing in the implementation changes and this paragraph is what gets corrected.

Setup, and the two derivatives that decide everything

Consider n constant-product pools trading the same pair. Pool i holds reserves x_i of the input token and y_i of the output token, and charges a fee written as the retention factor gamma_i = 1 - f_i, so a thirty-basis-point fee is gamma_i = 0.997. Sending delta_i into pool i returns the constant-product rule with the fee taken on the way in. We split a total order Delta into legs with sum delta_i = Delta and delta_i >= 0, and maximise total output.

Differentiating once and twice is the whole structural argument. The first derivative is strictly positive and the second strictly negative, so each leg is strictly increasing and strictly concave, and the objective is strictly concave on a convex feasible set. That is worth stating plainly because it is what makes the rest cheap: there is exactly one optimum, any stationary point is it, and no search over local maxima is required.

F_i(d)   = y_i * g_i * d / (x_i + g_i * d)

F_i'(d)  =        y_i * g_i * x_i / (x_i + g_i*d)^2      > 0
F_i''(d) = -2 * y_i * g_i^2 * x_i / (x_i + g_i*d)^3      < 0

A_i := y_i * g_i * x_i      =>   F_i'(d) = A_i / (x_i + g_i*d)^2
                                 F_i'(0) = A_i / x_i^2 = g_i * y_i / x_i

The optimality condition is equal marginal prices

Attaching a multiplier lambda to the budget constraint, the Karush-Kuhn-Tucker conditions say: every pool that receives a leg must return the same amount for the next marginal unit, and every pool that receives nothing must be worse than that common rate even at its very first unit. If two used pools disagreed on the marginal return, moving one unit from the worse to the better would increase the total — so at the optimum they cannot disagree.

The identity at the end of the code block above is what turns that condition into something a contract can evaluate. The marginal return at zero input is exactly the fee-adjusted spot price gamma_i * y_i / x_i, which is read straight from reserves: no oracle, no simulation, no trial swap. Pools therefore enter the route in descending order of that quantity, and admission ends at the first pool whose implied leg would be non-positive. Sorting dominates, so the whole selection is O(n log n).

Closed form for the legs

Solving the stationarity condition for the leg, and then summing over the active set to impose the budget, determines the multiplier in closed form. Two sums over the active set, one division, and one square root per pool. No iteration and no binary search over the split point — which is the entire reason this is publishable as an implementation result rather than as a restatement.

For two pools the substitution can be carried out by hand, giving the form that is easiest to sanity-check. Two checks come free. If the pools are identical then A_1 = A_2 and x_1 = x_2, and the expression collapses to Delta/2 — half each, as it must. And if it returns a value outside [0, Delta], the constraint binds and the whole order goes to the single better pool, which is the same statement as the admission test.

d_i        = (1/g_i) * ( sqrt(A_i / L) - x_i ),   valid iff sqrt(A_i/L) > x_i

sqrt(L)    = ( SUM_{i in S} sqrt(A_i)/g_i )
             / ( D + SUM_{i in S} x_i/g_i )

two pools: d_1* = ( sqrt(A_1)*(x_2 + g_2*D) - sqrt(A_2)*x_1 )
                  / ( sqrt(A_2)*g_1 + sqrt(A_1)*g_2 )

A worked example, to be redone on paper

Two pools on the same pair, both at a spot price of one, one four times deeper than the other, both charging thirty basis points, and an order of Delta = 100. The shallow pool holds 1,000 and 1,000; the deep pool holds 4,000 and 4,000; gamma = 0.997 for both.

Then sqrt(A_1) = 998.50 and sqrt(A_2) = 3993.99, and the two-pool formula gives delta_1* = 20.0 — the order splits in the ratio of the pools' depth, 1:4, which is the answer intuition would guess and a useful confirmation that the algebra is sound. Sending the whole order into the shallow pool returns 90.661; the whole order into the deep pool returns 97.276; the 20/80 split returns 97.746.

The split beats the best single pool by 0.470 output tokens, or 47 basis points of the order. That number is the router's entire economic claim on this trade. Every cost the router imposes — the protocol fee of 28 bps, the cost of an extra leg — is spent out of it, and a router that reports the split output while charging for the extra leg is quoting a number the user never receives.

pool     x_i     y_i    gamma
shallow  1000    1000   0.997
deep     4000    4000   0.997      order D = 100

sqrt(A_1) =  998.50      sqrt(A_2) = 3993.99      d_1* = 20.0

all 100 -> shallow   90.661
all 100 -> deep      97.276
split 20 / 80        97.746      <- +0.470  (47 bps of the order)

Two properties of the curve that matter more than the optimum

Plot total output against the amount routed to the shallow pool and two things appear that the table cannot show. The curve is flat near its peak: being a few units away from the optimal split costs almost nothing, which is why a cheap approximation is defensible where an exact solver is not — and it is the honest defence of the proportional allocation the solver actually ships. And it falls off a cliff on the right, because routing the whole order into the shallow pool is the one genuinely bad decision available.

The practical reading is deflationary about our own derivation. A router that merely avoids the right-hand end has captured most of the value; the closed form is what captures the rest. The gap between proportional-to-depth and equimarginal allocation is real — proportional allocation equalises share of capital, optimality requires equalising marginal return, and the two coincide only when the venues have identical curves and identical fees — but it is bounded by the flatness, not large in the typical case.

When an extra leg stops paying, and why the gate is a heuristic

Each additional leg costs gas. Writing g for the marginal gas of one more leg and p for the gas price expressed in the output token, the (k+1)-th pool should be admitted only when the incremental gain in output exceeds g*p. In the example above, a second leg is worth taking only while gas costs less than 0.470 output tokens; above that, the deep pool alone is the better route including the fee the user actually pays.

Two qualifications belong in the same paragraph as the gate. First, a fixed cost per leg breaks convexity: everything above holds for a given set of venues, and choosing the set when each carries a fixed charge is a mixed-integer problem. Applying the gate greedily down the admission order is exact only if the incremental gains are decreasing in k, which is what makes a single crossing point exist; where that fails, the gate is a heuristic — a good and cheap one, but it should be named as such rather than dressed as an optimum. Second, the comparison is only as honest as p. Turning gas into output-token units requires a price, and a protocol that refuses oracles does not have one lying around; the deployed router applies the gate with a fixed bound rather than a measured cost, and that is a weaker thing than the inequality suggests.

This article publishes no gas figure, and that is deliberate rather than coy. A gas number carries an implied promise of reproducibility, and one stated without a named chain, a pinned block, a declared build profile and warm and cold cases reported separately is not evidence.

The one allocation step that has a proof rather than a rationale

If a venue cannot honour the share it was allocated, the solver reduces the input and promises exactly the clamped output. That is safe for a reason that follows from the shape of every constant-function curve: output is a concave function of input passing through the origin, and any such function satisfies f(lambda*s) >= lambda*f(s) for lambda in [0,1]. Cutting the input by a factor while promising the proportionally reduced output therefore promises no more than the venue will actually deliver. The inequality runs in the safe direction by construction, not by tuning — which is a stronger statement than any threshold, because it does not depend on the threshold being right.

What this derivation does not cover

The derivation assumes each venue is a constant-product curve, that reserves do not move between quote and execution, and that the legs are independent — no two touching the same pool or the same token in a longer path. Concentrated liquidity is piecewise constant-product, so the same water-filling applies inside a tick range, but A_i changes when a leg crosses a tick and the closed form must be applied per range. Stableswap and weighted pools have a different leg function and therefore a different derivative, though the equimarginal condition itself holds for any concave leg and is the part worth carrying into those cases.

Multi-hop routing is not a split at all: it is a composition, where one leg's output is the next leg's input, and the concavity of a composition needs its own argument before any of this transfers. That argument, what survives it and what does not, is a separate article.

Related engineering

• Defeating dust-pool price manipulation: the capital-anchored split allocator ›
• Why splitting a trade across pools costs less: the convexity behind route splitting ›
• Multi-hop routes: why the split derivation does not transfer, and how the floors compose ›