Implementing Orbital: what the paper leaves open

01What we built

The paper ends with the authors noting that “Today, Orbital is just a design.” We turned it into a contract.

• Scope. Three ERC-20 stablecoins with 6 to 18 decimals.
  • All the math runs onchain, with no router, oracle or off-chain quoter.
  • It supports exact-input swaps, per-tick LP positions with several LPs per tick, and fees.
• Ticks. All ticks come from a fixed catalog of 54 planes, each defined by an exact decimal depeg price from 0.999999 down to 0.10.
  • The price step grows tenfold per band: 0.000001 next to the peg, 0.10 far from it.
  • Every pool uses the whole catalog. There is no tick spacing, and fee tiers are independent of concentration.
• Storage. The pool stores only aggregates:
  • $S = \sum x_i$ and $Q = \sum x_i^2$;
  • the interior radius $r_{int}$ and the boundary sums $k_{bound}$ and $s_{bound}$;
  • one integer for the current partition, and a 54-bit bitmap of initialized ticks.
  A swap touches two reserves and reads one tick record per partition it walks. The paper's constant cost in $n$ holds in practice.
• Deployment. The live pool on Polygon holds USDC, USDT0 and DAI, with one LP position at the 0.9997 tick and a 0.01 bp fee. It is deliberately small: the code is not audited, and its entrypoints are owner-guarded. We chose Polygon for two reasons:
  • Cheap gas. An Orbital swap uses more gas than a Uniswap V3 swap (section 06). On Polygon, that difference costs a fraction of a cent.
  • Three stablecoins with real volume and no PSM. USDC, USDT0 and DAI trade actively on Polygon, and no peg stability module swaps them 1:1 at zero fee. Their prices move against each other, so an AMM between them has flow to capture.

We follow the paper's notation: reserves $x$, $v = (1, \dots, 1)/\sqrt{n}$, $\alpha = x \cdot v$, $w = x - \alpha v$, and a tick $(r, k)$ with $s = \sqrt{r^2 - (k - r\sqrt{n})^2}$. With $n = 3$, $\alpha = S/\sqrt{3}$ and $\|w\|^2 = Q - S^2/3$.

02A correction: the consolidated boundary radius

The paper consolidates the ticks in two places, and the two disagree.

• Tick Consolidation, case 2. Two boundary ticks combine into one sphere in the subspace orthogonal to $v$, with radius $s_c = s_a + s_b$.
• Global Trade Invariant. All boundary ticks are treated as a single tick $(r_{bound}, k_{bound})$, with $\|w_{bound}\|^2 = s_{bound}^2 = r_{bound}^2 - (k_{bound} - r_{bound}\sqrt{n})^2$.

The two forms agree for a single boundary tick, or for several on the same normalized plane. Otherwise they differ, and always in the same direction.

Why the root form overstates

• $r^2 - (k - r\sqrt{n})^2 = (r - k + r\sqrt{n})(r + k - r\sqrt{n})$, a product of two linear forms in $(r, k)$ that are both positive on every valid tick.
• So $s(r, k)$ is their geometric mean: concave and homogeneous of degree one, hence superadditive.
• The root of the sums is therefore at least the sum of the roots. Equality holds only when all boundary ticks share the same $k/r$.

Take $n = 3$ with boundary ticks at 0.99 and 0.90. With equal radii, the root form overstates $s_{bound}$ by 30%. With the 0.99 tick ten times larger, it overstates it by 76%.

What we use

The case-2 argument is the right one: boundary reserves add along a common direction orthogonal to $v$. With $r_{int} = \sum r_i$ over interior ticks and $k_{bound}, s_{bound}$ summed over boundary ticks, the invariant becomes

a circle in the $(\alpha, \|w\|)$ plane.

What the sum buys

• When tick $i$ crosses, $r_i$ moves between $r_{int}$ and the boundary sums, and its $s_i$ moves with it.
• With the sum, the circles of the two partitions are internally tangent at the crossing point: their radii are $R$ and $R - r_i$, and their normals there are parallel.
• So the surface is not only continuous across a crossing, it is smooth. The marginal price does not jump when a tick flips. In exact arithmetic, a fee-free round trip through a crossing returns exactly to its start.
• With the root form, the new partition's circle generally misses the crossing point, and the invariant jumps.

We checked the consolidated model against an independent convex program, which maximizes output under per-tick sphere and plane constraints. The two agreed to about $10^{-13}$ on swaps that cross ticks, including swaps that pass the point where the two traded reserves are equal.

A smaller note: the paper's Computation formula sums $x_{int}$ in its first term. The derivation just above it gives $x_{total}$, since $\alpha_{int} = x_{total} \cdot v - k_{bound}$.

03From reals to integers: solving the endpoint, not the path

The paper's procedure

