Maladex: A DEX with Programmable Swaps

In this article, I will explain to you how the Maladex protocol works, a DEX development on the Cardano blockchain, with great technical foundation. 

In the previous article, Maladex: A DeFi Daemon, I explained the project in general terms.

Maladex will be a sound platform for developing investments with high capital efficiency and without impermanent loss.

Maladex aims to revolutionize the world of finance by:

• providing the tools that allow everyone to create sound and efficient ways of investing;
• increasing the efficiency of the cryptocurrency market and accelerating the transition from TradFi to DeFi;
• building the foundations of the financial markets of the future.

Cardano offers 3 major innovations, making many of the ambitious goals outlined in this paper achievable, which were previously impossible on global-shared state blockchains:

• Smart contracts are composed of on-chain validators and off-chain code; on-chain validators provide the same level of assurance as any other blockchain model, but at the same time Turing-complete off-chain code, enables performing complex and resource-consuming computation without any impact on transaction cost; this is revolutionary, as ideas such as programmable swaps and algorithmic automated market maker (AAMM) would not be possible to implement without it. What’s more, on-chain validators provide full scope of smart contract security, meaning that despite the off-chain code, the entire protocol is equivalent to being fully executed on-chain as all security is achieved on-chain. 
• eUTxOs fragmentation and redeemer model, which provides a unique method to enable many concurrent independent actions to take place in parallel across multiple protocols; for instance, given this fragmentation and desire to arbitrage with other DEXs, this can be done simply thanks to the eUTxOs model and how redeemers work. 
• Hydra head – fast and isomorphic state channels allowing for straightforward usage of the same transaction settlement code in the local hydra head formation. This enables a significant performance improvement without incurring layer 2 software engineering cost.

Programmable Swaps

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

The concept of programmable swaps is composed of:

• type – order type
• triggers – specifying conditions upon which the swap is active to be executed 
• actions – payload definition of what action a programmable swap performs upon activation 
• assets – assets required to perform actions outlined above.

The programmable exchange protocol has two phases:

• commit phase: sends the commitment to the blockchain to perform a certain action; each commitment can be cancelled by sending a cancellation order as another programmable exchange; each commitment is an NFT and can be produced in parallel using a minting policy, and 
• execution phase: all commitments are executed in each block against each other, resulting in trades. Due to high fragmentation and optimized routing, transactions require much less memory and can be managed efficiently.  

Maladex uses a minting policy to store all programmable exchanges as NFTs in a chain. Each NFT has data that defines all triggers. Publish this data on-chain for all to see and verify. 

The minting policy does not suffer from concurrency problems, and anyone can send as many programmable exchange orders at any time as desired. This naturally leads to the maximum possible concurrency, i.e., where all orders can be sent without a single error. The only limitation here is the 65 KB block limit size, although this could be increased in the coming months and is not a limiting factor for Maladex, as they have plans to scale well beyond any active limit. 

The process of minting NFTs can be done completely in parallel. Hence, it is possible to create a programmable swap, and interact with the Maladex protocol, with minimal risk of delays and requirement for sequencing. NFT minting is parallelizable. Once minted, NFTs storing the programmable swap code and assets required to transact are ready to interact with the market. Hence, the commit phase achieves the highest level of concurrency possible (full parallelism).

NFT Receipt

NFT receipt is an NFT containing the information about how the trade was executed and might contain a graphical visualization of the performed tasks, for instance:

• market orders (swaps) and limit orders will just include information about the execution price and time 
• Dollar-Cost Averaging (DCA) would contain a record of all buy orders, assuming DCA is executed daily over a period of 30 days, that would contain 30 records similar to market order / limit order outlined above 
• liquidity pool fragment minting using one of the available formulas and parameterization (stochastic models) will contain the pictorial representation of the model (distribution, its moments, and sensitivity to market dynamics), etc.

NFT receipts will fulfill these important roles:

• book-keeping – providing information to the user about how the orders were executed 
• Profit & Loss (P&L) tracking – tracking performance of the executed strategies 
• collectibles – best trades (achievements), first trade to exchange some newly listed asset, etc.

Algorithmic Automated Market Making (AAMM)

Algorithmic Automated Market Making (AAMM) is a novel AMM which emerges as a property of the Maladex protocol in order to:

