Cardano Swaps: A DEX that taps into the full potential of the eUTXO model

The Extended Unspent Transaction Output (E-UTxO) model of Cardano is fundamentally superior to Ethereum’s account-based model. This model enables the implementation of innovative, scalable solutions that are virtually impossible to achieve using Ethereum’s account-based approach.

However, many current dApps on the Cardano settlement layer (CSL) , especially DEXs, do not fully leverage the advantages of this model. Instead, most designs closely resemble the Ethereum Virtual Machine’s (EVM) account-based programming paradigm. What is needed are dApps that make innovative design choices and fully exploit the potential of Cardano’s E-UTxO model.

That’s where the idea of distributed dApps offers a groundbreaking approach to dApp design that fundamentally reimagines the underlying model, unlocking the full potential of Cardano’s E-UTxO model.

In this article, we will explore the benefits of distributed dApps and their functionality within the context of Cardano-Swaps, a distributed Cardano DEX proof-of-concept that utilizes composable atomic swaps, allowing users to maintain delegation control at all times.

Overview of Concentrated dApps

Before delving into the details, it is essential to understand the concept of concentrated dApps and differentiate them from distributed dApps.

Concentrated dApps are a type of decentralized application architecture where users share a limited number of addresses while interacting with the dApp. This design choice can have several implications, such as centralization of assets, reduced user control, and potential security risks.

Structure and Functioning of Concentrated dApps

In concentrated DApps, users’ assets are pooled together into one or more shared addresses, controlled by the DApp’s smart contracts. This allows for easier management of funds and consolidation of value, but it comes at the expense of individual user control.

The shared addresses in concentrated dApps are governed by smart contracts that define the rules and conditions for transactions and interactions within the application. While this can simplify certain aspects of the dApp, it may introduce potential bottlenecks and challenges related to scalability and decentralization.

Challenges and Drawbacks of Concentrated dApps

These dApps aren’t truly decentralized in their current form

Although they run on top of a decentralized platform, there are many points of centralization.

By pooling users’ assets into shared addresses, concentrated DApps can lead to centralized control of funds, which goes against the core principles of decentralization in blockchain technology.

Furthermore, managing such “concentrated” addresses requires either trusted “admin keys” or some kind of DAO structure, which in turn necessitates some kind of “dApp token,” thereby complicating the security/trust model. Higher complexity increases both the social and technical attack surfaces.

A simple example of management challenges is: who decides how or when to upgrade to new contracts?

These dApps fall short in facilitating decentralized scalability

As concentrated dApps grow in popularity, the shared addresses and smart contracts may struggle to handle the increasing volume of transactions and interactions, leading to potential bottlenecks and performance issues.

Additionally, it is unclear how concentrated dApps would interface with state channels like Hydra, which is a core component of Cardano’s scalability roadmap, without sacrificing decentralization.

These dApps fail to facilitate delegation control

Until now, only a few L1 dApps have allowed users to retain full delegation control over their assets. As the popularity of an L1 dApp grows in a Proof-of-Stake (PoS) blockchain, the centralization of underlying stakes becomes a significant security risk.

Some dApps employ strategies such as dividing asset pools or distributing governance tokens to tackle this issue. However, these solutions are insufficient, as they can lead to an inequitable distribution of governance tokens and an unavoidable centralization of stakes. This could become a major problem if any dApp attains a substantial stake on a PoS blockchain.

The greater the delegation control’s decoupling from the owner, the more Ouroboros’ game theory becomes distorted. This misalignment complicates estimating the distortion’s extent, highlighting the need to minimize its impact. It is essential for dApps to allow users to maintain full delegation control of their assets while using them, as this is fundamentally important for the proper functioning of PoS blockchains.

To make this concept of concentrated dApps more tangible, let’s take a look at the drawbacks of the current DEX models.

Drawbacks of the Current DEX Model

