Advanced Automated Market Making: How Nabla Technology is Changing the Game for Forex

Nabla Finance is a next generation automated market maker (AMM) that is optimized for Forex trading. It will be a major component of Pendulum that powers its stable coin trades efficiently.

The unique Nabla design addresses key DeFi challenges. Its single-sided pool design tackles capital inefficiencies in multi-asset pools, improving capital use. Oracle-based pricing combats impermanent loss (IL) and aligns AMM prices with market-fair prices, boosting overall liquidity.

The main feature of Nabla is that it greatly lowers risk for liquidity providers compared to conventional constant function market makers. This brings the following benefits:

• Nabla brings down the “costs of liquidity” by 50–90%, which allows to attract much deeper liquidity (and thus lower slippage).
• Nabla introduces a proper separation between asset provision and risk taking — thus opening up LPing for a much broader audience.
• Classic AMMs are not suited for trading assets, where the price finding happens somewhere else (off chain), as they incur significant, yet unnecessary IL in these cases. Classic AMMs can therefore intrinsically never compete with offchain trading venues with respect to swap costs and efficiency. Nabla solves that.

In this article we will give an approachable introduction into how Nabla achieves these goals.

Constant Function Market Makers

Let us first give a brief recap of how conventional AMMs work. Unlike an order book based exchange, an AMM uses liquidity pools, usually one pool per asset pair that the AMM allows to swap. The simplest version is an AMM with a single pool, e.g., a pool for the asset pair USD/EUR: this pool can hold an amount of USD tokens and EUR tokens and such an AMM makes it possible for users to swap USD tokens for EUR tokens and vice versa. Liquidity providers will initially fill the pool with some amount of USD and EUR tokens and they will then be able to participate in fee payments from trades or will receive other incentives from the AMM.

Users can then readily swap tokens with the AMM at any time and do not have to wait for a matching order as would be required in an order book system. If a user wants to trade, say, USD tokens for EUR tokens, they would transfer their USD tokens into the pool and would receive EUR tokens from the pool in return. The AMM determines the amount of EUR tokens the user receives in return. Ideally the AMM should do this at a rate that is fairly close to the actual mid market exchange rate of these currencies. Of course this is not always possible — if the amount of EUR tokens in the pool is low, then the AMM will not be able to return a sufficient amount of EUR tokens.

In fact the AMM will implement a system of diminishing return: the lower the liquidity of EUR tokens in the pool, the lower the amount of EUR tokens returned for the same amount of USD tokens that the user trades in. If the amount of EUR tokens in the pool is high compared to the amount of USD tokens, then it will return a high number of EUR tokens. If, on the other hand, the amount of EUR pool tokens is low compared to the number of USD tokens in the pool, then it will only return a low number of EUR tokens. Of course this relationship will also hold for the other trading direction. This means that if there is an excess of trades in one direction, then the amount of one of the tokens in the pool will increase over time and the amount of the other token will decrease — which implies that the exchange rate offered by the AMM will also be pushed in one direction accordingly. Thus, traders can influence the exchange rate of the AMM.

The mathematical model used to express the relationship of the amount of USD tokens and EUR tokens in the pool and the exchange rate offered by the AMM is expressed through a simple function, for that reason such AMMs are called Constant Function Market Makers (CFMMs).

That means that the exchange rate offered by the CFMM depends only on the amount of USD tokens and the amount of EUR tokens in its pool — the CFMM does not take the actual exchange rate of the currencies into account. However, the above system will ensure that the exchange rate of the CFMM is close to the mid market rate because otherwise there would be an opportunity for arbitrage that will move the exchange rate of the AMM back to the mid market rate.

Impermanent Loss

This system works well for users that want to execute trades with the CFMM but it exposes liquidity providers to economic risk, which is called impermanent loss.

Impermanent loss occurs when the mid market rate between the currency pairs changes over time. This is easy to see if we assume that there is a single liquidity provider (LP). Suppose that initially the mid market rate between USD and EUR is 1:1 and suppose that the LP provides 1000 USD tokens and 1000 EUR tokens.

