> 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/orders-and-transactions/fills-and-refunds.md).

# Fills and refunds

Surge learns that an order filled by watching the blockchain for the batcher's transaction that spends your order, then checking what it paid to your wallet. Fills normally show within seconds of landing on chain; a backstop re-checks every open order every 30 seconds. A refund is detected the same way and shown as **Cancelled**.

### How a fill is detected

1. When your order is submitted, Surge records exactly which output of your transaction is the order (the one at the DEX's order address) and starts watching it.
2. Surge's chain indexer notices when that output is spent and reports the spending transaction to Surge immediately. Independently, a reconciler re-checks every watched order that is older than 20 seconds, 25 at a time, every 30 seconds, and asks the chain directly.
3. Surge sums everything that transaction paid to your payout address in the asset you were buying.
4. It classifies the outcome (below) and records it once. A second report of the same fill is ignored.
5. The order's status updates and the owning strategy reacts (grid re-arms the rung, arbitrage builds the sell leg, and so on).

The payout address is the address written in the order — normally the wallet that placed it, but in parallel arbitrage and cadence rotation it is a different wallet of yours, and Surge watches that one.

### How Surge tells a fill from a refund

| What the spending transaction paid you                                           | Outcome                                                                                                                                                                                                       |
| -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The asset you were buying, in at least half of the order's minimum               | **Filled**                                                                                                                                                                                                    |
| Nothing                                                                          | **Cancelled** (refund or your cancel)                                                                                                                                                                         |
| For a sell: your tokens came back, and no plausible proceeds                     | **Cancelled** — a genuine sell never returns the sold token                                                                                                                                                   |
| The asset you were buying, but less than half the minimum                        | Not counted as a fill. Surge stops watching and leaves the order **Open** for you to check — it will not guess                                                                                                |
| Proceeds plus a dust amount of the token (batchers sometimes return a few units) | **Filled** — for strategy orders, which record their minimum. A *manual* sell has no recorded minimum, so token dust makes it look like a cancel and it may show as **Cancelled** even though the ADA arrived |

The "half the minimum" rule protects against reading an unrelated payment or a partial scoop as a full fill.

### When two orders share a batcher transaction

Batchers fill many orders at once. If one batcher transaction consumes **two or more of your orders paying to the same wallet**, Surge cannot tell which proceeds belong to which order. It marks both **ambiguous**, retries the classification up to 5 times, and if the ambiguity persists, stops watching and leaves them Open for manual review. Your funds are in your wallet either way; only the bookkeeping is unresolved. This is why strategies space orders from one wallet at least two minutes apart.

### Auto-refunds: Minswap only

If the price moves past your order's minimum before the batcher arrives:

* **Minswap** refunds the order to the funding wallet. It shows as Cancelled within a few minutes.
* **SundaeSwap, WingRiders, Splash** do nothing. The order stays Open until you cancel it. See [Cancelling stuck orders](/orders-and-transactions/cancelling-stuck-orders.md).

### Finality and reorganisations

A fill is marked **final** once 10 further blocks have been added after it (about 3–4 minutes). If the chain reorganises and drops a block containing a fill, Surge flags that fill for review; it does not silently reverse the strategy's bookkeeping.

### When Surge stops watching

* After a fill or refund is recorded.
* After 5 ambiguous attempts.
* When the proceeds are implausibly small (above).
* After **24 hours** with no batcher activity at all. The order is presumably still open on chain and still yours to cancel — check the wallet detail page.

### What you see

* **Filled** rows show the amount received, the effective price, and the fill transaction hash (linked to Cardanoscan).
* **Cancelled** rows show the refund/cancel transaction hash.
* An order that Surge could not locate inside its transaction (rare) shows **Unknown** and is not watched — check it on Cardanoscan.

### Delays you may notice

* Fill detection depends on Surge's chain indexer keeping up; the backstop covers a missed event within 30 seconds.
* The transaction-confirmed toast ("in block") can arrive before or after the fill shows, since they come from different watchers.
* Balances on the Wallets page refresh every minute; a fill can show in the trade log before the balance updates.


---

# 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/orders-and-transactions/fills-and-refunds.md?ask=<question>&goal=<endgoal>
```

`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.