• Compute the trade in the current torus.
• If the common interior point has crossed the nearest plane, solve a quadratic for the exact crossover.
• Flip that tick and repeat with the remaining input.
• Inside a segment, solve the quartic by Newton's method.

Why it breaks in integers

Our first engine followed this procedure.

• In integers, every event must satisfy several independently rounded computations at once:
  • the classification of the reserve sum against the plane;
  • the closed-form crossover;
  • the segment solver's root;
  • a tolerance on both sides of the flip.
• Near an event, sometimes no integer satisfies all of them, and a fail-closed engine reverts a swap that should succeed.
• Two rounds of fixes closed specific configurations, and others stayed open. Bands of input 607 wei wide reverted, and isolated inputs failed while their neighbours passed. The case space (event type × direction × regime × rounding side) is combinatorial.
• Separately, an unbounded Newton on the quartic could converge to the mirror root on the other side of the pair diagonal.

The endpoint view

Add the whole net input first.

• The input reserve $a$ and the untouched reserve $z$ are fixed. Only the output reserve $u$ is free.
• Along that line, $S = a + z + u$ grows with $u$. Every tick plane becomes an integer threshold on $S$: in partition $m$, the next tick $T_m$ is a boundary tick exactly when $$S \geq \sigma_m = \left\lceil \sqrt{3}\,\big(k_{bound,m} + r_{int,m}\,\kappa_{T_m}\big) \right\rceil$$ where $\kappa = k/r$ is the tick's normalized plane.
• These thresholds cut the line into pieces, each with one fixed torus. Neighbouring partitions compute the same integer, so pieces share their seams exactly.
• The engine finds the piece that holds the endpoint and solves once there. On a sphere, when every tick is interior, it uses a closed form. On a torus, it runs Newton, then bisection, inside a certified bracket.
• A state's partition is a function of its reserve sum alone. No event history is needed.

Two rules replace every tolerance

• Certified inside. Every stored state is proven on or inside the surface of the partition its sum selects. The proof uses the exact integers $S$ and $Q$, one square root and outward rounding.
• Doubt favours the pool. When a sign is uncertain, the engine takes the pool-favourable integer: a few wei less output. It reverts only for capacity, slippage or zero output.

What we proved for the stored integers and the pinned constant $\sqrt{3}$

• Every piece lies on the near side of its circle's center, where the arc is steeper than any output line can climb. Inside a piece, the pool side of the line is therefore an up-set of integers. Root selection disappears, and the mirror root with it.
• Consecutive stored circles are internally tangent to within half a unit.
• The search terminates and reverts only for capacity. It returns an output at most 50 wei below the exact integer optimum, or 77 wei at the largest supported radius.

Results

• Across about 780 swaps on six pool states, no swap reverted for a numerical reason; every refusal was a capacity limit.
• 864 swaps checked against an independent oracle land 0 to 3 wei from the integer optimum.
• On our reference fixture, a public swap went from 280,760 to 151,117 gas, and the contract got smaller.

The geometry is the paper's; the algorithm is not. The price is fee attribution, which can no longer follow an exact event path (section 05).

Beyond three assets

The contract fixes $n = 3$. The proof's numeric premises, however, can be recomputed for any $n$ with the same 54-price catalog.

• The up-set property holds for every $n$. For a tick at depeg price $p$, the premise that the arc is steeper than any output line reduces to $p > 0$.
• The endpoint bound has a closed form. Along an output line, the offset to the surface falls at a rate of at least $$\mu = \frac{p_{min}}{\sqrt{p_{min}^2 + n - 1}}$$ where $p_{min} = 0.10$ is the widest tick's price. The endpoint bound is about $3.5/\mu$ wei.

• What tightens is precision at the tightest tick. There, $(s/r)^2 = (n-1)(1-p)^2 / \big(n(p^2 + n - 1)\big)$, which shrinks like $1/n$. From $n = 8$, one constant in the liquidity-repair bound has to be re-derived.

These results cover the premises only. Other steps of the proof use identities specific to $n = 3$ and would have to be redone. In practice, gas limits $n$ before the proof does: each tick crossing updates two fee words per asset.

04Adding and removing liquidity

The paper assumes “each tick has only a single LP” and does not describe deposits or withdrawals once some ticks sit on their boundary. The invariant is homogeneous of degree 2 in $(x, r)$, which gives two rules:

• Interior tick. Adding $dr$ scales the consolidated interior circle by $(r_{int} + dr)/r_{int}$ about its offset $(k_{bound}, s_{bound})$.
• Boundary tick. Adding liquidity translates the point and the circle together, by the tick's own $dk$ along the axis and $ds$ orthogonally.

In both cases, no tick changes class. The virtual reserves $\sum x_{min}$ become dynamic and move with every deposit and withdrawal.

The trap

