Maladex order matching engine achieves the maximum concurrency as defined by Amdahl’s law and introduces a scaling mechanism beyond 16kB transaction and 65kB block size limits. Maladex achieves it at the same time by introducing the revolutionary concept of programmable swaps, increasing capital efficiency, removing impermanent loss, and providing a mechanism for decentralisation of DEX order routing.

Cardano uses a novel extended unspent transaction output (EUTxO) model to represent the ledger state. The consequences of this modelling choice are

• context locality, i.e., each transaction consumes the minimum amount of information required leading to predictable execution and much lower (and exact) fees than blockchains with a global memory;
• concurrency, since there’s no global state we can think of all transactions occurring in parallel to each other, where interacting with each other concurrently;
• EUTxO congestion where multiple agents attempt to spend the same input leading to race condition and only the first submitted transaction being executed successfully.

In contrast to account-based models such as Ethereum, which acts as a single-threaded application with global memory, Cardano is a highly concurrent system. In any concurrent system, access to shared parts need to be managed to ensure that the correct output is produced. Cardano achieves this correctness property via a requirement that each EUTxO must be spent to modify its state and that it can be only spent once per block (currently 20s).

This has 2 major consequences:

• transactions are much cheaper and fees can be computed exactly leading to a much better user experience;
• Plutus developers need to consider concurrency as part of their DApp design and implement it in a way to achieve the highest throughput possible maintaining fairness and trust.

Finally, Cardano currently has an additional scaling challenge which is

• a transaction memory limited to 16kB;
• a block memory limited to 65 kB.

This poses a serious challenge to the account-based model proposed by all other Cardano DEXes (such as SundaeSwap or MinSwap) as even the smallest aggregated transactions by off-chain code can easily exceed on the average both limits leading to transactions that cannot execute due to not fitting in transaction memory limit or due to serious throughput limitation (e.g. only 4 transactions per block = 20s).

In this article, we further cover, how our revolutionary programmable swaps model tackles this issue due to fragmentation and 2-phase commit model and how we plan to scale way beyond those limitations by introducing our own hydra head and side chain.

Cardano Scripts

We often hear the misleading term “smart contracts” applied in the case of Cardano. Yes, Cardano has smart contracts by the most general definition, but the way it implements them is significantly different. Therefore, when we talk about Cardano scripts we use 2 terms instead of the phrase “smart contracts”:

• on-chain validators / on-chain code — the code (script) that runs on-chain and verifies that transaction can be executed successfully;
• off-chain code — the code that does not run on the blockchain. This code is responsible for preparing transactions and submitting them on-chain.

It is a fundamental distinction because it implies that running off-chain code in the case of Cardano DApps is not only useful but mandatory. Even in the case of a fully distributed application, off-chain code would have to be distributed to each party to interact with the on-chain data. On-chain does not store scripts, only their hashes. We believe this is a significant efficiency improvement over other models without sacrificing many important properties of the blockchain. It is also worth noting that the classical account-based blockchain work in a very similar manner, but without a clear distinction of what part is precomputed off-chain and provided as data and which on-chain via EVM, etc. Cardano chooses healthy minimalism without the sacrifice of any decentralisation and security properties.

Good properties (non-custody, trustlessness, etc.) are derived from cryptographic design not from vanity metrics on which crypto Twitter tends to rely. Cardano is designed in a way to maintain all security properties compared to any other blockchain, and in many cases improves significantly upon them given the progress that has occurred in this field since the inception of Bitcoin.

Overview of Scaling Solutions Proposed by Other DEXes

The only more specific information regarding other solutions has been provided by ErgoDex, MinSwap, and Meld (the last of which is not a DEX). All other DEXes (such as SundaeSwap, OccamX, etc.) have only hinted to what their solution might be without giving any proof or delivering any concrete solutions in any detail beyond a few buzzwords in their media posts.

ErgoDex’s solution uses an off-chain sequencer that looks at all limit and AMM orders and prepares aggregated transactions to execute them. Despite, the fact that this leads to centralisation of order execution, we believe it is a sound solution and is quite efficient at it. The Cardano blockchain has been designed to have on-chain validators and off-chain code, which, even inside the Cardano developer ecosystem, many have not yet grasped (judging by the discussion originating from other DEXes). However, this model can be greatly improved upon.

