Sigmadex proposes a constant function market maker algorithm to determine liquidity variables among assets.

$$\mbox{p} = \frac{e^{\frac{q1}{b}}}{e^{\frac{q1}{b}} + e^{\frac{q2}{b}}}$$

Standard LMSR

Although the standard LMSR can work in many cases, a refined version is proposed and best suited for Sigmadex as liquidity will be a dynamic value.

Traditional 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

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: 10 * 500 = 5,000 and is the value of the pool we use for calculating the exchange rate of all trades that occur using the smart contract.

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

Constant

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 500–454.5 = 45.5 ETH.

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 modified LMSR to be a more applicable model for the Sigmadex on-chain liquidity protocol. Even though the LSMR model is efficient and simple, it fits more adequately for prediction markets and sports betting where liquidity is fixed across pools. In asset markets where people contribute to liquidity pools there becomes an issue that leaves too much discretion in the determination of the liquidity parameter. This problem would be difficult to calibrate in Sigmadex since liquidity will dramatically change over time.