Now assume that over the course of a year the value of the EUR drops and is only worth, say, half a USD. Due to the implied arbitrage mechanism of the CFMM, we will find that also the exchange rate of the CFMM will adapt accordingly as arbitrageurs will trade EUR tokens for USD tokens. This means that eventually the amount of EUR tokens in the pool will be comparatively high. The actual amounts depend on the constant function the CFMM implements, typically there would be about 707 USD tokens and 1414 EUR tokens in the pool (this is the example of a constant product market maker). This means that the CFMM will accumulate more of the token that loses relative value whereas the amount of the other token will decrease.

If the LP then intends to withdraw all liquidity from the CFMM, they would only receive 707 USD and 1414 EUR, which would have a total value of only 1414 USD — which is less than the value the LP would own if they did not provide liquidity and simply held the tokens instead, namely 1500 USD.

A similar effect also happens if the EUR gains in value compared to the USD. In this case the LP will receive fewer EUR tokens than they originally provided and will be worse off compared to not providing liquidity in the first place and just holding their tokens.

Proactive Market Makers

Nabla is a proactive market maker: it does not rely on arbitrage to determine the exchange rate but it uses a price oracle to determine the price of the tokens it allows to trade (the exchange rate is also influenced by other factors as we will explain below). This means (under the assumption of a perfect oracle) that no value provided by liquidity providers is lost to arbitrageurs.

In fact, Nabla guarantees that liquidity providers will not experience any loss (apart from some possible security fee): they will be able to recover all tokens they provided as liquidity or they will receive other tokens that have the same value. That means that there is almost no impermanent loss in Nabla. Impermanent loss cannot be completely eliminated — e.g., in case of instant large price movements that are bigger than the swap fees — but the remaining risk will be covered by the backstop pool (more below).

Liquidity provision in Nabla works differently to liquidity provision in CFMMs. In order to not affect the exchange rate of a CFMM an LP needs to deposit some amount of both tokens to the pool or withdraw both tokens from the pool at the same time, in a way that keeps the ratio of the amount of tokens in the pool constant.

In Nabla liquidity provision works in isolation: LPs can provide liquidity for tokens individually and can withdraw liquidity individually. This will almost have no effect on the exchange rate offered by Nabla as the exchange rate is mainly determined by the price feed of the oracle. For that reason these pools are called single sided liquidity pools.

The mathematical model of a CFMM gets quite complex when it intends to allow swaps between multiple tokens, i.e., when more than two tokens (and therefore more than one pool) are involved.

Due to the nature of single sided liquidity pools this is much simpler in Nabla: it supports an arbitrary number of liquidity pools, one for each token. In Nabla these pools are called swap pools. We will see later that there is another special pool, called the backstop pool, that has a different purpose.

Users can execute token swaps between each possible pair of swap pools: they transfer tokens into the appropriate swap pool and receive tokens from the destination swap pool in return.

Reserves and Liabilities

Every swap pool keeps track of two amounts: the reserve, which is the amount of tokens in its pool and the liability, which is the total amount of tokens provided by liquidity providers. Initially both amounts are the same but they can deviate through swaps: as long as LPs do not deposit or withdraw liquidity, the liability stays mostly the same (it will rise slightly due to swap fees). However, the reserve will change whenever a swap happens that involves the swap pool.

We can imagine a swap pool as a glass of water. The reserve is the amount of water in that jar. Initially liquidity providers will fill the glass with water. Assume that afterwards we mark the amount of water in the glass with a pen. This line represents the liability. When a user executes a swap, they will either add more water to the glass (in case they trade into this pool) or they will remove some water from that glass (in case they trade out of this pool). When liquidity providers deposit or withdraw liquidity, the liability will change by that amount — intuitively, we will raise or lower the mark on the glass accordingly.

The main mechanism of Nabla is to incentivize its users to keep the reserve and liability of each swap pool at a balance. In our metaphor that means that each glass should contain an amount of water that is close to its mark.

This happens through a system of rewards and penalties: usually users will be able to trade at the exchange rate given by the price oracle. However, this exchange rate will be slightly adapted: whenever the user executes a swap that moves the reserve of a swap pool further apart from its liability, then they will get a penalty on the exchange rate. If however they execute a swap that brings the reserve closer to the liability, then they will get a reward and will be able to trade at a more favorable exchange rate.

