Understanding Cardano Batchers

Published 16d14h5m ago

Batchers are a concept used by some decentralized exchanges (DEXes) on Cardano to collect orders and execute swaps. Come learn more about them. We'll also explain why Cardano needs batchers and Ethereum doesn't.

The Role of Batchers

Batchers are a concept used by some decentralized exchanges (DEXes) to collect user orders and execute swaps. Batchers are entities that run nodes on the Cardano network and have the ability to create and submit transactions that invoke the on-chain code (validator scripts) of DEXes.

The goal of batchers is to improve the efficiency and scalability of a DEX by reducing the number of transactions that have to be processed by the blockchain. Batchers aggregate multiple user transactions into a single batch transaction that executes them all at once. This is a more efficient approach than if each user submitted their own transaction to the DEX.

Batchers collect user orders and create transactions that involve locking funds. It is done in the off-chain logic of the smart contract. They match all user orders and perform swaps through the creation of spending transactions, which again happens in the off-chain part of the smart contract.

Batchers sort the user transactions according to their priority and price, which helps to avoid conflicts or failures.

Users have to pay the usual network fees plus they pay batchers for swaps. Batchers deduct a small fee from each transaction they create as a reward.

In the picture below you can see a simplified diagram of the DEX that processes orders, matches them, and executes swaps. For this, the batcher needs to create transactions that are validated in the on-chain part of the smart contract.

Let's show it with an example. We will highlight some important details.

Alice wants to sell HOSKY and to have more ADA. Bob wants to buy HOSKY and sell ADA. A batcher node can combine these orders and perform a swap.

First of all, Alice and Bob need to find a batcher they trust and who is able to perform the swap. It can either be done automatically by DEX or they can choose a batcher they want, depending on the design and implementation of the DEX. Some DEXes allow users to select a specific node to be tasked with performing the swap, while others use a lottery to ensure random selection.

Once the batcher is selected, Alice and Bob must lock ADA and HOSKY. The swap can only be executed if the batcher has control over the spending of funds.

Alice sends HOSKY tokens to a script address controlled by the batcher. In the script, the conditions for spending HOSKY (e.g. the amount of ADA that Alice requests) are defined. Funds can be unlocked by anyone who can create a valid spending transaction (satisfy the conditions of the script). This is usually (not necessarily) the batcher who locked the funds.

Notice that the batcher is responsible for building the transactions that include the locking script. The users must sign transactions with their private keys. This way, the funds cannot be stolen by the batcher, as they do not have access to the user’s private key. The batcher only controls the scripts that lock and unlock the funds, but they cannot spend them without satisfying the swap conditions.

Users need to verify the transactions that are provided by the batcher before signing them with their private key. They can check that the transactions match the swap conditions and parameters, such as the token amount, exchange rate, and expiration time.

Bob must do a similar operation to Alice but with ADA coins. So ADA coins get locked at the script address controlled by the batcher.

HOSKY and ADA are locked and the batcher can match both orders. It verifies if it is possible to satisfy the spending conditions of both scripts that lock funds. If so, the batcher will create two spending transactions that unlock HOSKY and ADA from script addresses and send them to the addresses of the recipients, i.e. Alice and Bob, precisely according to their requirements.

The batcher submits both spending transactions to the Cardano network as a single atomic transaction. This means that either both transactions are executed successfully, or none of them are executed at all. This ensures that Alice and Bob receive their tokens and coins without any risk of losing their funds or being cheated by the batcher or each other.

We showed an example of the so-called direct swap that requires more coordination and communication between parties. Alice can explicitly say to the DEX that the counterparty must be Bob if she knows Bob's address and the number of tokens she wants to swap. Alice and Bob must agree on the swap conditions and parameters beforehand and then use a batcher to execute their swap transaction. A direct swap is more secure and efficient than a pool-based swap, where Alice and Bob do not know each other and rely on a liquidity pool to find a suitable match for their swap.

