> For the complete documentation index, see [llms.txt](https://docs.carbon.inc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.carbon.inc/developers/architecture/how-trading-works.md).

# How trading works

Carbon is an **RFQ (Request for Quote)** venue. You don't match against an order book — you submit an intent, a **solver** (your counterparty) quotes and fills it, and the trade settles on-chain on Arbitrum.

```mermaid
flowchart LR
    A["You — PartyA<br/>(the trader)"] -- "1. intent" --> GW["Carbon API"]
    GW -- "2. quote" --> S["Solver — PartyB"]
    S -- "3. fill" --> GW
    GW -- "4. settle" --> CH["Arbitrum"]
    GW -- "status + position" --> A
```

### Reads are synchronous, trades are asynchronous

This is the one behavior to design around.

|         | **Reads** (positions, balances, prices, markets) | **Trades** (open, close, cancel, margin)       |
| ------- | ------------------------------------------------ | ---------------------------------------------- |
| Timing  | Answer is in the response                        | Response is a `tempId`; the fill happens after |
| Pattern | Normal request/response                          | **Submit, then poll**                          |

When you submit a trade, Carbon validates it, accepts it, and returns a `tempId` immediately — the fill (quote + on-chain settlement) completes over the next few seconds. You learn the outcome by polling a status endpoint.

```mermaid
stateDiagram-v2
    [*] --> Accepted: POST /v1/trade/create-position → 201 { tempId }
    Accepted --> Pending: being quoted & settled
    Pending --> Confirmed: filled → quoteId
    Pending --> Failed: rejected / expired
    Confirmed --> [*]
    Failed --> [*]
```

**Contract:** treat a `tempId` as *pending* until a status endpoint reports a terminal state. Don't infer success from the `201`, and don't blindly resubmit — poll first, and reconcile against `GET /v1/positions/all` if you time out.

#### Submit → poll, per operation

Every trade operation follows the same shape on its own request id:

| Submit                                | Poll for the result                             |
| ------------------------------------- | ----------------------------------------------- |
| `POST /v1/trade/create-position`      | `GET /v1/positions/open-request/status`         |
| `POST /v1/trade/close-position`       | `GET /v1/positions/close-request/status`        |
| `POST /v1/trade/cancel-quote`         | `GET /v1/positions/cancel-request/status`       |
| `POST /v1/trade/cancel-close-request` | `GET /v1/positions/cancel-close-request/status` |

Once an open confirms, the position appears in `GET /v1/positions/all` with its on-chain `quoteId`.

#### Minimal flow

```ts
// 1. Submit
const { data } = await post("/v1/trade/create-position", intent);
const tempId = data.tempId;

// 2. Poll until terminal (~1s apart, with a timeout)
for (let i = 0; i < 30; i++) {
  const { data } = await get("/v1/positions/open-request/status", { tempId });
  if (data.status === "SUCCESS") break; // filled → data.quoteId
  if (data.status === "FAILED") throw new Error(data.statusMessage);
  await sleep(1000);
}
```

### Order types

* `MARKET` — fills at the solver's current price, bounded by your `slippage`.
* `LIMIT` — rests until a solver can fill at your `limitPrice` or better; cancel it with `cancel-quote` while pending.

### Execution speed: instant vs on-chain

* **Instant (default)** — trades execute via off-chain signatures for low latency. Enabled by `useInstantActions: true` (the default), provided the subaccount has an instant-action token registered with the solver.
* **On-chain** — set `useInstantActions: false` to force a standard on-chain transaction. Slower, but needs no token. Some operations settle on-chain by nature. Only available in cross margin

### Batching

Act on many positions in one call; each returns per-item results (grouped by a `batchId`) so one failure doesn't sink the rest:

`batch-create-positions`, `batch-close-positions`, `batch-cancel-quotes`, `batch-cancel-close-requests`, `close-all-positions` (all under `/v1/trade/`).


---

# 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.carbon.inc/developers/architecture/how-trading-works.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.