06.02.2025|Dave WhiteDan RobinsonCiamac Moallemi
Outline
The future holds a million stablecoins. Today's infrastructure isn't ready.
This paper introduces Orbital, an automated market maker for pools of 2, 3, or 10,000 stablecoins.
Orbital unlocks capital efficiency by bringing concentrated liquidity to higher dimensions.
This is a graph of the reserves of an automated market maker (AMM) between USDC and USDT. When traders add USDT, they get USDC in return. In the middle, where reserves are equal, the coins have the same price. At the edges, one is worthless compared to the other.
Uniswap V3 pioneered the concept of concentrated liquidity. It creates and consolidates mini-AMMs, called ticks, that support more trading with less capital by restricting themselves to only a specified price range. Uniswap v3 allows liquidity providers to create positions between any two tick boundaries, and efficiently aggregates their liquidity so that traders can interact with it as if it were a single pool. However, it only supports pools between two assets.
Curve created an invariant-based AMM that allows trading of N stablecoins in a single pool. It focuses liquidity around the price of 1. However, Curve uses a uniform strategy for each pool, meaning all liquidity providers in the same pool have the same liquidity profile.
Orbital extends customizable concentrated liquidity to pools of three or more stables by drawing tick boundaries as orbits around the $1 equal price point.
Unlike in 2D concentrated liquidity, even if one stablecoin depegs to 0, an Orbital tick can still trade the others at fair prices.
Smaller ticks closer to the equal $1 price point don't need to hold capital in reserve to give out in case one of the coins depegs.
This lets LPs focus their resources where normal trading actually happens, unlocking significant capital efficiency gains.
The full Orbital AMM combines ticks of different sizes so LPs can customize their exposures.
Some might choose to focus narrowly around the $1 point for maximum efficiency, while others might provide wider coverage to earn fees during times of volatility.
Under the hood, Orbital ticks are
Thanks to symmetry, we can orbit some around the others to obtain a single toroid (donut-like) shape.
This lets us compute trades efficiently onchain regardless of the number of different coins in the pool.
The math below gets pretty dense, but it's just trying to formalize a relatively simple visual intuition.
In the 3D case, depicted above, the base Orbital AMM is a sphere. We only show 1/8th of the sphere in the animation because it's the only relevant part assuming prices stay non-negative.
The Orbital tick in the diagram refers to the part of the sphere inside the red circle. The red circle itself forms the boundary of the tick. Note that, unlike in Uniswap V3, Orbital ticks actually overlap, so that larger ones fully contain smaller ones.
We can see from the animation that a Orbital tick can be in one of two states. If prices for all the stablecoins are sufficiently close to the equal $1 price point, then the reserves will be somewhere on the interior tick. But once prices have diverged enough, the tick's reserves will become pinned to its boundary.
Now, imagine we have hundreds or thousands of ticks. Each one of them will either be an "interior tick" or a "boundary tick."
Locally, all interior ticks behave like spheres. Since they are geometrically similar, we can consolidate them all and treat them like a single sphere.
Similarly, all boundary ticks behave locally like circles (in general, in
Logically speaking, we are now dealing with one spherical AMM and one circular AMM. By rotating the sphere around the circle, we obtain a single torus, or donut shape.
The equation of this torus is simple enough that we can compute trades across its surface efficiently onchain. To compute larger trades, we update the equation every time a tick changes from boundary to interior or vice versa.
Luckily, all of this stays true in high-dimensional space, and the rest of the paper goes into the details of how that works.
Orbital is built on top of the Sphere AMM
where
To see that the minimum reserve of any asset is
As long as asset prices are positive, no-arbitrage implies we should never have reserves
and some trader could remove
Let's say a trader wants to give the AMM some token
In this case, we must have
so, abusing notation a bit, we can express the instantaneous price of one unit of
Intuitively we can verify that if the AMM has high reserves of
The most important point on the surface of our AMM is the point where all reserves are equal, so that, by symmetry, all prices are equal.
This should be the the normal state for stablecoins, because under normal conditions they should all worth the value they are pegged to, e.g. $1.
Let's denote this point
By our sphere constraint, we have
So then
so
and we have
Since they're all multiples of
In terms of trading, we can think of
This section introduces a concept and notation we'll be using to work with ticks through the rest of the paper.
Given any valid reserve state
In other words, for any reserve state
Note that because
Viewed through the lens of this decomposition, our AMM constraint becomes
Since
or, rearranging,
From this, we can see that if we hold the component of reserves parallel to
In the interest of simplicity, for the rest of the paper we will act as if each tick has only one liquidity provider. Of course, in practice, we would allow multiple LPs to pool their liquidity into the same tick, just like in Uniswap V3.
As a reminder, ticks in Orbital are nested. Each is centered at the equal price point, and larger ticks fully overlap with smaller ticks. This is in contrast to Uniswap V3, where ticks are fully disjoint.
We can think of a tick geometrically as all the points on the sphere's surface that are within some fixed geodesic distance from the equal-price point.
In the 3D case visualized above, it's possible to intuit that we can construct the boundary of such a tick by slicing the sphere with a plane orthogonal to the vector
We formalize this construction for higher dimensions below.
Any plane normal to
This is another way of saying that the plane consists precisely of all points whose projection on
From the polar reserve decomposition section above, we can see that when reserves lie on this boundary, since the component of reserves parallel to
By symmetry, every point on this boundary will have an equal geodesic distance from the equal price point.
This section is relatively technical and defines the sizes of the smallest and largest ticks that make sense.
The minimal tick boundary would be the equal price point itself, which we derived above as the point
for all
In that case
The maximal tick's boundary is defined by the plane that lets us achieve the highest possible value of
For example, consider
It's still on the sphere because
and we have
To see that this is indeed the maximal tick boundary, note that the reserves of all tokens but
But note that the gradient of
at this point. So if the AMM reduces its
This section explores how tick boundaries affect the minimum and maximum token reserves a tick can hold, and the implications that has for capital efficiency.
Consider an Orbital tick with a plane constraint of
Let's derive the minimum possible reserves of any one of the coins, which we'll denote as
Our sphere constraint then becomes
and our plane invariant becomes
so that
Solving the resulting quadratic equation for
In terms of trading, this will usually represent the situation where all coins but one depeg to a low value, causing traders to remove as much of that still-stable coin as they can from the AMM.
No matter what traders do, they cannot force the reserves of any token
This means the liquidity provider creating the tick can act as if they have "virtual reserves" of
We can repeat the above derivation but flip the sign of the square root to find the maximum quantity of any given coin in the tick assuming both constraints are binding.
Since, if prices are positive, no coin balance will go above
and
In terms of trading, this will normally represent the situation where one single coin loses its peg and falls in value, while the other coins remain stable, causing traders to give the AMM as much of that one coin as they can. We call this a single-depeg event.
If we assume that the most common way things will "go wrong" is a single depeg event of the type described in the section immediately above, then for small enough
Assuming only one coin depegs and the rest stay constant, and that
and
Recall from the section on pricing that the instantaneous price of token
In that case, the tick boundary corresponds to the single token depegging to
We can then invert this to obtain, for a given
Note that for large-enough
As we derived above, given a plane constant
for each of the
So, assuming prices never diverge enough to push reserves past the boundary of the tick, there is a capital efficiency gain of
Using the depeg price formula from the prior section, we can compute how much capital efficiency you get by picking a boundary corresponding to a max depeg price of
log Capital Efficiency Ratio vs. Depeg Price for n=5
For example, in the 5-asset case, a depeg limit of $0.90 corresponds to around a 15x capital efficiency increase, while a limit of $0.99 corresponds to around a 150x capital efficiency increase.
You can view the interactive graph on Desmos here.
A full Orbital AMM consists of multiple Orbital ticks with different
In this section, we discuss situations in which multiple ticks can be treated as one for the purposes of trade calculations. This will set us up to construct a global trade invariant for the overall orbital AMM in the next section.
As a reminder, for the sake of simplicity we will assume each tick has only a single LP.
Imagine we have 2 ticks,
The simplest case is that both reserves vectors begin and end the trade "interior" to their respective ticks, which is to say, not on the tick boundary -- i.e.
In this case, both ticks behave locally like normal spherical AMMs, and it must be that
Since by definition
This means the combined reserves of the two AMMs are equal to
Since our AMM constant is
As soon as one of the reserve vectors hits the boundary of its tick, we can no longer treat the two ticks as a single spherical AMM, and must move on to one of the later cases.
Let's say that both ticks start with reserves that are on their boundaries as defined by their plane constants.
Now imagine that they execute a trade
In this case for tick
This means the trade vector
As we discussed in the section on tick boundary geometry, ticks on their boundaries behave like spherical AMMs in the subspace orthogonal to
where from the section on tick boundary geometry we have e.g.
This section describes how we can locally compute trades using all of our ticks simultaneously. It is extremely dense. Your favorite LLM may be of some assistance if you are wanting to parse it.
First, note that the tick consolidation section above shows we can consolidate all currently interior ticks into a single spherical tick in
We call the total reserve vector of our combined Orbital AMM
for some
We do the same for our consolidated and boundary ticks:
and because
We know that the boundary reserves
by definition, since a boundary AMM always has its reserves on the boundary as defined by its plane constraint.
By the polar reserve decomposition, we also have
so that
Since
we then have that
Construct an orthonormal basis
Since this is just a rotation of the axes, our interior tick is still a spherical AMM between all of these new basis vectors, and our boundary tick, being a spherical AMM in the subspace orthogonal to
From this, we can see that the interior tick and boundary tick must hold the
Since the
Recall from the section on tick boundary geometry that
Since, as we showed in the previous subsection,
Substituting in, we then obtain
Our interior tick's sphere invariant is
by the Pythagorean theorem, this implies
Substituting in our results from the previous sections and simplifying, we then obtain our full invariant
Note this is equivalent to the formula for a generalized torus, a higher-dimensional extension of the familiar donut shape. Intuitively, this is because we are "adding together" the liquidity from the interior tick, a full sphere, with the liquidity from the boundary tick, a lower-dimensional sphere in a subspace, just the same way as a donut is construced by centering a sphere over every point on a circle.
We can directly compute this invariant as
Implementations of orbital should keep track of the sums of reserves and squared reserves that appear in that expression.
Since trades of one token for another affect only two of terms in those sums, we can compute the invariant for trades in constant time regardless of the number of dimensions
Now that we have the global trade invariant, it is straightforward to compute trades.
Let's say a user provides
Starting from some valid reserve state
This is a quartic equation in
The global trade invariant we derived in the previous section assumes that ticks maintain their status as either "interior" or "boundary."
However, during trades, the system's state can change in a way that causes a previously interior tick's reserves to become pinned at its boundary (or vice versa). In that case, we need to remove the tick from the consolidated boundary (interior) tick, and add it to the consolidated interior (boundary) tick, and then update the torus formula accordingly.
In this section, we'll explain how to detect when these crossings happen and how to handle them by breaking the trades that cause them into segments.
Imagine we have several ticks of different sizes, each one a sphere intersected by a plane determined by that tick's plane constant. These spheres might be different sizes depending on their respective radii, but we could imagine "zooming in" or "zooming out" on the spheres so that they all appeared to be the same size, perhaps represented by a radius of 1.
If we were to do this, we would see something interesting: all of the ticks that are currently "interior," i.e. all the ticks whose reserves are not precisely on their plane boundary, would appear to have their reserves at exactly the same point on the sphere. Geometrically, we can say this is because the spheres are similar. In terms of trading, we can say, as above, that this is because otherwise there would be an arbitrage opportunity between the ticks.
Furthermore, ticks have their reserves trapped on their plane boundary and become boundary ticks precisely when this common reserve point strays farther from the equal price point than that tick's plane boundary.
So, in order to trade across ticks, we just compute the trade assuming no ticks have moved from interior to boundary as described in the section on within-tick trades. Then we check the new common interior reserve point and see if it has crossed over the plane boundary of either the closest interior tick or the closest boundary tick. If it has, we compute the trade exactly up to that boundary point, update the type of the tick that was crossed, and compute the rest of the trade.
We use normalized quantities to compare ticks of different sizes by dividing through by the tick radius.
The normalized position is
The normalized projection is
The normalized boundary is
Note that if
Suppose that for a given tick we have
This interior normalized reserve vector has a projection
A given tick
At any given time, the AMM's location in tick space is demarcated by
Let's say we are trying to compute a trade
Calculate Assuming No Tick Boundary Crossing: Assume all currently interior ticks stay interior and all currently boundary ticks stay boundary and compute the potential final AMM state
Boundary Crossing Check: If our assumptions were correct and no ticks changed from interior to boundary or vice versa, then we will have
If that's the case, we're done. Otherwise, we need to segment the trade.
Segmentation (If Crossing Detected)
We know the normalized boundary being crossed from the prior step, which we'll call
So then at the crossover point, we have
where
Find Intersection Trade
We want to find the trade
between
so that we see
Substituting that in to the global invariant formula from above yields a quadratic equation in
Once we find the crossover point, we can execute the trade up to there, adjust the crossed tick from interior to boundary or vice versa, and proceed with the rest of the trade, re-segmenting if necessary.
Today, Orbital is just a design, but we're excited to see how it might change the stablecoin liquidity landscape.
If you're interested in exploring with us, we'd love to hear from you.
Copyright © 2025 Paradigm Operations LP All rights reserved. “Paradigm” is a trademark, and the triangular mobius symbol is a registered trademark of Paradigm Operations LP