AMM stands for “automated market maker”, a concept initiated during the development of Defi (“Decentralised Finance”) and subsequently widely deployed in DEX (“Defi Exchange”).
AMM is essentially the single entity servicing an incoming order or a request for quote (RFQ) to buy or sell an asset. The price returned by the AMM upon request is based on two pools of liquidity, one for the Base Asset and another one for the Quote Asset.
For example, for the pair ETH / USDT then the Base Asset is ETH native token and Quote Asset is USDT. In its most fundamental implementation, assuming the initial rate of one ETH is 1,000 USDT and there are 1,000 ETH in the Base Asset pool:
- Liquidity providers will have to deposit 1 ETH into the Base Asset Pool and 1,000 USDT into the Quote Asset Pool.
- Once ready, AMM will always start with two equal pools (in USDT terms) with 1,000 ETH and 1,000,000 USDT.
Figure 1: Automated Market Making Model
- The first user who asks for a quote to buy 1 ETH, will be answered with a price of 1,000 (= 1,000,000/1,000), equal to the initial rate. As long as he/she agrees to proceed, he/she needs to deposit 1,000 USDT into the Quote Asset Pool and redeem 1 ETH from the Base Asset Pool. The new pool status would be 999 DBOE and 1,001,000 USDT post this transaction.
- The second user who also asks for a quote to buy 1 ETH, now will be answered with a price of 1,001,000 / 999 = 1001.10 after rounding to two decimals. The law of Supply and Demand is adhered as there is less supply of the Base Asset and excessive supply for the Quote Asset.
In the above cases, the exchange rate (matchable price) will be calculated so that the product of the two pool liquidity (in its own currency) will be constant.
Mathematically, x * y = k
- x is the amount of the Base Asset in its pool,
- y is the amount of the Quote Asset in the other pool and
- k is a fixed constant
In fact, each DEX might derive their own variation from the above formula to suit their specific use cases. However, the similarity between all of them is that they determine the exchange rates algorithmically.
Apparently, the “elephants in the room” are as below:
Firstly, at the inception of Defi, builders quickly realised that it was impossible to duplicate the traditional exchange infrastructure typically centralised order book (CLOB) on-chain due to prohibitive cost. This is especially true when only a very small ratio of orders leading to matches and generating transaction fees while the majority of updates yield no economical benefit from a revenue point of view.
Secondly, from a regulatory perspective, deploying an AMM-based liquidity model, builders might claim that they have decentralised the entire end to end flow hence question on licensing i.e. operating a centralised order books etc might not be that pressing at the beginning.
Last but not least, pooling assets (aka staking) is a decent business, not only from a revenue point of view but also from a marketing and PR perspective.
Then why not?
However, for AMM for Option imposes higher security risk
Defi protocols or DEX started with spot markets with swap/exchange services and AMM model seems working fine in pricing spot/cash assets given all market variables are contained within the two Quote and Base liquidity pools.
Option DEX as the latest addition into the stack have also been trying to incorporate the AMM model into their core pricing and matching mechanism. However, different concerns arose.
The most popular pricing model for Option is Black Scholes with the key assumption on the log-normal movement of the underlying market and the extra parameter named implied volatility (IV).
Where V is the price of the option as a function of underlying spot price S and time to expiry t, r is the risk-free interest rate, and 𝞼 is the implied volatility (IV) of the stock.
There will be more equations when the option is defined and classified into more standard formats such as Call and Put and its striking price as part of its specification.
While other parameters are classified as either part of the product specifications or the market, the 𝞼 parameter (Implied Volatility) is a special kind (i.e. out of nowhere and has nothing to do with the two).
Figure 2: External connection to query for IV input in a typical AMM for Option
The Option AMM is still operated with two Liquidity Pools, one is the Option inventory and the other is the Quote Liquidity Pool, most likely a stablecoin such as USDT.
However, there needs a tweak in order to service an incoming quote to buy Option, the sequence would be:
- Option DEX queries to external source for Implied Volatility (IV). Typical source are the usual Option pricing venue such as Deribit or from aggregator platform
- After receiving the IV from the source, Option DEX might add in a mark-up (such as 1 or 2 vol. point) to make a market spread.
- With the marked-up IV, Option DEX can now price the Option as usual using Black-Scholes formula.
- The price will be returned to the users as the answer.
On the condition that the connection to the external IV source is secured, reliable and arbitrage-free, to be fair, this model might work. But this condition is not easy to meet and the otherwise consequence is dire e.g. what if the connection is hijacked and the IV returned is halved and Option is sold cheap?
Still, the low throughput as a scalability challenge
Now, let’s revisit the basic AMM a bit. “No-arbitrage” is the fundamental used to price derivatives. Everyone loves free money so breach of “no-arbitrage” always yields the highest attention.
x * y = k
Pricing of AMM is dependent on the liquidity of the two pools, therefore it is critical to have the exact liquidity balance in each pool in order to offer a tradable price.
Any estimations or proxies of these balances presents arbitrage opportunities and pending to be exploited. So it is not a surprise that in order to service a request for quote, AMM needs to “lock” the two pools so that the two balances are recorded and not updated for a period. The pools will be unlocked only when either the request is timed out or it turns out to be a trade and the trade is completed. Therefore, pricing and matching by AMM is almost done centrally and in a single-threaded manner.
If not locking then the mark-up price needs to be fat enough so that it gives enough room to cover the potential market move during the transaction. But clearly it is a balance between the price competitiveness and the throughput. If DEX wants a high throughput, then they are likely unable to offer competitive pricing (i.e. wide bid-offer spread).
Our own study using the most liquid DEX for some of the most popular pairs suggested that market participants are paying an effective Bid-Offer Spread (excluding market impact) of around 4% to 5% for a retail-sized order e.g. $30. For traditional assets, this is a huge Bid-Offer Spread and no market considered to be liquid having such monster spread.
Back to basics, what is CLOB?
Traditional finance professionals must be all familiar with the concept of an orderbook. A Centralised Orderbook (“CLOB”) is associated with a market operator who aggregates different quotes for Bid and Offer and ranks them to form a combined view of Bid and Offer.
Market participants benefit from CLOB for its transparency and most intuitive way of showing the best Bid and Offer as well as the visible Supply and Demand power available as of the time.
It is true that the quote aggregation is done centrally but there are usually ways to concurrently update and insert quotes such as by Bid and Offer and by price levels. There are advanced optimisations to speed up the aggregation here.
Incoming order will either trigger matches with prevailing resting orders or become a part of the resting orders. In the case of matching, the best Bid (highest) or best Offer (lowest) will be matched first. A typical data structure to handle matching logic is based on a binary heap structure.
Figure 3: CLOB — a combined view on Bid and Offer
Figure 4: Simplified Aggregation to speed up CLOB Update throughput
CLOB — true decentralised matching
As designed, CLOB is an uniform market view built up by market participants. Pricing is intuitive and readily available on screen or browser without “request for quote” as in AMM. Even better, the matching can be done between one Buyer and multiple Sellers and vice versa.
Figure 5: Decentralised matching nature of a CLOB
Now, putting the two CLOB and AMM together particularly for Option market
DBOE Hybrid Model
DBOE is the future of Crypto Options! It was architectured at the very beginning with a hybrid model by combining the best of the two worlds CeFi and DeFi.
DBOE benefits the decentralised matching and maximum security and transparency by operating CLOB model for the matching off-chain and enjoys the beauty of Smart Contract Blockchain technology when deploying its clearing and settlement on-chain.