• completely remove, or strongly limit, impermanent loss
• increase capital efficiency by utilising the capital more efficiently and keeping it constantly at work 
• use realistic pricing and liquidity curve models, as known from QuantFi and TradFi 
• dynamically adjust to market conditions and maintain liquidity pool properties via dynamically adjusting its parameters
• aid users in creating healthy liquidity pools and pairs 
• provide better means of price discovery 
• provide means of risk control.

Most established liquidity models do not model markets well, leading to low capital efficiency, expenditure of large amounts of energy compared to the total value locked, and have inherent scaling limitations due to global memory limitation. The AAMM model attempts to bridge that gap by applying more financial engineering scrutiny and bespoke methodologies.

Emerging Properties of Programmable Swaps and AAMM

The fragmented design of programmable swaps and mechanics built into AAMM lead to the emergence of a series of very desirable properties:

• Fragmentation leads to geometric price distribution due to the Central-Limit Theo- rem applied to the sample of investors; geometric price distributions are important because they represent the market accurately, and quickly arrive at new stable states when the market conditions shift 
• Freedom from impermanent loss due to all mechanics implemented into AAMM 
• High capital efficiency, meaning higher revenue generating potential on the same unit of money 
• Increased market efficiency, giving investors access to the true asset prices and a trove of investment educational content and data 
• Protocol adaptability to shifting market conditions 
• Means of risk control, helping to protect the investments made.

The automated and algorithmic execution offered by programmable swaps is fully executed on-chain. There are no links to external APIs, there is no external software that has access to the contracts, there is no critical component stored off-chain. It is worth noting that in Cardano’s on-chain validator and off-chain code programming model, while the off-chain component is responsible for selecting eUTxOs for the transaction, the actual execution still happens on-chain. This means that the model offered by the Maladex protocol is not only self-contained, but more importantly, it is trustless and implemented using smart contracts.

Off-Chain vs On-Chain

One property that is not talked about in sufficient depth, is the fact that any blockchain requires an off-chain component. In the case of classic account-based models like 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 sent to the blockchain for execution.

Cardano simply formalizes this concept by allowing a minimum required on-chain information, i.e., validators that provide all the typical guarantees and in which DEX developers must specify fairness and trust properties.

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

Off-chain execution engine

Anyone can run an off-chain execution engine.

• DEX has an incentive to run it for almost free, as it already charges a small percentage fee of all transactions (similar to 0.1-0.3%). 
• Anyone can run the DEX execution engine given its open source code provided along with any Cardano node (e.g., along with the relay).

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

The Cardano node in the following example is an updated node that can transmit transactions to the blockchain. An example of such a node is a relay. A portion of the DEX fees will be allocated for order execution, which will provide decentralization of the routing DEX component.

Furthermore, running these execution engines off-chain with the help of the community not only increases the decentralization of DEX (it is now run by a distributed group of people instead of routed by a centralized entity as in the case of classic DEX), but also leads naturally to the next point of this article, namely scaling beyond block and transaction memory limitations, and increasing the speed of transaction execution, through Hydra heads.

Memory Limit Solution

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

Let’s introduce the concept of scaling DEX execution capabilities across Hydra heads.

Each SPO (stake pool operator) running a Cardano relay and a Maladex execution engine will be able to join a group of operators participating in the creation of Hydra heads.

A Hydra head is a Cardano layer 2 isomorphic scalability solution. Isomorphism means that no compilation is required between different code formats and thus focus on writing Plutus code.

Hydra head formation will allow much shorter blocking times within the Hydra head, e.g., producing a layer 2 block every 1s and higher memory limit. Each Hydra head state of layer 1 block will be committed to the chain.

Since only the final state is returned to layer 1, where it is finally validated and merged, with no history, it allows significant scaling of transaction speed and memory limit. A Maladex Hydra head will be able to execute multiple block cycles (e.g., 20) during a single Cardano layer 1 block and return the result of 20 blocks to layer 1.

Oracles

Maladex is going to be both consumer and producer of Oracles.

Mathematically sound and timely Oracle data is necessary for implementation of collateralized synthetics, indexes rebalancing, and trading strategies, and more.

Maladex as an exchange with the highest capital efficiency will be able to provide the most timely and accurate Cardano-native asset prices, and we will make this information available to other projects, via Oracles in the future.

Additionally, Maladex is going to provide a series of trading indicators from the classical weighted moving price averages, divergence indicators, etc. to advanced quantitative data streams, similar to those used by the most sophisticated hedge funds in the world, advanced momentum based indicators (distribution momentums up to 6th order), Greeks, etc.

Source: White Paper v1

Web Site: https://www.maladex.com