The current decentralized exchange (DEX) implementations on Cardano settlement layer (CSL) face numerous challenges. Many of these DEXes operate by confining users’ assets within strictly defined or centrally managed sets of script addresses. These DEX models, which closely resemble the Ethereum Virtual Machine’s (EVM) account-based programming paradigm, inherit several drawbacks, including scalability limitations and centralization of both assets and stakes.

To better comprehend and tackle these limitations, it is essential to explore the complexities of the existing DEX models and assess their inherent weaknesses.

1. Impermanent Loss: Centralized script addresses necessitate liquidity pools and liquidity providers (LPs), which in turn leads to impermanent loss for LPs. Although workaround solutions like yield farming and concentrated liquidity attempt to mitigate these issues, they are highly capital inefficient.

2. Scaling Bottlenecks: To tackle scaling bottlenecks, workaround solutions such as batchers, execution/routing engines, and other intermediaries are employed. However, these “solutions” come with their own set of issues:

• Intermediaries can exploit their position between users and the protocol.

• Even with Miner Extractable Value (MEV) mitigated, an increase in users leads to higher execution demand, which could result in the centralization of intermediaries if batchers are not permissionless.

• Current implementations of order-book style DEXes (which do not use liquidity providers) still face scalability challenges posed by permissioned batchers. Regardless of a batcher system’s performance, its resources will not scale proportionally to the number of users unless new batchers can join permissionlessly when demand is high.

Introduction to Distributed L1 dApps

Distributed L1 dApps, in contrast to concentrated dApps, are decentralized applications where each user has their own personal address while using the dApp. This design allows for greater decentralization and user control over assets. 

Advantages of Distributed L1 dApps over Concentrated dApps

Distributed L1 dApps offer several advantages over concentrated dApps:

1. Censorship Resistance: DeFi as a whole may be perceived as a threat by those in positions of high power. Therefore, censorship resistance is an essential feature for protocols that offer an alternative to the status quo. Fully p2p dApps offer the highest level of censorship resistance of any dApp architecture because users not only have full custody of their assets but can also fractionalize and recompose their interactions across an already decentralized ledger, instead of pooling their assets into one or a few contracts.

2. Full delegation control: Users maintain full custody of their assets while using the dApp since owner-related actions must be approved by the staking credential.

3. No “dApp” Tokens: Since contracts are open source and fully p2p, there is no need for additional governance/DAO/yield tokens for distributed dApps. All you need is ADA to pay for transaction and minUTxO fees.

4. User ID simplification: The address itself can act as the User ID, eliminating the need to place a User ID in a datum and guard its usage.

5. Improved concurrency: The distributed L1 dApp is naturally concurrent and becomes more concurrent as the number of users increases.

6. Democratic upgradability: Users can choose whether to move their assets to an address using a newer version of the dApp’s spending script.

7. Easy integration: The dApp is easily integrable into existing frontends (wallets).

8. Simplified dApp logic: In some cases, the dApp’s logic can be dramatically simplified since the address itself can act as the User ID.

Designing of Distributed L1 dApps

Distributed L1 dApps typically follow a general design pattern:

1. All user addresses employ the same spending script for a given use case.

2. All user addresses must have a staking credential.

3. The spending script delegates the authorization of owner-related actions to the address’s staking credential. The staking key must sign, or the staking script must be successfully executed in the same transaction. This particular feature is also known as “Stake Key Overloading.”

How is such a dApp design possible?

So let’s take a look at Beacon Token, the native token standard (work in progress) that makes distributed dApps possible.

What is a Beacon Token?

A Beacon Token is a work-in-progress native token standard on Cardano that simplifies the querying of on-chain data by efficiently tagging it, making it easily accessible by off-chain APIs.

In simpler terms, Beacon tokens serve two main functions in dApps, depending on the specific application:

1. To manage the flow of dApp logic: A script validator can only output X if Token A is input. To get Token A, output Y containing Token A must have occurred earlier, which depends on Token B, etc. By carefully combining token minting policies with script validator policies, complex dApp logic can be achieved.

