Research Note 001/DeFi · Market microstructure

Golden-Ratio Splitting for Multi-Path CPMM Arbitrage

A constrained-optimization view of splitting a swap across pools on a constant-product AMM — why equal-splitting is suboptimal, where φ and Lagrange multipliers come from, and what belongs on-chain versus off-chain.

Methodology · grounded in our public BofhContract repository · no performance claims

The problem: one trade, many routes, a curved price

A constant-product market maker (CPMM) prices a pool by the invariant x · y = k, where x and y are the two token reserves. Trading an amount in returns the standard Uniswap-V2 fee-aware output:

amountOut = (amountIn · (10000 − feeBps) · reserveOut)
          / (reserveIn · 10000 + amountIn · (10000 − feeBps))

The important property is that this function is concavein the input: each additional unit you push through one pool buys you fewer units of output than the last. Price impact rises with size. Now suppose the same conversion is reachable by several routes — several pools, or several multi-hop paths, each with its own reserves and fees. You have a fixed amount to convert and a choice: how much to send down each route. Because each route's output is concave, concentrating the whole trade on the single “best” route over-pays for impact there while leaving cheaper marginal capacity unused elsewhere. There is a better allocation.

Why naive equal-splitting is wrong

The obvious heuristic — split the amount into equal shares across n routes — ignores that routes differ in depth and fee. A deep, low-fee pool should absorb more of the trade than a thin, high-fee one, because its marginal price impact stays low for longer. Equal-splitting throws away exactly the information (the reserves) that makes splitting worthwhile in the first place. The correct allocation is the one where the marginal output per unit of input is equalised across all routes that receive flow — push the last unit wherever it currently costs the least impact, and keep going until no route is cheaper at the margin than any other. That is a classic constrained optimization, and it is where the structure appears.

Where the golden ratio comes from

Formalise it. Choose allocations x₁, …, xₙ to optimise an output-style objective f(x₁, …, xₙ) under a product-form constraint on the allocations (a normalisation of the form ∏ᵢ xᵢ = const). Introduce a Lagrange multiplier λ and set the gradient of the Lagrangian to zero. The stationarity conditions take the symmetric form:

∂f/∂xᵢ = λ · ∏(j≠i) xⱼ      for every i

so every route is driven to the same marginal condition — the “equal marginal impact” intuition, now exact. Solving the resulting recurrence for the separable objective we studied yields proportions built from powers of φ ≈ 0.618034, the golden ratio. For a four-way split the stationary proportions come out near [φ, φ², φ³, 1−φ−φ²−φ³]; a five-way split extends the same pattern with higher powers of φ. The golden ratio is not mystical here — it is simply the fixed point of the particular self-similar recurrence that this objective-plus-constraint produces. A different objective gives different constants; the method — Lagrange stationarity over a concave, separable problem — is the transferable part. It is elegant, and correct for the idealised problem. It is also only a model of the problem, which is the point of the next two sections.

Precision: the arithmetic underneath

An optimizer like this is only as good as the arithmetic beneath it, and on-chain arithmetic is unforgiving: no floats, fixed 256-bit integers, every wei of rounding visible in the output. Our math library leans on Newton–Raphson iteration for the irrational roots such work needs — sqrt via yₙ₊₁ = (yₙ + x/yₙ)/2 and cbrt via yₙ₊₁ = (2yₙ + x/yₙ²)/3, both converging quadratically and rounding down deterministically — plus fixed-point log2/exp2 helpers and a geometric-mean √(reserveIn · reserveOut) pool-depth metric. These primitives are real and tested. Good numerical hygiene is a prerequisite for this kind of work; it is not, by itself, an edge.

What belongs on-chain — and what doesn't

An elegant allocator is one thing; the right place to run it is another. Three constraints push this kind of optimisation off the chain:

• —The premise often does not hold. The clean derivation assumes several independent routes for the same conversion. Real paths frequently revisit the same pools; once routes share reserves, the separable objective that produces φ no longer describes the true problem.
• —Path selection is the hard part, and it lives off-chain. Deciding which routes exist and are worth trading — discovering pools across many V2 forks, reading live reserves, finding profitable cycles — is a search over fast-moving state. Doing it on-chain would be both wrong-place and ruinously gas-expensive.
• —Gas and adversarial reality dominate. On contested pairs, extraction turns on gas, latency and inclusion — not on a more refined Solidity allocator.

So our production executor is deliberately focused. BofhContractV2 is a non-custodial, sequential constant-product multi-hop / multi-DEX atomic executor: the input flows hop-by-hop along a caller-supplied path, each hop priced with the fee-aware CPMM formula above, every path starting and ending in the base token, and the whole trade atomic — all hops settle or the transaction reverts. Per-hop price impact is computed exactly from x · y = kand checked against a configured cap. Routing and sizing are decided off-chain, where the search lives; the contract's job is to execute a chosen path safely and atomically.

MEV-aware execution, honestly scoped

“MEV protection” for an executor of this kind is not a magic shield; it is a set of guardrails. Atomicity is the foundational one: a multi-hop trade that turns unprofitable mid-path reverts as a whole rather than leaking value. On top of that the contract carries reentrancy guards, deadline enforcement, per-hop price-impact and liquidity validation, and basic rate-limiting. These reduce specific failure modes. They do not, on their own, win an ordering auction — the genuinely decisive MEV defences for a strategy like this (private inclusion, token-safety simulation to avoid honeypots and transfer-tax traps) sit in the off-chain layer, not the executor.

How we work

This note is a faithful sample of the method. We derive the idealised optimum — the Lagrange conditions, the φ proportions, the Newton–Raphson precision layer — because understanding the best-case solution tells you exactly what you trade away when reality forces a simpler design. Then we build the focused thing that survives real chains, and we say what it is and nothing more. The mathematics is worth understanding; the engineering is worth getting right; and the two are not the same decision.

This note describes methodology on EVM / BNB Chain CPMM venues and reflects an early stage of work. It makes no claims about returns, and the code and its scope continue to change.