Why does Cardano need batchers?

Batchers play a crucial role in enabling smart contracts and swaps on Cardano. However, they also introduce some challenges and trade-offs. Let’s first have a look at some advantages:

  • They reduce the load on the blockchain and increase the throughput of the DEX, as fewer transactions have to be validated by nodes and stored in the blockchain. A batch transaction with 10 transactions has a smaller size than 10 individual transactions. This is because a batch transaction can combine multiple inputs and outputs into a single transaction, which reduces the overhead and redundancy of creating separate transactions.
  • They lower the fees for the users, as they can share the cost of the batch transaction among them. Fees in Cardano are based on the size of the transaction and the size depends (among other things) on the number of witnesses (signatures).
  • They improve the user experience, as they can provide faster and more reliable execution of their transactions.

Some disadvantages of batchers are:

  • They reduce the decentralization and security of the DEX, as they introduce a point of failure for the user transactions. If a batcher is malicious or compromised, it can manipulate, censor, or front-run the user transactions.
  • They increase the complexity and risk for the users, as they have to trust and interact with the batcher. Users have to send their funds and data to the batcher, who then creates and submits the batch transaction on their behalf.
  • Users have to rely on the availability and performance of the batcher node to execute their orders. If the batcher node goes offline or becomes overloaded, the transactions could be delayed or fail.
  • It is common for batchers to be mostly staking pool operators (SPOs) with a high stake. This poses an entry barrier for interested parties. This mechanism is intended to ensure honest behavior, as it combines the operation of the pool with the operation of the batcher node. If the batcher did not behave honestly, it could discourage delegators from staking ADA to the operator's pool. In addition to the fee for batching transactions, a dishonest batcher also risks losing staking rewards.

Now we come to the key question. Why does Cardano need batchers and Ethereum doesn't?

Batching is a technique that allows multiple transactions to be executed as a single atomic transaction on the blockchain. This means that either all transactions are executed successfully, or none of them are executed at all. From a security and correctness point of view, atomicity is absolutely essential. If any part of the batch is invalid or conflicting, the whole batch should fail. This prevents partial or inconsistent execution of transactions, which could lead to loss of funds, double-spending, or fraud.

Batchers are needed because Cardano does not support smart contracts in the same way as Ethereum or other blockchains, as it uses a different accounting model.

In the UTXO model, each UTXO can only be spent once. Each transaction consumes some UTXOs as inputs and creates new UTXOs as outputs. The balance of a user is calculated as the sum of all UTXOs associated with their addresses.

Outputs can be locked by scripts that specify the conditions for spending them. The logic for spending funds defined in the script may require the ability to know some context or state. A state is a set of data that represents the current condition of a system or a program. State information is essential for many applications that require interaction, computation, or verification on the blockchain.

Unlike Ethereum, where smart contracts can store and manipulate state variables, Cardano scripts can only access the inputs and outputs of the current transaction (only a local context or state is available). This means that Cardano scripts cannot perform complex logic or interact with other scripts within the on-chain part of the DEX smart contract.

The limitation of the UTXO model is that it does not support complex logic or state information.

To overcome this limitation, batchers act as intermediaries that collect, order, and execute transactions that involve locking and unlocking funds with scripts. In other words, the business logic of DEX is executed off-chain because it is possible to work with the state of the application.

The UTXO model does not have a global state that can be updated or accessed by transactions. Instead, each transaction can only access the inputs and outputs of the current transaction. UTxO's Datum, Redeemer from spending transaction, and transaction (local) context are available during script execution.

This means that transactions cannot perform operations that depend on external variables or conditions, such as arithmetic operations, conditional statements, loops, or function calls. Moreover, transactions cannot interact with other transactions or scripts on the blockchain, which limits the functionality and interoperability of applications.

Batchers enable swaps on Cardano because they enable the implementation of algorithms that can work with multiple transactions (orders) simultaneously and maintain the application state.

