SundaeSwap launched not too long ago and while the project had its unique problems taking off the ground, it had since stabilized. However, it is still not the most ideal decentralized exchange (DEX) on the Cardano network as it is continuously plagued by congestion issues. This is where Cardax enters the picture, bringing a hitch-free DApp to the Cardano ecosystem.
Cardax’s underlying framework sets the project up for success as users do not have to worry about running into the same issues they did with SundaeSwap at launch. It eliminates the risk of congestion issues by solving underlying problems with transaction confirmations. With its unique Streaming Merge algorithm, Cardax promises to be the answer to users’ prayers.
How Is Cardax Different From SundaeSwap?
The SundaeSwap DEX has transactions confirmed in two stages. The first stage is verification which takes place in the stake pools. This first stage runs perfectly well. The bottleneck is during the second stage of this two-part system that requires the scoopers. Scoopers basically need to pick up a user’s order (transaction) for confirmation before the transaction goes through. This is where congestion issues arise.
Cardax completely eliminates this risk by using a Streaming Merge model instead of Scoopers/Mergers. The Streaming Merge algorithm makes it possible that Cardax does not require a group of elected, trusted mergers to confirm transactions. Orders do not have to be merged in this model, thus greatly reducing the risk of congestion when merging takes longer than expected.
Cardax also makes some significant deviations on the code side to ensure that there are no congestion issues with the project. Firstly, the Cardax dev team writes its code in an unorthodox way. There is currently what is considered the ‘normal’ way of writing smart contracts, using Plutus and Haskell and compiling it down to (Untyped) Plutus Core but Cardax does not go this way.
Instead, Cardax uses Plutarch, which is a very thin layer on top of (Untyped) Plutus Core. So although it is basically targets the same format as that used in the Haskell pipeline, it is able to eliminate the overhead, complexity and introduce boilerplate along the usual compile path.
A major benefit of Cardax using Plutarch is it will significantly reduce memory and CPU usage, while also allowing for a drop in the script size, leading to faster transactions.
Ready, Set, Go
Cardax will be launching on the mainnet later this year. With its underlying model, the decentralized exchange (DEX) will be able to avoid all of the congestion issues suffered by the SundaeSwap protocol.
The DEX is also using the Automated Market Maker (AMM) protocol, which is the same protocol that underpins SundaeSwap. However, Cardax will take all of the good parts of the SundaeSwap DEX and do away with the bad. This includes keeping up with SundaeSwap’s track record of not losing any user funds despite the congestion issues that continue to plague the protocol.
Since Cardax does not write its smart contracts in the ‘usual’ way, users will not have to reveal their intended order on the blockchain. But would only need to wait for the registration, instead of having to wait for their orders to go through.
This means that once a user registers, their order will be processed at a much faster pace, completing doing away with the bottleneck that is the uncertainty of the order state.
Â
Discussion about this post