> For the complete documentation index, see [llms.txt](https://docs.surgecardano.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.surgecardano.com/core-concepts/how-cardano-dex-trading-works.md). # How trading on Cardano DEXes works A swap on a Cardano DEX is not instant and is not guaranteed to happen. You place an **order**; a third-party **batcher** run by the DEX executes it against the liquidity pool a minute or two later, or refunds it, or — on some DEXes — leaves it sitting until you cancel. Everything else in Surge follows from this. ### Orders, not swaps On most blockchains a swap is a single call that either succeeds or fails immediately. On Cardano, a swap is two transactions by two different parties: 1. **Your transaction** places an order. It locks your ADA (or tokens) at the DEX's order address along with a small note — called a **datum** — stating what you want to receive, the minimum you will accept, and where to pay out. This is the transaction Surge builds and you sign. 2. **The batcher's transaction** fills it. A batcher (SundaeSwap calls it a scooper, WingRiders an agent, Splash an executor) collects many pending orders, executes them all against the pool in one transaction, and pays each order's proceeds to the address in its datum. The batcher keeps a flat fee for this. Surge does not control the batcher, cannot call it, and gets no receipt from it. When your order transaction is confirmed on chain, all that is known is that the order was *placed*. Whether it *filled* is detected separately, by watching the chain for the batcher's transaction. See [Fills and refunds](/orders-and-transactions/fills-and-refunds.md). ### Why fills are not instant A Cardano block arrives roughly every 20 seconds, and the batcher needs a few blocks to see your order, include it in a batch and have that batch confirmed. The normal wait between placing an order and seeing it filled is **1–2 minutes** on every supported DEX. Surge treats an order as "stuck" only after it has been open for more than **3 minutes**. ### Why an order can sit unfilled Your order carries a **minimum received** amount (the "slippage floor"). If the price moves against you between placing the order and the batcher arriving, the pool can no longer deliver that minimum, so the batcher cannot fill it. What happens next depends on the DEX: * **Minswap** refunds it automatically. Your funds come back to your wallet minus the network fee, and the order shows as Cancelled. * **SundaeSwap, WingRiders and Splash** leave it where it is. The order stays open at the DEX's order address, with your funds locked in it, until you cancel it. Surge's strategies offer you a cancel transaction automatically after 5 minutes; for manual swaps you use "Cancel & reclaim". See [Cancelling stuck orders](/orders-and-transactions/cancelling-stuck-orders.md). Your funds are never lost in either case — they are in an on-chain order that only you can cancel — but on the three non-refunding DEXes they are tied up until you act. ### Where the price comes from There is no order book. Each pool holds a reserve of ADA and a reserve of the token, and the price is the ratio of the two. Every trade moves the ratio, so a large trade gets a worse average price than a small one — this is **price impact**, and it is already included in every quote Surge shows. The pool also charges a **liquidity-provider fee** (typically 0.3%) on every trade, which is likewise inside the quoted price rather than a separate line. See [How prices are sourced](/core-concepts/how-prices-are-sourced.md). ### One order at a time per wallet Cardano wallets hold funds as discrete "coins" (UTxOs). When you place an order, the change from that transaction is not spendable until it confirms. If a second order is built from the same wallet a few seconds later it will try to spend coins the first order already used, and the second transaction fails. Surge therefore spaces orders from the same wallet by about **two minutes**. This is why a grid or rule-based plan never fires two rungs at once from one wallet, and why Cadence waits for each order's transfer to settle before sending the next. ### The fees you pay on every order Every order pays the Cardano network fee, the batcher fee, a refundable order deposit (returned when the order fills or is cancelled), the pool's fee (inside the price), and the Surge fee. The [Fee breakdown](/fees-tiers-and-staking/fee-breakdown.md) page has the numbers and a worked example. ### What this means for a strategy * A strategy's decision to trade and the actual fill are separated by a minute or more, and the price can move in between. Strategies handle this with minimum-received floors and, for grid and arbitrage, by re-checking the price just before building the order. * A strategy cannot "undo" a placed order. It can only wait for the fill, wait for a refund, or cancel. * Profit and loss can only be measured from actual fills, never from the moment of decision. See [Profit and loss](/orders-and-transactions/pnl.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.surgecardano.com/core-concepts/how-cardano-dex-trading-works.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.