# Agent CLI
Source: https://pond.dflow.net/ai/agent-cli

Agent-first CLI for executing trades on Solana via DFlow

<div>
  <h2>
    Your AI agent's new best friend
  </h2>

  <div>
    <div>
      <code>
        curl -fsS [https://cli.dflow.net](https://cli.dflow.net) | sh
      </code>

      <button type="button" aria-label="Copy install command">
        Copy
      </button>
    </div>
  </div>
</div>

Give your AI agent a Solana wallet and let it trade. Spot swaps, structured JSON output, keys that never leave your machine.

* **One binary, zero dependencies:** install and go.
* **Agent-native:** every command returns JSON; every error includes a machine-readable code and a recovery suggestion.
* **Your keys, your machine:** private keys live in an encrypted local vault, never uploaded anywhere.

### Getting started

The `dflow` CLI is a single self-contained binary that runs on macOS and Linux.

```bash theme={null}
curl -fsS https://cli.dflow.net | sh
```

Then run setup:

```bash theme={null}
dflow setup
```

`setup` prompts for:

| Setting        | Default                               | Notes                                                           |
| -------------- | ------------------------------------- | --------------------------------------------------------------- |
| Wallet name    | `default`                             | Creates a new encrypted wallet if the name doesn't exist.       |
| Vault password |                                       | Min 12 characters.                                              |
| Solana RPC     | `https://api.mainnet-beta.solana.com` |                                                                 |
| DFlow API key  | Required                              | Provided when you receive your [API key](/get-started/api-key). |

The Solana RPC is the only optional setting. All DFlow fields are required; setup will not proceed until each is entered. Config is saved to `~/.config/dflow/config.json`. Re-run `dflow setup` anytime; existing wallets are left untouched.

At the end of the install script, you'll be prompted to install the [DFlow Skills library](/ai/agent-skills#dflow-skills), a set of Claude Code Skills that teach agents how to drive the CLI. This is optional, but highly recommended and can be installed later with `dflow skills install`.

On macOS, the CLI stores your vault password in the system keychain so your agent can sign transactions without a password prompt blocking execution. The first time it does this, you'll see a dialog asking permission to access **dflow-ows**, choose **Always Allow**, not just **Allow**. The dialog asks for your **Mac login keychain** password, which is separate from your DFlow vault password.

<Info>
  After installing an updated `dflow` binary, macOS treats it as a new app and will prompt for keychain access again. Run a small test transaction to prime the CLI before turning it over to your agent.
</Info>

## Command reference

Global flags (apply to subcommands that need config):

| Flag              | Description                                                                              |
| ----------------- | ---------------------------------------------------------------------------------------- |
| `--rpc-url <url>` | Override Solana RPC (else `config.json` or default).                                     |
| `--wallet <name>` | Vault wallet name (else `config.json` or `default`). Files live under `~/.ows/wallets/`. |

### Setup, identity, balances

| Command                      | Description                                                                                                              |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `dflow setup`                | Interactive wallet creation, RPC, and DFlow API configuration.                                                           |
| `dflow whoami`               | Print the active wallet's public key (plain text, not JSON).                                                             |
| `dflow positions`            | Show all token balances.                                                                                                 |
| `dflow agent --model <name>` | Register the AI model running this session. Cached for 48 hours; sets the `X-Dflow-Model` header on subsequent requests. |

### Skills

| Command                | Description                                                                          |
| ---------------------- | ------------------------------------------------------------------------------------ |
| `dflow skills install` | Install the [DFlow Skills library](/ai/agent-skills#dflow-skills). Requires Node.js. |
| `dflow skills update`  | Update all installed skills to their latest version. Requires Node.js.               |

<Info>
  `dflow skills update` updates **every** skill the `skills` CLI manages, not only DFlow's. The underlying CLI updates by skill name, not by repo.
</Info>

### Wallet

| Command                                                 | Description                                                                                                                                        |
| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| `dflow wallet list`                                     | List all named wallets in the vault.                                                                                                               |
| `dflow wallet import --name <n> --keypair <path>`       | Import a Solana keypair JSON (e.g. from `solana-keygen`) into the vault.                                                                           |
| `dflow wallet import --name <n> --mnemonic "word1 ..."` | Import a BIP-39 mnemonic (24 words) into the vault. Use to restore a wallet exported from another machine.                                         |
| `dflow wallet export --name <n> --out <path>`           | Decrypt the recovery phrase/keypair and write it to `<path>` (0600). Requires a typed vault password; the secret is never printed to the terminal. |
| `dflow wallet delete --name <n> [--yes]`                | Delete a wallet file and its keychain entry. `--yes` skips confirmation.                                                                           |
| `dflow wallet rename --from <n> --to <n>`               | Rename a wallet. Updates the keychain entry if present.                                                                                            |
| `dflow wallet keychain-sync --name <n>`                 | Re-save the vault password to the OS keychain. Use after keychain issues.                                                                          |

### Trading

| Command                            | Description                                                        |
| ---------------------------------- | ------------------------------------------------------------------ |
| `dflow quote <amount> <from> <to>` | Spot swap quote. `--slippage <bps>` (defaults to backend auto).    |
| `dflow trade <amount> <from> <to>` | Spot swap. `--slippage <bps>`, `--confirm` (poll until confirmed). |

### Transfers and funding

| Command                                   | Description                                                                                               |
| ----------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| `dflow send <amount> <token> <recipient>` | Native SOL or SPL transfer; `recipient` is base58 pubkey. Creates recipient ATA if needed (you pay rent). |
| `dflow fund <USDC\|SOL>`                  | Buy crypto with fiat via MoonPay CLI.                                                                     |

### Guardrails

| Command                              | Description                                                                  |
| ------------------------------------ | ---------------------------------------------------------------------------- |
| `dflow guardrails show`              | Display current guardrails. No password required, so agents can read limits. |
| `dflow guardrails set <key> [value]` | Set a guardrail. Requires vault password typed in the terminal.              |
| `dflow guardrails remove <key>`      | Remove a guardrail. Requires vault password typed in the terminal.           |
| `dflow guardrails reset`             | Remove all guardrails. Requires vault password typed in the terminal.        |

<Tip>
  See [Guardrails](#guardrails) for the full list of available keys and examples.
</Tip>

<Info>
  **Atomic units**: Amounts are integers in the smallest token unit (e.g. `500000` = 0.50 USDC with 6 decimals; `10000000` lamports = 0.01 SOL).
</Info>

## Key management

Each wallet is an encrypted JSON file under `~/.ows/wallets/`, following the [Open Wallet Standard (OWS)](https://openwallet.sh/docs/) format (powered by `ows-lib` v1.4.2). Private keys never exist on disk in plaintext. All cryptographic operations (decrypt, sign, zeroize) are handled by the `ows-lib` crate. The CLI binary itself never touches raw key material.

When a command needs to sign, the CLI resolves the vault password by trying these sources in order:

1. **OS keychain** (if saved via `dflow setup` or `wallet keychain-sync`)
2. **`DFLOW_PASSPHRASE` env var** (read once, then cleared from the environment)
3. **Password prompt**

The resolved password is cached for the duration of the process so back-to-back operations (e.g. guardrail check → sign → broadcast) only resolve it once.

Guardrails changes (`set` / `remove` / `reset`) always require the password **typed in the terminal**. The keychain and env var are intentionally bypassed so a human must be present to change policy.

```mermaid theme={null}
flowchart TB
  subgraph persist["On disk"]
    W["Encrypted wallet (~/.ows/wallets/)"]
  end
  subgraph pass["Vault password"]
    KC["OS keychain"]
    EV["DFLOW_PASSPHRASE env var"]
    PR["Prompt"]
  end
  subgraph run["Inside ows-lib"]
    OWS["Decrypt + sign (key material never leaves ows-lib)"]
    AUD["audit.jsonl"]
  end
  W --> OWS
  KC --> OWS
  EV --> OWS
  PR --> OWS
  OWS --> AUD
```

<Info>
  The vault uses a **key derivation function (KDF)** to turn the password into a decryption key. This is intentionally slow to make brute-force guessing expensive.
</Info>

### What is stored where

| Piece                  | Location                                              | Notes                                               |
| ---------------------- | ----------------------------------------------------- | --------------------------------------------------- |
| Encrypted key material | `~/.ows/wallets/<uuid>.json`                          | One file per wallet. Filename is a fixed UUID.      |
| Vault password         | macOS Keychain / Linux secret service, env, or prompt | Service `dflow-ows`, account = wallet name.         |
| Config (RPC, API key)  | `~/.config/dflow/config.json`                         | No signing keys.                                    |
| Guardrails             | `~/.ows/guardrails.json`                              | HMAC-signed; editing requires typed vault password. |
| Trade history          | `~/.ows/trade_history.json`                           | Used for rate limit and daily volume enforcement.   |
| Audit log              | `~/.ows/logs/audit.jsonl`                             | Append-only signing and lifecycle events.           |

Permissions: `~/.ows` directories **700**, wallet files **600**. If permissions are too open, commands fail with `VAULT_INSECURE`.

<Warning>
  If someone has both your wallet files and your password, they can move funds. Use a strong password, lock down file permissions, and treat the machine like any workstation that signs crypto transactions.
</Warning>

### Creating and importing keys

* **Create**: `dflow setup` with a **new** wallet name generates a **24-word BIP-39 mnemonic** and encrypts it into the vault.
* **Import keypair**: `dflow wallet import --name <n> --keypair <path>` encrypts an existing **Solana JSON keypair** (from `solana-keygen`) into the vault.
* **Import mnemonic**: `dflow wallet import --name <n> --mnemonic "word1 word2 ..."` restores a BIP-39 wallet (12 or 24 words). Use this to move a wallet created on another machine.
* **Export**: `dflow wallet export --name <n> --out <path>` decrypts the recovery phrase (mnemonic) or keypair and writes it to `<path>` with `0600` permissions. The secret is **never printed to the terminal** (so it can't leak into scrollback or recordings), `--out` is required, and a symlink at the destination is refused. Requires a typed vault password. **Highly sensitive:** use for backup or migration only. The confirmation includes `wordCount` and import instructions when the wallet is a BIP-39 mnemonic. When importing into Phantom or another wallet, make sure to select the matching word count (24).

### Multiple wallets

The vault supports an unlimited number of named wallets. Each is a separate encrypted file with its own keypair and password. Pass `--wallet <name>` to target a specific wallet:

```bash theme={null}
dflow whoami --wallet hot
dflow trade 500000 USDC SOL --wallet savings
```

### Headless environments

If there's no terminal for a password prompt (e.g. a background process or Docker container), export the vault password as an environment variable:

```bash theme={null}
export DFLOW_PASSPHRASE="your-vault-password"
dflow trade 500000 USDC SOL
```

The CLI unsets `DFLOW_PASSPHRASE` from its own process environment at startup, so any subprocesses it spawns will not see it. The value still persists in the parent shell and, on Linux, in the read-only `/proc/<pid>/environ` snapshot for the life of the process. The OS keychain is the most secure option.

## Output format

**Success (most commands):**

```json theme={null}
{ "ok": true, "data": { ... } }
```

**Classified error** (most failures):

```json theme={null}
{
  "ok": false,
  "error": "Human-readable message",
  "error_code": "MACHINE_CODE",
  "category": "routing",
  "recoverable": true,
  "suggestion": "Actionable next step.",
  "details": { ... }
}
```

`details` is present when there is additional structured context. Its shape varies by error category: API errors include `httpStatus` and the parsed response `body`; onchain errors include `rawLogs` or `programErrorDecimal`; others may include `raw` or `inputMint`.

**Simple error** (edge cases such as cancelled prompts or misconfiguration):

```json theme={null}
{ "ok": false, "error": "Human-readable message" }
```

**Exception:** `dflow whoami` prints only the pubkey string on success.

## Token resolution

Symbols resolve to mints (built-in list includes `SOL`, `USDC`, `USDT`, `CASH`, `BONK`, `JUP`, `WIF`, `PYTH`, `JTO`, `RAY`, `ORCA`, `MNDE`, `MSOL`, `JITOSOL`, `BSOL`, `RENDER`). Any other asset: pass the **mint address** (base58).

```bash theme={null}
dflow quote 500000 EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v So11111111111111111111111111111111111111112
```

## Guardrails

Guardrails are **optional** client-side safety limits. An agent can read them freely (`guardrails show` requires no password), but only a human can change them. `set`, `remove`, and `reset` require the vault password typed in the terminal.

| Key                    | What it does                                                                          |
| ---------------------- | ------------------------------------------------------------------------------------- |
| `max_trade_size_usd`   | Cap the USD value of a single trade.                                                  |
| `max_daily_volume_usd` | Cap total USD volume per rolling 24-hour window.                                      |
| `max_wallet_value_usd` | Cap the total USD value held in the wallet.                                           |
| `allowed_tokens`       | Whitelist of mints the agent can **buy**. Sells are unrestricted.                     |
| `rate_limit`           | Max trades within a time window (e.g. `max_trades` per `window_seconds`).             |
| `sweep_address`        | Public key to sweep excess funds to when wallet value exceeds `max_wallet_value_usd`. |

USD estimates use the same route as the trade itself, including SOL-to-USDC conversion when needed.

```bash theme={null}
dflow guardrails set max_trade_size_usd 5000000    # $5 per trade
dflow guardrails set max_daily_volume_usd 50000000 # $50/day
dflow guardrails set allowed_tokens SOL,USDC,BONK
dflow guardrails show                              # Agent reads this
```

## Funding

Use `fund` to buy crypto with fiat through the [MoonPay CLI](https://www.moonpay.com/agents). It supports **USDC** and **SOL**.

The MoonPay CLI is not bundled with `dflow`. Install it separately only if you need the `fund` command:

```bash theme={null}
npm install -g @moonpay/cli
```

The `<amount>` is in your **local fiat currency**, auto-detected by MoonPay based on your locale. For example, `dflow fund 50 USDC` in the US buys USD 50 of USDC; in Thailand it buys THB 50 of USDC.

```bash theme={null}
dflow fund 50 USDC       # Buy USDC with local fiat currency
dflow fund 100 SOL       # Buy SOL with local fiat currency
```

When `dflow fund` runs, it fetches the wallet address, calls MoonPay to generate a checkout URL, opens it in the browser for KYC and payment, then polls the wallet balance until a deposit lands (10-second intervals, 10-minute timeout).

<Info>
  This command requires a browser and is intended for wallet funding by a human operator, not for autonomous agent use.
</Info>

## Spot trading

Swap any supported token pair. Amounts are always in **atomic units** of the input token (e.g. `500000` = 0.50 USDC).

### Get a quote

```bash theme={null}
dflow quote 500000 USDC SOL                 # How much SOL for 0.50 USDC?
dflow quote 500000 USDC SOL --slippage 100  # Same, with 1% slippage tolerance
```

The CLI calls the DFlow Trade API `/order` endpoint and returns the route, expected output amount, and price impact, without executing anything.

### Execute a trade

```bash theme={null}
dflow trade 500000 USDC SOL                 # Swap 0.50 USDC -> SOL
dflow trade 500000 USDC SOL --slippage 100  # With 1% slippage tolerance
```

The CLI uses standard [`/order`](/spot/introduction) execution: it fetches a route, signs the transaction locally, and submits it to the network. The response status is `"submitted"`. Add `--confirm` to poll the RPC until the transaction reaches `confirmed` commitment before returning:

```bash theme={null}
dflow trade 500000 USDC SOL --confirm
```

### Slippage

Slippage is specified in **basis points** (bps). If `--slippage` is omitted, the backend selects a tolerance automatically. If the price moves beyond the tolerance between quote and execution, the transaction reverts.

```bash theme={null}
dflow trade 500000 USDC SOL --slippage 200  # 2% tolerance
```

## Response verification

The CLI can cryptographically verify that Trade API responses came from DFlow and were not altered in transit, using [RFC 9421 HTTP Message Signatures](https://pond.dflow.net/resources/request-signing) (ed25519). This is **opt-in** and **off by default**.

Enable it by setting an environment variable (truthy values: `1`, `true`, `yes`):

```bash theme={null}
export DFLOW_VERIFY_SIGNATURES=1
dflow trade 500000 USDC SOL
```

When enabled, every Trade API request asks DFlow to sign its response, and the CLI checks the response **before** using it:

* the ed25519 `signature` validates against DFlow's pinned public key (baked into the binary, so a swapped key can't be substituted);
* the `content-digest` matches the response body (integrity);
* the echoed `x-request-id` matches the per-request id the CLI sent (anti-replay);
* the signed component set actually covers `content-digest` and `x-request-id` (no downgrade).

If any check fails, the CLI returns a `RESPONSE_SIGNATURE_INVALID` error and discards the response without acting on it.

<Info>
  This defends against a tampered network path (TLS MitM with a mis-issued certificate, BGP hijack, or a compromised intermediary between you and DFlow's edge). It does not attempt to defend against DFlow's own backend, which is the entity producing the signature.
</Info>

## Observability

Every outbound API request includes three headers that identify the caller:

| Header           | Values                                                                 | Description                                                                      |
| ---------------- | ---------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| `X-Dflow-Caller` | `human`, `agent`, `unknown`                                            | Whether the CLI was invoked by a person or an agent.                             |
| `X-Dflow-Agent`  | `cursor`, `claude-code`, `openclaw`, `github-actions`, `ci`, or custom | Detected or self-reported agent tool. Present only when caller is `agent`.       |
| `X-Dflow-Model`  | e.g. `gpt-4o`, `claude-sonnet-4.6`                                     | Model registered via `dflow agent --model`. Present only when caller is `agent`. |

**Self-reporting:** Set `DFLOW_AGENT=<name>` to explicitly identify a custom agent. This takes precedence over automatic detection:

```bash theme={null}
DFLOW_AGENT=my-bot dflow trade 500000 USDC SOL
```

**Agent model prompt:** When an agent calls `quote` or `trade` and no model has been registered (or the registration has expired), the success response includes an additional `_hint` key:

```json theme={null}
{
  "ok": true,
  "data": { ... },
  "_hint": {
    "action": "Run the replyWith command now to register your model before proceeding.",
    "options": ["claude-opus-4.6", "claude-sonnet-4.6", "gpt-4o", "..."],
    "replyWith": "dflow agent --model <option>",
    "note": "Required once every 48 hours. Sends X-Dflow-Model on subsequent API requests."
  }
}
```

## Logging

The CLI writes two log files under `~/.ows/logs/`:

| File          | Contents                                                                        |
| ------------- | ------------------------------------------------------------------------------- |
| `audit.jsonl` | Append-only record of every signing and wallet lifecycle event.                 |
| `debug.log`   | Per-command caller detection entries. Only written when `DFLOW_DEBUG=1` is set. |

The debug log is useful for verifying that agent detection is working correctly in a new environment:

```bash theme={null}
DFLOW_DEBUG=1 dflow whoami
cat ~/.ows/logs/debug.log
```

## Troubleshooting

| Symptom                              | What to try                                                                                                                                                                                                                                                         |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `NOT_CONFIGURED`                     | Run `dflow setup`; ensure `~/.ows/wallets/` has a file for the resolved wallet name.                                                                                                                                                                                |
| `VAULT_INSECURE`                     | `chmod 700 ~/.ows` and `chmod 600 ~/.ows/wallets/*.json`.                                                                                                                                                                                                           |
| Repeated keychain / password prompts | Run `dflow wallet keychain-sync --name default` (or your wallet name). When macOS asks to access **dflow-ows**, choose **Always Allow** and enter your **login keychain** password. Then prime with a small manual `dflow trade` or `dflow send` before agents run. |
| `Blockhash not found`                | Retry; use a faster RPC if it persists.                                                                                                                                                                                                                             |


# Agent Skills
Source: https://pond.dflow.net/ai/agent-skills

Pre-built Claude Code Skills for DFlow

[Claude Code Skills](https://docs.claude.com/en/docs/claude-code/skills) are focused recipes that teach AI agents how to use a given tool or API. We publish two skills repositories, each for a different use case.

## DFlow Skills

For agents driving the [Agent CLI](/ai/agent-cli) or [Trading API](/resources/trading-api/introduction) directly.

```bash theme={null}
npx skills add DFlowProtocol/dflow-skills
```

Includes the following skills:

| Skill                                                                                                              | Description                                                                                                                                                    |
| :----------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [`dflow-spot-trading`](https://github.com/DFlowProtocol/dflow-skills/blob/main/skills/dflow-spot-trading/SKILL.md) | Swap any pair of Solana tokens via the DFlow CLI or Trading API, including builder platform fees (`platformFeeBps`), sponsored swaps, and priority-fee tuning. |
| [`dflow-market-data`](https://github.com/DFlowProtocol/dflow-skills/blob/main/skills/dflow-market-data/SKILL.md)   | Stream real-time quotes, order-book depth, and priority-fee estimates over WebSocket.                                                                          |
| [`dflow-proof-kyc`](https://github.com/DFlowProtocol/dflow-skills/blob/main/skills/dflow-proof-kyc/SKILL.md)       | Integrate Proof identity verification to gate app features by wallet KYC and check verification status.                                                        |

## Phantom Connect Skill

For full-stack web apps. Teaches Claude [Phantom's](https://phantom.app) wallet SDKs alongside DFlow's Trading API. Covers wallet connection, transaction signing, token swaps, and real-time market-data streaming.

```bash theme={null}
npx skills add https://github.com/DFlowProtocol/dflow_phantom-connect-skill
```


# Introduction
Source: https://pond.dflow.net/ai/introduction

Tools and files for building with and for AI agents on DFlow

DFlow is built to be agent-ready. Connect your AI tools to our docs, give AI agents their own Solana wallet, and teach coding agents how to use DFlow through pre-built skills.

<div>
  <a href="/ai/mcp">
    <div>
      <Icon icon="plug" />

      <h3>MCP Server</h3>
      <p>Connect Cursor, VS Code, Claude, and Claude Code to DFlow's docs and API specs.</p>
    </div>

    <div>
      <Icon icon="arrow-right" />
    </div>
  </a>

  <a href="/ai/agent-cli">
    <div>
      <Icon icon="terminal" />

      <h3>Agent CLI</h3>
      <p>A single binary that gives an AI agent a Solana wallet and lets it trade.</p>
    </div>

    <div>
      <Icon icon="arrow-right" />
    </div>
  </a>

  <a href="/ai/agent-skills">
    <div>
      <Icon icon="puzzle-piece" />

      <h3>Agent Skills</h3>
      <p>Pre-built Claude Code Skills that teach agents how to use DFlow.</p>
    </div>

    <div>
      <Icon icon="arrow-right" />
    </div>
  </a>
</div>


# llms-full.txt
Source: https://pond.dflow.net/ai/llms-full-txt





# llms.txt
Source: https://pond.dflow.net/ai/llms-txt





# MCP Server
Source: https://pond.dflow.net/ai/mcp

Connect AI tools to DFlow documentation and API references with our hosted MCP server.

The DFlow MCP server gives AI tools direct access to our documentation, API specs, and code examples so they can generate accurate, up-to-date code for your integration.

```
https://pond.dflow.net/mcp
```

## What is MCP?

[Model Context Protocol](https://modelcontextprotocol.io/) (MCP) is an open standard that connects AI applications to external data sources. Instead of relying on general web search, your AI tool searches DFlow documentation directly during response generation, giving you current API methods, correct parameters, and working examples.

## Connecting to the DFlow MCP Server

Use the contextual menu at the top of any documentation page for one-click setup, or follow the manual instructions below.

<Tabs>
  <Tab title="Claude Code">
    Run the following command:

    ```bash theme={null}
    claude mcp add --transport http DFlow https://pond.dflow.net/mcp
    ```

    Or add to your project's `.mcp.json`:

    ```json theme={null}
    {
      "mcpServers": {
        "DFlow": {
          "type": "http",
          "url": "https://pond.dflow.net/mcp"
        }
      }
    }
    ```

    Verify with:

    ```bash theme={null}
    claude mcp list
    ```
  </Tab>

  <Tab title="Claude">
    1. Go to [Connectors](https://claude.ai/settings/connectors) in your Claude settings.
    2. Select **Add custom connector**.
    3. Set the name to `DFlow` and the URL to `https://pond.dflow.net/mcp`.
    4. When chatting, click the attachments button (plus icon) and select the DFlow connector.
  </Tab>

  <Tab title="Cursor">
    <InstallButton href="cursor://anysphere.cursor-deeplink/mcp/install?name=DFlow&config=eyJ1cmwiOiJodHRwczovL3BvbmQuZGZsb3cubmV0L21jcCJ9">Install in Cursor</InstallButton>

    To connect the DFlow MCP server to Cursor, click the **Install in Cursor** button above. Or to manually connect the MCP server, follow these steps:

    1. Open the command palette with `Cmd + Shift + P` (or `Ctrl + Shift + P` on Windows).
    2. Search for **Open MCP settings**.
    3. Add the following to your `mcp.json`:

    ```json theme={null}
    {
      "mcpServers": {
        "DFlow": {
          "url": "https://pond.dflow.net/mcp"
        }
      }
    }
    ```
  </Tab>

  <Tab title="VS Code">
    Create a `.vscode/mcp.json` file in your project and add:

    ```json theme={null}
    {
      "servers": {
        "DFlow": {
          "type": "http",
          "url": "https://pond.dflow.net/mcp"
        }
      }
    }
    ```
  </Tab>

  <Tab title="Windsurf">
    1. Open the command palette with `Cmd + Shift + P` (or `Ctrl + Shift + P` on Windows).
    2. Search for **Windsurf: Configure MCP Servers**.
    3. Add the following to your `mcp_config.json`:

    ```json theme={null}
    {
      "mcpServers": {
        "DFlow": {
          "serverUrl": "https://pond.dflow.net/mcp"
        }
      }
    }
    ```
  </Tab>
</Tabs>

## What You Get

Once connected, your AI tool can search DFlow documentation while generating responses. This includes:

* **Trading API**: Order, imperative, and declarative endpoints with parameters and examples.
* **Code Recipes**: End-to-end implementation patterns for common use cases.
* **Concepts**: How routing, slippage, priority fees, and platform fees work.
* **Debugging**: Draws from a large FAQ library that is continuously updated based on real integration questions from builders, so your AI tool can troubleshoot issues using the same answers our team gives in support channels.

<Note>
  The MCP server is automatically generated from this documentation and stays in sync as pages are updated.
</Note>

## Example Prompts

Try these with the DFlow MCP server connected:

**Execution Optimization**

* "Write an imperative trade that restricts routing to a single DEX using the dexes parameter."
* "How do I use priority fee presets like auto, medium, high, and veryHigh to speed up time-sensitive trades?"

**Trading Basics**

* "Write a TypeScript function that executes an imperative token swap on DFlow with custom slippage."

**Debugging**

* "My trade is returning `route_not_found`, how do I debug this?"
* "Why is my swap transaction failing onchain after getting a successful quote?"

## Tips

* **Be specific**: "How do I submit a declarative trade with platform fees?" works better than "help with trading."
* **Mention your stack**: "Using TypeScript and Next.js, show me how to..." gives better results.
* **Iterate**: Use generated code as a starting point and ask for modifications.
* **Prepare**: Read the docs first, so you know how to properly frame your commands.

## Other AI Resources

For tools that don't support MCP, see the [AI overview](/ai/introduction).


# skill.md
Source: https://pond.dflow.net/ai/skill-md





# API Keys
Source: https://pond.dflow.net/get-started/api-key

How to request an API key for production use

Developer endpoints work without an API key, however they are rate limited and not suitable for production use.

For production use, [fill out this form](https://forms.gle/eX3cghbMF8VBB9qa9) to receive an API key with higher rate limits. We will get back to you within 2-5 days.

Once you have an API key, [see this recipe](/resources/recipes/api-keys) for example code showing how to use it.


# Endpoints
Source: https://pond.dflow.net/get-started/endpoints

DFlow endpoints for the Trading API

## Developer endpoints

No API key required. These endpoints are rate-limited and intended for testing only.

| Service             | Endpoint                          |
| ------------------- | --------------------------------- |
| Trade API           | `https://dev-quote-api.dflow.net` |
| Trade API WebSocket | `wss://dev-quote-api.dflow.net`   |

## Production endpoints

Production endpoints have higher rate limits and are suitable for live applications. To get access, [request an API key](/get-started/api-key) and [pass it as the `x-api-key` header on all requests](/resources/recipes/api-keys).

| Service             | Endpoint                      |
| ------------------- | ----------------------------- |
| Trade API           | `https://quote-api.dflow.net` |
| Trade API WebSocket | `wss://quote-api.dflow.net`   |

<Note>
  The Trade API serves multiple WebSocket streams on that host. Append a stream
  path: `/quote-stream`, `/book-stream`, or `/priority-fees/stream`. See the
  [Websockets overview](/resources/trading-api/websockets/overview).
</Note>


# Get Started
Source: https://pond.dflow.net/get-started/what-is-dflow

Overview of DFlow's trading infrastructure on Solana

DFlow is the most powerful trading infrastructure on Solana, enabling apps to access the cutting edge of financial markets.

## Get Started

You can start right now: the [developer endpoints](/get-started/endpoints) work with no API key. [Request an API key](/get-started/api-key) for higher rate limits in production.

## Spot

Swap any SPL token on Solana through the Trading API, with no protocol fee taken out. [Send your first order](/spot/recipes/quickstart), or read [how spot trading works](/spot/introduction).

## Proof

Verify that a wallet belongs to a KYC'd individual so you can gate app features by identity, without building identity verification yourself. Read [how Proof works](/proof/introduction), or follow the [integration guide](/proof/partner-integration).

## More

[API reference](/resources/introduction) and [Build with AI](/ai/introduction).


# Welcome to DFlow
Source: https://pond.dflow.net/introduction

DFlow is a trading protocol for spot trading natively on Solana.

<div>
  <div>
    <div>
      <h1>Build on DFlow.</h1>
      <p>Integrate spot trading into your app with one unified API.</p>

      <div>
        <a href="/get-started/what-is-dflow">Get Started <svg><path /></svg></a>
        <a href="/resources/introduction">API Reference <svg><polyline /><polyline /></svg></a>
      </div>
    </div>
  </div>

  <div>
    <section>
      <h2>Spot Trading</h2>

      <div>
        <a href="/spot/introduction">
          <div>
            <Icon icon="arrow-up-right" />
          </div>

          <div>
            <Icon icon="arrow-right-arrow-left" />
          </div>

          <h3>Introduction</h3>
          <p>How spot trading works across aggregated Solana liquidity through one API.</p>
        </a>

        <a href="/spot/recipes/quickstart">
          <div>
            <Icon icon="arrow-up-right" />
          </div>

          <div>
            <Icon icon="paper-plane" />
          </div>

          <h3>Send Your First Order</h3>
          <p>Quote, sign, and submit your first swap in a few lines of code.</p>
        </a>
      </div>
    </section>

    <section>
      <h2>Tools & Reference</h2>

      <div>
        <a href="/ai/introduction">
          <div>
            <Icon icon="arrow-up-right" />
          </div>

          <div>
            <Icon icon="robot" />
          </div>

          <h3>Build with AI</h3>
          <p>Agent CLI, MCP server, and Claude Code skills for connecting AI agents to DFlow.</p>
        </a>

        <a href="/resources/introduction">
          <div>
            <Icon icon="arrow-up-right" />
          </div>

          <div>
            <Icon icon="code" />
          </div>

          <h3>APIs</h3>
          <p>Trading API reference, plus troubleshooting and wallet integration guides.</p>
        </a>
      </div>
    </section>
  </div>
</div>


# Introduction
Source: https://pond.dflow.net/proof/introduction

Identity verification service linking verified identities to Solana wallets

Proof is an identity verification service on Solana. It enables partner applications to verify that a wallet belongs to a KYC'd individual without handling identity verification themselves.

<Note>
  Have a specific question? See the [Proof FAQ](/resources/faqs#proof).
</Note>

## When to Use Proof

Use Proof when your application needs to confirm that a wallet belongs to a verified, KYC'd individual: to gate features by identity or jurisdiction, or to meet compliance requirements, without building identity verification yourself. Spot trading on DFlow does not require Proof.

## High-Level Model

Proof connects three key entities: users, verified identities, and wallets. Users authenticate and verify their identity once, then link multiple wallets to that identity. Partner applications query the identity graph to check verification status.

```mermaid theme={null}
flowchart TD
    User -->|authenticates| Session
    User -->|completes| Verification
    Verification -->|creates| VerifiedIdentity[Verified Identity]
    VerifiedIdentity -->|links to| Wallet1[Wallet 1]
    VerifiedIdentity -->|links to| Wallet2[Wallet 2]
    VerifiedIdentity -->|links to| WalletN[Wallet N]
    PartnerApp[Partner App] -->|queries| VerifiedIdentity
```

## Verified Information

Proof verifies the following information about users:

| Verified Information      | Description                             |
| ------------------------- | --------------------------------------- |
| Name                      | Full legal name from government ID      |
| Address                   | Residential address                     |
| Contact Information       | Email address (used for authentication) |
| Government Identification | Government-issued ID document           |

## Key Outcomes

### Identity Graph

Creates a mapping between verified identities and wallet addresses that can be queried by partner applications. This graph is the core data structure that enables verification across the ecosystem.

### Reduce Friction for Partner Apps

Allows apps to outsource identity verification while maintaining a seamless user experience. Partners redirect users to Proof, and users return verified, no need to build KYC infrastructure.

### Compliance

Helps partner applications meet regulatory requirements by providing verified wallet ownership data. When a partner queries a wallet, they get a clear verification status they can use for compliance decisions.

### One-Time Verification

Users verify once and can use their verified identity across all partner applications. This reduces friction for users and increases conversion for partners.

## What Proof Delivers

### Authentication

* Email-based authentication with one-time codes
* Session persistence across visits

### Identity Verification

* Document verification (government-issued ID)
* Biometric verification (selfie matching / liveness check)
* Clear status communication (pending, verified, failed)

### Wallet Management

* Link multiple wallets to a single verified identity
* Cryptographic proof of wallet ownership (signature verification)
* Optional wallet labels for organization
* Remove wallets when needed
* Audit trail of wallet changes

## Next Steps

<CardGroup>
  <Card title="User Journeys" href="user-journeys">
    Understand the verification flows for different user types.
  </Card>

  <Card title="Integration Guide" href="partner-integration">
    Learn how to integrate Proof into your application.
  </Card>

  <Card title="Proof API Reference" href="/resources/proof-api/verify-address">
    Explore the API endpoints for verification and wallet management.
  </Card>
</CardGroup>


# Integration Guide
Source: https://pond.dflow.net/proof/partner-integration

How to integrate Proof into your application with deep linking and the verification API

<Info>
  Using an AI coding agent? The [`dflow-proof-kyc` skill](https://github.com/DFlowProtocol/dflow-skills/blob/main/skills/dflow-proof-kyc/SKILL.md) teaches Claude Code to build a Proof integration end-to-end. See [Agent Skills](/ai/agent-skills).
</Info>

This page describes how partner applications can integrate with Proof to verify users. Partners can redirect users to Proof for verification and query the Proof API to check verification status.

## Integration Overview

```mermaid theme={null}
flowchart LR
    subgraph partner [Partner App]
        A[User Action] --> B[Check Verification]
        B --> C{Verified?}
        C -->|No| D[Redirect to Proof]
        C -->|Yes| E[Allow Action]
    end
    
    subgraph proof [Proof]
        D --> F[User Verifies]
        F --> G[Redirect Back]
    end
    
    G --> B
```

## Deep Linking

Partners can redirect users to Proof with pre-populated data to streamline the verification flow. When the user completes verification, they are redirected back to your application.

### Deep Link Parameters

| Parameter      | Required | Description                                               |
| -------------- | -------- | --------------------------------------------------------- |
| `wallet`       | Yes      | The Solana wallet address to link                         |
| `signature`    | Yes      | Pre-signed ownership proof (base58 encoded)               |
| `timestamp`    | Yes      | Unix timestamp in milliseconds when signature was created |
| `redirect_uri` | Yes      | URL to redirect the user after verification               |
| `email`        | No       | Email address to prefill in the authentication step       |
| `projectId`    | No       | Your project identifier for tracking                      |

<Info>
  **Redirect URIs must use `https:` or `chrome-extension:` schemes.** Custom URL schemes (e.g. `myapp://`) are not supported and the redirect will not fire. Native mobile apps should use [universal links](https://developer.apple.com/ios/universal-links/) (iOS) or [app links](https://developer.android.com/training/app-links) (Android), which use `https:` URLs that deep link into your app.
</Info>

### Constructing a Deep Link

Build the deep link URL with query parameters:

```
https://dflow.net/proof?wallet={address}&signature={signature}&timestamp={timestamp}&redirect_uri={encodedRedirectUri}&email={encodedEmail}
```

### Generating the Signature

The user must sign a message proving wallet ownership. The message format is:

```
Proof KYC verification: {timestamp}
```

Where `{timestamp}` is the Unix timestamp in **milliseconds** (13 digits).

### Example: Creating a Deep Link

```typescript theme={null}
import { Connection, PublicKey } from "@solana/web3.js";
import bs58 from "bs58";

async function createProofDeepLink(
  wallet: { publicKey: PublicKey; signMessage: (message: Uint8Array) => Promise<Uint8Array> },
  redirectUri: string
): Promise<string> {
  // Generate timestamp in milliseconds
  const timestamp = Date.now();
  
  // Create the message to sign
  const message = `Proof KYC verification: ${timestamp}`;
  const messageBytes = new TextEncoder().encode(message);
  
  // Request signature from wallet
  const signatureBytes = await wallet.signMessage(messageBytes);
  const signature = bs58.encode(signatureBytes);
  
  // Build the deep link URL
  const params = new URLSearchParams({
    wallet: wallet.publicKey.toBase58(),
    signature,
    timestamp: timestamp.toString(),
    redirect_uri: redirectUri,
  });
  
  return `https://dflow.net/proof?${params.toString()}`;
}

// Usage
const deepLink = await createProofDeepLink(wallet, "https://yourapp.com/callback");
window.location.href = deepLink;
```

### Handling the Return

When the user completes verification (or cancels), they are redirected to your `redirect_uri`. Query the verification API to confirm their status.

When verification succeeds, Proof also sends an "Identity Verification Complete" email to the user.

```typescript theme={null}
async function handleProofCallback(walletAddress: string): Promise<boolean> {
  const response = await fetch(
    `https://proof.dflow.net/verify/${walletAddress}`
  );
  const { verified } = await response.json();
  return verified;
}
```

## Verification API

The verification API lets you check if a wallet address is linked to a verified identity. This is a public endpoint that does not require authentication.

### Endpoint

```
GET https://proof.dflow.net/verify/{address}
```

### Parameters

| Parameter | Location | Type   | Description                              |
| --------- | -------- | ------ | ---------------------------------------- |
| `address` | path     | string | Solana wallet address (32-44 characters) |

### Response

```json theme={null}
{
  "verified": true
}
```

| Field      | Type    | Description                                         |
| ---------- | ------- | --------------------------------------------------- |
| `verified` | boolean | Whether the wallet is linked to a verified identity |

### Example: Checking Verification Status

```typescript theme={null}
async function isWalletVerified(address: string): Promise<boolean> {
  const response = await fetch(
    `https://proof.dflow.net/verify/${address}`
  );
  
  if (!response.ok) {
    throw new Error(`Failed to check verification: ${response.status}`);
  }
  
  const { verified } = await response.json();
  return verified;
}

// Usage
const walletAddress = "DFlow1111111111111111111111111111111111111";
const verified = await isWalletVerified(walletAddress);

if (verified) {
  console.log("Wallet is verified");
} else {
  console.log("Wallet is not verified");
}
```

### Example: Gating Features

```typescript theme={null}
async function handleRestrictedAction(walletAddress: string) {
  const verified = await isWalletVerified(walletAddress);
  
  if (!verified) {
    // Redirect to Proof for verification
    const redirectUri = encodeURIComponent(window.location.href);
    window.location.href = `https://dflow.net/proof?redirect_uri=${redirectUri}`;
    return;
  }
  
  // User is verified, proceed with action
  await performRestrictedAction();
}
```

## Integration Flow

Here's a complete integration flow combining deep linking and the verification API:

```mermaid theme={null}
sequenceDiagram
    participant User
    participant PartnerApp as Partner App
    participant Wallet
    participant Proof
    
    User->>PartnerApp: Initiate restricted action
    PartnerApp->>Proof: GET /verify/{address}
    Proof->>PartnerApp: { verified: false }
    
    PartnerApp->>User: Request wallet signature
    User->>Wallet: Sign verification message
    Wallet->>User: Signature
    User->>PartnerApp: Provide signature
    
    PartnerApp->>Proof: Redirect with deep link
    Note over Proof: User completes verification
    Proof->>PartnerApp: Redirect to redirect_uri
    
    PartnerApp->>Proof: GET /verify/{address}
    Proof->>PartnerApp: { verified: true }
    PartnerApp->>User: Allow restricted action
```

## Best Practices

### Cache Verification Status

Verification status is stable once a user is verified. Consider caching the result to reduce API calls:

```typescript theme={null}
const verificationCache = new Map<string, boolean>();

async function isWalletVerified(address: string): Promise<boolean> {
  // Check cache first
  if (verificationCache.has(address)) {
    return verificationCache.get(address)!;
  }
  
  const response = await fetch(
    `https://proof.dflow.net/verify/${address}`
  );
  const { verified } = await response.json();
  
  // Cache verified status (don't cache unverified as it may change)
  if (verified) {
    verificationCache.set(address, true);
  }
  
  return verified;
}
```

### Showing Order Quotes to Unverified Users

To show order quotes to unverified users, omit `userPublicKey` from [`/order`](/resources/trading-api/order/order) requests.

### Handle Edge Cases

* **Signature expiration**: Generate fresh signatures close to redirect time
* **User cancellation**: Handle cases where users return without completing verification
* **Network errors**: Implement retry logic for API calls

### Security Considerations

* Always verify wallet ownership server-side when performing sensitive actions
* Do not trust client-side verification status alone for security-critical operations
* Use HTTPS for all API calls and redirects

## API Reference

For complete API documentation, see the [Proof API Reference](/resources/proof-api/verify-address):

* [Verify Address](/resources/proof-api/verify-address) — Check if a wallet is verified


# User Journeys
Source: https://pond.dflow.net/proof/user-journeys

Verification flows for direct users, partner app users, and returning users

This page describes the three primary user journeys through Proof:

* [New users visiting directly](#new-user-direct).
* [New users redirected from a partner app](#new-user-from-partner-app).
* [Returning users](#returning-user).

## New User (Direct)

<div>
  ```mermaid theme={null}
  flowchart LR
      subgraph direct [New User - Direct]
          direction LR
          D1[Visit Proof] --> D2[Authenticate]
          D2 --> D3[Verify Identity]
          D3 --> D4[Link Wallets]
          D4 --> D5[Manage Wallets]
      end
  ```
</div>

<div>
  ```mermaid theme={null}
  flowchart TD
      subgraph direct [New User - Direct]
          D1[Visit Proof] --> D2[Authenticate]
          D2 --> D3[Verify Identity]
          D3 --> D4[Link Wallets]
          D4 --> D5[Manage Wallets]
      end
  ```
</div>

Users who visit Proof directly to verify their identity and link wallets.

### Flow

1. **User visits Proof directly**
   * User navigates to the Proof application
   * Landing page explains the verification process

2. **Authenticates with email**
   * User enters their email address
   * Proof sends a one-time code
   * User enters the code to authenticate

3. **Completes identity verification**
   * User uploads a government-issued ID
   * User completes a liveness check (selfie matching)
   * Verification processes (may take time)
   * User sees status: pending, verified, or failed
   * On successful verification, Proof sends an "Identity Verification Complete" email

4. **Links one or more wallets**
   * User connects a Solana wallet
   * User signs a message to prove ownership
   * Proof verifies the signature and links the wallet
   * User can optionally add a label

5. **Manages linked wallets over time**
   * User can view all linked wallets
   * User can add new wallets
   * User can update wallet labels
   * User can remove wallets

### Sequence Diagram

```mermaid theme={null}
sequenceDiagram
    participant User
    participant Proof
    participant Wallet
    
    User->>Proof: Visit Proof
    User->>Proof: Enter email
    Proof->>User: Send OTP
    User->>Proof: Enter OTP
    Proof->>User: Authenticated
    
    User->>Proof: Upload ID
    User->>Proof: Complete liveness check
    Proof->>User: Verification status
    
    User->>Wallet: Connect wallet
    Wallet->>User: Connected
    User->>Proof: Request signature message
    Proof->>User: Signature message
    User->>Wallet: Sign message
    Wallet->>User: Signature
    User->>Proof: Submit signature
    Proof->>User: Wallet linked
```

## New User (From Partner App)

<div>
  ```mermaid theme={null}
  flowchart LR
      subgraph partner [New User - Partner App]
          direction LR
          P1[Partner Redirects] --> P2[Authenticate]
          P2 --> P3[Verify Identity]
          P3 --> P4[Auto-Link Wallet]
          P4 --> P5[Redirect Back]
      end
  ```
</div>

<div>
  ```mermaid theme={null}
  flowchart TD
      subgraph partner [New User - Partner App]
          P1[Partner Redirects] --> P2[Authenticate]
          P2 --> P3[Verify Identity]
          P3 --> P4[Auto-Link Wallet]
          P4 --> P5[Redirect Back]
      end
  ```
</div>

Users redirected to Proof from a partner application that requires verification.

### Flow

1. **User initiates action in partner app**
   * User attempts an action requiring verification
   * Partner app detects user is not verified

2. **Partner app redirects to Proof**
   * Partner app generates a deep link with:
     * Wallet address to link
     * Pre-signed ownership proof (signature)
     * Return URL for post-verification redirect
   * User is redirected to Proof

3. **User authenticates**
   * User enters their email address
   * Proof sends a one-time code
   * User enters the code to authenticate

4. **User completes identity verification**
   * User uploads a government-issued ID
   * User completes a liveness check
   * Verification processes
   * On successful verification, Proof sends an "Identity Verification Complete" email

5. **Wallet is automatically linked**
   * Proof verifies the pre-signed ownership proof
   * Wallet is linked without additional user action

6. **User is redirected back to partner app**
   * Proof redirects to the provided return URL
   * Partner app can now query verification status

### Sequence Diagram

```mermaid theme={null}
sequenceDiagram
    participant User
    participant PartnerApp as Partner App
    participant Proof
    participant Wallet
    
    User->>PartnerApp: Initiate action
    PartnerApp->>User: Request wallet signature
    User->>Wallet: Sign message
    Wallet->>User: Signature
    User->>PartnerApp: Provide signature
    PartnerApp->>Proof: Redirect with wallet + signature + returnUrl
    
    User->>Proof: Enter email
    Proof->>User: Send OTP
    User->>Proof: Enter OTP
    Proof->>User: Authenticated
    
    User->>Proof: Upload ID
    User->>Proof: Complete liveness check
    Proof->>User: Verified
    
    Proof->>Proof: Verify signature
    Proof->>Proof: Link wallet
    Proof->>PartnerApp: Redirect to returnUrl
    
    PartnerApp->>Proof: Query verification status
    Proof->>PartnerApp: Verified
```

## Returning User

<div>
  ```mermaid theme={null}
  flowchart LR
      subgraph returning [Returning User]
          direction LR
          R1[Visit or Redirect] --> R2[Authenticate]
          R2 --> R3[Skip Verification]
          R3 --> R4[Manage or Redirect]
      end
  ```
</div>

<div>
  ```mermaid theme={null}
  flowchart TD
      subgraph returning [Returning User]
          R1[Visit or Redirect] --> R2[Authenticate]
          R2 --> R3[Skip Verification]
          R3 --> R4[Manage or Redirect]
      end
  ```
</div>

Users who have already completed verification and return to Proof.

### Flow

1. **User visits Proof or is redirected from partner app**
   * User navigates directly to Proof, or
   * Partner app redirects user to Proof

2. **Authenticates with email**
   * User enters their email address
   * Proof sends a one-time code
   * User enters the code to authenticate

3. **Skips verification (already complete)**
   * Proof recognizes the user is already verified
   * No additional verification required

4. **Manages wallets or is redirected back**
   * If direct visit: User can manage wallets
   * If from partner: User is redirected back with existing wallet linked, or can link a new wallet

### Sequence Diagram

```mermaid theme={null}
sequenceDiagram
    participant User
    participant Proof
    participant PartnerApp as Partner App
    
    alt Direct Visit
        User->>Proof: Visit Proof
        User->>Proof: Authenticate
        Proof->>User: Already verified
        User->>Proof: Manage wallets
    else From Partner App
        PartnerApp->>Proof: Redirect with wallet + signature
        User->>Proof: Authenticate
        Proof->>User: Already verified
        Proof->>Proof: Link wallet if new
        Proof->>PartnerApp: Redirect to returnUrl
    end
```

## Verification States

Throughout these journeys, users may encounter different verification states:

| State        | Description                       | Next Action                  |
| ------------ | --------------------------------- | ---------------------------- |
| `unverified` | User has not started verification | Begin verification           |
| `pending`    | Verification is processing        | Wait for completion          |
| `verified`   | Verification successful           | Link wallets or use services |
| `failed`     | Verification unsuccessful         | Contact support or retry     |

## Related Pages

* [Integration Guide](/proof/partner-integration) — How to redirect users and query verification status
* [Proof API Reference](/resources/proof-api/verify-address) — API endpoints for all operations

<ContactUs />


# Dev Notifications
Source: https://pond.dflow.net/resources/dev-notifications

Stay in the loop on new DFlow features and announcements

<CardGroup>
  <Card title="Dev Notifications" href="https://t.me/+GubbVyulzDFjZTkx" icon="https://mintcdn.com/dflow/a8Yx7HBusmKl4Z7w/images/meteor-icons_telegram.svg?fit=max&auto=format&n=a8Yx7HBusmKl4Z7w&q=85&s=e928c5dd68311ff0d419936a35c86eed">
    Join the DFlow Dev Notifications Telegram group to stay in the loop on new features and other announcements.
  </Card>
</CardGroup>


# Error Codes
Source: https://pond.dflow.net/resources/error-codes

Understanding and resolving error codes

## General HTTP errors

| Code | Title               | When it happens                     | How to fix                                                                         |
| ---- | ------------------- | ----------------------------------- | ---------------------------------------------------------------------------------- |
| 429  | Rate limit exceeded | Too many requests in a short window | Retry with backoff, reduce request rate, or use an [API key](/get-started/api-key) |

## Trading API

### `route_not_found`

This error is most common in two situations:

1. **Incorrect `amount` units.** The `amount` parameter is the `inputMint`
   amount in atomic units (scaled by decimals). If you pass standard
   (human-readable) units (for example `8` instead of `8_000_000`), the router will not find a viable route.

2. **No available route.** The router found no viable route between `inputMint`
   and `outputMint`. This can happen for illiquid pairs or when the trade size
   exceeds available liquidity. Try a smaller amount or a different pair.

### `price_impact_too_high`

The effective price during routing is worse than the allowed threshold. If unspecified, the server determines the default. To set your own threshold, pass [`priceImpactTolerancePct`](/resources/trading-api/order/order#parameter-price-impact-tolerance-pct).


# FAQs
Source: https://pond.dflow.net/resources/faqs

Answers to common questions about building with DFlow

## General

<AccordionGroup>
  <Accordion title="Which wallets are supported?">
    Any Solana wallet that supports standard transaction signing.
  </Accordion>

  <Accordion title="Does DFlow custody user funds?">
    No. Funds stay in the user's wallet throughout the trade lifecycle.
  </Accordion>

  <Accordion title="Do users need to KYC to trade?">
    Spot trades are non-custodial and don't require KYC.
  </Accordion>

  <Accordion title="Does DFlow charge a protocol fee on spot trades?">
    No.
  </Accordion>

  <Accordion title="Does DFlow take positive slippage?">
    No.
  </Accordion>

  <Accordion title="Does DFlow support Pump.fun tokens?">
    Yes. Both on the bonding curve and after graduation to PumpSwap (Pump.fun's native AMM).
  </Accordion>

  <Accordion title="Will DFlow support limit orders?">
    On the roadmap. No timeline yet.
  </Accordion>
</AccordionGroup>

## Trading & Routing

<AccordionGroup>
  <Accordion title="How do I trade with native SOL?">
    Use the WSOL mint (`So11111111111111111111111111111111111111112`) as `inputMint` or `outputMint` and set `wrapAndUnwrapSol=true`. DFlow auto-wraps and unwraps SOL.
  </Accordion>

  <Accordion title="In POST /swap, what should destinationTokenAccount.address be for native SOL output?">
    Use the destination wallet address, not the wallet's WSOL associated token account address.
  </Accordion>

  <Accordion title="What's the difference between price impact and slippage?">
    Slippage is the price drift between quote and execution. Price impact is the gap between market price and your effective fill, caused by your trade's size relative to available liquidity.
  </Accordion>

  <Accordion title="What's the maximum price impact allowed on a trade?">
    The server applies a default threshold and rejects trades that exceed it with a `price_impact_too_high` error. Override with [`priceImpactTolerancePct`](/resources/trading-api/order/order#parameter-price-impact-tolerance-pct).
  </Accordion>

  <Accordion title="How does DFlow handle multiple token accounts for the same mint?">
    DFlow uses the associated token account by default. To send output elsewhere, pass [`destinationTokenAccount`](/resources/trading-api/order/order#parameter-destination-token-account) on `/order`; output lands in that account even if it isn't the ATA.
  </Accordion>

  <Accordion title="What is JIT routing?">
    Traditional aggregators commit a route at quote time. DFlow's [JIT routing](/spot/jit-routing) may refine the route at execution onchain, reflecting current conditions.
  </Accordion>

  <Accordion title="Does DFlow offer an intent-based swap?">
    Yes, as an opt-in. Most builders use [`/order`](/resources/trading-api/order/order) (imperative): the app signs a fully constructed transaction and submits through its own RPC. The intent flow ([`GET /intent`](/resources/trading-api/declarative/quote) + [`POST /submit-intent`](/resources/trading-api/declarative/submit)) gives stronger sandwich resistance on standard SPL pairs: the user signs an open order without a fixed route, and DFlow submits the open order and fill atomically as a Jito bundle. Token-2022 mints aren't supported on `/intent`.
  </Accordion>

  <Accordion title="Why do intermediate token accounts and residual dust sometimes remain after a swap?">
    Multi-leg routes can create intermediate token accounts to pass value between legs.

    * **Full consumption:** If subsequent legs consume the intermediate amount, the accounts are closed.
    * **Partial consumption:** If a residual remains (venue rounding, leg constraints), the accounts stay open with small dust.
  </Accordion>

  <Accordion title="Why am I getting route_not_found?">
    It means DFlow couldn't find a route for the pair at your trade size. A likely cause is insufficient liquidity for that pair and size. It's also worth confirming both mint addresses are correct and that `amount` is in atomic units (scaled by the input token's decimals, e.g. `5000000` for 5 USDC).
  </Accordion>

  <Accordion title="Can I use token symbols like &#x22;USDC&#x22; with the API?">
    No. The Trading API accepts **base58 mint addresses only**; there's no symbol resolver. (The `dflow` CLI resolves a small set of common symbols, but the API does not.)
  </Accordion>

  <Accordion title="How do I get a price quote without a connected wallet?">
    Call [`/order`](/resources/trading-api/order/order) **without** `userPublicKey`. It returns the price fields (`inAmount`, `outAmount`, `priceImpactPct`) and no transaction, so you can show a price before the user has connected a wallet. A separate `/quote` endpoint still works, but `/order` is preferred for new integrations.
  </Accordion>
</AccordionGroup>

## Fees & Sponsorship

<AccordionGroup>
  <Accordion title="What fees apply to a trade?">
    Network fees, optional [priority fees](/spot/trading/priority-fees), optional [platform fees](/spot/trading/platform-fees) if you set them, and any DEX fees baked into the route. Slippage depends on market liquidity and trade size.
  </Accordion>

  <Accordion title="How do I set a priority fee on a trade?">
    Pass [`prioritizationFeeLamports`](/resources/trading-api/order/order#parameter-prioritization-fee-lamports) on `/order` as a lamport amount or one of `auto`, `medium`, `high`, `veryHigh`, `disabled`. See [Priority Fees](/spot/trading/priority-fees) for the two fee modes.
  </Accordion>

  <Accordion title="Does DFlow support gas sponsorship?">
    Yes. Pass the [`sponsor`](/resources/trading-api/order/order#parameter-sponsor) parameter on `/order` to have a sponsor wallet cover the transaction fee.
  </Accordion>

  <Accordion title="Should I set platformFeeBps if I'm not collecting a fee?">
    No. The API factors `platformFeeBps` into slippage tolerance, so declaring a fee you don't collect wastes slippage budget and gives users worse pricing. See [Platform Fees](/spot/trading/platform-fees#how-platform-fees-affect-trades).
  </Accordion>
</AccordionGroup>

## Troubleshooting

<AccordionGroup>
  <Accordion title="Why is my trade failing with &#x22;exceeded CUs meter at BPF instruction&#x22;?">
    The transaction hit its compute unit (CU) limit. Pass `dynamicComputeUnitLimit=true` on `/order` to have the API size the limit automatically.
  </Accordion>

  <Accordion title="Does dynamicComputeUnitLimit add latency?">
    Enabling [`dynamicComputeUnitLimit`](/resources/trading-api/order/order#parameter-dynamic-compute-unit-limit) may add latency; however, it depends on the rest of your parameters.
  </Accordion>

  <Accordion title="Can I call /order directly from the browser?">
    No. The Trading API doesn't set CORS headers, so browser requests are blocked. Proxy `/order` through your backend; most builders use an edge function (Cloudflare Workers, Vercel Edge Functions) to keep added latency low.
  </Accordion>

  <Accordion title="Can I connect to the market-data streams from the browser?">
    No. As a security best practice, your DFlow API key belongs on the backend, not in browser code where anyone can read it. Stream through a backend proxy that holds the key, connects to DFlow, and relays messages to the browser.
  </Accordion>

  <Accordion title="My API key works for /order but the stream rejects it. Why?">
    Access to the quote and book streams is granted per API key; it's a separate permission, not automatic with a valid or production key. A key that trades fine on `/order` can still be refused on the stream until the team enables stream access on that specific key. So if a working key is rejected only on the stream, that's a key permission, not a bug in your integration; request stream access from the team.
  </Accordion>
</AccordionGroup>

## Proof

<AccordionGroup>
  <Accordion title="Who provides KYC for Proof?">
    [Stripe Identity](https://docs.stripe.com/identity).
  </Accordion>

  <Accordion title="Is there a fee to use Proof?">
    No.
  </Accordion>

  <Accordion title="Does Proof work with embedded wallet providers like Privy?">
    Yes. Your app directs the user to `https://dflow.net/proof` to complete KYC, with a [redirect URL](/proof/partner-integration#deep-link-parameters) to send them back to your app after verification.
  </Accordion>

  <Accordion title="Why isn't my Proof redirect firing after verification?">
    Proof only redirects to `https:`, `moz-extension://`, or `chrome-extension:` URLs. Custom schemes (e.g. `myapp://callback`) silently fail. Native mobile apps should use [universal links](https://developer.apple.com/ios/universal-links/) (iOS) or [app links](https://developer.android.com/training/app-links) (Android). See [redirect\_uri parameter docs](/proof/partner-integration#deep-link-parameters).
  </Accordion>
</AccordionGroup>


# Introduction
Source: https://pond.dflow.net/resources/introduction

APIs, wallet integration guides, and troubleshooting

Everything you need to integrate DFlow: the Trading API, request signing, wallet integration guides, and troubleshooting.

<div>
  <a href="/resources/trading-api/order/order">
    <div>
      <Icon icon="arrow-right-arrow-left" />

      <h3>Order endpoint</h3>
      <p>Request a quote and get a ready-to-sign swap. The core Trading API call.</p>
    </div>

    <div>
      <Icon icon="arrow-right" />
    </div>
  </a>

  <a href="/resources/trading-api/websockets/overview">
    <div>
      <Icon icon="tower-broadcast" />

      <h3>WebSockets</h3>
      <p>Stream quotes, order book depth, and priority fees in real time.</p>
    </div>

    <div>
      <Icon icon="arrow-right" />
    </div>
  </a>

  <a href="/resources/request-signing">
    <div>
      <Icon icon="signature" />

      <h3>Request signing</h3>
      <p>Ask DFlow to sign its API responses so you can verify them.</p>
    </div>

    <div>
      <Icon icon="arrow-right" />
    </div>
  </a>

  <a href="/resources/recipes/wallets/phantom-connect">
    <div>
      <Icon icon="wallet" />

      <h3>Wallet integration</h3>
      <p>Connect Phantom, Privy, and Turnkey to your DFlow app.</p>
    </div>

    <div>
      <Icon icon="arrow-right" />
    </div>
  </a>
</div>


# Verify Address
Source: https://pond.dflow.net/resources/proof-api/verify-address

GET /verify/{address}
Check if a wallet address has been verified



# Authenticate Requests
Source: https://pond.dflow.net/resources/recipes/api-keys

How to authenticate requests with DFlow API keys

<Info>
  During development, you can use the [developer endpoints](/get-started/endpoints) without an API key. For production use, you'll need an [API key](/get-started/api-key) to avoid rate limits.
</Info>

## Using Your API Key

Include your API key in all requests to the APIs by setting the `x-api-key` header.
All calls to the production endpoints must use an API key.

<AccordionGroup>
  <Accordion title="GET request">
    For GET requests, include the API key in the request headers:

    ```typescript theme={null}
    import "dotenv/config";

    import { Keypair } from "@solana/web3.js";
    import bs58 from "bs58";

    const DFLOW_TRADE_API_URL = process.env.DFLOW_TRADE_API_URL ?? "https://dev-quote-api.dflow.net";
    const DFLOW_API_KEY = process.env.DFLOW_API_KEY; // optional; not needed for dev endpoints
    const DFLOW_SETTLEMENT_MINT = process.env.DFLOW_SETTLEMENT_MINT ?? "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"; // USDC

    const SOL_MINT = "So11111111111111111111111111111111111111112";
    const amount = 100_000; // 0.0001 SOL (9 decimals)
    const slippageBps = 50; // 0.5%

    const keypair = Keypair.fromSecretKey(
      bs58.decode(process.env.SOLANA_PRIVATE_KEY ?? "")
    );

    const headers: HeadersInit = {};
    if (DFLOW_API_KEY) headers["x-api-key"] = DFLOW_API_KEY;

    const queryParams = new URLSearchParams();
    queryParams.append("inputMint", SOL_MINT);
    queryParams.append("outputMint", DFLOW_SETTLEMENT_MINT);
    queryParams.append("amount", amount.toString());
    queryParams.append("slippageBps", slippageBps.toString());
    queryParams.append("userPublicKey", keypair.publicKey.toBase58());

    const response = await fetch(
      `${DFLOW_TRADE_API_URL}/order?${queryParams.toString()}`,
      { headers }
    ).then((x) => x.json());
    ```
  </Accordion>

  <Accordion title="POST request">
    For POST requests, include the API key alongside other headers:

    ```typescript theme={null}
    // Reuses DFLOW_TRADE_API_URL, DFLOW_API_KEY, and headers from the GET setup above.
    // intentData and openTransaction come from an earlier /intent call.
    async function submitIntent(intentData: unknown, openTransaction: { serialize(): Buffer }) {
      const response = await fetch(`${DFLOW_TRADE_API_URL}/submit-intent`, {
        method: "POST",
        headers: { ...headers, "Content-Type": "application/json" },
        body: JSON.stringify({
          quoteResponse: intentData,
          signedOpenTransaction: Buffer.from(openTransaction.serialize()).toString(
            "base64"
          ),
        }),
      });
      return response.json();
    }
    ```
  </Accordion>
</AccordionGroup>

## WebSocket Authentication

The Trade API exposes WebSocket [endpoints](/get-started/endpoints). They authenticate the same way as REST: developer endpoints are open without a key, and production endpoints take the API key as an `x-api-key` header on the upgrade request, not a URL query parameter.

```typescript theme={null}
// Reuses DFLOW_API_KEY from the GET setup above.
const DFLOW_TRADE_API_WS_URL = process.env.DFLOW_TRADE_API_WS_URL ?? "wss://dev-quote-api.dflow.net/quote-stream";

const wsHeaders: Record<string, string> = {};
if (DFLOW_API_KEY) wsHeaders["x-api-key"] = DFLOW_API_KEY;

const ws = new WebSocket(DFLOW_TRADE_API_WS_URL, { headers: wsHeaders });
```

## Security Best Practices

* Store your API key securely using environment variables.
* Never commit API keys to version control.
* Rotate your API key if it's ever exposed.

## Getting Help

If you need an API key or have questions about rate limits, [reach out to us](/get-started/api-key).

## Related Resources

<CardGroup>
  <Card title="Endpoints" href="/get-started/endpoints" icon="server">
    Dev and production base URLs for the Trade API.
  </Card>

  <Card title="Request an API Key" href="/get-started/api-key" icon="key">
    Submit the form to get a production API key.
  </Card>

  <Card title="Send Orders" href="/spot/recipes/quickstart" icon="rocket">
    Send a spot order end-to-end.
  </Card>
</CardGroup>

## API Routes

* [GET /order](/resources/trading-api/order/order)
* [POST /submit-intent](/resources/trading-api/declarative/submit)


# Phantom Connect
Source: https://pond.dflow.net/resources/recipes/wallets/phantom-connect

How to add Phantom Connect to a Next.js + React app

Use Phantom Connect to add wallet access, embedded wallets, and social login to a
Next.js + React app.

<Info>
  This recipe covers adding Phantom Connect to a Next.js + React app. Use their [Browser SDK](https://docs.phantom.com/sdks/browser-sdk/index) for
  non-React web apps and the [React Native SDK](https://docs.phantom.com/sdks/react-native-sdk/index)
  for mobile apps.
</Info>

## Prerequisites

Create a [Phantom Portal](https://phantom.com/portal/) app, configure allowed
domains and redirect URLs, and copy the App ID.

## Step-by-step (Next.js + React)

<Steps>
  <Step title="Install the React SDK">
    Use the [React SDK](https://docs.phantom.com/sdks/react-sdk) for Next.js + React.

    <AccordionGroup>
      <Accordion title="Install dependencies">
        ```bash theme={null}
        npm install @phantom/react-sdk @solana/web3.js
        ```
      </Accordion>

      <Accordion title="Optional starter template">
        ```bash theme={null}
        npx -y create-solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-react
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Add PhantomProvider (App Router or Pages Router)">
    Wrap your root layout so Phantom Connect can manage auth and wallet state.
    Put your App ID in `config.appId` (see `appId: "your-app-id"` in the examples)
    and set the redirect URL you configured.

    <Tabs>
      <Tab title="App Router">
        Create a client-side provider component, then wrap it in `app/layout.tsx`.

        <AccordionGroup>
          <Accordion title="app/providers.tsx">
            ```tsx theme={null}
            // app/providers.tsx
            "use client";

            import { PhantomProvider, darkTheme } from "@phantom/react-sdk";
            import { AddressType } from "@phantom/browser-sdk";

            export function Providers({ children }: { children: React.ReactNode }) {
              return (
                <PhantomProvider
                  config={{
                    providers: ["google", "apple", "injected", "deeplink"],
                    appId: "your-app-id",
                    addressTypes: [AddressType.solana],
                    authOptions: {
                      redirectUrl: "https://yourapp.com/auth/callback",
                    },
                  }}
                  theme={darkTheme}
                  appIcon="https://your-app.com/icon.png"
                  appName="Your App Name"
                >
                  {children}
                </PhantomProvider>
              );
            }
            ```
          </Accordion>

          <Accordion title="app/layout.tsx">
            ```tsx theme={null}
            // app/layout.tsx
            import { Providers } from "./providers";

            export default function RootLayout({
              children,
            }: {
              children: React.ReactNode;
            }) {
              return (
                <html lang="en">
                  <body>
                    <Providers>{children}</Providers>
                  </body>
                </html>
              );
            }
            ```
          </Accordion>
        </AccordionGroup>
      </Tab>

      <Tab title="Pages Router">
        Wrap your app in `pages/_app.tsx`.

        <AccordionGroup>
          <Accordion title="pages/_app.tsx">
            ```tsx theme={null}
            // pages/_app.tsx
            import type { AppProps } from "next/app";
            import { PhantomProvider, darkTheme } from "@phantom/react-sdk";
            import { AddressType } from "@phantom/browser-sdk";

            export default function App({ Component, pageProps }: AppProps) {
              return (
                <PhantomProvider
                  config={{
                    providers: ["google", "apple", "injected", "deeplink"],
                    appId: "your-app-id",
                    addressTypes: [AddressType.solana],
                    authOptions: {
                      redirectUrl: "https://yourapp.com/auth/callback",
                    },
                  }}
                  theme={darkTheme}
                  appIcon="https://your-app.com/icon.png"
                  appName="Your App Name"
                >
                  <Component {...pageProps} />
                </PhantomProvider>
              );
            }
            ```
          </Accordion>
        </AccordionGroup>
      </Tab>
    </Tabs>
  </Step>

  <Step title="Connect a user">
    Use the built-in modal or ConnectButton to trigger the Phantom flow.

    <AccordionGroup>
      <Accordion title="Connect with the modal">
        ```tsx theme={null}
        "use client";

        import { useModal, usePhantom } from "@phantom/react-sdk";

        function WalletComponent() {
          const { open } = useModal();
          const { isConnected } = usePhantom();

          if (isConnected) return <p>Connected</p>;
          return <button onClick={open}>Connect Wallet</button>;
        }
        ```
      </Accordion>

      <Accordion title="ConnectButton (ready-to-use)">
        ```tsx theme={null}
        "use client";
        import { ConnectButton } from "@phantom/react-sdk";

        function Header() {
          return <ConnectButton />;
        }
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Theme the Phantom ConnectUI">
    Use [theming](https://docs.phantom.com/sdks/react-sdk#theming) to customize
    the modal UI.
  </Step>
</Steps>


# Privy
Source: https://pond.dflow.net/resources/recipes/wallets/privy

How to add Privy to a Next.js + React app

Use Privy to add authentication and embedded wallets to a Next.js + React app.

<Info>
  Privy supports multiple authentication methods (email, socials, passkeys, and
  external wallets). This guide uses email OTP as a simple starting point.
</Info>

## Prerequisites

Create a Privy app in the [Privy Dashboard](https://dashboard.privy.io/) and
copy your App ID.

## Step-by-step (Next.js + React)

<Steps>
  <Step title="Install the React SDK">
    Install the [React SDK](https://docs.privy.io/basics/react/quickstart).

    <AccordionGroup>
      <Accordion title="Install dependencies">
        ```bash theme={null}
        npm install @privy-io/react-auth
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Wrap your app with PrivyProvider">
    Put your App ID in `appId="your-app-id"` and wrap your app root. For Solana
    embedded wallets, set `embeddedWallets.solana.createOnLogin` to create
    wallets on login.

    <Tabs>
      <Tab title="App Router">
        Create a client-side provider component, then wrap it in `app/layout.tsx`.

        <AccordionGroup>
          <Accordion title="app/providers.tsx">
            ```tsx theme={null}
            // app/providers.tsx
            "use client";

            import { PrivyProvider } from "@privy-io/react-auth";

            export function Providers({ children }: { children: React.ReactNode }) {
              return (
                <PrivyProvider
                  appId="your-app-id"
                  config={{
                    embeddedWallets: {
                      solana: {
                        createOnLogin: "users-without-wallets",
                      },
                    },
                  }}
                >
                  {children}
                </PrivyProvider>
              );
            }
            ```
          </Accordion>

          <Accordion title="app/layout.tsx">
            ```tsx theme={null}
            // app/layout.tsx
            import { Providers } from "./providers";

            export default function RootLayout({
              children,
            }: {
              children: React.ReactNode;
            }) {
              return (
                <html lang="en">
                  <body>
                    <Providers>{children}</Providers>
                  </body>
                </html>
              );
            }
            ```
          </Accordion>
        </AccordionGroup>
      </Tab>

      <Tab title="Pages Router">
        Wrap your app in `pages/_app.tsx`.

        <AccordionGroup>
          <Accordion title="pages/_app.tsx">
            ```tsx theme={null}
            // pages/_app.tsx
            import type { AppProps } from "next/app";
            import { PrivyProvider } from "@privy-io/react-auth";

            export default function App({ Component, pageProps }: AppProps) {
              return (
                <PrivyProvider
                  appId="your-app-id"
                  config={{
                    embeddedWallets: {
                      solana: {
                        createOnLogin: "users-without-wallets",
                      },
                    },
                  }}
                >
                  <Component {...pageProps} />
                </PrivyProvider>
              );
            }
            ```
          </Accordion>
        </AccordionGroup>
      </Tab>
    </Tabs>

    <Info>
      To use external Solana wallets, pass `toSolanaWalletConnectors()` to
      `externalWallets`. See
      [configuring connector chains](https://docs.privy.io/wallets/connectors/setup/configuring-external-connector-chains).
    </Info>
  </Step>

  <Step title="Connect a user">
    Use Privy’s modal and show a connected state when login completes.

    <AccordionGroup>
      <Accordion title="Connect button">
        ```tsx theme={null}
        "use client";

        import { usePrivy } from "@privy-io/react-auth";

        export default function ConnectButton() {
          const { ready, authenticated, login, user } = usePrivy();

          if (!ready) return <p>Loading...</p>;
          if (authenticated) return <p>Connected</p>;
          return <button onClick={login}>Connect Wallet</button>;
        }
        ```
      </Accordion>
    </AccordionGroup>
  </Step>
</Steps>

<Info>
  See the
  [Privy Solana wallet docs](https://docs.privy.io/wallets/using-wallets/solana/send-a-transaction)
  for transaction examples.
</Info>


# Turnkey
Source: https://pond.dflow.net/resources/recipes/wallets/turnkey

How to add Turnkey to a Next.js + React app

Use Turnkey Embedded Wallet Kit to add authentication and embedded wallets to a
Next.js + React app.

## Prerequisites

Create a [Turnkey organization](https://docs.turnkey.com/getting-started/quickstart) in the [Turnkey dashboard](https://app.turnkey.com),
enable **Auth Proxy**, **email OTP**, and **passkeys**.

Copy your **Organization ID** and **Auth Proxy Config ID**.

## Step-by-step (Next.js + React)

<Steps>
  <Step title="Install the React Wallet Kit">
    Install the Turnkey React Wallet Kit in your Next.js app.

    <AccordionGroup>
      <Accordion title="Install dependencies">
        ```bash theme={null}
        npm install @turnkey/react-wallet-kit
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Add environment variables">
    Store your IDs in `.env.local` so your app can initialize Turnkey.

    <AccordionGroup>
      <Accordion title="Create .env.local">
        ```bash theme={null}
        NEXT_PUBLIC_ORGANIZATION_ID="your-org-id"
        NEXT_PUBLIC_AUTH_PROXY_CONFIG_ID="your-auth-proxy-config-id"
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Wrap your app with TurnkeyProvider">
    Initialize Turnkey at the app root and include the wallet kit styles.

    <Tabs>
      <Tab title="App Router">
        Create a client-side provider component, then wrap it in `app/layout.tsx`.

        <AccordionGroup>
          <Accordion title="app/providers.tsx">
            ```tsx theme={null}
            // app/providers.tsx
            "use client";

            import {
              TurnkeyProvider,
              TurnkeyProviderConfig,
            } from "@turnkey/react-wallet-kit";

            const turnkeyConfig: TurnkeyProviderConfig = {
              organizationId: process.env.NEXT_PUBLIC_ORGANIZATION_ID!,
              authProxyConfigId: process.env.NEXT_PUBLIC_AUTH_PROXY_CONFIG_ID!,
            };

            export function Providers({ children }: { children: React.ReactNode }) {
              return (
                <TurnkeyProvider
                  config={turnkeyConfig}
                  callbacks={{
                    onError: (error) => console.error("Turnkey error:", error),
                  }}
                >
                  {children}
                </TurnkeyProvider>
              );
            }
            ```
          </Accordion>

          <Accordion title="app/layout.tsx">
            ```tsx theme={null}
            // app/layout.tsx
            import "@turnkey/react-wallet-kit/styles.css";
            import { Providers } from "./providers";

            export default function RootLayout({
              children,
            }: {
              children: React.ReactNode;
            }) {
              return (
                <html lang="en">
                  <body>
                    <Providers>{children}</Providers>
                  </body>
                </html>
              );
            }
            ```
          </Accordion>
        </AccordionGroup>
      </Tab>

      <Tab title="Pages Router">
        Wrap your app in `pages/_app.tsx`.

        <AccordionGroup>
          <Accordion title="pages/_app.tsx">
            ```tsx theme={null}
            // pages/_app.tsx
            import type { AppProps } from "next/app";
            import "@turnkey/react-wallet-kit/styles.css";
            import {
              TurnkeyProvider,
              TurnkeyProviderConfig,
            } from "@turnkey/react-wallet-kit";

            const turnkeyConfig: TurnkeyProviderConfig = {
              organizationId: process.env.NEXT_PUBLIC_ORGANIZATION_ID!,
              authProxyConfigId: process.env.NEXT_PUBLIC_AUTH_PROXY_CONFIG_ID!,
            };

            export default function App({ Component, pageProps }: AppProps) {
              return (
                <TurnkeyProvider
                  config={turnkeyConfig}
                  callbacks={{
                    onError: (error) => console.error("Turnkey error:", error),
                  }}
                >
                  <Component {...pageProps} />
                </TurnkeyProvider>
              );
            }
            ```
          </Accordion>
        </AccordionGroup>
      </Tab>
    </Tabs>
  </Step>

  <Step title="Connect a user">
    Use Turnkey’s modal and show a connected state when login completes.

    <AccordionGroup>
      <Accordion title="Connect button">
        ```tsx theme={null}
        "use client";

        import {
          AuthState,
          ClientState,
          useTurnkey,
        } from "@turnkey/react-wallet-kit";

        export default function ConnectButton() {
          const { handleLogin, authState, clientState } = useTurnkey();

          if (clientState === undefined || clientState === ClientState.Loading) {
            return <p>Loading...</p>;
          }
          if (clientState === ClientState.Error) {
            return <p>Turnkey failed to initialize.</p>;
          }
          if (authState === AuthState.Authenticated) {
            return <p>Connected</p>;
          }

          return <button onClick={handleLogin}>Connect Wallet</button>;
        }
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Theme the Turnkey UI">
    Use [theming](https://docs.turnkey.com/sdks/react/ui-customization) to customize
    the Turnkey UI.
  </Step>
</Steps>

<Info>
  See [authentication](https://docs.turnkey.com/sdks/react/auth) for custom login
  flows.
</Info>


# Request Signing
Source: https://pond.dflow.net/resources/request-signing

Ask DFlow to cryptographically sign its API responses

Ask DFlow to cryptographically sign its API responses so you can confirm a response came from DFlow and was not altered in transit. Signatures follow [RFC 9421 (HTTP Message Signatures)](https://datatracker.ietf.org/doc/html/rfc9421) and use ed25519.

<Note>
  Signing applies only to REST requests, not WebSocket connections.
</Note>

## Request a signed response

Add the `x-sign-request` header to a request:

```
x-sign-request: true
```

DFlow signs the response and returns the signature in standard response headers.

You can also send an `x-request-id` header with any string value. It is included in the signed content and echoed back in the response, so you can tie a response to your request and guard against replay. If you omit it, DFlow generates one.

```
x-sign-request: true
x-request-id: 0f8c2b1a-...    # optional
```

Try it against the [developer endpoint](/get-started/endpoints) (no API key required) and read the response headers:

```bash theme={null}
curl -sS -D - -o /dev/null \
  -H "x-sign-request: true" \
  "https://dev-quote-api.dflow.net/order?inputMint=So11111111111111111111111111111111111111112&outputMint=EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v&amount=100000000"
```

`-D -` prints the response headers and `-o /dev/null` discards the body, so you see `signature`, `signature-input`, and `content-digest`.

## Response headers

A signed response includes:

| Header            | Description                                                                     |
| ----------------- | ------------------------------------------------------------------------------- |
| `signature-input` | The signed components and metadata: `keyid`, algorithm, and `created` timestamp |
| `signature`       | The signature, base64-encoded                                                   |
| `content-digest`  | SHA-256 digest of the response body                                             |
| `x-request-id`    | Your `x-request-id`, or one DFlow generated                                     |

These headers are exposed via CORS (`access-control-expose-headers`), so they are readable from the browser.

Example:

```http theme={null}
signature-input: sig1=("@status" "content-type" "content-digest" "x-request-id";req);created=1781240303;keyid="EZKxYr7bbXHaKAGw2MEpVUU9He3hwXGejSpCsdsZCmiF";alg="ed25519"
signature: sig1=:DeW+BqtOUUtgb4NKx9mV9MrhVuOgzSO6GfbRWWcbFuqiMFjVJrSVOSw/ntI7GO0JNvGUpsAxUxiGX/USFUWlBQ==:
content-digest: sha-256=:98r7y7hVcmXvMYQqkLeUWtWuLDH5nVWGyRpzSRwKhIc=:
```

The signature covers the response `@status`, `content-type`, `content-digest`, and your `x-request-id`.

## Public key

DFlow's base58-encoded public key, carried as the `keyid` in `signature-input`:

```
EZKxYr7bbXHaKAGw2MEpVUU9He3hwXGejSpCsdsZCmiF
```

## Verify a response

Verify the `signature` against the public key above using an RFC 9421 library, which handles rebuilding the signature base from the signed components and checking the `content-digest`.


# Get Intent Quote
Source: https://pond.dflow.net/resources/trading-api/declarative/quote

GET /intent
API reference for GET /intent

<Note>
  Most builders use [`GET /order`](/resources/trading-api/order/order), which returns a fully constructed transaction in one call. `GET /intent` is the opt-in path for builders who need stronger sandwich resistance on standard SPL pairs: routing is finalized at execution time and the trade lands as a Jito bundle. Token-2022 mints are not supported on `/intent`; use [`GET /order`](/resources/trading-api/order/order) for those.
</Note>


# Submit Intent Swap
Source: https://pond.dflow.net/resources/trading-api/declarative/submit

POST /submit-intent
API reference for POST /submit-intent

<Note>
  Most builders use [`GET /order`](/resources/trading-api/order/order), which returns a fully constructed transaction in one call. `POST /submit-intent` is the second step of the opt-in intent flow for builders who need stronger sandwich resistance on standard SPL pairs: pair it with [`GET /intent`](/resources/trading-api/declarative/quote). Token-2022 mints are not supported on this flow; use [`GET /order`](/resources/trading-api/order/order) for those.
</Note>


# Get Quote
Source: https://pond.dflow.net/resources/trading-api/imperative/quote

GET /quote
API reference for GET /quote

<Info>
  We recommend using the [`/order`](/resources/trading-api/order/order) endpoint for new
  integrations. This endpoint is still available but `/order` is the preferred
  approach. For a code example, see the
  [Send Orders](/spot/recipes/quickstart) recipe.
</Info>


# Create Swap
Source: https://pond.dflow.net/resources/trading-api/imperative/swap

POST /swap
API reference for POST /swap

<Info>
  We recommend using the [`/order`](/resources/trading-api/order/order) endpoint for new
  integrations. This endpoint is still available but `/order` is the preferred
  approach. For a code example, see the
  [Send Orders](/spot/recipes/quickstart) recipe.
</Info>


# Create Swap Instructions
Source: https://pond.dflow.net/resources/trading-api/imperative/swap-instructions

POST /swap-instructions
API reference for POST /swap-instructions

<Info>
  We recommend using the [`/order`](/resources/trading-api/order/order) endpoint for new
  integrations. This endpoint is still available but `/order` is the preferred
  approach. For a code example, see the
  [Send Orders](/spot/recipes/quickstart) recipe.
</Info>


# Introduction
Source: https://pond.dflow.net/resources/trading-api/introduction

How to use the Trading API to trade crypto on Solana.

<CardGroup>
  <Card title="Order API Endpoints" href="order/order">
    <p>Retrieve order information and check order status</p>
  </Card>

  <Card title="Imperative Trading API Endpoints" href="imperative/quote">
    <p>
      Get a constructed transaction back, sign it, and submit through your own
      RPC
    </p>
  </Card>

  <Card title="Declarative Trading API Endpoints" href="declarative/quote">
    <p>
      Post a trade intent to DFlow for better prices and sandwich resistance
    </p>
  </Card>

  <Card title="Priority Fee API Endpoints" href="priority-fees/priority-fees">
    <p>Get current priority fee estimates for trade requests</p>
  </Card>

  <Card title="Websockets" href="websockets/overview">
    <p>Stream priority fee estimate updates in real time</p>
  </Card>

  <Card title="Token API Endpoints" href="token/tokens">
    <p>Get token information and lists with decimal precision</p>
  </Card>

  <Card title="Venue API Endpoints" href="venues/venues">
    <p>Get venue information and available trading venues</p>
  </Card>
</CardGroup>


# Get Order
Source: https://pond.dflow.net/resources/trading-api/order/order

GET /order
API reference for GET /order



# Get Order Status
Source: https://pond.dflow.net/resources/trading-api/order/order-status

GET /order-status
API reference for GET /order-status



# Get Priority Fees
Source: https://pond.dflow.net/resources/trading-api/priority-fees/priority-fees

GET /priority-fees
API reference for GET /priority-fees

Returns the latest priority fee estimates for `medium`, `high`, and `very high`.

Response values are micro-lamports per compute unit.


# Get Token List
Source: https://pond.dflow.net/resources/trading-api/token/tokens

GET /tokens
API reference for GET /tokens



# Get Token List with Decimals
Source: https://pond.dflow.net/resources/trading-api/token/tokens-with-decimals

GET /tokens-with-decimals
API reference for GET /tokens-with-decimals



# Get Venue List
Source: https://pond.dflow.net/resources/trading-api/venues/venues

GET /venues
API reference for GET /venues



# Book Stream
Source: https://pond.dflow.net/resources/trading-api/websockets/book-stream

Stream ten levels of order book depth for token pairs over WebSocket

The `book-stream` endpoint streams ten levels of order book depth per side for a
pair of token mints. See [Market Data Streams](/spot/trading/market-data-streams)
for what the depth means and when to use the stream; this page documents the
message format.

<Info>
  Book levels are **approximations** computed at runtime, on **direct routes
  only**. Each level's size is cumulative from the spot outward.
</Info>

<Note>
  Access to the book stream is gated. Reach out to the team to request access.
</Note>

## Connection

See the [Websockets Overview](/resources/trading-api/websockets/overview#connection)
for endpoint details.

## Subscribe

Send a `subscribe` op with the base and quote mints:

```json theme={null}
{
  "op": "subscribe",
  "base_mint": "So11111111111111111111111111111111111111112",
  "quote_mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"
}
```

## Unsubscribe

```json theme={null}
{
  "op": "unsubscribe",
  "base_mint": "So11111111111111111111111111111111111111112",
  "quote_mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"
}
```

## Message Format

Each message is a batch covering one slot. `b` and `a` each carry ten levels,
ordered nearest to spot outward:

```json theme={null}
{
  "u": 425218519,
  "ts": 1780964621,
  "subscribe": [
    {
      "sb": "So11111111111111111111111111111111111111112",
      "sq": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"
    }
  ],
  "updates": [
    {
      "sb": "So11111111111111111111111111111111111111112",
      "sq": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
      "mid": 66.287,
      "tick": 0.0066287,
      "crossed": false,
      "b": [
        { "price": 66.2803713, "cumulative_size_human": 11.275078961 },
        { "price": 66.2737426, "cumulative_size_human": 4030.117529621 }
      ],
      "a": [
        { "price": 66.2936287, "cumulative_size_human": 727.767025378 },
        { "price": 66.3002574, "cumulative_size_human": 1606.23883139 }
      ]
    }
  ]
}
```

### Fields

| Field                       | Type   | Description                                                             |
| --------------------------- | ------ | ----------------------------------------------------------------------- |
| `u`                         | number | Slot the book was computed at                                           |
| `ts`                        | number | Unix timestamp in seconds                                               |
| `skipped`                   | number | Slots skipped before this batch under load. `0` when the stream kept up |
| `updates`                   | array  | Per-pair book updates for this slot                                     |
| `subscribe` / `unsubscribe` | array  | Acknowledgements of subscription changes                                |

Each entry in `updates` has:

| Field     | Type    | Description                                                                                      |
| --------- | ------- | ------------------------------------------------------------------------------------------------ |
| `sb`      | string  | Base mint                                                                                        |
| `sq`      | string  | Quote mint                                                                                       |
| `mid`     | number  | Mid price, quote per base                                                                        |
| `tick`    | number  | Tick width, quote per base                                                                       |
| `crossed` | boolean | Whether the aggregated book was crossed before being uncrossed                                   |
| `b`       | array   | Ten bid levels, nearest to spot outward                                                          |
| `a`       | array   | Ten ask levels, nearest to spot outward                                                          |
| `e`       | string  | Per-pair error code (for example `no_market`), present instead of a book when one is unavailable |

Each level in `b` and `a` has:

| Field                   | Type   | Description                                          |
| ----------------------- | ------ | ---------------------------------------------------- |
| `price`                 | number | Level price, quote per base                          |
| `cumulative_size_human` | number | Cumulative base size from the spot out to this level |

## Code Examples

<AccordionGroup>
  <Accordion title="Subscribe to a Pair">
    ```typescript theme={null}
    // Dev endpoint — no API key required, but rate-limited.
    // For production, use your production WS URL and add
    // { headers: { "x-api-key": "YOUR_API_KEY" } } as the second arg to new WebSocket().
    const WS_URL = "wss://dev-quote-api.dflow.net/book-stream";

    const SOL = "So11111111111111111111111111111111111111112";
    const USDC = "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v";

    const ws = new WebSocket(WS_URL);

    ws.onopen = () => {
      ws.send(JSON.stringify({ op: "subscribe", base_mint: SOL, quote_mint: USDC }));
    };

    ws.onmessage = (event) => {
      const frame = JSON.parse(event.data);
      for (const book of frame.updates ?? []) {
        if (book.e) {
          console.log(`${book.sb} / ${book.sq}: ${book.e}`);
          continue;
        }
        console.log(`slot ${frame.u}  mid ${book.mid}`);
        console.log("top ask:", book.a[0]);
        console.log("top bid:", book.b[0]);
      }
    };

    ws.onerror = (error) => console.error("WebSocket error:", error);
    ws.onclose = () => console.log("WebSocket connection closed");
    ```
  </Accordion>

  <Accordion title="TypeScript Interface">
    ```typescript theme={null}
    interface BookLevel {
      price: number;
      cumulative_size_human: number; // cumulative base size from spot to this level
    }

    interface BookUpdate {
      sb: string; // base mint
      sq: string; // quote mint
      mid?: number;
      tick?: number;
      crossed?: boolean;
      b?: BookLevel[]; // 10 bid levels
      a?: BookLevel[]; // 10 ask levels
      e?: string; // per-pair error code
    }

    interface BookFrame {
      u: number; // slot
      ts: number; // unix seconds
      skipped?: number; // slots skipped under load
      updates?: BookUpdate[];
      subscribe?: { sb: string; sq: string }[];
      unsubscribe?: { sb: string; sq: string }[];
    }
    ```
  </Accordion>
</AccordionGroup>

## Related

<CardGroup>
  <Card title="Quote Stream" href="quote-stream" icon="signal-stream">
    Stream top-of-book bid and ask
  </Card>

  <Card title="Market Data Streams" href="/spot/trading/market-data-streams" icon="layer-group">
    How the streams work and when to use each
  </Card>

  <Card title="Websockets Overview" href="/resources/trading-api/websockets/overview" icon="plug">
    Connection details for Trading API streams
  </Card>

  <Card title="Stream Order Book Depth" href="/spot/recipes/stream-order-book" icon="code">
    Recipe: connect, subscribe, and render depth
  </Card>
</CardGroup>


# Websockets Overview
Source: https://pond.dflow.net/resources/trading-api/websockets/overview

Stream real-time Trading API updates via WebSocket

The Trading API serves three WebSocket streams: live quotes, order book depth,
and priority fee estimates.

## Connection

Find the WebSocket base URL on the [Endpoints](/get-started/endpoints) page, then append a stream path from the table below.

## Streams

Each stream is a path on the Trade API WebSocket host:

| Stream        | Path                    | Description                             |
| ------------- | ----------------------- | --------------------------------------- |
| Quote stream  | `/quote-stream`         | Top-of-book bid and ask for token pairs |
| Book stream   | `/book-stream`          | Ten levels of order book depth          |
| Priority fees | `/priority-fees/stream` | Real-time priority fee estimates        |

<CardGroup>
  <Card title="Quote Stream" href="quote-stream" icon="signal-stream">
    Stream top-of-book bid and ask for token pairs
  </Card>

  <Card title="Book Stream" href="book-stream" icon="layer-group">
    Stream ten levels of order book depth
  </Card>

  <Card title="Priority Fees Stream" href="priority-fees-stream" icon="bolt">
    Stream priority fee estimates without polling
  </Card>
</CardGroup>


# Priority Fees Stream
Source: https://pond.dflow.net/resources/trading-api/websockets/priority-fees-stream

Stream Trading API priority fee estimates over WebSocket

Use this stream to receive real-time priority fee estimate updates.

<Info>
  No subscribe message is required. Connect to the endpoint and start reading
  messages.
</Info>

## Connection

See the [Websockets Overview](/resources/trading-api/websockets/overview#connection)
for endpoint details.

## Message Format

Each message is a JSON object with the same shape as
[`GET /priority-fees`](/resources/trading-api/priority-fees/priority-fees):

```json theme={null}
{
  "mediumMicroLamports": 100000,
  "highMicroLamports": 150000,
  "veryHighMicroLamports": 220000
}
```

## Example (TypeScript)

```typescript theme={null}
import WebSocket from "ws";

const WS_URL = "wss://dev-quote-api.dflow.net/priority-fees/stream";
const ws = new WebSocket(WS_URL);

ws.onopen = () => {
  console.log("Connected — waiting for priority fee updates");
};

ws.onmessage = (event) => {
  const fees = JSON.parse(event.data.toString());
  console.log("Priority fees (micro-lamports/CU):", fees);
};
```

## Related

* [Websockets Overview](/resources/trading-api/websockets/overview)
* [GET /priority-fees](/resources/trading-api/priority-fees/priority-fees)


# Quote Stream
Source: https://pond.dflow.net/resources/trading-api/websockets/quote-stream

Stream live bid/ask quotes for token pairs over WebSocket

The `quote-stream` endpoint streams a live bid and ask for a pair of token mints.
See [Market Data Streams](/spot/trading/market-data-streams) for what the quotes
mean and when to use the stream; this page documents the message format.

<Info>
  Quotes are **approximations** across **direct and one-hop** routes, computed
  from a \$10 USDC equivalent round-trip trade. They can differ from the quote you
  receive at order time.
</Info>

<Note>
  Access to the quote stream is gated. Reach out to the team to request access.
</Note>

## Connection

See the [Websockets Overview](/resources/trading-api/websockets/overview#connection)
for endpoint details.

## Subscribe

Send a `subscribe` op with the base and quote mints:

```json theme={null}
{
  "op": "subscribe",
  "base_mint": "So11111111111111111111111111111111111111112",
  "quote_mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"
}
```

## Unsubscribe

```json theme={null}
{
  "op": "unsubscribe",
  "base_mint": "So11111111111111111111111111111111111111112",
  "quote_mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"
}
```

## Message Format

Each message is a batch covering one slot:

```json theme={null}
{
  "u": 425218378,
  "ts": 1780964565,
  "subscribe": [
    {
      "sb": "So11111111111111111111111111111111111111112",
      "sq": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
      "auto": false
    }
  ],
  "updates": [
    {
      "sb": "So11111111111111111111111111111111111111112",
      "sq": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
      "b": "66.46416041",
      "B": "9.99791400",
      "a": "66.46410253",
      "A": "9.99791400"
    }
  ]
}
```

### Fields

| Field                       | Type   | Description                              |
| --------------------------- | ------ | ---------------------------------------- |
| `u`                         | number | Slot the quotes were computed at         |
| `ts`                        | number | Unix timestamp in seconds                |
| `updates`                   | array  | Per-pair quote updates for this slot     |
| `subscribe` / `unsubscribe` | array  | Acknowledgements of subscription changes |

Each entry in `updates` has:

| Field | Type   | Description                                                                                         |
| ----- | ------ | --------------------------------------------------------------------------------------------------- |
| `sb`  | string | Base mint                                                                                           |
| `sq`  | string | Quote mint                                                                                          |
| `b`   | string | Bid price, quote per base, 8 decimals                                                               |
| `a`   | string | Ask price, quote per base, 8 decimals                                                               |
| `B`   | string | Bid size, quote-denominated (\$10 USDC equivalent)                                                  |
| `A`   | string | Ask size, quote-denominated                                                                         |
| `e`   | string | Per-pair error code (for example `no_route`), present instead of prices when a quote is unavailable |

## Code Examples

<AccordionGroup>
  <Accordion title="Subscribe to a Pair">
    ```typescript theme={null}
    // Dev endpoint — no API key required, but rate-limited.
    // For production, use your production WS URL and add
    // { headers: { "x-api-key": "YOUR_API_KEY" } } as the second arg to new WebSocket().
    const WS_URL = "wss://dev-quote-api.dflow.net/quote-stream";

    const SOL = "So11111111111111111111111111111111111111112";
    const USDC = "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v";

    const ws = new WebSocket(WS_URL);

    ws.onopen = () => {
      ws.send(JSON.stringify({ op: "subscribe", base_mint: SOL, quote_mint: USDC }));
    };

    ws.onmessage = (event) => {
      const frame = JSON.parse(event.data);
      for (const u of frame.updates ?? []) {
        if (u.e) {
          console.log(`${u.sb} / ${u.sq}: ${u.e}`);
          continue;
        }
        console.log(`slot ${frame.u}  bid ${u.b}  ask ${u.a}`);
      }
    };

    ws.onerror = (error) => console.error("WebSocket error:", error);
    ws.onclose = () => console.log("WebSocket connection closed");
    ```
  </Accordion>

  <Accordion title="TypeScript Interface">
    ```typescript theme={null}
    interface QuoteUpdate {
      sb: string; // base mint
      sq: string; // quote mint
      b?: string; // bid, quote per base
      a?: string; // ask, quote per base
      B?: string; // bid size, quote-denominated
      A?: string; // ask size, quote-denominated
      e?: string; // per-pair error code
    }

    interface QuoteFrame {
      u: number; // slot
      ts: number; // unix seconds
      updates?: QuoteUpdate[];
      subscribe?: { sb: string; sq: string; auto: boolean }[];
      unsubscribe?: { sb: string; sq: string; auto: boolean }[];
    }
    ```
  </Accordion>
</AccordionGroup>

## Related

<CardGroup>
  <Card title="Book Stream" href="book-stream" icon="layer-group">
    Stream 10 levels of order book depth
  </Card>

  <Card title="Market Data Streams" href="/spot/trading/market-data-streams" icon="signal-stream">
    How the streams work and when to use each
  </Card>

  <Card title="Websockets Overview" href="/resources/trading-api/websockets/overview" icon="plug">
    Connection details for Trading API streams
  </Card>

  <Card title="Stream Top-of-Book Quotes" href="/spot/recipes/stream-quotes" icon="code">
    Recipe: connect, subscribe, and read quotes
  </Card>
</CardGroup>


# Spot Trading
Source: https://pond.dflow.net/spot/introduction

How spot trading on DFlow works: request an order, sign, submit

Swap any SPL token on Solana through the Trading API.

DFlow charges **no protocol fee** on spot trades, and you can add your own [platform fee](/spot/trading/platform-fees) on top. Spot trades are imperative: your app sends the trade parameters to DFlow, and DFlow returns a fully constructed transaction for you to sign and submit.

## Features

* **[Best execution](/spot/jit-routing)**: JIT routing re-optimizes your route at execution time, so you get the best available price even as liquidity shifts.
* **[Live market data](/spot/trading/market-data-streams)**: The quote stream pushes top-of-book prices, and the book stream pushes ten levels of depth. Use them to build live tickers and order books without polling.
* **[Gasless swaps](/spot/trading/sponsored-swaps)**: Your app can sponsor users' transaction fees, so they trade without holding SOL for gas.
* **Composable transactions**: Each call to the order endpoint returns a transaction, so you can bundle it with your own instructions and run them atomically.
* **Fine-grained control**: Optional parameters cover [slippage](/spot/trading/slippage-tolerance), [priority fees](/spot/trading/priority-fees), and [venue restrictions](/spot/liquidity-venues), so you decide how each order routes and lands.

## How it works

```mermaid theme={null}
flowchart LR
  A[Request /order] --> B[Sign transaction]
  B --> C[Submit to RPC]
  C --> D[Confirm status]
```

1. The app requests an order from the [`/order`](/resources/trading-api/order/order) endpoint with input mint, output mint, and amount, plus optional parameters like slippage, platform fees, priority fees, and venue restriction.
2. The user signs the returned transaction.
3. The app submits it to a Solana RPC and confirms status.

<Note>
  DFlow also offers an **intent-based declarative** trade flow via [`GET /intent`](/resources/trading-api/declarative/quote) for stronger sandwich protection. The majority of builders stay on `/order`; `/intent` is the opt-in for apps where sandwich exposure matters more than transaction composability. Token-2022 mints are not supported on `/intent`.
</Note>


# JIT Routing
Source: https://pond.dflow.net/spot/jit-routing

How JIT routing updates trade execution onchain

JIT Routing (Just-in-Time Routing) re-optimizes a trade's route at execution time, so the fill reflects current onchain prices instead of a stale quote.

Some onchain venues, especially prop AMMs (proprietary automated market makers), update their prices fast enough that the route DFlow picks at quote time can be outdated by the time the transaction lands. JIT routing closes that gap by moving the routing decision onchain.

## Why static routing struggles

* Routes are computed offchain and locked into the transaction at quote time.
* Prop AMM prices can move between signing and execution.
* The trade either fills at a worse price or fails on slippage.

## How JIT routing works

1. **Quote time.** DFlow computes an initial route from current market data and embeds it in a transaction built so the route can be updated onchain.
2. **Execution time.** JIT routing re-checks prop AMM prices just before executing each leg onchain. If a better path exists, it reroutes inside the same transaction.

## When JIT routing engages

No builder configuration or extra parameters required. JIT routing engages when both of the following are true:

* The trade goes through the Trading API ([`/order`](/resources/trading-api/order/order) or [`/quote`](/resources/trading-api/imperative/quote)).
* The route includes a prop AMM leg. Routes without one execute as static paths.

## What builders get

* **Lower realized slippage.** Trades fill against current onchain prices, not stale quotes.
* **Higher success rates.** Fewer transactions fail because the market moved between signing and execution.
* **Tighter slippage limits.** Less need for wide buffers to absorb pre-execution drift.


# Liquidity and Venues
Source: https://pond.dflow.net/spot/liquidity-venues

How DFlow routes liquidity across venues

DFlow sources liquidity through multiple venues on Solana.

This includes onchain AMMs, Prop AMMs, order-book-style venues, and other onchain venues. DFlow treats these venues as interchangeable sources of liquidity and exposes them through a single execution interface. DFlow uses reliable DEXs like Raydium, Orca, Meteora, Pump.fun and many more.

For users, this typically results in **better realized prices** than routing through a single venue or a fixed path.

For builders, this means better execution quality without hard-coding venue logic or price comparisons.

A full list of venues is available from the  [Venues API Endpoint](/resources/trading-api/venues/venues).


# Add Platform Fees
Source: https://pond.dflow.net/spot/recipes/platform-fees

How to implement platform fees with the DFlow Trading API

<Info>
  During development, you can use the [developer endpoints](/get-started/endpoints) without an API key. For production use, you'll need an [API key](/get-started/api-key) to avoid rate limits.
</Info>

<Steps>
  <Step title="Set up">
    Imports, env config, and the wallet used across every step.

    <AccordionGroup>
      <Accordion title="Imports, env, and wallet">
        ```typescript theme={null}
        import "dotenv/config";

        import { Keypair } from "@solana/web3.js";
        import bs58 from "bs58";

        const DFLOW_TRADE_API_URL = process.env.DFLOW_TRADE_API_URL ?? "https://dev-quote-api.dflow.net";
        const DFLOW_API_KEY = process.env.DFLOW_API_KEY; // optional; not needed for dev endpoints
        const DFLOW_SETTLEMENT_MINT = process.env.DFLOW_SETTLEMENT_MINT ?? "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"; // USDC

        const SOL_MINT = "So11111111111111111111111111111111111111112";

        const keypair = Keypair.fromSecretKey(
          bs58.decode(process.env.SOLANA_PRIVATE_KEY ?? "")
        );

        const headers: HeadersInit = {};
        if (DFLOW_API_KEY) headers["x-api-key"] = DFLOW_API_KEY;
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Fixed Fees with platformFeeBps">
    Use [`platformFeeBps`](/resources/trading-api/order/order#parameter-platform-fee-bps) to specify a fixed fee in basis points. Control which token the fee is collected from using [`platformFeeMode`](/resources/trading-api/order/order#parameter-platform-fee-mode).

    <AccordionGroup>
      <Accordion title="Basic Example">
        ```typescript theme={null}
        const queryParams = new URLSearchParams();
        queryParams.append("inputMint", SOL_MINT);
        queryParams.append("outputMint", DFLOW_SETTLEMENT_MINT);
        queryParams.append("amount", "1000000000");
        queryParams.append("platformFeeBps", "50"); // 0.5% fee
        queryParams.append("platformFeeMode", "outputMint"); // Collect from output (USDC)
        queryParams.append("feeAccount", "YourUSDCTokenAccountAddress");
        queryParams.append("userPublicKey", keypair.publicKey.toBase58());

        const orderResponse = await fetch(
          `${DFLOW_TRADE_API_URL}/order?${queryParams.toString()}`,
          { headers }
        ).then((x) => x.json());
        ```
      </Accordion>

      <Accordion title="Collect Fee from Input Mint">
        ```typescript theme={null}
        /// To collect fee from input mint instead, override the values from above with `.set()` (not `.append()`):
        queryParams.set("platformFeeMode", "inputMint");
        queryParams.set("feeAccount", "YourSOLTokenAccountAddress"); // Must match input mint
        ```
      </Accordion>

      <Accordion title="Other Endpoints">
        ```typescript theme={null}
        /// For /quote endpoint (imperative swaps)
        const quoteResponse = await fetch(
          `${DFLOW_TRADE_API_URL}/quote?${queryParams.toString()}`,
          { headers }
        ).then((x) => x.json());

        /// For /intent endpoint (declarative swaps)
        const intentResponse = await fetch(
          `${DFLOW_TRADE_API_URL}/intent?${queryParams.toString()}`,
          { headers }
        ).then((x) => x.json());
        ```
      </Accordion>
    </AccordionGroup>

    <Note>
      `feeAccount` is required. It must be a token account for the mint you're collecting the fee in (input or output, per `platformFeeMode`) and must already exist before the trade executes.
    </Note>
  </Step>

  <Step title="Check Fee in Response">
    Both `/order` and `/quote` responses include `platformFee` information.

    <AccordionGroup>
      <Accordion title="Reading Platform Fee from Response">
        ```typescript theme={null}
        // Reuses the `orderResponse` from the request step above.
        if (orderResponse.platformFee) {
          console.log("Platform fee details:", {
            amount: orderResponse.platformFee.amount,
            feeBps: orderResponse.platformFee.feeBps,
            feeAccount: orderResponse.platformFee.feeAccount,
          });
        }
        ```
      </Accordion>
    </AccordionGroup>
  </Step>
</Steps>

## Related Resources

<CardGroup>
  <Card title="Platform Fees" href="/spot/trading/platform-fees" icon="percent">
    How platform fees work, fee modes, and accepted denominations.
  </Card>

  <Card title="Send Orders" href="/spot/recipes/quickstart" icon="rocket">
    Send a spot order end-to-end.
  </Card>

  <Card title="Add Priority Fees" href="/spot/recipes/priority-fees" icon="bolt">
    Control execution speed with priority fees.
  </Card>

  <Card title="Authenticate Requests" href="/resources/recipes/api-keys" icon="key">
    Authenticate requests for production rate limits.
  </Card>
</CardGroup>

## API Routes

* [GET /order](/resources/trading-api/order/order)
* [GET /quote](/resources/trading-api/imperative/quote)
* [GET /intent](/resources/trading-api/declarative/quote)


# Add Priority Fees
Source: https://pond.dflow.net/spot/recipes/priority-fees

How to set priority fees for Trading API requests

<Info>
  During development, you can use the [developer endpoints](/get-started/endpoints) without
  an API key. For production use, you'll need an [API key](/get-started/api-key) to avoid
  rate limits.
</Info>

Priority fees only affect **when** a trade executes. They do not change routing,
slippage checks, or trade semantics ([what priority fees do not affect](/spot/trading/priority-fees#what-priority-fees-do-not-affect)).

[How DFlow handles priority fees](/spot/trading/priority-fees#how-dflow-handles-priority-fees) details the two modes.

<Steps>
  <Step title="Set up">
    Imports, env config, and the constants used across every step.

    <AccordionGroup>
      <Accordion title="Imports, env, and constants">
        ```typescript theme={null}
        import "dotenv/config";

        import { Keypair } from "@solana/web3.js";
        import bs58 from "bs58";

        const DFLOW_TRADE_API_URL = process.env.DFLOW_TRADE_API_URL ?? "https://dev-quote-api.dflow.net";
        const DFLOW_API_KEY = process.env.DFLOW_API_KEY; // optional; not needed for dev endpoints
        const DFLOW_SETTLEMENT_MINT = process.env.DFLOW_SETTLEMENT_MINT ?? "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"; // USDC

        const SOL_MINT = "So11111111111111111111111111111111111111112";
        const amount = 1_000_000; // 0.001 SOL

        const keypair = Keypair.fromSecretKey(
          bs58.decode(process.env.SOLANA_PRIVATE_KEY ?? "")
        );

        const headers: HeadersInit = {};
        if (DFLOW_API_KEY) headers["x-api-key"] = DFLOW_API_KEY;
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Choose your priority fee mode">
    Use [max priority fee](/spot/trading/priority-fees#max-priority-fee) for adaptive speed
    (server selects a fee up to your cap), or [exact priority fee](/spot/trading/priority-fees#exact-priority-fee)
    when you need predictable costs.
  </Step>

  <Step title="Apply priority fees to your request">
    <Tabs>
      <Tab title="Imperative (Order)">
        Set `prioritizationFeeLamports` on the `/order` request as either a lamport
        value or one of `auto`, `medium`, `high`, `veryHigh`, `disabled`.

        <AccordionGroup>
          <Accordion title="Max Priority Fee (auto/level)">
            ```typescript theme={null}
            const maxParams = new URLSearchParams();
            maxParams.append("inputMint", SOL_MINT);
            maxParams.append("outputMint", DFLOW_SETTLEMENT_MINT);
            maxParams.append("amount", amount.toString());
            maxParams.append("userPublicKey", keypair.publicKey.toBase58());
            maxParams.append("slippageBps", "50");

            // Adaptive fee chosen by the server.
            maxParams.append("prioritizationFeeLamports", "high");
            // Or use automatic selection:
            // maxParams.append("prioritizationFeeLamports", "auto");

            const maxOrderResponse = await fetch(
              `${DFLOW_TRADE_API_URL}/order?${maxParams.toString()}`,
              { headers }
            ).then((x) => x.json());
            ```
          </Accordion>

          <Accordion title="Exact Priority Fee (lamports)">
            ```typescript theme={null}
            const exactParams = new URLSearchParams();
            exactParams.append("inputMint", SOL_MINT);
            exactParams.append("outputMint", DFLOW_SETTLEMENT_MINT);
            exactParams.append("amount", amount.toString());
            exactParams.append("userPublicKey", keypair.publicKey.toBase58());
            exactParams.append("slippageBps", "50");

            // Fixed priority fee in lamports.
            exactParams.append("prioritizationFeeLamports", "20000");

            const exactOrderResponse = await fetch(
              `${DFLOW_TRADE_API_URL}/order?${exactParams.toString()}`,
              { headers }
            ).then((x) => x.json());
            ```
          </Accordion>
        </AccordionGroup>
      </Tab>

      <Tab title="Declarative (Intent)">
        For intents, set `feeBudget` on the `/intent` request to your desired
        priority fee plus the 10,000 lamport base processing fee.

        <AccordionGroup>
          <Accordion title="Exact Priority Fee (feeBudget)">
            ```typescript theme={null}
            const desiredPriorityFeeLamports = 20_000;
            const baseProcessingFeeLamports = 10_000;
            const feeBudget = desiredPriorityFeeLamports + baseProcessingFeeLamports;

            const intentParams = new URLSearchParams();
            intentParams.append("inputMint", SOL_MINT);
            intentParams.append("outputMint", DFLOW_SETTLEMENT_MINT);
            intentParams.append("amount", amount.toString());
            intentParams.append("userPublicKey", keypair.publicKey.toBase58());
            intentParams.append("slippageBps", "50");
            intentParams.append("feeBudget", feeBudget.toString());

            const intentResponse = await fetch(
              `${DFLOW_TRADE_API_URL}/intent?${intentParams.toString()}`,
              { headers }
            ).then((x) => x.json());
            ```
          </Accordion>
        </AccordionGroup>
      </Tab>
    </Tabs>
  </Step>
</Steps>

## Related Resources

<CardGroup>
  <Card title="Priority Fees" href="/spot/trading/priority-fees" icon="bolt">
    How priority fees and the fee budget work, and when to use each mode.
  </Card>

  <Card title="Send Orders" href="/spot/recipes/quickstart" icon="rocket">
    Send a spot order end-to-end.
  </Card>

  <Card title="Add Platform Fees" href="/spot/recipes/platform-fees" icon="percent">
    Monetize trades with builder fees.
  </Card>

  <Card title="Authenticate Requests" href="/resources/recipes/api-keys" icon="key">
    Authenticate requests for production rate limits.
  </Card>
</CardGroup>

## API Routes

* [GET /order](/resources/trading-api/order/order)
* [GET /intent](/resources/trading-api/declarative/quote)
* [POST /submit-intent](/resources/trading-api/declarative/submit)


# Send Orders
Source: https://pond.dflow.net/spot/recipes/quickstart

Send a spot order with the DFlow Trading API: request, sign, and submit

<Info>
  During development, you can use the [developer endpoints](/get-started/endpoints) without an API key. For production use, [request an API key](/get-started/api-key) for higher rate limits.
</Info>

This recipe sends a SOL → USDC order on DFlow: request an order, sign the returned transaction, and submit it through your RPC.

```mermaid theme={null}
flowchart LR
  A[Request /order] --> B[Sign transaction]
  B --> C[Submit to RPC]
```

<Steps>
  <Step title="Set up">
    Imports, env config, and the wallet/connection used across every step.

    <AccordionGroup>
      <Accordion title="Imports, env, and wallet">
        ```typescript theme={null}
        import "dotenv/config";

        import {
          Connection,
          Keypair,
          VersionedTransaction,
        } from "@solana/web3.js";
        import bs58 from "bs58";

        const DFLOW_TRADE_API_URL = process.env.DFLOW_TRADE_API_URL ?? "https://dev-quote-api.dflow.net";
        const DFLOW_API_KEY = process.env.DFLOW_API_KEY; // optional; not needed for dev endpoints
        const DFLOW_SETTLEMENT_MINT = process.env.DFLOW_SETTLEMENT_MINT ?? "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"; // USDC
        const SOLANA_RPC_URL = process.env.SOLANA_RPC_URL ?? "https://api.mainnet-beta.solana.com";

        const SOL_MINT = "So11111111111111111111111111111111111111112";
        const AMOUNT = 10_000_000; // 0.01 SOL (9 decimals)
        const SLIPPAGE_BPS = 50; // 0.5%

        const connection = new Connection(SOLANA_RPC_URL, "confirmed");
        const keypair = Keypair.fromSecretKey(
          bs58.decode(process.env.SOLANA_PRIVATE_KEY ?? "")
        );

        const headers: HeadersInit = {};
        if (DFLOW_API_KEY) headers["x-api-key"] = DFLOW_API_KEY;
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Request an order">
    [`GET /order`](/resources/trading-api/order/order) returns a quote and a base64-encoded transaction in one call. Pass `userPublicKey` so DFlow can construct the transaction for you to sign.

    <AccordionGroup>
      <Accordion title="Request an order">
        ```typescript theme={null}
        const params = new URLSearchParams({
          inputMint: SOL_MINT,
          outputMint: DFLOW_SETTLEMENT_MINT,
          amount: AMOUNT.toString(),
          slippageBps: SLIPPAGE_BPS.toString(),
          userPublicKey: keypair.publicKey.toBase58(),
        });

        const orderResponse = await fetch(
          `${DFLOW_TRADE_API_URL}/order?${params}`,
          { headers }
        ).then((r) => r.json());
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Sign and submit">
    Deserialize the returned transaction, sign it with the user's keypair, and submit it through your RPC.

    <AccordionGroup>
      <Accordion title="Sign and submit">
        ```typescript theme={null}
        const tx = VersionedTransaction.deserialize(
          Buffer.from(orderResponse.transaction, "base64")
        );
        tx.sign([keypair]);

        const signature = await connection.sendTransaction(tx);
        const explorerUrl = `https://orbmarkets.io/tx/${signature}`;

        const { value } = await connection.confirmTransaction(signature, "confirmed");

        if (value.err) {
          console.log(`Failed: ${JSON.stringify(value.err)}`);
        } else {
          console.log("Success: trade landed");
        }
        console.log(`  Tx: ${explorerUrl}`);
        ```
      </Accordion>
    </AccordionGroup>
  </Step>
</Steps>

## Related Resources

<CardGroup>
  <Card title="Spot Trading" href="/spot/introduction" icon="arrow-right-arrow-left">
    How spot trading works on DFlow, and when the intent-based path makes sense.
  </Card>

  <Card title="Add Platform Fees" href="/spot/recipes/platform-fees" icon="percent">
    Monetize trades with builder fees.
  </Card>

  <Card title="Add Priority Fees" href="/spot/recipes/priority-fees" icon="bolt">
    Control execution speed with priority fees.
  </Card>

  <Card title="Authenticate Requests" href="/resources/recipes/api-keys" icon="key">
    Authenticate requests for production rate limits.
  </Card>
</CardGroup>

## API Routes

* [`GET /order`](/resources/trading-api/order/order)


# Stream Order Book Depth
Source: https://pond.dflow.net/spot/recipes/stream-order-book

Connect to the book stream and read ten levels of order book depth

<Info>
  During development, the [developer endpoints](/get-started/endpoints) work without an API key. Access to the book stream in production is gated: [request an API key](/get-started/api-key) with book stream access, or have an existing key upgraded.
</Info>

This recipe connects to the [book stream](/resources/trading-api/websockets/book-stream) and reads ten levels of order book depth per side for a single pair. See [Market Data Streams](/spot/trading/market-data-streams) for how the book is built.

<Steps>
  <Step title="Set up">
    Import a WebSocket client, read the endpoint from the environment, and pick the pair to watch.

    <AccordionGroup>
      <Accordion title="Imports and config">
        ```typescript theme={null}
        import "dotenv/config";
        import WebSocket from "ws";

        const DFLOW_TRADE_API_WS_URL =
          process.env.DFLOW_TRADE_API_WS_URL ?? "wss://dev-quote-api.dflow.net";
        const DFLOW_API_KEY = process.env.DFLOW_API_KEY; // optional; not needed for dev

        const SOL_MINT = "So11111111111111111111111111111111111111112";
        const USDC_MINT = "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v";
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Connect and subscribe">
    Open the connection to `/book-stream` and send a `subscribe` op once it is open. The book stream covers direct routes only.

    <AccordionGroup>
      <Accordion title="Connect and subscribe">
        ```typescript theme={null}
        const ws = new WebSocket(
          `${DFLOW_TRADE_API_WS_URL}/book-stream`,
          DFLOW_API_KEY ? { headers: { "x-api-key": DFLOW_API_KEY } } : undefined
        );

        ws.on("open", () => {
          ws.send(
            JSON.stringify({ op: "subscribe", base_mint: SOL_MINT, quote_mint: USDC_MINT })
          );
        });
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Render the book">
    Each update carries `mid`, `tick`, and ten levels per side. `b` and `a` are arrays of `{ price, cumulative_size_human }`, ordered nearest to spot outward, where the size is cumulative base from the spot to that level.

    <AccordionGroup>
      <Accordion title="Handle messages">
        ```typescript theme={null}
        ws.on("message", (data) => {
          const frame = JSON.parse(data.toString());
          for (const book of frame.updates ?? []) {
            if (book.e) {
              console.log(`${book.sb} / ${book.sq}: ${book.e}`);
              continue;
            }
            console.log(`\nslot ${frame.u}  mid ${book.mid}  tick ${book.tick}`);
            console.log("asks (low to high):");
            for (const level of [...book.a].reverse()) {
              console.log(`  ${level.price}\t${level.cumulative_size_human}`);
            }
            console.log("bids (high to low):");
            for (const level of book.b) {
              console.log(`  ${level.price}\t${level.cumulative_size_human}`);
            }
          }
        });

        ws.on("error", (err) => console.error("WebSocket error:", err));
        ws.on("close", () => console.log("Connection closed"));

        // demo only: stop after the first updates
        setTimeout(() => ws.close(), 6000);
        ```
      </Accordion>
    </AccordionGroup>
  </Step>
</Steps>

<Note>
  Book levels are approximations computed at runtime. The `cumulative_size_human`
  at each level is the total base size available from the spot out to that price.
</Note>

## Related Resources

<CardGroup>
  <Card title="Market Data Streams" href="/spot/trading/market-data-streams" icon="signal-stream">
    How the streams work and when to use each.
  </Card>

  <Card title="Book Stream API" href="/resources/trading-api/websockets/book-stream" icon="plug">
    Messages, fields, and the depth format.
  </Card>

  <Card title="Stream Top-of-Book Quotes" href="/spot/recipes/stream-quotes" icon="signal-stream">
    Read live bid and ask for a pair.
  </Card>

  <Card title="Authenticate Requests" href="/resources/recipes/api-keys" icon="key">
    Authenticate requests for production rate limits.
  </Card>
</CardGroup>


# Stream Top-of-Book Quotes
Source: https://pond.dflow.net/spot/recipes/stream-quotes

Connect to the quote stream and read live bid/ask updates for a token pair

<Info>
  During development, the [developer endpoints](/get-started/endpoints) work without an API key. Access to the quote stream in production is gated: [request an API key](/get-started/api-key) with quote stream access, or have an existing key upgraded.
</Info>

This recipe connects to the [quote stream](/resources/trading-api/websockets/quote-stream) and reads live bid and ask updates for a single pair. See [Market Data Streams](/spot/trading/market-data-streams) for how the quotes are built.

<Steps>
  <Step title="Set up">
    Import a WebSocket client, read the endpoint from the environment, and pick the pair to watch.

    <AccordionGroup>
      <Accordion title="Imports and config">
        ```typescript theme={null}
        import "dotenv/config";
        import WebSocket from "ws";

        const DFLOW_TRADE_API_WS_URL =
          process.env.DFLOW_TRADE_API_WS_URL ?? "wss://dev-quote-api.dflow.net";
        const DFLOW_API_KEY = process.env.DFLOW_API_KEY; // optional; not needed for dev

        const SOL_MINT = "So11111111111111111111111111111111111111112";
        const USDC_MINT = "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v";
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Connect and subscribe">
    Open the connection to `/quote-stream` and send a `subscribe` op once it is open. The API key header is only needed in production.

    <AccordionGroup>
      <Accordion title="Connect and subscribe">
        ```typescript theme={null}
        const ws = new WebSocket(
          `${DFLOW_TRADE_API_WS_URL}/quote-stream`,
          DFLOW_API_KEY ? { headers: { "x-api-key": DFLOW_API_KEY } } : undefined
        );

        ws.on("open", () => {
          ws.send(
            JSON.stringify({ op: "subscribe", base_mint: SOL_MINT, quote_mint: USDC_MINT })
          );
        });
        ```
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="Read updates">
    Each message is a batch covering one slot. Read the `updates` array, and handle the per-pair `e` field for pairs with no route.

    <AccordionGroup>
      <Accordion title="Handle messages">
        ```typescript theme={null}
        ws.on("message", (data) => {
          const frame = JSON.parse(data.toString());
          for (const u of frame.updates ?? []) {
            if (u.e) {
              console.log(`${u.sb} / ${u.sq}: ${u.e}`);
              continue;
            }
            console.log(`slot ${frame.u}  bid ${u.b}  ask ${u.a}`);
          }
        });

        ws.on("error", (err) => console.error("WebSocket error:", err));
        ws.on("close", () => console.log("Connection closed"));

        // demo only: stop after a few seconds
        setTimeout(() => ws.close(), 4000);
        ```
      </Accordion>
    </AccordionGroup>
  </Step>
</Steps>

<Note>
  Quotes are approximations and can briefly cross (bid above ask) between slots.
  Treat them as a live read on the market, not a guaranteed execution price.
</Note>

## Related Resources

<CardGroup>
  <Card title="Market Data Streams" href="/spot/trading/market-data-streams" icon="signal-stream">
    How the streams work and when to use each.
  </Card>

  <Card title="Quote Stream API" href="/resources/trading-api/websockets/quote-stream" icon="plug">
    Messages, fields, and the all-markets subscription.
  </Card>

  <Card title="Stream Order Book Depth" href="/spot/recipes/stream-order-book" icon="layer-group">
    Read ten levels of depth per side.
  </Card>

  <Card title="Authenticate Requests" href="/resources/recipes/api-keys" icon="key">
    Authenticate requests for production rate limits.
  </Card>
</CardGroup>


# Market Data Streams
Source: https://pond.dflow.net/spot/trading/market-data-streams

Stream live top-of-book quotes and order book depth over WebSocket

DFlow serves live market data over two WebSocket streams on the Trading API.
Subscribe to the pairs you want and read updates each slot.

| Stream       | What you get                 | Coverage                  | Endpoint        |
| ------------ | ---------------------------- | ------------------------- | --------------- |
| Quote stream | Top-of-book bid and ask      | Direct and one-hop routes | `/quote-stream` |
| Book stream  | Ten levels of depth per side | Direct routes only        | `/book-stream`  |

See [Endpoints](/get-started/endpoints) for the WebSocket URLs and access details.

## Connecting

As a security best practice, keep your DFlow API key on the backend, not in browser code where anyone can read it. Stream through a backend proxy that holds the key, connects to DFlow, and relays messages to the browser.

In production, access to the quote and book streams is granted per API key: a key that works for `/order` is not automatically allowed on the streams. Reach out to the team to request stream access on your key.

## Quote Stream

The quote stream returns a live bid and ask for any pair of token mints, across
direct and one-hop routes. New quotes stream out as the underlying liquidity
moves, so you read prices as they change without polling.

DFlow builds each quote by routing a \$10 USDC equivalent trade through the best
path in each direction, so the bid and ask are the rates that trade would
execute at.

For the full message format and parameters, see the [Quote Stream API](/resources/trading-api/websockets/quote-stream). The [Stream Top-of-Book Quotes recipe](/spot/recipes/stream-quotes) shows how to connect and read updates in code.

## Book Stream

The book stream gives you ten levels of order book depth per side, with the mid
price and tick size. Levels are cumulative from the spot outward, so each level
carries the total size available up to that price. The book stream covers direct
routes only.

For the full message format and parameters, see the [Book Stream API](/resources/trading-api/websockets/book-stream). The [Stream Order Book Depth recipe](/spot/recipes/stream-order-book) shows how to connect and render depth in code.

## Accuracy

Quotes and book levels are approximations. DFlow computes them at runtime from current routes, so they may differ from the quote you receive at order time. Treat them as a live read on the market, not a guaranteed execution price.

## Choosing a Stream

Use the **quote stream** for price displays, pre-trade pricing, and watching
many pairs at once. Use the **book stream**
when you need depth: order book visualizations, depth charts, and sizing larger
trades against available liquidity.


# Platform Fees
Source: https://pond.dflow.net/spot/trading/platform-fees

How to apply platform fees to trades

<Info>
  DFlow charges no protocol fee on spot trades. The platform fee described here is the fee builders can set on their own integration.
</Info>

Use platform fees to monetize DFlow integrations by collecting fees on trades executed through applications. Add platform fees by setting fee parameters on [Trade API requests](/resources/trading-api/order/order).

Users pay platform fees only when a trade completes successfully. Platform fees do not affect quoting, routing, slippage checks, or execution behavior.

When a trade completes, the platform fee is transferred to a builder-controlled fee account.

From a user’s perspective:

* Fees apply only on successful trades.
* Fees change net proceeds, not execution.

## Fee Models

Builders choose one of two fee models.

### Fixed Platform Fees

Charge a fixed percentage of the trade amount.

* Fees are specified in basis points (bps).
* 1 bps = 0.01%.
* Example: `platformFeeBps: 50` means a 0.5% fee.

Builders decide whether the fee is collected from the input token or output token using `platformFeeMode`.

## Platform Fee Parameters

Configure platform fees using two parameters.

### platformFeeMode

Use `platformFeeMode` to choose which token users pay the fee in:

* `outputMint` (default): fee is collected from the output token.
* `inputMint`: fee is collected from the input token.

For [spot trades](/spot/introduction) via `/order`, fees can be paid in either the `inputMint` or `outputMint`.
For the intent flow (`/intent` + `/submit-intent`), fees can currently only be paid in the `outputMint`.

### platformFeeBps

Use `platformFeeBps` to set a fixed platform fee in basis points.

* The fee is calculated as a percentage of the trade amount.
* The fee is collected from the input or output token based on `platformFeeMode`.

## Fee Accounts

Platform fees are transferred to a builder-controlled token account. You need a separate token account (ATA) for each token you collect fees in. For example, if your app collects fees in both USDC and SOL, you need a USDC fee account and a SOL fee account.

### Using `feeAccount`

Pass `feeAccount` to specify the token account that receives the fee. The account must:

* Be a valid SPL token account for the token being collected.
* Already exist before the trade executes.

The token must match the fee mode:

* Input token account when collecting from `inputMint`
* Output token account when collecting from `outputMint`

## How Platform Fees Affect Trades

Platform fees change net economics, not trade behavior.

* Routing stays the same.
* Slippage enforcement stays the same.
* Execution timing stays the same.

If a trade fails, users pay no platform fee.

<Warning>
  Only specify a nonzero platform fee if you will actually collect the fee at execution time. When the API receives a nonzero `platformFeeBps`, it factors the fee into slippage tolerance calculations. If the fee is declared in the request but not collected onchain, the slippage budget is effectively wasted on a fee that never gets taken, resulting in suboptimal pricing for your users.
</Warning>

## When To Use Platform Fees

Use platform fees if you want to:

* Monetize trading volume.
* Fund product development.
* Align incentives with usage.

## Code Recipes

* [Platform fee recipe](/spot/recipes/platform-fees).


# Priority Fees
Source: https://pond.dflow.net/spot/trading/priority-fees

How priority fees affect trade execution

Priority fees affect **when a trade executes**, not **how it executes**.

They are additional fees paid to Solana validators to increase the likelihood that a transaction is included quickly during periods of network congestion. Higher priority fees improve execution speed. Lower fees reduce cost but may delay execution.

Priority fees do **not** change routing, slippage checks, or trade semantics. They only influence transaction ordering.

## How DFlow Handles Priority Fees

DFlow supports two ways to set priority fees:

* **Max Priority Fee**
* **Exact Priority Fee**

Choose between them based on whether you prefer **cost predictability** or **adaptive execution speed**.

## Priority Fee Estimates API

If you want current fee estimates, use:

* [GET /priority-fees](/resources/trading-api/priority-fees/priority-fees) for a snapshot.
* [GET /priority-fees/stream](/resources/trading-api/websockets/priority-fees-stream) for real-time updates over WebSocket.

## Max Priority Fee

Use the Max Priority Fee to allow DFlow to **dynamically choose an optimal priority fee**, capped at a pre-defined maximum.

This approach balances execution speed with cost. DFlow reacts to current network conditions but never exceeds the maximum you set.

### How It Works

Specify:

* A **priority level** (`medium`, `high`, `veryHigh`).
* A **maximum fee** (`maxLamports`).

DFlow selects the lowest fee likely to achieve the requested priority, capped by your maximum.

If no priority fee parameters are provided, DFlow defaults to automatic priority fees capped at **0.005 SOL**.

### When Max Priority Fee Makes Sense

Use Max Priority Fee when:

* Execution speed matters.
* Network conditions are unpredictable.
* You want protection against overpaying during congestion.

This is the recommended default for most user-facing trading flows.

## Exact Priority Fee

Exact Priority Fee uses a **fixed fee amount** for every trade.

DFlow applies the specified fee regardless of network conditions. No adjustments are made.

### How It Works

Provide a fixed priority fee in lamports. That fee is always used.

When using intent-based endpoints, the app must include the **base processing fee (10,000 lamports)** in addition to the desired priority fee.

If the network requires higher fees than the amount specified, the trade may be delayed or fail.

### When Exact Priority Fee Makes Sense

Use Exact Priority Fees when:

* Cost predictability is critical.
* Fees must be strictly budgeted.
* Delayed execution is acceptable.

This mode is best suited for automation, testing, or environments with strict fee constraints.

## What Priority Fees Do *Not* Affect

Priority fees do **not**:

* Change routing decisions.
* Bypass slippage checks.
* Alter trade execution logic.
* Guarantee execution success.

They only influence how quickly a transaction is considered for inclusion.

## Code Recipes

* [Priority fee recipe](/spot/recipes/priority-fees).


# Slippage Tolerance
Source: https://pond.dflow.net/spot/trading/slippage-tolerance

How slippage works and how to control it in Trading API requests

<Info>
  Slippage is the difference between the quoted price and
  the final execution price. On Solana, prices can move between quote and execution
  because transactions are processed in blocks and liquidity shifts rapidly. A
  higher tolerance increases execution probability; a lower tolerance tightens
  price protection.
</Info>

Builders have two options for slippage tolerance:

* **Auto slippage**: DFlow chooses the tolerance dynamically.
* **Custom slippage**: You set the tolerance explicitly.

## Auto Slippage Tolerance

With auto slippage, DFlow determines the optimal slippage based on market
conditions so trades have a high probability of success while maintaining price
protection.

To use auto slippage, set `slippageBps=auto` on either of the following API routes:

* [`GET /order`](/resources/trading-api/order/order)
* [`GET /intent`](/resources/trading-api/declarative/quote)

<Note>
  Auto slippage is calculated server-side by the DFlow Aggregator and updates
  continuously based on current onchain conditions.
</Note>

## Custom Slippage Tolerance

Custom slippage gives traders direct control over the maximum price deviation
they are willing to accept.

To use custom slippage, set `slippageBps` to a non-negative integer (u16) on either of the following API routes:

* [`GET /order`](/resources/trading-api/order/order)
* [`GET /intent`](/resources/trading-api/declarative/quote).

The value is in basis points (1 bp = 0.01%).

<Note>
  Setting slippage too low can cause trades to fail during high volatility or
  when liquidity is thin.
</Note>

## Sequence of Events

1. You set slippage tolerance (auto or custom).
2. You request an order or intent quote.
3. DFlow validates the execution price against your tolerance.
4. If the tolerance is met, the trade executes; otherwise it fails safely.

## API Routes

* [GET /order](/resources/trading-api/order/order)
* [GET /intent](/resources/trading-api/declarative/quote)


# Sponsored Swaps
Source: https://pond.dflow.net/spot/trading/sponsored-swaps

How to implement gasless swaps where a sponsor covers transaction fees

Use sponsored swaps to build gasless trading features where users swap tokens without holding SOL for fees. A **sponsor** pays the transaction fee and token account creation costs on the user's behalf.

To create a sponsored swap, pass the `sponsor` parameter with the sponsor's wallet address on a [Trade API request](/resources/trading-api/order/order). Both the user and sponsor must sign the resulting transaction.

## Why Use User-Executed Sponsored Swaps

* **Smaller transactions.** Eliminates the input transfer to the sponsor and output transfer back to the user, reducing overall transaction size.
* **Simpler transaction structure.** The user swaps directly from their own token accounts in a single step.

## Execution Modes

Execution modes determine who performs the swap.

### Sponsor Executes (Default)

The sponsor performs the swap on the user's behalf:

1. User transfers input tokens to sponsor.
2. Sponsor executes the swap using their token accounts.
3. Sponsor transfers output tokens to user.

### User Executes

The user performs the swap directly using their own token accounts. The sponsor still pays the transaction fee and token account creation costs.

## Parameters

### sponsor

The sponsor's wallet address. When specified, the sponsor pays the transaction fee and token account creation costs. Base58-encoded.

### sponsoredSwap

Set to `true` to indicate the swap will be sponsored. This ensures the quote accounts for the correct transaction structure and fees based on the execution mode. Not needed on `/order` or `/swap` — those endpoints infer sponsorship from the `sponsor` parameter.

### sponsorExec

Choose who executes the swap in a sponsored transaction.

| Value            | Executor | Description                                           |
| ---------------- | -------- | ----------------------------------------------------- |
| `true` (default) | Sponsor  | Sponsor executes the swap using their token accounts  |
| `false`          | User     | User executes the swap using their own token accounts |

Pass this parameter on three endpoints:

* [`GET /order`](/resources/trading-api/order/order) — query parameter, used when `sponsor` is specified.
* [`GET /quote`](/resources/trading-api/imperative/quote) — query parameter, used when `sponsoredSwap` is `true`.
* [`POST /swap`](/resources/trading-api/imperative/swap) — request body field, used when `sponsor` is specified.

## Code Examples

<AccordionGroup>
  <Accordion title="GET /order">
    ```typescript theme={null}
    const SPONSOR_ADDRESS = "SPONSOR_WALLET_ADDRESS";

    const params = new URLSearchParams({
      inputMint: "So11111111111111111111111111111111111111112",
      outputMint: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
      amount: "1000000000",
      userPublicKey: userKeypair.publicKey.toBase58(),
      sponsor: SPONSOR_ADDRESS,
      sponsorExec: "false", // user executes; omit or set "true" for sponsor execution
    });

    const headers: HeadersInit = {};
    if (process.env.DFLOW_API_KEY) {
      headers["x-api-key"] = process.env.DFLOW_API_KEY;
    }

    const orderResponse = await fetch(
      `${API_BASE_URL}/order?${params.toString()}`,
      { headers }
    ).then((x) => x.json());

    // Both user and sponsor must sign
    const tx = VersionedTransaction.deserialize(
      Buffer.from(orderResponse.transaction, "base64")
    );
    tx.sign([userKeypair, sponsorKeypair]);

    const signature = await connection.sendRawTransaction(tx.serialize());
    await connection.confirmTransaction(signature, "confirmed");
    ```
  </Accordion>

  <Accordion title="GET /quote">
    ```typescript theme={null}
    const params = new URLSearchParams({
      inputMint: "So11111111111111111111111111111111111111112",
      outputMint: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
      amount: "1000000000",
      sponsoredSwap: "true", // required on /quote to signal sponsorship
      sponsorExec: "false",
    });

    const quoteResponse = await fetch(
      `${API_BASE_URL}/quote?${params.toString()}`,
      { headers }
    ).then((x) => x.json());
    ```
  </Accordion>

  <Accordion title="POST /swap">
    ```typescript theme={null}
    const swapResponse = await fetch(`${API_BASE_URL}/swap`, {
      method: "POST",
      headers: { "Content-Type": "application/json", ...headers },
      body: JSON.stringify({
        quoteResponse,
        userPublicKey: userKeypair.publicKey.toBase58(),
        sponsor: "SPONSOR_WALLET_ADDRESS",
        sponsorExec: false,
      }),
    }).then((x) => x.json());

    // Both user and sponsor must sign
    const tx = VersionedTransaction.deserialize(
      Buffer.from(swapResponse.swapTransaction, "base64")
    );
    tx.sign([userKeypair, sponsorKeypair]);

    const signature = await connection.sendRawTransaction(tx.serialize());
    await connection.confirmTransaction(signature, "confirmed");
    ```
  </Accordion>
</AccordionGroup>


# Trading Data Model
Source: https://pond.dflow.net/spot/trading/trade-api-data-model

How trading data is structured around `/order` requests

Use this page as a reference for the key objects returned by the [`/order
`](/resources/trading-api/order/order) endpoint and where each one appears in the request/response flow.

This page focuses on **imperative** trades.

<Info>
  We recommend using the `/order` endpoint for new integrations. The `/quote`, `/swap`, and
  `/swap-instructions` endpoints are still available but `/order` is the preferred approach.
</Info>

## High-Level Model

You request an **Order**, which returns a **Quote** and, if `userPublicKey` is
provided, a **Transaction** to sign and submit. The response may include a
**routePlan** (one or more legs) and an **executionMode** (sync or async).

```mermaid theme={null}
flowchart TD
  OrderRequest -->|returns| OrderResponse
  OrderResponse -->|may_include| Transaction
  OrderResponse -->|may_include| RoutePlanLeg
  Transaction -->|submit| SolanaRPC
  SolanaRPC -->|track| OrderStatus
```

## Example (Trade SOL → USDC)

**Input mint**: SOL\
**Output mint**: USDC

Flow:

1. Call [`GET /order`](/resources/trading-api/order/order) with `inputMint`,
   `outputMint`, and `amount`.
2. Inspect `priceImpactPct`, `routePlan`, and `executionMode`.
3. If `transaction` is returned, sign it and send it to Solana.
4. For async execution, poll [`GET /order-status`](/resources/trading-api/order/order-status).

## Entity Reference

### Order Request (Query Parameters)

Core parameters:

| Field                     | Type                | Notes                                      |
| ------------------------- | ------------------- | ------------------------------------------ |
| `inputMint`               | string              | Base58 input mint                          |
| `outputMint`              | string              | Base58 output mint                         |
| `amount`                  | integer             | Input amount (scaled integer)              |
| `userPublicKey`           | string              | Wallet; includes `transaction` in response |
| `slippageBps`             | integer \| `"auto"` | Max allowed slippage                       |
| `priceImpactTolerancePct` | integer             | Max price impact % override                |

Routing controls:

| Field              | Type    | Notes                                    |
| ------------------ | ------- | ---------------------------------------- |
| `dexes`            | string  | Comma-separated include list             |
| `excludeDexes`     | string  | Comma-separated exclude list             |
| `onlyDirectRoutes` | boolean | Force single-leg routes                  |
| `maxRouteLength`   | integer | Max legs (ignored if `onlyDirectRoutes`) |
| `onlyJitRoutes`    | boolean | Force JIT routes                         |
| `forJitoBundle`    | boolean | Routes compatible with Jito bundles      |

Execution controls:

| Field                | Type    | Notes                               |
| -------------------- | ------- | ----------------------------------- |
| `allowSyncExec`      | boolean | Allow sync execution                |
| `allowAsyncExec`     | boolean | Allow async execution               |
| `restrictRevertMint` | boolean | Input must be revert mint for async |

Fees and accounts:

| Field                        | Type    | Notes                           |
| ---------------------------- | ------- | ------------------------------- |
| `platformFeeMode`            | enum    | Fee collected from input/output |
| `platformFeeBps`             | integer | Platform fee in bps             |
| `feeAccount`                 | string  | Token account for platform fees |
| `positiveSlippageFeeAccount` | string  | Account for positive slippage   |
| `positiveSlippageLimitPct`   | integer | Cap on positive slippage fee    |
| `sponsor`                    | string  | Sponsor wallet (gasless)        |
| `destinationTokenAccount`    | string  | Output token account            |
| `destinationWallet`          | string  | Output wallet (ATA if needed)   |
| `revertWallet`               | string  | Revert wallet for async orders  |

<Note>
  In `POST /swap`, if you set `destinationTokenAccount.address` and want native SOL output, pass the wallet address (owner) instead of the wallet's WSOL associated token account address.
</Note>

Transaction configuration:

| Field                                  | Type              | Notes                                                                                                                                                                                                                                                                                                                                              |
| -------------------------------------- | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `wrapAndUnwrapSol`                     | boolean           | Use native SOL if true                                                                                                                                                                                                                                                                                                                             |
| `prioritizationFeeLamports`            | integer \| enum   | Priority fee or level                                                                                                                                                                                                                                                                                                                              |
| `computeUnitPriceMicroLamports`        | integer           | CU price (mutually exclusive)                                                                                                                                                                                                                                                                                                                      |
| `dynamicComputeUnitLimit`              | boolean           | Simulate to determine CU limit                                                                                                                                                                                                                                                                                                                     |
| `includeJitoSandwichMitigationAccount` | boolean \| string | Jito mitigation                                                                                                                                                                                                                                                                                                                                    |
| `maxAccounts`                          | integer           | Max number of accounts the transaction can use. Mutually exclusive with `reserveAccounts`.                                                                                                                                                                                                                                                         |
| `maxTransactionSize`                   | integer           | Max transaction size in bytes. Mutually exclusive with `reserveTransactionSize`.                                                                                                                                                                                                                                                                   |
| `reserveAccounts`                      | integer           | Number of accounts to leave unused. The server ensures the transaction uses at most `TRANSACTION_MAX_ACCOUNTS - reserveAccounts` accounts. Use this when you add instructions to the transaction — specify only the unique accounts your additions will introduce, not accounts already in the transaction. Mutually exclusive with `maxAccounts`. |
| `reserveTransactionSize`               | integer           | Bytes to leave unused. The server ensures the transaction size is at most `TRANSACTION_MAX_SIZE - reserveTransactionSize` bytes. Use this when you add instructions to the transaction — specify the number of bytes your modifications will add. Mutually exclusive with `maxTransactionSize`.                                                    |

### Order Response (OrderResponse)

| Field                       | Type           | Notes                                   |
| --------------------------- | -------------- | --------------------------------------- |
| `inputMint`                 | string         | Base58 input mint                       |
| `inAmount`                  | string         | Max input amount (scaled integer)       |
| `outputMint`                | string         | Base58 output mint                      |
| `outAmount`                 | string         | Expected output amount (scaled integer) |
| `otherAmountThreshold`      | string         | Min output after fees                   |
| `minOutAmount`              | string         | Same as `otherAmountThreshold`          |
| `slippageBps`               | integer        | Max slippage in bps                     |
| `priceImpactPct`            | string         | Estimated price impact                  |
| `contextSlot`               | integer        | Slot at evaluation time                 |
| `executionMode`             | enum           | `sync` or `async`                       |
| `routePlan`                 | array          | Route legs (sync and known routes)      |
| `platformFee`               | object \| null | Platform fee if applied                 |
| `revertMint`                | string         | Revert mint for async orders            |
| `transaction`               | string         | Base64 tx to sign/send                  |
| `lastValidBlockHeight`      | integer        | Last valid block height                 |
| `computeUnitLimit`          | integer        | Compute unit limit                      |
| `prioritizationFeeLamports` | integer        | Priority fee in lamports                |
| `prioritizationType`        | object         | Priority fee type                       |

### Route Leg (RoutePlanLeg)

Each leg is either a **DynamicRoutePlanLeg** or **SingleMarketRoutePlanLeg**.

Common fields:

| Field                | Type    | Notes                        |
| -------------------- | ------- | ---------------------------- |
| `venue`              | string  | Venue for the leg            |
| `marketKey`          | string  | Market key for venue         |
| `inputMint`          | string  | Input mint                   |
| `outputMint`         | string  | Output mint                  |
| `inAmount`           | string  | Max input amount             |
| `outAmount`          | string  | Expected output amount       |
| `inputMintDecimals`  | integer | Input decimals               |
| `outputMintDecimals` | integer | Output decimals              |
| `data`               | string  | Present only on dynamic legs |