Ethereum does not need batchers because it uses a different accounting model called the account-based model. The account-based model keeps track of the balance of each account as a global state. Each transaction updates the state of the system according to the logic and data contained in the transaction. The account-based model supports complex logic and state information because it allows transactions to access and modify the global state of the system. Simply put, Ethereum enables the implementation of DEX logic through smart contracts.

Short Comparison between Cardano and Ethereum

The difference between the UTXO and account-based models is related to the global state of Ethereum. Ethereum has a global state that can be updated or accessed by transactions.

Cardano does not have a global state. The execution of transactions is independent of each other, as it depends only on the local context. This makes Ethereum more suitable for smart contracts and swaps than Cardano, but it also introduces some challenges and trade-offs:

  • Ethereum’s global state is more complex than Cardano’s UTXO model, which makes it harder to verify and maintain. Higher complexity often brings vulnerabilities and attack vectors.
  • Ethereum’s global state requires more storage and computation than Cardano’s UTXO model, which limits its scalability and performance. The EVM executes transactions sequentially, one after another, and updates the state accordingly. The sequence must be followed during block validation.
  • Ethereum’s global state exposes more information than Cardano’s UTXO model, which reduces its privacy and anonymity.

The IOG team chose the UTxO model and they deliberately did not want to have something like a global state. They wanted to leverage the benefits of the UTxO model while overcoming its limitations. They did this by introducing an extended version of the UTxO model, called eUTXO, which allows transactions to carry some state information and execute custom logic using smart contracts.

The eUTXO model preserves the simplicity, privacy, and scalability of the UTxO model (as you know it from Bitcoin) while enabling more functionality and interoperability of applications.

The eUTxO model, i.e. the absence of the global state, has certain advantages for Cardano.

  • Validator scripts (on-chain logic) are very small and simple to validate. This saves the computing resources of the distributed network. Teams are forced to implement most of the application logic in the off-chain part that can be easily upgraded. During on-chain validation, it is possible to work with the local state (unlike Bitcoin's UTxO model) through Datum and Redeemer.
  • The eUTxO model allows users to create multiple addresses and use different UTxOs for each transaction, which makes it harder to link transactions to a single identity or trace the history of funds.
  • The eUTxO model enables parallel processing of transactions, as each UTxO can be verified independently and concurrently by different nodes. This reduces the bottleneck and latency of the network. During block validation, it is not necessary to follow the order, as the transactions are independent of each other.

One of the main reasons for choosing the eUTXO model over the account-based model is better scalability and parallelism. The eUTXO model allows transactions to be processed in parallel by different nodes, as long as they do not conflict with each other. This means that the throughput and performance of the network can be increased by adding more nodes and resources.

The account-based model, on the other hand, requires sequential processing of transactions, as each transaction depends on the global state of the system. This means that the throughput and performance of the network are limited by the speed and capacity of a single node.

This topic is more complex and the comparison between Cardano and Ethereum would deserve a separate article. We wanted to explain how batchers work and why Cardano needs them, unlike Ethereum. I hope we succeeded.


The nice thing about Ethereum is that it is possible to implement DEX logic in smart contracts without the need to have off-chain logic. On the other hand, it is inefficient. If more users wanted to use DEXes, Ethereum could have problems with scalability. There are already DEXs in the Ethereum ecosystem today that have an off-chain Cardano-like logic for matching orders and executing swaps. The most used DEX in the Ethereum ecosystem is Uniswap and it is an on-chain DEX.

Most DEXes in the Cardano ecosystem use batchers. Batchers can be seen as a single point of failure. If a batcher locks funds and subsequently goes offline, it may not be possible to create spending transactions (it may be possible that another batcher can create them within one DEX). On the other hand, it must be said that the economic incentives are set well. Batchers are motivated to perform batching honestly as they risk losing business and potentially delegated ADA coins.


Related articles

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