MinSwap proposes a very similar model to ErgoDex just giving it a fancy name: “Laminar”, but under the hood, this solution uses the same batching model that relies on ledger data provided by Cardano Node, hence for instance runnable on any relay.

From our perspective, conceptually these are 2 identical models with only small technical differences, and an attempt to fit a solution to a problem created by the liquidity model, rather than solve the issue fundamentally from the ground up.

We often see the terms parallel and concurrent used incorrectly and we use both terms in this article, let’s clarify their meaning before we go further:

• concurrency means the progressing of the same task by multiple agents at the same time, which implies communication between agents (an agent might mean thread, process, person, Mal, etc.);
• parallelism means splitting a task into smaller tasks, each of which can proceed independently, what this implies is that there is no communication between agents.

Why we never thought concurrency was an issue?

It was amusing to us to observe all the unjustified emotions around the inability to interact with any eUTxO more than once per block. Controversy sells and for sure a lot of projects manage a successful marketing campaign on top of fast-spreading concurrency FUD, the pieces left to be collected by projects who are developing in silence.

First of all, it was an obvious realisation to arrive at, one of the first things you run into when thinking about how to build a decentralised exchange using EUTxO model. Second, if a developer cannot solve a problem it is not the issue with the hardware or software, but simply the lack of developer skills. Concurrency is a field studied in extreme depth with a series of not only vivid research and publications but with a ton of real-world examples, not to mention a field of distributed databases. Distributed databases deal with topics ranging from 2-phase commits, data consistency, and many trade-offs such as outlined in CAP theorem. It is a ready field to inspire a series of solutions to achieving concurrency on the blockchain.

When first approaching designing a solution to the concurrency issue a tonne of solutions pop up immediately such

• on-chain commitment with a reward for merging into liquidity pool EUTxO;
• an off-chain sequencer proposed by ErgoDex: https://github.com/ergolabs/ergo-dex-backend
• deterministic batching proposed by Meld: https://medium.com/meld-labs/concurrent-deterministic-batching-on-the-utxo-ledger-99040f809706;
• EUTxO fragmentation and a deterministic selection mechanism to ensure minimal collision;
• use of randomised algorithms and fragmentation solution to perform scheduling purely on-chain, given trustworthy source of randomness;
• and many more, including our own outlined below.

This issue was first reported, then magnified by the social media discourse and users who took all words given by devs for granted (i.e., concurrency being an issue and currently only being able to execute only one transaction per block), then it was picked up by Ethereum maximalists, and finally exploded on Twitter. A real crapfest for which we can thank a diabolic incompetency watermill which magically pours water on itself defying all laws of entropy — but welcome to the Internet.

The simple truth is, that EUTxO is a novel model for concurrency and blockchain. It is a new marriage, and because it is a new marriage we need pioneers to think of solutions and build on each others work to arrive at a set of standard design patterns and libraries. It is nothing new, this is how the engineering world has worked since the days of punched tapes.

However, we realise the angst of the non-technical community and the curiosity of the technical in how the problem will be tackled by different platforms. So we will deliver a complete report, which can be seen below.

Programmable Swaps

Before we get into the detailed discussion of how we approach concurrency and memory limit, let’s outline how our DEX works.

Maladex is a project that not only aims to build a decentralised exchange capable of real-time simple exchange of assets, but aims to introduce a series of novel concepts such as trading strategy writing and running, indexes, derivatives, synthetics, option structures, and active investing akin to how hedge funds generate returns.

The core concept in the above strategy is the creation of a framework that allows users to specify trading strategies that can then be executed automatically. This is game-changing as decentralised trading goes because for the first time anyone can design a solution that will execute complex orders without the user having to monitor the exchange at all times or develop their own solutions that interact with blockchain protocols.

So, that being said, may we introduce our programmable swaps.

A programmable swap is a set of triggers in which transactions should occur and funds for such transactions.

Programmable swaps allow for the below actions and many others:

