### Sigmadex proposes a dynamically calibrated automated market maker algorithm to determine liquidity variables among assets.

## Traditional Centralized Model

Typically, an exchange has an order book that is comprised of many limit orders. Investors who look through the order book find quantities and prices which match what they are looking for.

## Proposed Model

Sigmadex proposes a Dynamic AMM that utilizes an on-chain oracle to calculate price volatility from standard deviation and rebalances price elasticity of liquidity pools which also integrates the following elements to enhance liquidity at appropriate price points:

- Implied volatility using Chainlink V2
- Historical pricing with volume correlation
- Transaction fee adjustment relative to incentivizing the appropriate direction to bring liquidity pools back to equilibrium

### Adding Implied Volatility

The implied volatility of an asset can be derived through the options market for that asset through the Black-Scholes equation.

$$\frac{\partial V}{\partial t}+\frac{1}{2}\sigma ^2S^2\frac{\partial ^2V}{\partial S^2}+ rS \frac{\partial V}{\partial S}-rV=0$$

Which, can be simplified with a formula that is based on the at the money price under normal model approximation.

$$C(S,t) = N(d_1)S-N(d_2)Ke^{-r(T-t)}=[N(\frac{1}{2}\sigma \sqrt{T-t})-N(-\frac{1}{2}\sigma \sqrt{T-t})]S$$

Which derives an approximation of implied volatility as:

$$IV \approx \sqrt{\frac{2\pi }{T}\cdot \frac{C}{S}}$$

Where *S* is the price of the underlying asset, *V* is the price of the call option, *IV* is the implied volatility, and *r* is the risk free interest rate. Thankfully, Chainlink oracles in their upcoming V2 will be providing this data through their API, making it consistent, reliable and easy to use without having to calculate advanced quantitative financial models.

Given their implied volatility is not out yet, it is hard to determine what form they will present their metric. Specifically, how long in the future the option expires. What ever the length of time, log returns, or percent, we can map this value to the normal distribution to dynamically calibrate transaction fees to reduce arbitrage loss to the 3 $\sigma$ range (or set this as a governance parameter).

$$Calibration(P_{chainlink},IV_{chainlink})x \mapsto \sigma_{system}\mapsto(tx_{fee},k)$$

scholes

$$\frac{\partial Calibration}{\partial \sigma }>0x \mapsto tx_{feet1}>tx_{feet0}$$

$$\frac{\partial Calibration}{\partial \sigma }>0x \mapsto k_{t1} < k_{t0}$$

Ultimately it would be optimal to have some sort on value change to respond to, like the 0.5% price movement update, but until the API is out the exact nature of this variable will be unknown.

An asset with an average price of 100 and a higher volatility ($\sigma$ = 0.5). Can now use the implied volatility feed to re calibrate its transaction fee to minimize the possible arbitrage opportunities, no matter the volatility.

### Pool Anatomy

In any liquidity pool the `Root`

Token is the desired token to be traded, paired against the `Native`

SDEX token. The Native Token is always SDEX.

Type | Symbol |
---|---|

Root Token | DOT |

Native Token | SDEX |

As you can see, the transaction fees fluctuate on the maker and taker side as the pool becomes imbalanced from regular transactions. This concept provides greater incentives for arbitragers to come in and bring the pool to an equilibrium state.

### Price Curvature

$$k = Curve$$

### Forced Rebalance

The rebalance variable `r`

is a set parameter which calls for a rebalance when `k`

has reached a certain curve value. When called, the smart contract will attempt to replenish the pool with assets which were reserved through penalties.

## Competitor Model

In contrast to the traditional model, the CFMM model utilizes an order book where all liquidity is pooled into one. We then calculate prices algorithmically using a constant product mechanism. In this style of AMM system, the liquidity available on both sides of the potential trade are multiplied together, and that pool value is held constant while being used to determine the price of transactions that occur within the smart contract.

*Example A:*

We begin with a liquidity provider depositing 10 BTC and 500 ETH into the contract. The pool then becomes:

and is the value of the pool we use for calculating the exchange rate of all trades that occur using the smart contract.*10 * 500 = 5,000*

$$z=(x)\cdot(y)$$

x | y | z |
---|---|---|

BTC | ETH | Pool |

10.00 | 500.00 | 5,000.00 |

Now an ETH buyer wants to trade 1 BTC for ETH. The pool of BTC gets pushed up from 10 to 11.

x | y | z |
---|---|---|

BTC | ETH | Pool |

11.00 | 454.545 | 5,000.00 |

The pool doesn't change from 5,000 since no new liquidity is added so therefore, we divide 5,000 by 11 to calculate the new pool of ETH which is equal to 454.545. In return for adding 1 BTC to the pool, the buyer receives an amount of ETH equal to the change in ETH, or

ETH.*500–454.5 = 45.5*

Now another ETH buyer steps in and wants to trade their 2 BTC for ETH. The pool of BTC gets pushed up even more from 11 to 13.

x | y | z |
---|---|---|

BTC | ETH | Pool |

13.00 | 384.616 | 5,000.00 |

Given that exchange rates are driven solely by the pool, this means the next trade will receive a slightly different rate.

This makes the market more efficient as spreads decrease over time as trading imparts price knowledge and subsidizes liquidity.

In our first example, the buyer's desire was to trade their 1 BTC for ETH. If they had purchased a larger amount, the exchange rate received would have also been different. In this case, the exchange rate reflects how much a trade moves the “x” to “y” ratio.

See the chart below for a graphical depiction of this relationship. As the size of the purchase increases, the exchange rate becomes less favorable. In this way, the end result ultimately bears some similarity to traditional markets where market participants see the market moving against them as they trade more aggressively.

Controlling Arbitrage

**Setting order minimums.** By only allowing trades above a certain threshold we eliminate non-optimal arbitrage problem. Although arbitrage is necessary for bringing pricing to equilibrium, there are certain cases that can affect the protocol negatively.

**Restricting gas fees.** To avoid front running, we propose smart contracts with gas limitations. An attacker who can see a transaction in the mining queue will still be forced behind existing transactions even if the fees selected are higher than the existing transactions in the queue.

## Conclusion

We have found a dynamic automated market maker to be a more applicable model for the Sigmadex on-chain liquidity protocol. Even though current applications such as Uniswap have exceptional adoption, there are still many areas of optimization for decentralized swaps. Sigmadex aims to enhance liquidity and retain a balanced ecosystem by merging several mathematical models to compliment the facilitation of token swaps.