• An integer state sits slightly inside the surface, and a plain homothety of the reserve point scales that depth too.
• After a large mint, the point sits far inside every output line, and the next swap captures the surplus.
• Our 1,000-run fuzz campaign found exactly this: a minimal round trip returned 390 wei more than its input.
• The fix applies the homothety to the point's radial projection on the circle and keeps the depth unchanged.

Rounding

Each new state goes through the same certification as a swap endpoint.

• If rounding leaves it outside, the scarcest reserve is raised along its own line, with the same search a swap uses.
• The LP pays the difference: the minter deposits a few wei more, the burner receives a few wei less.
• Across 1,076 certifications in our test suite, 97.6% needed no repair, and the rest needed 1 to 3 wei.

05Fees

The paper does not discuss fees. Ours are charged on the gross input. The net input enters the reserves, and the fee stays outside the invariant, owed to LPs. There is no protocol fee.

Attribution follows the paper's own geometry

• The paper shows that $w_{int}$ is parallel to $w_{bound}$.
• So the consolidated boundary tick holds $k_{bound}/\sqrt{n} + s_{bound}\,\hat{w}_i$ of asset $i$, where $\hat{w} = w/\|w\|$.
• Over a segment in a fixed partition, it absorbs $s_{bound}\,\Delta\hat{w}_{in}$ of the input, and the interior tick absorbs the rest. The segment's fee is split in the same proportion.
• Interior fees accrue per unit of $r_{int}$, and boundary fees per unit of $s_{bound}$. A boundary tick therefore earns in proportion to its own $s_i$.
• Each tick keeps a fee history that is updated at every flip. Fees survive flips, full burns and the re-creation of a tick, without granting old growth to a new position.

What is exact and what is not

• The total fee is exact.
• The interior/boundary split is approximate. Segments are cut at closed-form crossing points, which are not certified, along a monotone path from the start partition to the end partition.
• A tick that leaves the boundary and returns to it within one swap is credited as a boundary tick for the whole swap, and the reverse holds for an interior tick. In a four-tick depeg example, this moved about 1.5% of the swap's fee between interior and boundary ticks.

What LPs earn

At a 1 bp fee, Orbital LPs earn exactly 1.00 bp per dollar of volume. LPs spread across three V3 pools earn 1.11 to 1.15 bp, because two-hop routes pay the fee twice. At 1.3 bp, Orbital matches V3 LP income in 10 of 12 benchmark paths, while traders still lose less than on V3 for 100,000-token orders in three of the four configurations.

06Measured against Uniswap V3, V4 and Curve

The test setup

• Every protocol gets USD 1,000,000 of liquidity and a 1 bp trader fee, with the same tokens, order flow and arbitrage search on a local chain.
• V3 means one pool per pair, routed over the better of the direct and two-hop paths. A variant also splits orders optimally between them.
• V4 mirrors the V3 positions and returned identical outputs to the wei on all 504 fills, so only its gas differs.
• Curve is stableswap-ng with A = 2000, and its pool and math contracts are byte-identical to the implementations live on mainnet.
• Every revert is recorded, never worked around.

Where Orbital loses

• Curve at the peg against wider LPs. Against Orbital LPs at 0.999 and wider, Curve needs only 0.04 to 0.86 times the capital to match.
• Volume share. When each order goes to the venue with the best output net of gas, Curve takes most of the volume in every configuration. A tight Orbital LP wins the largest share, 39 to 47%.
• V3 split routing against the widest LP. V3 with split routing beats Orbital when the LP sits at 0.95.

07Open questions

1. Exact fee attribution. Is there a closed form for a segment's boundary share that avoids approximate crossing points, at constant cost?
2. A cheaper fee model. Fees are not in the paper. Ours split each segment between the interior and boundary radii, and every crossed tick must then record its accrued fees, about half of a crossing's gas. Do you see a fee model for Orbital that needs less per-tick work at a crossing?
3. Tick spacing. Every crossing costs gas, which argues for fewer planes, while LPs want fine choices near the peg. Our catalog uses decimal depeg prices in tenfold bands. Is there a better criterion, for example equal steps in capital efficiency?
4. Other implementations. Do you know of another implementation of Orbital, onchain or in production? If none exists more than a year after the paper, what do you see as the main obstacle: integer arithmetic, the gas of tick crossings, LP demand, or something else?

08Status

• Polygon factory 0x5bB041af367d4eFF595c9b355083fD6b62786DeD, pool 0xdAdE7FD14d8B9ab2447cdc5C923ebc2b3921c5B9 (USDC / USDT0 / DAI).
• App: orbitaldefi.com/app. SDK: @orbitaldefi/sdk.
• Not audited. Entrypoints stay owner-guarded until an audit.
• The full technical notes, the engine's decision record and its proofs are available on request.
• Contact: [email protected].