• provide liquidity using any liquidity-curve formula (including x * y = const) within any range (this is an extension of UniSwap v3 on its own with the ability to specify a liquidity-curve); what’s more Maladex in the future will help you choose the optimal liquidity curve;
• set a buy/sell limit order;
• DCA (Dollar-Cost Average) over 30 days from USD to Cardano each day buying a chunk of ADA, or even adjusting the chunks by weights based on ADA price dynamics;
• provide liquidity when the price of ADA/USD remains stable, but as soon as it moves beyond desired range exchange all USD to ADA;
• seed Maladex arbitrage bots that exploit pricing inefficiencies of models used by other exchanges to both increase the profits of arbitrage bot seeders and increase the overall market efficiency and ensure that Maladex reflects the true market price, regardless of TVL (Total Value Locked);
• develop advanced automating trading strategies and even share them with other people in the community via profit-sharing (e.g. share strategy with published metrics of performance and e.g. collect 1% of all revenue generated by the strategy) connecting strategy writers with the capital;
• dynamically hedge your position using derivatives/underlying/etc.;
• and many more.

Finally, a programmable swaps model allows for extending the Maladex trading protocol without any need for hard updates, it basically remains forever backward compatible.

Programmable swaps and Mal

The reason Mal looks like a daemon is because of programmable swaps. A daemon in computing is a background process that performs tasks for the user, just like our programmable swaps. You could even say that each programmable swap is a daemon (or Mal). As programmable swaps are the underlying building blocks of everything on the Maladex platform from swaps, through DCA, indexes, synthetics, strategy development, and active investing, it is only fair we are named after Mal.

Maladex Concurrency Solution

Maladex programmable swap protocol is composed of 2 parts:

• The commit phase — send commitment onto the blockchain to perform a certain action; each commitment can be cancelled by sending a cancel order as another programmable swap; each commitment is an NFT and can be produced in parallel using a minting policy;
• The execution phase — all commitments are executed each block against each other resulting in trades happening. Due to high fragmentation and optimised routing transactions take much less memory and can be efficiently managed.

How are programmable swaps stored?

Maladex uses a minting policy to store all programmable swaps as NFTs on-chain. Each NFT has data that defines all the triggers. Publishing this data on-chain for everyone to see and verify.

The minting policy does not suffer from concurrency issues and anyone can submit as many programmable swap orders at any point as they want. This naturally leads to maximum possible concurrency, i.e. where all orders can be submitted without a single failure. The only limitation here is the block limit size of 65kB, this is though to be increased in the coming months and is not a limiting factor for Maladex as we have plans to scale way beyond whatever limit is active (more on that later).

Amdahl’s law represents the theoretical limit of speed achievable on the Cardano blockchain by increasing concurrency.

This approach already guarantees 0 failed transactions. If MinSwap released a testnet with this model, it would not have been possible for any transactions to fail. In a worst-case scenario, they would just execute sequentially once on-chain, one by one.

Finally, as a nice touch, we plan in the future to implement transaction receipts in the form of NFTs. Say your programmable DCA finished executing after 30 days or your limit order was matched, we will mint an NFT with the history of your trade — the transaction inputs, outputs, and a visualisation to represent the trade as an image. Beyond pragmatic use of easily available and transparent information on how the trade was executed, those NFT receipts might become collectibles at some point — first trade of token X, your best trade, launch of token Y, etc.

Execution Phase

Triggers are a set of conditions which all must be met in order for the transaction to be executed:

• market order has no triggers and will be executed at the best available market price immediately;
• sell limit order will require that the ratio of the other assets is L or higher;
• buy limit order will require that the ratio of the other asset is U or lower;
• DCA from USD to ADA over 30 days will require that 24 hours elapsed since the last update, that there are still days left in 30 days, and potentially any other conditions;
• AMM liquidity providing will require that the orders matched are within the range at which the liquidity is provided (e.g. trading ADA/USD between $2–3 per ADA), etc.

Further, to cancel any existing order, a new commit is sent with the proof of ownership that the user owned programmable swap is to be returned to the user at its given state. This further, enhances scalability as each programmable swap will have only one owner.

