> 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/trade-lifecycle-and-statuses.md). # From decision to confirmation: the trade lifecycle A Surge trade goes through six stages: **decided → built → signed → submitted → open → filled (or cancelled)**. The stages up to "submitted" happen in seconds; "open" normally lasts 1–2 minutes; "filled" is detected, not returned. ### The stages | Stage | What happens | Where you see it | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------- | | 1. Decided | A strategy's conditions are met (a grid line crossed, a spread appeared, a rule level reached, a DCA interval elapsed in your browser), or you clicked Swap | Strategy activity feed | | 2. Built | Surge builds the exact transaction: the order with its minimum-received floor, the DEX deposit, the Surge fee output, change back to you. A manual swap or send build is valid for **5 minutes**; strategy builds are re-offered by the strategy if unsigned | "Building" / "Rung built" steps | | 3. Signed | Your browser signs it (see [Signing and approvals](/core-concepts/signing-and-approvals.md)) | Signing Approval window | | 4. Submitted | Surge verifies the signed transaction matches what it built, then broadcasts it. You now have a transaction hash | Status **Submitted** | | 5. Open | The transaction is in a block. Your order sits at the DEX waiting for the batcher | Status **Open** | | 6. Filled / Cancelled | The batcher spent your order and paid you (Filled), or refunded it / you cancelled it (Cancelled) | Status **Filled** or **Cancelled** | ### Statuses you will see The Activity page, dashboard and strategy trade logs use one set of statuses for every order: | Status | Meaning | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Submitted** | Broadcast, not yet seen in a block. Usually under a minute | | **Open** | On chain, waiting for the batcher. Normal for 1–2 minutes. After 3 minutes Surge labels it **stuck** and offers diagnosis and cancel | | **Filled** | The batcher executed it and paid your wallet. The received amount and effective price are recorded | | **Cancelled** | Your funds came back — either the DEX refunded an unfillable order (Minswap) or you cancelled it. Both show as Cancelled | | **Dropped** | The transaction never made it into a block (the network dropped it). Nothing was spent; the strategy can retry | | **Unknown** | Surge could not identify the order's position in the transaction, so it cannot track the fill automatically. Rare; check the transaction on Cardanoscan | Strategy-specific pages add finer steps (for example a grid rung's "pending sign" or an arbitrage opportunity's "sell ready"); those are explained on each strategy page. ### How Surge knows an order filled Surge cannot ask the DEX. It watches the blockchain for the transaction that *spends* your order. Two watchers run: a live feed from Surge's chain indexer (fastest) and a backstop that re-checks every open order every 30 seconds. Whichever sees it first wins. Surge then looks at what that transaction paid to your address: * proceeds arrived → **Filled**; * nothing arrived, or (for a sell) your tokens came back → **Cancelled** (refund); * the same batcher transaction consumed two or more of your orders at once → Surge cannot tell which proceeds belong to which order and marks the outcome **ambiguous**; it retries up to 5 times and then leaves the order Open for you to check. A fill is treated as **final** after 10 further blocks. If the chain reorganises after that, Surge flags the fill for review rather than silently changing history. ### Timing you can expect | From | To | Typical | | --------------- | ------------------------------ | ------------------------------------------------------------ | | Decided | Signing prompt in your browser | seconds `[VERIFY: approximate]` | | Signed | Submitted | seconds | | Submitted | Open (in a block) | one or two blocks (\~20–60 seconds) | | Open | Filled | 1–2 minutes | | Filled on chain | Shown as Filled in Surge | seconds via the live feed; up to 30 seconds via the backstop | An order still Open after **3 minutes** is shown as stuck. An order that no batcher has touched after **24 hours** stops being watched; it is still yours to cancel. See [Cancelling stuck orders](/orders-and-transactions/cancelling-stuck-orders.md). ### What can go wrong at each stage | Stage | Failure | What Surge does | | --------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Built | The wallet cannot cover the order (not enough ADA, or funds fragmented into many small coins) | Shows an "insufficient funds" error; strategies retry with backoff and pause or disable the level after repeated failures | | Built | Manual swap or send build older than 5 minutes when you sign | "Invalid or expired trade identifier" — click Swap/Send again to rebuild | | Signed | Transaction guard refuses | Not signed; logged; trade skipped | | Submitted | Network rejects the transaction (for example a coin was already spent by another order) | Marked failed; strategies rebuild against fresh coins | | Open | Price moved past your minimum | Minswap refunds; other DEXes park until cancelled | | Filled | Received less than half the expected minimum | Surge refuses to count it as a fill and stops watching; the order shows Open — check it manually | --- # 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/trade-lifecycle-and-statuses.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.