2. To label or tag data in a way that makes sense for dApp users: “Data” can refer to an address, UTXO, or transaction, depending on the dApp. This approach addresses the routing and indexing problem for distributed dApps, as existing off-chain APIs can be used for queries.

For example, a simple beacon token can be used to store an “address book” on-chain that spans multiple UTxOs. They can also be used to build complex distributed dApps. 

How Do Beacon Tokens Work?

All native tokens on Cardano continuously broadcast their current address and any transactions they have been a part of. However, Beacon Tokens are specifically designed to broadcast information efficiently by tagging on-chain data, making it possible to query this data using off-chain API services.

While all native tokens can broadcast information, broadcasting is usually not the primary purpose of native tokens (e.g., governance tokens). In contrast, a Beacon Token’s sole purpose is to broadcast information, making it easier to identify and access specific transactions, addresses, or UTxOs.

By identifying which addresses and transactions contain the Beacon Token, we can gather various pieces of information, including:

1. Any reference scripts stored at the address and their associated UTxO TxIx.
2. Any datums stored at the address.
3. The stake address associated with that payment address.
4. The metadata history of each transaction that contained the token.
5. The datum history of each UTxO that held the token.

(UTxO TxIx stands for Unspent Transaction Output Transaction Index. The term “TxIx” refers to the transaction index, which is a unique identifier assigned to each UTxO within a specific transaction. This index is used to differentiate multiple UTxOs associated with the same transaction, allowing for precise identification and tracking of UTxOs on the blockchain.)

Design of Beacon Tokens

Every native token on Cardano has two configurable fields: the policy ID and the token name. The policy ID is application-specific, while the token name can be data-specific.

In the case of Beacon Tokens, a unique native token is created for a specific application, and if necessary, the spending of UTxOs with beacons is controlled.

To broadcast particular transactions, addresses, or UTxOs, the Beacon Token is included in the corresponding transactions, stored at the desired addresses, or held within the specified UTxOs.

DDoS and bloat prevention is achieved by carefully aligning Beacon Tokens’ minting policies with script spending policies. This ensures that the broadcasting functionality is secure and efficient, providing a seamless experience for Cardano-Swaps users.

Cardano Swaps: a proof of concept DEX based on distributed dApp design

Cardano Swaps is a proof-of-concept distributed DEX that leverages Cardano’s unique features. This section will break down how it works and explain its key functionalities.

Address Structure, Beacon Tokens, and Trading Pairs in Cardano Swaps

Cardano addresses consist of both a payment credential and a staking credential. Users maintain delegation control over their addresses as long as the staking credential is unique. Cardano Swaps employs this concept by providing users with addresses composed of identical spending scripts (per swap pair) and unique staking credentials. The spending credential is designed to grant the staking credential authority over all owner-related actions, except for the actual swap execution.

Beacon Tokens are employed to tag Cardano Swaps addresses, making them easily queryable via off-chain APIs like Koios or Blockfrost. All addresses containing a specific native token can be easily found. The UTxO query also returns information about which UTxOs contain reference scripts, allowing users to execute their swaps.

In Cardano Swaps, each trading pair gets its own spending script, which is achieved through the use of an extra parameter. Each combination of swapOffer and swapAsk results in a different spending script, and consequently, a unique beacon policy. The beacon policy-id carries all the information needed to determine the trading pair being used.

Here are some examples:

1. Simple Swap

2. A Complex Swap

Minting and Burning Requirements for Cardano Swaps Beacon Token

Minting beacons for Cardano-Swaps is a tightly controlled process. In order to mint beacons, all of the following must be true:

1. Only one beacon is minted per Tx.

2. The minted beacon uses an empty token name.

3. The beacon is minted to an address protected by the Cardano-Swaps spending script for a particular trading pair.

4. The beacon is minted to an address with a staking credential (either a pub-key or a script).

5. The staking credential is unique per trading pair.

Burning beacons is always allowed, as long as the burn redeemer is used solely for burning beacons.

Querying, Pricing Visibility, and Swap Contract Actions in Cardano Swaps

