status

Understanding Programmable Swaps

Published 8.3.2024, updated 11.3.2024

We view Axo as a significant innovator among blockchain projects in the trading sector. In this article, we will delve into the essence of programmable swaps, which form the cornerstone of Axo.

Harnessing The Potential Of Cardano

Cardano’s smart contracts, comprising on-chain validators and off-chain code, offer robust security. The Turing-complete off-chain code allows for the execution of complex and resource-intensive computations without affecting the transaction cost. The on-chain validators offer a level of security comparable to other blockchain models.

This innovation is groundbreaking, as it enables the implementation of concepts like programmable swaps and algorithmic automated market makers (AAMM), which would otherwise be unfeasible.

The Axo team has effectively harnessed the capabilities of the UTxO model and the design of the SC platform, enabling the execution of complex logic that executes all programmable swaps in the off-chain segment by their specifications and the on-chain state.

Despite the off-chain order matching engine, the protocol is as secure as if fully executed on-chain, thanks to on-chain validators.

On Cardano, it is possible to satisfy the demands of decentralization and Peer-to-Peer communication while building a modern scalable financial application.

Programmable Swaps

Think of a programmable swap as the most compact representation of a trader’s intent, embodied in a minted NFT with an on-chain state.

Programmable swaps comprise four elements:

  • Order type
  • Triggers
  • Actions
  • Assets

The order type conveys the swap preference, such as an immediate asset exchange (market order) or a swap at a set price (limit order).

Triggers set the conditions for swap activation. A market order, being trigger-less, is instantly active, resulting in an immediate asset swap.

A limit order has a price trigger. It remains inactive until the market price aligns with the set price, activating the swap and triggering the action.

The action outlines the swap’s operation upon activation, resulting in the creation of a transaction.

Assets are the subject of the proposed action.

The image illustrates a programmable swap of the limit order type. The trader has set a condition to exchange HOSKY for ADA when the HOSKY price matches or exceeds the ADA price. The intended swap involves 10000 HOSKY.

In the Axo protocol, there are many highly fragmented programmable swaps from many traders. Swaps are matched with each other by the order-matching engine and executed.

Programmable swaps allow an elegant way to execute many order types. Another example could be the dollar-cost average (DCA), dynamic liquidity provision, portfolio management strategy, etc.

The creation of programmable swaps is linked to the process of NFT minting, which occurs during the commitment phase. Programmable swaps are submitted to the blockchain via NFT minting, encapsulating all the essential data for swap execution. The parallelizability of NFT minting is a key advantage.

Once a programmable swap is recorded in the ledger, it transitions into the commitment phase. This is the waiting phase before the programmable swaps are moved to the execution pool. In the next block, programmable swaps are placed in the execution pool from which they can be selected and used.

To execute a swap, a minimum of two blocks is needed. The initial block is utilized for the commitment phase, during which a new NFT, representing a fresh swap intention, is minted. The swap can only take place in the subsequent block once the programmable swap is recorded in the blockchain.

With each additional block, new programmable swaps can be submitted, but already committed swaps are also executed.

The execution pool is divided into two sections: the Active Frontier and the Inactive Frontier. The Active Frontier houses swaps that are schedulable and can be executed in the current block, as all trigger-defined conditions are satisfied. Conversely, the Inactive Frontier contains swaps that are not executable as not all activation conditions are met.

The image illustrates the interaction of the Axo protocol with a Cardano block. New programmable swaps are submitted in the block. From Axo’s perspective, this occurs during the commitment phase, meaning swaps 5, 6, and 7 are only executable in the subsequent block. Swaps 1 and 2, situated in the Active Frontier, are presently engaged in asset swapping. Swaps 3 and 4, in the Inactive Frontier, await the fulfillment of all activation prerequisites to transition into the Active Frontier.

Let's see what happens with programmable swaps between two blocks.

The swap execution involves matching programmable swaps from the Active Frontier in block N and generating a transaction for block N+1. Multiple programmable swaps are used as input, from which not only a transaction can be created, but also a new programmable swap output containing unconsumed assets.

As depicted in the subsequent image, a new swap 8 emerges from swaps 1 and 2, serving as the input for a new transaction (indicated by the red arrow).

All programmable swaps from the commitment phase in block N transition to either the Active or Inactive Frontier (denoted by green arrows). Swaps 5 and 6 shift to the Active Frontier (they are schedulable), while Swap 7 stays in the Inactive Frontier.

Additionally, Swap 3 shifted from the Inactive Frontier in block N to the Active Frontier in block N+1 (highlighted by the purple arrow). Meanwhile, Swap 4 remains in the Inactive Frontier (marked by the blue arrow).

New swaps 9 and 10 were submitted in the new block N+1.

