Swap Algorithm
Slippage Curves derived from Scalar Potentials
Bots swap an amount into a source pool (trade-in) which increases that pool’s balance and then this amount is converted into an amount of the target pool where it is deducted from the balance and credited to the trader (trade-out).
The trade-in and trade-out are executed atomically and the swap rate is based on external oracle price feeds, modulated with a function of the states of both involved pools. Swaps furthermore incur a fee which is credited to liquidity providers as a reward (split between the involved trade-out Swap Pool, the Backstop Pool, and the Protocol).
The swap activity and withdrawals from liquidity providers can bring a pool into an unfavorable state. If a pool’s balance for example approaches zero while its liabilities (= initial deposits) remain substantial, then meaningful swapping (out) will not be possible anymore, and liquidity providers will not be able to withdraw their funds directly from that pool (but have to fall back to the “insurance withdrawal” function instead). In a healthy market, the pools should therefore always tend to revert back to a balanced state.
We therefore introduce the concept of potential energy from physics to liquidity pools in order to incentivize traders, arbitrageurs and liquidity providers to contribute to keeping pools healthy. The basic idea is that any action that moves a pool away from a balanced state results in a dynamic slippage that accumulates as a potential. Bringing the pool closer to a balanced state results in the opposite: a dynamic reward that reduces the potential. The idea is analogous to potential energy in other settings, for example the gravitational potential where moving an object away from a large mass requires work to be done while that energy is released when moving the object back to its original location.
Mathematically, we introduce a scalar potential and require all operations on a pool to fulfil certain constraints that keep the pool’s potential consistent with its state. With the potential approach we can prove several desirable mathematical properties with direct benefits for the AMM. For example, operations can be split, merged, and reordered without changing the result - regardless of the exact properties of the scalar potential. That implies fair and predictable behaviour for liquidity providers and traders on the one hand, and that the AMM cannot be exploited through such strategies on the other hand.
This approach thus enables Nabla to support arbitrary scalar potentials (as long as they fulfil a few basic requirements), and thus allows to tailor them to the respective asset’s volatility characteristics.
Nabla uses single-sided liquidity pools to facilitate all swap orders. These swaps are routed directly between two swap pools through the Nabla Router, for the two relevant currencies involved in the transaction.
Multihop swaps are possible between "pool hubs." A pool hub is a combination of a Router, a Backstop Pool, and Swap Pools. If an asset is not available in one pool ensemble but is available in another, the swap is performed using a shared intermediary asset. This means that the asset being swapped out from the initial pool hub is exchanged into a common intermediary asset through the Nabla Portal, and then swapped again into the desired asset in the target pool hub.
This process allows for greater flexibility and liquidity across Nabla, enabling bots to trade between multiple assets even if they are not directly paired within the same pool hub.
There is a flat fee of 0.05% on each swap, which is deducted from the pay-out currency. The collected fee is being split between the swap-out pool LPs, the backstop pool and the protocol. The current fee split (Nabla Mainnet Alpha) is as follows: - 0.025% is accruing to the swap-out pool LPs - 0.025% is accruing to the backstop pool - 0.00% is accruing to the protocol (the DAO can decide to set this to a non-zero value)
All swap fee parameters can be adapted for each pool individually via governance vote.
Last updated