Of course each swap involves two swap pools and the penalty and reward system applies to both pools so that penalties or rewards of both pools are combined. That means that a user can get a particularly high reward if they execute a swap between two pools in a way that equalizes the reserve and liability of both pools at the same time.

Slippage Curve

The reward or penalty of a pool depends only on its current reserve and liability and how they are affected through a swap. The underlying mathematical model is called the slippage curve. Each swap pool has its own slippage curve that can be optimized for the economic behavior of the pool token, e.g., to its stability or volatility.

The slippage curve model is designed in a way that makes Nabla path independent. This means that a sequence of trades can be ordered or split in an arbitrary way and will always result in the same total reward or penalty. Simpler AMMs such as CFMMs also exhibit path independence but Nabla achieves this property even for its more complex model.

Nabla realizes path independence through an idea inspired by the concept of potential energy in physics. The reserve of a swap pool actually consists of two parts: the usable reserve and the accumulated slippage. The latter is usually just a minor part of the reserve. Speaking in terms of our glass of water analogy again, the accumulated slippage is like a thin layer of oil on top of the usable reserve. The accumulated slippage is the sum of all rewards and penalties that have been applied to user interactions that involve this swap pool. Although this makes it look like the accumulated slippage depends on the order of user interactions in the past, its crucial property is that it is completely determined by the current reserve and liability of the swap pool. Thus, the accumulated slippage is itself path independent and behaves similarly to an object that moves through a potential energy field: the potential energy of that object only depends on its current position and not on the path it took to get to that position.

Path independence makes trading with Nabla more predictable and avoids a situation where users split a swap into many small parts or use other complicated schemes to optimize their outcomes. Put differently the main benefit of path independence is that it greatly reduces the design space for attempted economic exploits.

Backstop Pool

The incentive mechanism of Nabla will imply that usually the reserves of each swap pool stay close to their liabilities. This usually ensures that LPs can withdraw all the liquidity they originally provided so that they do not experience any loss.

However, there will be situations where the reserve of a swap pool is lower than its liability and not all LPs can be served if they decide to withdraw. For that reason Nabla uses one additional special pool that is not used for swaps. This pool is called the backstop pool and uses a token that is particularly stable, e.g., a USD token. If there are not sufficient tokens in a swap pool, a swap pool LP can always alternatively withdraw tokens from the backstop pool for the same value (minus a small security fee). This guarantee ensures that swap pool LPs do not experience any loss.

Also the backstop pool requires liquidity providers. Nabla is carefully designed so that neither the swap pool LPs nor the backstop pool LPs experience any loss as long as all token prices stay constant. Opposed to the swap pool LPs the backstop pool LPs are exposed to risk that can be caused by price changes of the swap pool tokens.

Note that also swap pool LPs face a risk when there are neither sufficient tokens in the swap pool nor in the backstop pool. Thus, Nabla provides extra incentives for backstop pool LPs to keep the backstop pool sufficiently filled so that any risk for swap pool LPs gets minimized — and furthermore, additional security features ensure that swap pool LPs are always covered.

Many activities in Nabla cost a fee, particularly when users execute a swap. This fee is distributed to LPs. Due to the risk exposure, backstop pool LPs take a relatively high share of all generated fees. More precisely, the total share for the swap pools is higher (e.g. 70:30), yet the relative share (compared to the pool sizes), and therefore the fee APR is much higher for the backstop pool.

Pendulum’s Forex DEX Powered by Nabla Technology

Scheduled for a Q1 release, Pendulum’s Forex DEX leveraging Nabla’s technology, is set to bring Forex trading onchain and improve stablecoin utility for the Polkadot and Stellar ecosystems. It will enable single-sided liquidity provisioning, effectively mitigating impermanent loss issues. To discover more, you are welcome to ask any questions in the Nabla and Pendulum communities.

About Nabla

Spot AMM making LPing profitable for all. Deep liquidity for crypto & RWAs.

About Pendulum

Building the missing link between fiat and DeFi through a fiat-optimized smart contract blockchain based on Polkadot’s Substrate. Allowing traditional finance fiat services to integrate with DeFi applications such as specialized Forex AMMs, lending protocols, or yield farming opportunities. Developed by SatoshiPay.

Keep your eyes on the Pendulum!

Twitter | Telegram Announcements | Telegram Community | Discord | Reddit