These procedures recur in each block with a larger number of programmable swaps.

Under given market conditions, it may happen that swaps that are in the Active Frontier are moved to the Inactive Frontier.

Every programmable swap eventually reaches its end of life (EOL), signifying that it can be discarded as it’s no longer required.

There are two scenarios leading to the destruction of programmable swaps.

One is the submitting of a cancel order in the form of another programmable swap, which destroys the existing programmable swap. The other is when the programmable swap reaches its EOL. It means that the intended actions have been completed or time expired.

The image below illustrates the various operations within the Axo protocol. The Execution Engine, an off-chain component of Axo, handles cancel orders (preventing their use in swaps), executes swaps, and updates the Active and Inactive Frontiers (relocating programmable swaps based on market fluctuations).

The Axo protocol stands out in its handling of programmable swaps. Its order-matching engine can pair programmable swaps of varying order types, such as matching a market order with a limit order.

Suppose a market order M is committed. This order can be executed as long as there’s liquidity, at the most favorable price available. Let’s say this price is offered by limit order L, and the assets sold by L are enough to fulfill market order M entirely. A transaction T is then submitted, using both M and L as input EUTxOs. Transaction T includes the swapped assets, which are spendable by the agent who submitted market order M, hence the assets are directly transferred to the agent’s wallet. A new UTxO is generated, holding the remaining assets not used up by the market order, thus creating a new programmable swap - a fresh limit order.

The image below illustrates the transaction executing the swap. The transaction input comprises the market order M from agent 1 and the limit order L. The transaction transfers assets to agent 1’s address and submits a new limit order L’, holding the remaining assets not utilized in the swap.

Observe that the market order’s requirements were met using the liquidity from the limit order, an approach that proves highly efficient in the context of liquidity.

Axo Works With Resources Very Efficiently

The minting of NFTs during the commitment phase is ideally structured for parallel processing. This enables the concurrent minting of programmable swaps in each block cycle, eliminating delays and sequencing requirements. The commitment phase optimizes concurrency and paves the way for high throughput.

The execution of programmable swaps requires the bare minimum of information, leading to reduced memory usage and cost.

Cardano’s architecture allows developers to integrate basic functionality in the on-chain part of the application, while complex functionality, including transaction preparation, is handled off-chain. On-chain validators only verify that UTxO spending conditions are fulfilled.

Off-chain functionality compiles transactions, which are then validated on-chain using validator scripts. These scripts can confirm the required state transition.

The Axo protocol’s intricate logic, which includes the order-matching engine and the execution engine for programmable swaps, is located in the off-chain part of the application.

It’s crucial to note that an automated and algorithmic execution process facilitated by programmable swaps is entirely conducted on-chain. This implies there are no connections to external APIs, no external software has access to the contracts, and no essential components are stored off-chain.

In Cardano’s programming model, the off-chain component is responsible for selecting EUTxOs for the transaction. However, the actual execution still takes place on-chain.

This suggests that the model provided by the Axo protocol is not only self-contained but, more importantly, it is trustless and implemented using smart contracts.

This design theoretically allows for efficiency comparable to modern centralized exchanges, while maintaining the characteristics of decentralization and self-custody of assets.

The Axo protocol works with highly fragmented programmable swaps. These are paired in the off-chain part of the application, requiring only minimal information stored in each programmable swap.

Once the Axo protocol can leverage the Hydra head for programmable swaps to scale transactions, the impact of this elegantly simple, fragmented design becomes evident. All EUTxOs in the active frontier can be transferred to the Hydra head for execution and, once executed, returned to layer 1 to settle trades. As each programmable swap represents the smallest possible intent, it ensures the most efficient information exchange between layers.

A distinctive characteristic of programmable swaps is their ability to be composed. This composability of programmable swaps implies that they can be merged, undergo type checking, and consequently generate new, unique programmable swaps. Composability is a fundamental aspect of functional programming, and the composition of programmable swaps represents the most functional programming approach to implementing financial contracts.

Conclusion

A programmable swap is a self-contained, trustless financial contract executed entirely on-chain. It's an autonomous unit of on-chain code. This allows for automated and algorithmic transactions, with complex logic handled off-chain. It's easy to transfer swaps to other layers and back.

These swaps are unique as they can be composed with each other, undergo type checking, and generate new unique programmable swaps.

The design of programmable swaps fractionalizes liquidity, making institutional-grade market making possible on-chain for the first time. This results in high efficiency, comparable to centralized exchanges, while maintaining decentralization and self-custody of assets.

Overall, programmable swaps are a key component in the decentralized finance landscape, increasing capital market efficiency and security.

Featured:

Related articles

Did you enjoy this article? Other great articles by the same author