Beacon Tokens can be used to tag on-chain data associated with the address containing the Beacon, the UTxO containing the Beacon, or the transaction information where the Beacon has been involved. This creates an easily searchable and trustless metadata history trail.

To allow users to view each other’s asking prices, Cardano Swaps requires all datums for the DEX to be inline datums, enforcing this behavior whenever possible. Prices in Cardano Swaps are always local, resembling limit orders in an order-book exchange.

Swap contracts in Cardano Swaps offer three possible actions or redeemers: Close, Update, and Swap. The Close redeemer enables the owner to withdraw any UTxO located at the swap address and burn the beacon. The Update redeemer allows the owner to modify the asking price of their positions. The Swap redeemer carries out a swap with assets at the swap address.

Impactful Features of Cardano-Swaps

So let’s take a look at some of the key features of Cardano-Swaps that would set it apart from other DEXs on Cardano settlement layer (CSL).

1. Full Custody – users always maintain full spending and delegation control over their assets.

2. Natural Concurrency – throughput scales with the number of users. No specialized batchers/indexers are required.

3. Composable Swaps – many swaps can be fulfilled in a single transaction by “chaining” swap logic.

4. Emergent Liquidity – arbitragers are incentivized to spread liquidity to all trading pairs.

5. Zero Slippage – minimum swap prices are explicitly defined

6. No Superfluous “DEX” Tokens – ADA is all you need to pay for TX fees.

7. Democratic Upgradability – users choose if/when to use new contracts.

8. Frontend Agnosticism – relatively straightforward integration with existing frontends (i.e. wallets).

What prevents this DEX from deployment on Cardano today?

A notable limitation in deploying Cardano Swaps on the Cardano Settlement Layer (CSL) involves the redundant execution of validator scripts. In simpler terms, when multiple UTxOs are locked by a single validator script, the script has to execute once for every individual UTxO, regardless of whether the transaction validity relies on any specific UTxO.

This issue is particularly apparent in Cardano Swaps, where UTxOs are frequently composed, often from the same address or script. As a result, the validator script needs to execute multiple times for each UTxO. This redundancy not only leads to increased transaction fees but also quickly reaches the maximum limit for script execution units in a single transaction.

An important factor to consider when discussing dApps like Cardano Swaps is the programming language used for their development. Presently, many dApps, including Cardano Swaps, are written in Plutus-Tx, a high-level Haskell-like language that compiles to Untyped Plutus Core (UPLC). The UPLC code is then executed by the cardano-node. Although Plutus-Tx provides auditability and upgradeability, it demands substantial resources.

Newer, more resource-efficient languages that compile directly to UPLC, such as Aiken, could offer up to a 100-fold increase in execution unit headroom. This significant optimization has the potential to render redundant executions a negligible concern. 

However, it is worth noting that directly addressing redundancy issues would necessitate hardfork-level changes to Plutus, which is a considerable challenge.

Conclusion

In conclusion, to achieve massive scale on the Cardano settlement layer (CSL), dApps must adopt a fundamentally different approach that leverages the concurrency and parallelism offered by the eUTxO model, moving away from designs resembling the Ethereum Virtual Machine’s (EVM) account-based paradigm. Embracing innovative design choices and harnessing the full potential of Cardano’s eUTxO model is crucial for this evolution.

The realm of distributed dApps on Cardano is still relatively unexplored, with concepts like Cardano Swaps—a distributed Cardano DEX proof-of-concept employing composable atomic swaps—showing immense promise. By allowing users to maintain delegation control at all times, these pioneering solutions pave the way for a new era of decentralized applications on the Cardano platform.

References

https://github.com/fallen-icarus/cardano-swaps

https://github.com/fallen-icarus/cardano-reference-scripts

https://github.com/fallen-icarus/cardano-address-book

Courtesy: A huge thank you to Zhekson, the mastermind behind Cardano Swaps, for his invaluable guidance in completing this article and to Perry for his excellent feedback.