If you came from an EVM chain, that wait feels like a bug. It is not. It is the ledger model talking, and once you see why, every chart and table of Cardano DEX data starts to read differently.

This post is for developers and data people who want to understand what is actually happening between "order placed" and "swap done", and how to avoid the classic mistakes when you index or analyze Cardano DEX activity.

Start with the coin, not the account

On an account based chain, a pool contract is one object with mutable storage. A thousand users can hit it in the same block, and the chain just orders their calls one after another.

Cardano does not work like that. It uses the Extended UTXO model. Value lives in discrete outputs. Each output has an address, a value, and optionally a datum. A transaction consumes existing outputs whole and creates new ones. Each output can be spent exactly once.

The "extended" part adds two things. Addresses can be scripts, so spending can depend on arbitrary validation logic. And outputs can carry data, so a script can keep state in the datum.

Validators do not compute new state. They check it. Off chain code builds the transaction, and the on chain script returns yes or no. The Plutus docs put the upside plainly: validity depends only on the transaction and its inputs, so you can check it off chain before you submit. The catch is in the same paragraph. A transaction can still fail if someone else spends an input it expected.

Hold that thought. It is the whole story.

One pool, one UTXO, one winner

A constant product pool needs a single shared view of its reserves. On Cardano the natural place for that is one UTXO at the pool script address, holding the reserves and a datum with pool parameters.

Now picture three users building a direct swap against that pool in the same block. All three transactions reference the same pool UTXO as an input. The first one included wins. The other two fail because their input no longer exists. The Cardano Developer Portal describes exactly this and calls it what it is: a fundamental property of the model, not a bug.

If you build a DEX the account way on eUTXO, you get a race on every block. Users rebuild, resubmit, and lose again. Sundae Labs wrote a good deep dive on this contention problem if you want the long version.

Enter the batcher

The most common fix splits a swap into two steps by two different parties.

Step one, the user. Your wallet does not touch the pool. It sends your funds to an order script address with a datum that encodes intent: what you sell, what you want, the minimum you accept, and where to pay out. This transaction cannot conflict with anyone else, because it only spends your own UTXOs.

Step two, the batcher. An off chain service watches the order address, collects pending orders, and builds one transaction that spends the pool UTXO plus many order UTXOs together. It outputs a new pool UTXO with updated reserves and pays each user per their datum. The validator enforces that every order got what its datum allows.

Different DEXs name this role differently. Scooper, agent, executor. Same job.

The batcher absorbs the contention users would have felt. It keeps its own view of pending orders, rechecks that queued orders still exist before building a batch, and rebuilds from fresh chain state when it loses a race. It also picks which orders go in and in what sequence. That ordering policy is where fairness lives, so it is worth reading for any DEX you analyze.

IOG notes another cost: when N orders are consumed in one transaction, the order script runs N times and the execution budget adds up. That is why batch sizes have practical ceilings and why some designs move work around to keep scripts cheap.

There are other patterns too. Some designs split liquidity across several UTXOs so more than one transaction can touch the pool per block. Others chain transactions within a block. But batching is the one you will meet most when you read raw data.

What this means when you read DEX data

Here is where people get burned. Most mistakes in Cardano DEX analytics come from treating a swap as one event.

1. An order is not a trade

The user transaction that locks funds at the order address is intent, not execution. Some orders get filled. Some get cancelled. Some sit until the user reclaims them. If you count order transactions as volume, you are counting wishes.

Real volume comes from the batch transaction, where pool reserves actually change. Measure the delta between the pool UTXO consumed and the pool UTXO produced. That delta is the trade.

2. Price lives in reserves, not in orders

The minimum receive amount in an order datum is a slippage guard, not a price. The executed price is set by pool reserves at batch time, in the order the batcher processed things. Two orders in one batch can get different prices because the first one moved the reserves before the second one hit.

If you want a clean price series, read reserves from successive pool UTXOs. Do not average minimums from order datums.

3. Timestamps have two meanings

There is the time the user placed the order and the time it executed. In a busy period those can be different blocks. Decide which one your metric uses. "Time to fill" is a useful metric in its own right and tells you a lot about batcher health.

4. One batch, many wallets

A single batch transaction pays out to many addresses. If your indexer attributes the whole transaction to whoever signed it, you will make the batcher look like the biggest whale on the chain. Attribute each payout to the address in the corresponding order datum.

5. Fees come in layers

The user pays the normal network fee to place the order. The batcher earns a flat fee per order for execution. The pool charges its swap fee, which usually stays in reserves and accrues to liquidity providers. These are three different numbers with three different recipients. Mixing them up makes fee revenue charts wrong in confusing ways.

6. Each DEX encodes datums its own way

There is no universal order datum. Every protocol defines its own schema for orders and pool state, and versions change. A robust indexer keeps a parser per protocol and version, keyed by script hash, and fails loudly on an unknown shape instead of guessing.

7. Your own wallet has contention too

A wallet is also a set of UTXOs. Fire two orders back to back from the same wallet before the first confirms, and the second may try to spend inputs the first already used. That shows up in data as a burst of failed or delayed submissions that have nothing to do with the DEX itself.

A quick mental model for your pipeline

When you design a Cardano DEX indexer, think in three streams:

• Intent stream. Order UTXOs created at order script addresses, decoded per protocol.
• Execution stream. Pool UTXO transitions, with reserve deltas and the set of orders consumed in each batch.
• Settlement stream. Payouts to user addresses, linked back to the order that caused them.

Join them on order output references. Now you can answer real questions. Fill rate. Time to fill. Effective price versus quoted minimum. Batcher share of executions. Volume that actually moved reserves.

If you would rather explore those numbers than build the pipeline yourself, DeFiTap tracks Cardano pools, tokens and DEX volume in one dashboard.

The takeaway

On Cardano, a swap is a conversation between your wallet, an order script, a batcher, and a pool UTXO. Read the data as that conversation, not as a single call, and your numbers stop lying to you.

Not financial advice. Do your own research.

Track Cardano DeFi in one tap at https://defitap.io