The Sovryn financial platform is decentralized, permissionless and never takes custody of your keys/coins. To enable trustless trades and swaps, Sovryn uses an oracle-based Dynamic Automated Market Maker (DAMM).
To understand how the Sovryn DAMM works and outperforms other market-making techniques, we must first consider the characteristics of traditional Automated Market Makers. An Automated Market Maker is a decentralized protocol that prices assets based on a mathematical formula. This differs from a conventional order book, which simply stores and matches buy and sell orders. For an order-book system to fulfill an order of "buy asset X at price Y," there must also be a corresponding order of "sell asset X at price Y" to match. Alternatively, AMMs use liquidity pools that contain a balance of both assets, given to the AMM by a liquidity provider. The following concepts are key to understanding AMMs.
If a user purchases an amount of asset X, the payment is made using asset Y and the balance between the tokens in the pool changes. The supply of X in the pool decreases and the supply of Y increases, resulting in an increase in the price of X and a decrease in the price of Y. Because the price of X increases as a result of this purchase, the price of the asset may increase as the asset transfer within the trade itself occurs over the full quantity of the trade. The result is that the price the trader pays is more than originally estimated – this price difference is known as slippage. The higher the trade amount, the more likely it is to impact the price of the asset being traded; thus, larger trade amounts incur higher rates of slippage.
The staked balance indicates the total amount of tokens staked by liquidity providers. It is a record of the pool's obligation to its LPs. The contract (or current) balance indicates the number of tokens actually held by the contract at any time. The current balance can diverge from the staked balance due to relative price movement of one of the assets in the pool. When current balance is different from staked balance, the pool's weights are adjusted to incentivize arbitrageurs to return the current balance back to its staked balance. Although the arbitrage incentive does not always push the balance back to 100% equilibrium, frequent arbitrage operations guarantee that it always remains very close to (slightly below or above) the staked balance.
The current balance can deviate from the staked balance between the time somebody provides liquidity and the time they wish to withdraw it. If the current balance is lower than the staked balance at the time of withdrawal, the liquidity provider's share of the pool is actually worth less than their initial liquidity amount. This is called impermanent loss. It is impermanent because providers can wait for a time where the balances have equalized and withdraw without suffering a loss. Impermanent loss is something every LP should be aware of when providing liquidity. There are several mitigating factors that could offset the impermanent loss. For example, LPs can earn from trade fees and liquidity mining.
Traditional AMMs require LPs to deposit an equal share of both assets to each side of the pool. Liquidity providers who may hold one of the tokens in the pool are forced to purchase the other asset in order to provide liquidity. This limits their potential long exposure to a single token and exposes the LP to price changes and impermanent loss on both sides of the pool.
The Sovryn Dynamic Automated Market Maker (DAMM) is an on-chain liquidity protocol that enables automated decentralized token exchange. The Dynamic aspect of the AMM mitigates impermanent loss and exposure to multiple assets by maintaining a dynamically balanced ratio for the assets in a pool. Within each pool, a trade generates a fee in the asset of the token converted to. For example, a trade of USDT to BTC generates a fee amount in BTC. This fee is distributed between liquidity providers as a reward in exchange for their market-making service. The fees collected by the system and rewarded to LPs can be seen here - What are the fees?
To execute a trade quickly, liquidity is needed. Every market facilitator is bound by this requirement: if somebody wants to buy something, there must be another entity selling it. Traditionally, in centralized systems, large market-makers profit from executing these trades en masse. Sovryn is a decentralized protocol and therefore has an entirely different approach to market-making than centralized exchanges. However, this creates a need for liquidity to facilitate trades and swaps. Without adequate liquidity, the AMM will suffer high rates of slippage and divergence from external market prices. Sovryn overcomes this through liquidity providers. Liquidity providers lock their assets in a pool to act as market-makers in return for LP tokens – a representation and receipt of their share of assets within the pool. Within each pool, a trade generates a fee in the asset of the token converted to. For example, a trade of USDT to BTC generates a fee amount in BTC. This fee is distributed between liquidity providers as a reward in exchange for their market-making service.
There are times where additional incentives/rewards are granted to liquidity providers. Standard liquidity provision will earn fee rewards in return for liquidity. During time periods where liquidity mining is active, providers are rewarded further with SOV tokens, which may be subject to vesting periods.
The Sovryn DAMM does not require equal deposits of both assets within a liquidity pool, allowing liquidity providers to deposit one of the assets on only one side of the pool if they choose. Therefore, while traditional AMMs grant LP tokens in exchange for deposits to both sides of the pool, the Sovryn DAMM grants separate LP tokens for each asset. This simplifies the tracking of the liquidity provided to the pool and can enable dynamic fee reward balancing, rewarding LPs more for providing assets on the side of the pool that is most in need of liquidity.
The Sovryn DAMM utilizes "Liquidity Amplification." This means trading liquidity is concentrated within a specific range of prices rather than providing an unlimited market-making price range. This involves making a trade more expensive, proportionate to its relative size against the current balance and its deviation from the wider market price - this is known as the pricing curve. Price oracles, like Chainlink, can assist in dynamically updating a pool's pricing curve, so an asset's index price (on Sovryn) tracks its external market price. Therefore, when the market price of an asset changes, or there is significant demand for one asset that would cause high rates of slippage, the Sovryn DAMM dynamically updates the pool weights to provide slippage costs that are equal to the market price or demand change. This means that the further a trade of an asset deviates from its market price, and the further it deviates against its weight equilibrium, the more expensive the trade becomes. As a result, arbitrageurs will still have just enough incentive to re-balance prices, while depletion of the current balance would become exponentially expensive, retaining LP's liquidity inside the pool and not in the arbitrageurs' pockets.
In short, where an asset price is within an acceptable range of market price and where weightings are closer to equilibrium, slippage is greatly reduced. Large entity (whale) trades become more expensive, while smaller trades are relatively cheaper.
In most liquidity pools, the liquidity provider is exposed to the risk of impermanent loss. Sovryn’s DAMM reduces this risk through dynamic pool weight adjustment. For example, when liquidity providers add or remove liquidity, the pool asset weights automatically adjust to account for the change in the current balance to maintain fair value. For example, providing BTC to the pool would increase BTC’s weight in the pool, incentivizing arbitrageurs to bring the prices back to equilibrium.
Within, for example, a RBTC/RUSDT pool, the arbitrage incentive is always to convert RBTC to USDT or vice-versa, so that the following conditions are met:
RBTC/USDT pool price= RBTC/USDT market price
current balance = staked balance
Therefore, in the case that RUSDT current balance < RUSDT staked balance (which would result in an impermanent loss for RUSDT providers), the goal is to set the weights of the pool such that the arbitrage incentive of equalizing the pool price and the external market price will subsequently increase the current balance to become equal to the staked balance. In other words, the arbitrageur is incentivized to transfer “staked balance − current balance” RUSDT to the pool in exchange for RBTC. So whenever there is a shortage in RUSDT and the pool is unable to pay back its obligation to RUSDT providers, the pool creates an incentive for the market to fix the deficit immediately.
While not guaranteeing to return the pool balance back to 100% equilibrium, these measures keep the current liquidity balance very close to the liquidity provider’s staked balance. This reduces the risk and severity of impermanent loss – providers can simply wait for arbitrageurs to re-balance the pool before they withdraw their liquidity.
Consider a liquidity pool with two reserve tokens S and R of equal weights, where:
● s = balance of token S
● r = balance of token R
Converting an amount of S tokens into R tokens is based on , where:
● x = input amount of token S
● y = output amount of token R
The conversion formula for any type of weighted-pool is , where:
● w1 = weight of token S
● w2 = weight of token R
As you can see, when , the latter formula reduces to the former formula.
As an example, we can examine an RUSDT/RBTC pool. Let the following denote:
● = RUSDT staked balance
● = RUSDT reserve balance
● = RBTC reserve balance
● = RBTC/RUSDT rate numerator
● = RBTC/RUSDT rate denominator
Where RUSDTs are equal to RBTC (or RUSDTs are equal to RBTCs).
First, note that the market’s arbitrage incentive is always to convert RBTCs to RUSDTs or vice-versa, such that the on-chain price of RBTC/RUSDT will become equal to the off-chain price of RBTC/RUSDT.
Consider the case of . Our goal is to set the weights of the pool such that the arbitrage incentive of equalizing the on-chain price and off-chain price will subsequently increase to become equal to . In other words, we want the arbitrager to transfer RUSDTs to the pool in exchange for RBTC.
Suppose that we’ve set the weights:
● = RUSDT reserve weight
● = RBTC reserve weight
Then:
● A user converting RUSDTs will get RBTCs
● RUSDT reserve balance after the arbitrage conversion will be of course
● RBTC reserve balance after the arbitrage conversion will be
● RBTC/RUSDT on-chain price after the arbitrage conversion will be
● RBTC/RUSDT off-chain price is of course (or if the inverse rates are provided)
Whether either or change, we want to recalculate and such that the arbitrage incentive of making the on-chain price equal to the off-chain price will be equivalent to converting RUSDTs to RBTC, thus increasing RUSDT reserve balances () to be equal to RUSDT staked balance ().
In other words, we want to recalculate and such that = .
Let denote in the following paragraph:
= →
= →
= →
= , where is the Lambert W Function.
After computing , we can represent it as a quotient of integers, ie., = .
Then, since = and = , we can calculate:
• = = =
• = = =