> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vane.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Order lifecycle

> The six order statuses, the 30 minute timeout rule, the deposit bounds, and when to stop tracking.

Every order moves through up to three open states, then lands in one of three terminal ones.

| Status                                | Phase    | Meaning                                                                                                                |
| ------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------- |
| `AWAITING_USER_DEPOSIT`               | Open     | Waiting for your deposit at `walletAddress`. The order expires at `timeout` if nothing arrives.                        |
| `AWAITING_USER_DEPOSIT_CONFIRMATIONS` | Open     | The deposit was detected and is collecting the deposit chain's required confirmations. The order can no longer expire. |
| `PROCESSING`                          | Open     | A [solver](/features/solver-auctions) is filling the order.                                                            |
| `COMPLETED`                           | Terminal | The settle tokens were delivered to `receivingAddress` and `settleAmount` is final.                                    |
| `ERROR`                               | Terminal | The swap hit a problem. Contact [support](/resources/support) with the order UUID.                                     |
| `TIMED_OUT`                           | Terminal | No deposit arrived before `timeout` and the order expired.                                                             |

## The timeout rule

`timeout` lands about 30 minutes after `createdAt`. Miss it with no deposit and the order moves to `TIMED_OUT` for good. A detected deposit removes expiry entirely, even when confirmations run past the stamp. Never fund an expired order: check the status right before sending, and create a fresh order if the window closed.

## The bounds bind your deposit

Creation never validates `intendedAmount` against the pair's limits. An intent below the minimum still returns `201`, with `initialQuote: 0` as the tell. So does `intendedAmount: 0`, which the quote endpoint would reject with `Invalid amount: 0`; check for zero yourself before creating. What's enforced is the deposit you actually send, which must fall between the order's `minimalAmount` and `maximalAmount`, both in deposit-token units. Those bounds are set per order at creation and can differ from `GET /v1/tokens/swap-limits` for the same pair; `minimalAmount` has come back higher than `depositTokenMin`. Treat swap-limits as a pre-check and read the binding numbers off the `201` response before any funds move.

## Terminal states

`COMPLETED`, `ERROR`, and `TIMED_OUT` never change again, so stop polling and close any open stream. After `TIMED_OUT`, create a new order whenever you're ready. After `ERROR`, send the UUID to support.

Read the state any time with `GET /v1/orders/{uuid}`; the UUID is the only credential, so don't leak it. [Track orders](/api-reference/track-orders) shows the polling and SSE patterns.