Paul Fulbrook
Will the cardax app hosted on IPFS?
I think that we probably will not start out with having our web app on IPFS from the beginning. The reasons are manyfold. The most important one is that currently “true decentralization” (which I assume is the reason behind your question) is currently hard to achieve from an infrastructural point of view.
This means that there are too many additional services (i.e. servers) that need to be up and running (and maintained) – next to your web app – that hosting the web app on IPFS is not really providing any benefit as of now (i.e. other than the dApp is only a very tiny bit more decentralised).
We are however working towards it.
One example is that we are not using the Plutus Application Backend (PAB) which is a server component (i.e. centralised), rather we use an in-browser (i.e. decentralised) replacement for it called Cardano Transaction Lib (CTL; former “Cardano Browser Tx” library; Read this article for more on this).
Essentially, our off-chain code runs in the client browser (i.e. very decentralised) and all other services and servers “could be hosted” by anybody. But because of the costs and maintenance work involved, this would be unlikely.
Having said all this, we are on our journey towards truly decentralised dApps in the Cardano ecosystem.
Does Cardax use bots (like scoopers, batchers) to manage transactions?
The original Streaming Merge design defined bots that were needed to submit deterministic merge transactions.
However, we improved the model even further in order to achieve true decentralisation; exactly what we designed the Streaming Merged for.
All users of a pool will do the merging of orders along with submitting their orders. The incentivisation in this is that their orders will be executed sooner in case they merge previous orders.
To do the merge will not cost anything to the user, there is no reason not to contribute to the progression of the pool.
How does registration work from a user’s point of view?
Essentially, the user goes to the DEX app, selects a pool (pair) and clicks the “register” button. This may not be instant, depending on how many users are attempting to register at the same time. If this is the case, we will provide an estimated waiting time. Once the registration is processed, the user is registered for this pool and can place their orders (without contention and waiting).
If the price is out of my slippage tolerance, will my order be rejected?
In this case, do I pay the fee? Which fee do I need to pay? (cardano network fee, 2 ada, 0.3% to LP)
The order will be rejected, yes. Only the Cardano network fee is taken by the blockchain.
Regarding other fees, we have not yet decided on this. The reason is that we may need to deduct a small fee in order to prevent blocking pool threads. But it is not yet decided how to best achieve this and to not frustrate or penalize good actors.
How does the Streaming Merge protocol treat everybody’s order fairly, and how does it prevent anyone from gaming the system?
This is what Streaming Merge is all about: It takes all orders from all users and sequences them according to the time it was submitted. There are two things which makes this more complicated:
1) The blockchain has a limit on how granular we can distinguish if one transaction happened after another. And this is also why the second thing is so important, since:
2) Whenever two or more transactions are considered to have happened simultaneously, the Streaming Merge algorithm sorts them randomly. All this means that the Streaming Merge defines precisely how these situations need to be handled. There is no “freedom” for a bot/batcher/merger to submit unfair merge transactions. And other users can not see in advance the queued up orders, since the orders are recorded at the moment they are placed.
What challenges did you recently have to overcome?
Re-writing our smart contracts from PlutusTx to Plutarch. While this took a little extra time, it has been completed and is worth it due to the 300% greater efficiency that Plutarch has over PlutusTx.
Another topic is the integration of the in-browser Cardano Transaction Lib (CTL; former “Cardano Browser Tx” library; Read this article for more on this) which is something totally new.
For both major steps forward for the Cardano development ecosystem, Cardax is, as far as we know, the leading project.
Did the PAB release help you fixing some of the issues you had to face during the congestion period ?
We do not use PAB but the Cardano Transaction Lib (CTL; former “Cardano Browser Tx” library). The CTL is a replacement for PAB which will allow us to run our smart contracts from a JavaScript library within the browser. And this, in essence, means more decentralisation since the code is not hosted on a central server (which is required for the PAB) but runs on the user’s browser.
What in your opinion would be the biggest challenge ahead waiting DeFi on Cardano ?
Finding and fixing bugs since the concepts introduced with smart contracts and the eUTXO model are so new. Protocols to avoid typical mistakes are still in the development. For example, the Plutonomicon page on GitHub is an exciting hub for the development of these protocols.
Do you anticipate any problems that the Dex might face, especially in its early days, for users? Apart from congestion on the cardano side.
That’s essentially a quite difficult question. We are doing everything we can in advance, to eliminate all potential issues. Nevertheless, the environment and all the technology we are using are cutting edge.
For example, our DEX will be the first dApp completely written in Plutarch and the Cardano Transaction Library (CTL; formerly “Cardano Browser Tx” library) is a PAB replacement.
They are just some of the parts of the whole DEX. There are a large number of additional services and applications which are required to provide a good user experience.
Some of them we must host and maintain ourselves (e.g. a Cardano Node, a DB Sync instance, an Ogmios server, …). Next to this, the wallets need to provide a nice integration and work as expected; we have seen unexpected behaviour of wallets on the launch of other DEXs.
So yes, we do expect to need to improve our setup after the launch since unexpected things will happen. But no, we cannot precisely foresee anything concrete yet.
Does the Streaming Merge approach require any off chain logic such as scoopers? What levels of performance are expected from this approach?
Since all dApps require some kind of off-chain code, I assume that you want to know some “third party trusted” off-chain code (let’s call the scoopers, “bots” from now on). Regarding the second part of the question, you are also asking what influence these bots have on the progression of the DEX, i.e. processing of order queues.
Our original version of the Streaming Merge algorithm planned to use bots to merge transactions, however, Streaming Merge was developed further and now does not use any bots. The users themselves can merge transactions as part of their order. We believe that eliminating the bots will lead to a more streamlined process and in essence, be more decentralised.
Are LP and YF smart contracts also in Plutarch and translated successfully?
The LP smart contracts are not really special contracts, we talk about “pool actions” – which are essentially all actions possible with a pool (basically: order submitting, adding liquidity, removing liquidity).
Anyway, all our smart contracts are written in Plutarch, yes.
We don’t have yield farming in version 1, but we will write all our smart contracts in Plutarch.
What wallets are going to be available? And if it’s only NAMI, why? While other dexes integrated all sorts of wallets, without fuss, what’s stopping you?
We will start out with Nami since that was the first wallet which offered the dApp bridge/integration. Nami still does some things different from the standard described in CIP-30. So in essence, all wallets which support the CIP-30 will be integrated easily – but assuming that some wallets deviate from the standard, these will need some special integration (but we assume that all wallets work towards supporting the standard). And to put it into context: All this happens in the Cardano Transaction Lib (CTL; former “Cardano Browser Tx” library), which is a real decentralized version of the PAB (i.e. no central servers, but JS code run on the client-side).
For reference, CIP-30 and Cardano Transaction Lib.