The execution phase is managed as a set of nodes to which a graph scheduler is applied. It has a nice similarity to Apache Spark graph execution model and scheduling.

The execution happens in the following stages:

1. All cancel orders are applied and any active orders that have been cancelled are removed from the frontiers.
2. All programmable swaps triggers are evaluated with a graph of shared triggers (this is just an optimal way to evaluate millions of triggers at the same time) and marked as active or inactive.
3. All active triggers form what is called an active frontier — a set of all nodes (programmable swaps) that are executable in the given block. All inactive triggers, programmable swaps that cannot be executed in the given block, form an inactive frontier and can be omitted from all calculations at this block.
4. An exchange order matching engine provides optimal scheduling, via optimal execution graph construction (the graphs nodes are EUTxOs and edges flow of data) of programmable swap execution given the constraints such as transaction memory limit, fairness (e.g. executing market orders in the order of submission), immutable ordering (ordering cannot be influenced by any external factors to avoid front-running, MEV, etc.). The order matching engine creates optimised transactions for a given block and submits them on-chain.
5. On-chain performs validation of submitted orders for all the triggers and constraints ensuring trustless execution. The previous block committed programmable swaps to become visible in the next block, the results of the previous transactions produce new programmable swaps (nodes), some swaps become active, some become inactive. The cycle repeats.

Frontiers

To further increase the efficiency of the graph scheduling solution, we introduce the concept of

• active frontier — all programmable swaps active (all triggers) active in the given block;
• inactive frontier — all programmable swaps with at least one trigger being inactive.

Such an approach to graph scheduling increases significantly the efficiency of routing algorithms and further makes the transition state between blocks faster.

Finally, the triggers themselves form a graph from activation (triggers) to state execution. This is very similar to Petri nets and for a reason due to the inherent similarity between EUTxO model and locking the required EUTxOs for state transition and the state transition itself.

Off-chain vs on-chain

A property that is not talked about in enough depth is the fact that any blockchain requires an off-chain component. In the case of classical account-based models such as Ethereum, someone needs to provide data to the smart contract, this data is prepared off-chain, then approved by the user in the trusted wallet, and submitted to the blockchain for execution.

Cardano merely formalises this concept further allowing for minimal required information on-chain, i.e. validators which provide all typical guarantees plus at which DEX developers must specify the fairness and trust properties.

Off-chain is an integral part of Cardano and allows for the efficient formation of transactions. Regardless, of what is specified in on-chain validator and what is specified in off-chain code, as long as developers have access to the off-chain code, anyone can interact with the protocol.

We believe that the models such as proposed by ErgoDex are not inherently flawed, only require additional scrutiny in open sourcing on-chain validator code and verification that on-chain hashes correspond to the off-chain scripts.

Hence, this is not surprising that each DEX will have off-chain routing component. Any other solution would require for the community to develop their own routing software that meets the conditions set in the on-chain validators and provide routing for the DEX transactions via a reward mechanism.

Off-chain execution engine

Such an off-chain execution engine can be run by anyone

• DEX has an incentive to run it for free as it already collects a small % fee of all transactions (akin to 0.1–0.3%);
• Anyone can run the DEX execution engine given its provided open-source alongside any Cardano Node (e.g. alongside relay).

Maladex will run multiple auto-scalable instances of order matching and routing engine on Kubernetes and will provide the engine open source for any SPO (Stake Pool Operator) to run.

The Cardano Node in the below example is an up to date node that can relay transactions onto the blockchain. An example of such a node is a relay. A portion of DEX fees will be allocated for the order execution, hence providing decentralisation of the routing DEX component.

What’s more, running such off-chain execution engines with the help of the community not only increases DEX decentralisation (it is now run by a distributed group of people as opposed to routed by a centralised entity as in the case of classical DEXes), but also naturally leads to the next point of this article, i.e., scaling beyond transaction and block memory limitations, and increasing the transaction execution speed, via hydra heads.

Memory Limit Solution

Cardano transactions are limited by to 16kB and blocks to 65kB. Although Cardano plans to adjust the parameters in response to the network load, it is better to think in terms of scalability beyond these typical blockchain limitations.

