Cardax DEX and SundaeSwap are both Automated Market Maker (AMM) based Decentralized Exchanges (DEX). In contrast to an order book based DEX, where the exchange of assets is supported by matching traders’ buy and sell orders, an AMM based DEX uses liquidity pools, a container of crypto tokens for enabling the exchange of tokens. Compared with SundaeSwap, our approach for managing the token swaps are pretty different.
Difference 1: Cardax uses Plutarch in the smart contract for better scalability
When we started the development of the Cardax DEX, we were using the Plutus Tx language as other Cardano projects, but very quickly, we realized that if we continued using Plutus Tx, the DEX would suffer from significant scalability and transaction throughput issues.
After having lots of discussions with our technical partners, we decided to use Plutarch. Plutarch is a Haskell language, but it achieves 300% more efficient performance. We found a better way to build the Cardax DEX that would be much faster to use and not struggle with scalability.
Difference 2: Cardax does not need elected scoopers
SundaeSwap uses Scoopers to submit and process users’ orders. In a way, the execution of transactions depends on the Scoopers: they decide which orders are selected and in which order they are processed, and the speed for execution also depends on how fast they work. The community elected 30 Scoopers from the SPOs (Stake Pool Operator). SundaeSwap provided the elected SPOs software and license to do the job. Scoopers get a fee from each transaction they process.
Contrary to the Scooper model, Cardax DEX uses the deterministic Streaming Merge protocol to handle users’ orders. This means that, first, the sequence for processing the orders is determined in advance. Second, the order of execution for user pool actions is not under the discretion of Cardax nor anyone else (e.g. scoopers, order batching bots, whatever you call it).
In other words, the equivalent “scoopers” on Cardax DEX can only run the deterministic commands, but can not intervene in how users’ orders will be processed or manipulate them. So the Cardax DEX and Streaming Merge do not need a closed group of elected, to-be-trusted scoopers: No third party is economically incentivized to game the system.
Contrary to delegating to a third party to merge the transactions, we rely on our users themselves for doing that. Because merging all previous happened orders and pool actions is aligned with their best interests: The execution of their own order. This means that we enable users to merge the transactions when they are submitting their orders!
We make the network transaction fee cost-neutral for every trader, meaning that traders pay for the fee corresponding to their orders, the extra fees for merging transactions are covered by Cardax. In simple words, you only pay for yourself (your order) and the rest (merging other transactions) is on us.
How do we make sure that the Streaming Merge protocol treats all users fairly? The Streaming Merge takes orders from all users in a sequence according to the time it was submitted. The blockchain limits how granular we can distinguish if one transaction happened after another. And whenever two or more orders need to be considered to have coincided, we sort them randomly.
Randomness helps treat these simultaneous orders fairly since none of the order submitters can predict if his order will be processed before another. The Streaming Merge defines precisely how these situations are handled. And users cannot see in advance the queued up orders for predicting a future price. There is simply no room for manipulation to submit unfair transactions.
Difference 3: There are long-time pending orders on SundaeSwap. It won’t happen on Cardax
On Sundaeswap, anyone can submit an order at any moment. Then users will need to wait for the Scoopers to pick up their orders and process them. The orders remain pending for days due to the combined factors of congestion and slippage.
Congestion. Under the AMM model that underpins SundaeSwap and Cardax DEX, orders need to be processed in sequence since each order updates the pool reserves and thus the token price. This means they can not be processed in parallel. On Sundaeswap, the Scoopers’ task is to collect all the orders, sequence them, and process them. What is already apparent is that there seem to be a lot more orders than the mergers can process – also due to blockchain limits.
Slippage is the difference in a token’s price between what the trader initially requested and the execution price due to price change between the time the order is submitted and executed. When the token’s price is out of a user’s slippage tolerance, the order becomes a limit order which can only be fulfilled when the price falls within the slippage tolerance. Slippage may stop the order for an undefined period – an unlucky order may be stuck in a loop between queueing to get processed and price falling out of slippage tolerance.
This situation won’t happen on Cardax. We move the congestion point in advance of order submission. To reach this, we implement a booking system. Booking means that a user submits his intention to make transactions in a liquidity pool. Once booked, the user has his exclusive lane and can place orders without contention and waiting. Each liquidity pool has a maximum number of lanes it can take.
So the congestion point, if there is any, is where people book into the lane. We will provide an estimated waiting time on the website front end. Booking has no money involved. The DEX does not ask for the user’s order’s content or block funds from the user’s wallet upon booking. During the waiting time to book a slot, your funds are still in your wallet.
Once a user has booked a slot, his submitted orders will be processed by the Streaming Merge and executed within a limited period. Since the duration of a merge transaction’s cycle is limited and only booked users can interact with the pool, we expect that the price fluctuation within a cycle will be restricted compared to an open system.