# Stabilizer: A Constant-Sum AMM for Zero-Slippage Trading

Stabilizer is a decentralized Automated Market Maker (AMM), similar to Uniswap and Curve, that enables zero-slippage trading across cryptocurrency pairs. In this paper, we demonstrate that an AMM can employ a dual-reserve architecture using a constant-price formula, coupled with an internal balancing mechanism, to consistently quote prices at a targeted level without relying on external price oracles. We further show how to mitigate the inherent risks of this design while preserving liquidity and maximizing returns for liquidity providers.

## Introduction
Decentralized exchanges (DEXs) are among the most widely used platforms in the cryptocurrency ecosystem, with over $20B in total value locked and weekly trading volumes exceeding $100B, according to [DeFiLlama](https://defillama.com/dexs). This activity accounts for 18.4% of global spot market volume in the [first half of 2025](https://docsend.com/view/ih8xx9xnj2dw4g2m). Despite their growth, the majority of trading still occurs on centralized exchanges (CEXs) and over-the-counter (OTC) venues, primarily due to their deeper liquidity and superior pricing. Weekly spot volumes on CEXs alone exceed [$1T](https://www.coingecko.com/en/exchanges), an order of magnitude higher than DEX volumes. This 10X gap highlights a significant opportunity to explore new AMM designs capable of closing the liquidity and pricing efficiency gap.

The largest DEX, [Uniswap](https://app.uniswap.org/swap), uses a simple constant-product market maker (CPMM), which enforces the invariant:

$$ x \cdot y = k $$

This mechanism inherently introduces price slippage: as trades shift the balance of reserves, the marginal price changes nonlinearly, increasing more rapidly as one asset becomes scarce.

[Curve Finance](https://www.curve.finance/dex/ethereum/swap) introduced the StableSwap invariant to provide lower slippage and more efficient pricing for assets that trade near parity. The design incorporates an amplification coefficient $A$, which controls how closely the AMM behaves like a constant-sum model near the peg, while still falling back to constant-product behavior when the pool becomes imbalanced.

The StableSwap invariant is given by:

$$A n^{n} \sum_{i} x_{i} + D = A D n^{n} + \frac{D^{n+1}}{n^{n} \prod_{i} x_{i}}$$

where $D$ is the total liquidity invariant (equivalent of $k$) and $n$ is the number of tokens in the pool.
When reserves are close to balanced, the amplification term dominates, flattening the curve and allowing trades to execute with near-zero slippage. As reserves drift further from equilibrium, the constant-product term becomes dominant, ensuring that liquidity cannot be depleted.

To examine this more formally, consider the limiting cases:

* **Limit $A \to 0$: Constant-product behavior**
When $A = 0$, the amplification factor disappears:

$$\frac{D^{n+1}}{n^{n} \prod_{i} x_{i}} = D ⟹ \prod_{i} x_{i}= D $$
which recovers the Uniswap-style constant-product invariant.

* **Limit $A \to ∞$: Constant-sum behavior**
Dividing the invariant by $An^n$, and taking $A \to ∞$ yields:

$$ \sum_{i} x_{i} = D$$
which is the constant-sum invariant, providing zero slippage but being unstable if used alone.

Whereas StableSwap only approximates constant-sum behavior within a narrow region around the peg, reverting to constant-product dynamics to preserve liquidity, its design still inherits the fundamental limitation that a pure constant-sum invariant becomes unstable once reserves drift too far from balance.

Stabilizer addresses this limitation directly. It operates on a true constant-sum AMM, but augments it with a dual-reserve structure and an endogenous stabilization mechanism that together maintain a consistent price level without relying on amplification parameters or external oracles.

This architecture eliminates the slippage inherent in hybrid models while preventing the reserve depletion that traditionally prevents constant-sum AMMs from being used safely, enabling genuinely zero-slippage trading across the entire functional range of the pool.

## How Stabilizer Works
Stabilizer is built on the constant-sum invariant and a rebalancing mechanism that maintains the pool’s desired price level. To motivate the design, we first outline the fundamental properties of the constant-sum AMM.

### Constant-Sum AMM
For two assets $X$ and $Y$, the constant-sum AMM is defined by the linear invariant

$$x+y = k$$

where $x$ and $y$ denote the token reserves, and $k$ represents the total liquidity measure. Under this invariant, the sum of the reserves must remain unchanged after any trade. This model corresponds to the theoretical limit of infinite amplification ($A→∞$) in Curve’s StableSwap, where the curve becomes perfectly flat and all trades execute at a fixed price.


**Figure 1:** The left panel illustrates the linear invariant $x+y =10$, with $k =10$. From the invariant, $$x+y = k ⟹dy = -dx ⟹ \frac{dy}{dx} = -1$$ indicating that for every unit of token $X$ added, exactly one unit of token $Y$ is removed. This creates a perfectly symmetric exchange rate of 1:1, represented by a straight-line invariant with constant slope $-1$.

The right plot shows the corresponding price curve, defined as $$P = -\frac{dy}{dx}$$

Substituting the invariant $x+y = k$ yields $$P =1$$

everywhere, which explains why the price curve is perfectly flat. Its derivative is zero: $$\frac{dP}{dx} = 0$$

indicating that the price does not change with trade size. There is no curvature and therefore no slippage: every infinitesimal trade executes at exactly the same price. While ideal for zero-slippage execution, this also implies that the AMM has no internal price elasticity, and thus cannot respond to external price movements on its own.

Let $p_m$ denote the true external market price of asset $X$ in terms of $Y$. When $p_m \neq 1$, the AMM's fixed internal price $P=1$ deviates from market reality. If $p_m > 1$, meaning that $X$ is more valuable externally, arbitrageurs will buy $X$ cheaply from the constant-sum pool and sell it on external markets. This pushes the pool toward $$x \to 0, \space y \to k$$

Conversely if $p_m < 1$ , traders sell $X$ into the pool to extract $Y$, driving the reserves in the oppoosite direction: $$y \to 0, \space x \to k$$

Thus, although the constant-sum AMM guarantees zero slippage, it is inherently unstable under price deviations. To address this, Stabilizer introduces a second mechanism: a native asset paired with a dedicated set of reserves designed to continuously rebalance the $X-Y$ pool toward a predefined target price.

### Balancing Mechanism
For any pair of pegged assets (e.g., USDT and USDC), a constant-sum AMM is in a balanced state when the pool holds equal reserves: $$x = y$$ This equality defines the **balance condition**, ensuring the AMM prices both assets at a strict 1:1 ratio. However, maintaining this balance across multiple pools cannot be achieved through constant-sum mechanics alone. A constant-sum AMM enforces $x=y$ when already balanced, but it cannot recover balance once trades push the pool into an imbalanced state. External intervention is required to bring reserves back into alignment.

To continuously uphold the balance condition, Stabilizer introduces two additional components:

1. **Protocol reserves**, which hold the underlying backing assets $r$, and
1. **A mint–burn mechanism for USDZ**, the protocol’s native stablecoin.

USDZ exists specifically so the protocol can correct imbalances. When a pool holds excess of the external asset, the system mints USDZ to absorb it; when a pool holds excess USDZ, the system burns USDZ using its reserves to restore balance. Through this process, Stabilizer ensures that for every pool $i$, $$x_i = y_i$$

where $x$ and $y$ represent the quantities of the external asset and USDZ, respectively. Thus, USDZ functions both as the value numeraire and as the balance-restoration instrument that maintains equilibrium throughout the ecosystem.

## Initial Setup

To begin, we assume USDZ is single-collateral and fully backed by USDT. We define the accounting variables for the USDT/USDZ pool as follows:

| USDT/USDZ | Pool Balance (USDT) | Pool Balance (USDZ) | Reserves (USDT) | Circulating Supply (USDZ) |
|:---------:|:-------------------:|:-------------------:|:---------------:|:-------------------------:|
| $i=T$ | $x_{_T}$ | $y_{_T}$ | $r_{_T}$ | $s_{_T}$ |

### Solvency Rule 1 — Global Solvency

USDZ maintains global solvency by requiring that all outstanding USDZ must be fully backed by the protocol’s base asset: $$ s_{_T} = r_{_T}$$ This ensures that the circulating supply of USDZ is always redeemable 1:1 against protocol reserves.

### Solvency Rule 2 — Local Pool Solvency

To guarantee that a constant-sum AMM can always return to its balanced state $x=y$, the protocol must satisfy a local solvency condition. Since the invariant is $x + y = k$, a perfectly balanced pool satisfies $$x = y = \frac{k}{2}$$

Therefore, to ensure that the pool can always be restored to balance, the protocol must be able to supply at least $\frac{k}{2}$ units of USDT. This yields the correct solvency requirement: $$r_{_T}≥ \frac{k}{2}$$

If users mint USDZ and use it outside the pool, then $r_{_T}> \frac{k}{2}$, making the system over-solvent and providing additional buffer for rebalancing operations.

## Calculating Delta

We define two intervention variables, depending on the direction of the imbalance:

* $\Delta y_{_T}$: the amount of USDZ minted and injected when the pool is **USDT-heavy**
($x_{_T}>y_{_T}$). It is swapped for $\Delta x_{_T}$ USDT, and the received USDT is added to protocol reserves to maintain global solvency.
* $\Delta x_{_T}$: the amount of USDT withdrawn from reserves when the pool is **USDZ-heavy**
($x_{_T}<y_{_T}$). It is swapped for $\Delta y_{_T}$ USDZ, and the acquired USDZ is burned to preserve solvency.

Using these intervention variables, Stabilizer ensures that the pool always returns to the balanced state $x_{_T} = y_{_T}$ while respecting the solvency constraints introduced earlier.

There are three possible pool states:

### 1. Unbalanced State 1 — USDT-Heavy Pool ($x_{_T} > y_{_T}$)

The pool contains excess USDT. The protocol must mint $\Delta y_{_T}$ USDZ, swap it for $\Delta x_{_T}$ USDT, and restore balance while preserving solvency.

| State $t=0$ | Control Variable | Balance Condition | Solvency Condition |
|:----------------------------------:|:-------------------------------------------------:|:---------------------------------------------:|:-------------------------------------------:|
| $x_{_T} > y_{_T}, \space r_{_T} =s_{_T}$ | $\Delta y_{_T} \to \Delta y_{_T} = \Delta x_{_T}$ | $x_{_T}-\Delta x_{_T} = y_{_T}+\Delta y_{_T}$ | $r_{_T} + \Delta x_{_T} =s_{_T} + \Delta y_{_T}$ |

The intervention $\Delta y_{_T}$ is computed by solving

$$\left\{
\begin{aligned}
&\Delta x_{_T} = \Delta y_{_T} \\
&x_{_T}-\Delta x_{_T} = y_{_T}+\Delta y_{_T}
\end{aligned}
\right.$$

Substituting the first equation into the second:

$$x_{_T}-\Delta y_{_T} = y_{_T}+\Delta y_{_T}$$

which yields:

$$\Delta y_{_T} = \frac{x_{_T} - y_{_T}}{2}$$

After executing the swap, the received $\Delta x_{_T}$ USDT is added to the protocol reserves, ensuring full solvency.

### 2. Balanced State — Equal Reserves ($x_{_T} = y_{_T}$)

When the pool is already balanced, no action is required.

| State $t=0$ | Control Variable | Balance Condition | Solvency Condition |
|:----------------------------------:|:--------------------------------:|:-----------------:|:------------------:|
| $x_{_T} = y_{_T}, \space r_{_T} =s_{_T}$ | $\Delta x_{_T} = 0, \space\Delta y_{_T} = 0$ | $x_{_T} = y_{_T}$ | $r_{_T}=s_{_T}$ |

### 3. Unbalanced State 2 — USDZ-Heavy Pool ($x_{_T} < y_{_T}$)

The pool contains excess USDZ. The protocol must withdraw $\Delta x_{_T}$ USDT from reserves, swap it for $\Delta y_{_T}$ USDZ, and burn the acquired USDZ.

| State $t=0$ | Control Variable | Balance Condition | Solvency Condition |
|:----------------------------------:|:-------------------------------------------------:|:---------------------------------------------:|:-------------------------------------------:|
| $x_{_T} < y_{_T}, \space r_{_T} =s_{_T}$ | $\Delta x_{_T} \to \Delta x_{_T} = \Delta y_{_T}$ | $x_{_T}+\Delta x_{_T} = y_{_T}-\Delta y_{_T}$ | $r_{_T} - \Delta x_{_T} =s_{_T} - \Delta y_{_T}$ |

We solve the system:

$$\left\{
\begin{aligned}
&\Delta y_{_T} = \Delta x_{_T} \\
&x_{_T}+\Delta x_{_T} = y_{_T}-\Delta y_{_T}
\end{aligned}
\right.$$

Substituting the first equation:

$$x_{_T}+\Delta x_{_T} = y_{_T}-\Delta x_{_T}$$

which yields:

$$\Delta x_{_T} = \frac{y_{_T} - x_{_T}}{2}$$

After the swap, the protocol burns $\Delta y_{_T}$ USDZ, reducing circulating supply and preserving global solvency.

## Multi-Pool Stabilization

We now extend the single-pool mechanism to a multi-pool, multi-collateral system. Consider two constant-sum pools:

* **Pool 1: USDT / USDZ**
* **Pool 2: USDC / USDZ**

Both pools allow zero-slippage swaps, and USDZ acts as the price-anchoring intermediary between USDT and USDC.

### Definitions

| Pool 1 (USDT/USDZ) | Pool 2 (USDC/USDZ) | Reserve 1 (USDT) | Reserve 2 (USDC) |
|:-----------------------:|:-----------------------:|:----------------:|:----------------:|
| $x_{_T}, \space y_{_T}$ | $x_{_C}, \space y_{_C}$ | $r_{_T}$ | $r_{_C}$ |

### System Conditions

| Pool 1 (Constant Sum) | Pool 2 (Constant Sum) | Global Solvency | Local Solvency (USDT) | Local Solvency (USDC) |
|:--------------------------:|:--------------------------:|:---------------------:|:---------------------------:|:---------------------------:|
| $x_{_T} + y_{_T} = k_{_T}$ | $x_{_C} + y_{_C} = k_{_C}$ | $s = r_{_T} + r_{_C}$ | $r_{_T} ≥ \frac{k_{_T}}{2}$ | $r_{_C} ≥ \frac{k_{_C}}{2}$ |

* **Constant sum:** each pool maintains a fixed invariant.
* **Global solvency:** every USDZ is fully backed by USDT + USDC reserves.
* **Local solvency:** each reserve must cover half pool exposure.

We assume the system begins in a fully balanced, fully solvent state:

| Pool 1 Balance | Pool 2 Balance | Global Solvency |
|:--------------------------:|:--------------------------:|:---------------------:|
| $x_{_T} = y_{_T}$ | $x_{_C} = y_{_C}$ | $s = r_{_T} + r_{_C}$ |

### Example 1 — USDT → USDC Swap

A user swaps $\Delta x_{_T}$ USDT and receives $\Delta x_{_C}$ USDC. Both pools become imbalanced:

#### Pool 1 (USDT/USDZ)

* USDT increases
* USDZ decreases

$$x^{'}_{_T} = x_{_T} +\Delta x_{_T} ,\space \space \space \space \space y^{'}_{_T} = y_{_T} -\Delta y_{_T}, \space \space \space \space \space x^{'}_{_T} > y^{'}_{_T}$$

#### Pool 2 (USDC/USDZ)

* USDZ increases
* USDC decreases

$$x^{'}_{_C} = x_{_C} -\Delta x_{_C} ,\space \space \space \space \space y^{'}_{_C} = y_{_C} +\Delta y_{_C}, \space \space \space \space \space x^{'}_{_C} < y^{'}_{_C}$$

Both pools now require symmetric interventions.

#### Stabilizer Response

**Pool 1: USDT-Heavy**

Mint and sell USDZ:

$$\Delta y^{'}_{_T} = \frac{x^{'}_{_T} - y^{'}_{_T}}{2}$$

Swap it for $\Delta x^{'}_{_T} = \Delta y^{'}_{_T}$ USDT

* pool returns to balance:

$$x^{''}_{_T} = y^{''}_{_T}$$

* reserves increase:

$$r^{''}_{_T} = r^{''}_{_T} + \Delta x^{'}_{_T}$$

* USDZ supply increases by $\Delta y^{'}_{_T}$

**Pool 2: USDZ-Heavy**

Buy and burn USDZ:

$$\Delta x^{'}_{_C} = \frac{y^{'}_{_C} - x^{'}_{_C}}{2}$$

Swap $\Delta x^{'}_{_C}$ USDC for $\Delta y^{'}_{_C} = \Delta x^{'}_{_C}$ USDZ and burn it:

* pool returns to balance:

$$x^{''}_{_C} = y^{''}_{_C}$$

* reserves decrease:

$$r^{''}_{_C} = r^{''}_{_C} - \Delta x^{'}_{_C}$$

* USDZ supply decreases by $\Delta y^{'}_{_C}$

### Example 2 — USDC → USDT Swap

The process is symmetric:

Pool 1 becomes USDZ-heavy → buy USDZ → burn from Pool 1.

Pool 2 becomes USDC-heavy → mint USDZ → sell into Pool 2.

The same delta formulas apply:

$$\Delta y = \frac{x - y}{2},\space \space \space \space \space \Delta x = \frac{y - x}{2}$$

Each pool is restored to the balanced state $x=y$, reserves adjust correspondingly, and global solvency is preserved. USDZ’s total supply also stays unchanged: any USDZ minted to rebalance one pool is exactly offset by an equal burn in the opposing pool, while aggregate reserve movements mirror this symmetry.

## Liquidity Measures

We start from the constant-sum invariant:

$$x+y = k$$

and define the total liquidity (and total LP token supply) as

$$L = k$$

Thus, the total amount of LP tokens $L$ is constant across trades and changes only when liquidity is added or removed.

### Deposit Ratios

To add liquidity without changing the pool composition, a user must deposit in proportion to the current reserves:

$$\frac{\Delta x}{\Delta y} = \frac{x}{y}$$

Equivalently,

$$\Delta x = \Delta y \cdot \frac{x}{y} \space \space \space \text{or} \space \space \space \Delta y = \Delta x \cdot \frac{y}{x}$$

depending on which leg the user specifies.

* **Balanced pool ($x=y$):**
$$\frac{x}{y} = 1 ⇒ \Delta x = \Delta y$$

The user must deposit equal amounts of both assets.

* **Unbalanced pool ($x \neq y$):**

The user’s second leg is computed from the pool ratio using one of the two formulas above.

### Single Value Deposits $v$

If the user specifies only a total value $v$, we require:

$$\frac{\Delta x}{\Delta y} = \frac{x}{y}, \space \space \space \space \space \Delta x + \Delta y = v$$

Solving this system yields:

$$\Delta x = v \cdot \frac{x}{x+y} \space \space \space \text{or} \space \space \space \Delta y = v \cdot \frac{y}{x+y}$$

So the user’s deposit is automatically split proportionally to the existing pool composition.

### Reserve Solvency Check on Liquidity Additions

Whenever a user adds liquidity, Stabilizer enforces the local solvency rule

$$r ≥ \frac{k}{2}$$

where:

* $r$ is the protocol reserve backing for the pool’s quote base asset (USDT or USDC),
* $k$ is the pool’s constant-sum invariant.

This condition ensures users cannot push the system into an undercollateralized state by adding liquidity. If a deposit would violate $r ≥ \frac{k}{2}$, the transaction reverts, preventing the creation of liquidity that the system cannot safely support.

### LP Token Allocation

The LP tokens received by user $u$ are defined as:

$$L_{_u} = \Delta x + \Delta y$$

The user’s share of the pool is then:

$$f_{_u} = \frac{L_{_u}}{L}$$

where $L$ is the total LP supply for that pool (with $L= x + y= k$)

### Withdrawals

When the user burns their LP tokens, they receive the same fraction of the current reserves:

$$\Delta x_{\text{out}} = f_{_u} \cdot x, \space \space \space \space \space \space \Delta y_{\text{out}} = f_{_u} \cdot y$$

Thus, deposits and withdrawals are always proportional to the pool’s composition at the time of the operation.

## Fee Parameters

Stabilizer pools specify their trading fee at the moment of pool creation, allowing each market to choose the structure most appropriate for its assets and expected flow. Fees can be set anywhere in the range 0% to 1%, giving governance or pool creators full flexibility to tailor pool economics. Once configured, the fee remains fixed and transparent, ensuring predictable execution for traders and stable revenue expectations for liquidity providers.

In addition to the base fee, Stabilizer includes an `emergencyFee` mechanism that can be activated by a governance guardian in the event of a depeg or abnormal market stress. In such situations, the fee can be temporarily increased (e.g., proportional to the observed depeg) to discourage draining the pool, prevent the protocol from being pushed entirely into the depegged asset, and protect USDZ holders from reserve losses.

## Conclusion

Stabilizer introduces a new class of AMM architecture built on a true constant-sum invariant and an endogenous stabilization mechanism. By separating the roles of pricing and rebalancing, Stabilizer achieves what constant-product and hybrid AMMs fundamentally cannot: zero-slippage execution at scale, with solvency and continuous balance across all pools. At the core of the system is a simple invariant, $x + y =k$, which ensures a perfectly flat price curve and eliminates all price impact during trading. While a pure constant-sum AMM is ordinarily unstable, since any imbalance drives reserves toward exhaustion. Stabilizer resolves this limitation through a dual-reserve structure and a mint–burn mechanism for USDZ, the protocol’s native stablecoin. This mechanism restores $x=y$ after every trade, without relying on external price oracles or arbitrage, creating a self-sustaining balance system that keeps each pool in its optimal trading state.

The consequences are significant. Users receive strictly optimal execution: no slippage, no price drift, no MEV exposure. Liquidity providers benefit from superior capital efficiency, since 100% of liquidity sits at the peg at all times, and from protocol-internal rebalancing flows that protect reserves and generate yield. Aggregators route trades through Stabilizer by default because it consistently delivers the lowest effective trading cost in the stablecoin space, even with trading fees. As a result, Stabilizer is positioned to capture multiples of the volume processed by comparable stable AMMs such as Curve and Uniswap, while generating competitive fee revenue for LPs.

Stabilizer’s architecture is deterministic, transparent, and free from oracle dependencies. Every pool is locally solvent at all times, and the global solvency rule $s=r$ ensures that USDZ remains fully backed under all circumstances. The system scales naturally to multiple pools and collateral types, enabling zero-slippage routing across any supported set of stable assets.