Let us introduce the concept of scaling DEX execution capabilities via hydra heads.

Each SPO (stake pool operator) running a Cardano relay and Maladex execution engine will be able to join a group of operators part-taking in creating hydra heads.

A Hydra head is an isomorphic Cardano layer 2 scaling solution. Isomorphism means that no compilation between different code formats, used by both layers, is required and one can focus on writing Plutus code.

Hydra heads formation will allow for much shorter block times inside hydra head, e.g. producing layer 2 block every 1s and increased memory limit. Each layer 1 block hydra-head state will be committed to the chain.

As only the final state is committed back to the layer 1, where it is finally validated and merged, with no history, it allows for significant scaling of transactions speed and memory limit. A Maladex hydra head will be capable of executing multiple block cycles (e.g. 20) during a single Cardano layer 1 block and commit the result of 20 blocks back to layer 1.

Do we need an account-based model for DEX?

MinSwap mentions in their article that they believe that an (inefficient) account-based model is required for functioning DEX because the state needs to be centralised for AMM (automated market maker) liquidity models.

We completely disagree with this. In any market, the current price and liquidity is an emerging property of the underlying orders. In classical markets, liquidity is provided via limit orders in the order book, in typical decentralised markets it is provided via AMM formulas, which can be completely centralised as in the case of UniSwap v1/v2 (and all projects trying to mimic this model on Cardano such as SundaeSwap, MinSwap, etc.) or highly fragmented as in the case of UniSwap v3.

For orders to be executed only local information is necessary, e.g., to match a limit sell order to a corresponding limit buy order which prices cross are necessary. Similarly, for the market order to execute, we only need to find the matching lowest price limit order or AMM fragment (in the case of Maladex AMM resulting in the best execution price).

Therefore, the global liquidity state such as in UniSwap v1/v2 (and as proposed by SundaeSwap or MinSwap) is completely unnecessary. What’s more, it is highly undesirable as it leads to extremely inefficient liquidity supply.

CFMM (constant-formula market makers) with global liquidity believe that it is as likely to buy 12" pizza today for $20 as for ¢1 or $1B. This leads to extreme liquidity inefficiency and unrealistic market models.

The liquidity fragmentation alone, such it is the case for UniSwap v3, lead to the emergence of a geometric price model, and as the result to a significant reduction of impermanent loss and an increase in capital efficiency.

High capital efficiency means that market prices can be represented effectively using even small capital in AMM (automated market maker) models and low impermanent loss means that investors do not lose funds simply by using DEX.

Therefore, Maladex is not only the first Cardano DEX to propose a model that inherently removes impermanent loss and significantly increases capital efficiency, but the first DEX which proposes both. We believe this change of paradigm will make the transition of traders and investors out of centralised exchanges onto decentralised ones possible.

A layer to scale all DApps

The generality of Maladex proposed programmable swaps and the optimal approach to both concurrency, memory efficiency due to state fragmentation, and finally, hydra heads mean that its an ideal platform to allow for DApps scaling. In the future, we plan to allow other DApps to execute via our protocol automatically achieving high concurrency.

Why our model is the best achievable?

Finally, let’s discuss why the proposed exchange model by Maladex is the best possible (full stop).

The proposed model:

• achieves maximum concurrency as defined by Amdahl’s law;
• increases the transaction throughput beyond Cardano limitations via the usage of hydra heads;
• provides built-in incentives for fair order execution;
• allows for the trustless expression of order types beyond the current offering of exchanges both centralised and decentralised, both blockchain-native and traditional finance;
• allows for distribution of routing component, which classically is centralised by each exchange and community participation in exchange running;
• is free of impermanent loss and naturally leads to high capital efficiency (which we will further augment via other Maladex features);
• converges on the true market price (increasing the market efficiency) and enabling Maladex to be an Oracle of the true market price for Cardano native assets.

Where other DEXes provide problems to talk about, we are ready to provide solutions for all, and even those that others do not realise are serious issues such as lack of capital inefficiency and high impermanent loss.