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

# Trading

> Execute deposits, withdrawals, and private trades via the Vanish Core API on behalf of your platform users.

Vanish wraps your swap instructions unchanged and routes them through a fresh one-time wallet, so the user's wallet is never exposed as a signer on-chain.

Trading runs on a funded Vanish balance, so this page covers all three steps: [**Deposit**](#deposit), [**Trade**](#trade), and [**Withdraw**](#withdraw). Every request also needs a signature - see [Signing](/guide/integration/signing).

***

## Deposit

<Steps>
  <Step title="Get a deposit address">
    ```bash theme={null}
    GET /deposit_address?token_address={token_address}
    ```

    Pass the token mint you want to deposit, or `11111111111111111111111111111111` for native SOL. Always fetch a fresh address before each deposit - addresses may rotate to ensure maximum privacy.

    ```json Response theme={null}
    { "address": "7ozoNcVqgptbAUHjLR1vNHgEfKiE5aYufStEHzJhxKeG" }
    ```
  </Step>

  <Step title="Transfer on-chain, then commit">
    Send tokens to the returned address and wait for on-chain confirmation, then commit the signature:

    ```json POST /commit theme={null}
    { "tx_id": "<confirmed on-chain transaction signature>" }
    ```

    A `completed` status means the balance is live and ready to trade. [`/account/balances`](/api-reference/account/get_balances) confirms it. For every other status, see [Commit Status](/guide/handling#commit-status).
  </Step>
</Steps>

**Reference:** [Get Deposit Address](/api-reference/funds/deposit_address) · [Commit Action](/api-reference/commit)

***

## Trade

<Steps>
  <Step title="Get a one-time wallet">
    ```bash theme={null}
    GET /trade/one-time-wallet
    ```

    This wallet is for a single trade only - **never reuse it.**

    ```json Response theme={null}
    { "address": "<one-time wallet address>" }
    ```
  </Step>

  <Step title="Build the swap transaction">
    Fetch a route from any DEX or aggregator that outputs a standard Solana transaction body - Titan and Jupiter are common choices, and nothing is restricted to them. Assemble all swap instructions into a single **unsigned** transaction and base64-encode it as `swap_transaction`.

    The one-time wallet must be the **signer** for all swap instructions, and must be a regular Solana wallet - not an ATA. Do not add any extra instructions: Vanish Core wraps the transaction and returns the full signed version.
  </Step>

  <Step title="Create the trade">
    ```json POST /trade/create theme={null}
    {
      "user_address":         "<user's Solana wallet address>",
      "source_token_address": "11111111111111111111111111111111",
      "target_token_address": "<output token mint>",
      "amount":               "100000000",
      "swap_transaction":     "<base64-encoded unsigned swap transaction>",
      "one_time_wallet":      "<address from /trade/one-time-wallet>",
      "loan_additional_sol":  "12000000",
      "jito_tip_amount":      "1000000",
      "split_repay":          1,
      "timestamp":            "<unix milliseconds>",
      "user_signature":       "<trade signing format>"
    }
    ```

    | Field                 | Guidance                                                                                                                             |
    | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
    | `loan_additional_sol` | Covers ATA creation during the trade. We recommend `12000000` (0.012 SOL) - unused amount is automatically refunded.                 |
    | `jito_tip_amount`     | Minimum recommended `1000000` (0.001 SOL). Only applied on the Jito route.                                                           |
    | `split_repay`         | Number of Trading Accounts to distribute purchased tokens across. Use `1` unless `amount_out` exceeds 0.5% of total supply. Max `9`. |
    | `prefer_non_jito`     | Omit entirely to route via Jito. Include it to self-broadcast - see [Routing](#routing).                                             |

    <Check>
      Vanish Core automatically deducts a **50bps protocol fee** at trade settlement. If you would like to enable fees, speak to the Vanish team.
    </Check>
  </Step>

  <Step title="Broadcast if needed, then commit">
    On the Jito route the response is `tx_id` + `jito_bundle_id` and Vanish has already broadcast it. On the non-Jito route it is a signed `transaction` for you to broadcast through your own RPC - commit the **on-chain signature** it returns, not `tx_id`.

    ```json POST /commit theme={null}
    { "tx_id": "<on-chain transaction signature>" }
    ```

    <Warning>
      `/commit` must be called for every transaction - success, failure, or expiry. Balances in a pending state are only resolved once commit is received.
    </Warning>
  </Step>
</Steps>

**Reference:** [Get One-Time Wallet](/api-reference/trade/one-time-wallet) · [Create Trade](/api-reference/trade/create) · [Commit Action](/api-reference/commit)

***

## Withdraw

Withdrawals are always routed back to the wallet that made the original deposit. This is enforced at the protocol level and cannot be bypassed - see [Compliance](/start/compliance).

<Steps>
  <Step title="Create the withdrawal">
    Verify the balance via [`/account/balances`](/api-reference/account/get_balances) first.

    ```json POST /withdraw/create theme={null}
    {
      "user_address":   "<user's Solana wallet address>",
      "token_address":  "<token mint to withdraw>",
      "amount":         "<amount in base units>",
      "additional_sol": "2000000",
      "timestamp":      "<unix milliseconds>",
      "user_signature": "<withdraw signing format>"
    }
    ```

    `additional_sol` covers ATA creation at the destination wallet if required - `2000000` (0.002 SOL) is a safe default.
  </Step>

  <Step title="Broadcast and commit">
    The response returns `transaction_data`, routed through the user's initial deposit wallet for compliant fund flow. Broadcast it through your RPC, then commit the on-chain signature at [`POST /commit`](/api-reference/commit).
  </Step>
</Steps>

**Reference:** [Withdraw](/api-reference/funds/withdraw) · [Commit Action](/api-reference/commit)

***

## Routing

<AccordionGroup>
  <Accordion title="Jito vs non-Jito">
    **Jito (default)** - omit `prefer_non_jito`. Vanish builds, signs, and broadcasts via a Jito bundle. Best for most trades and high-value amounts where MEV protection matters.

    **Non-Jito** - add `prefer_non_jito` to the request. Vanish returns a fully signed transaction for you to broadcast. Use it when you have your own low-latency RPC, want control over retry logic, and transaction size is small.

    ```json theme={null}
    "prefer_non_jito": {
      "compute_unit_price": "71429",
      "compute_unit_limit": "1400000",
      "custom_tip_address": "optional - your tip wallet address",
      "custom_tip_amount":  "optional - tip amount in lamports"
    }
    ```

    Vanish Core preserves your compute budget settings when wrapping the transaction.

    Lending does not offer this choice - Vanish picks by transaction size. See [Lending](/guide/integration/lending).
  </Accordion>

  <Accordion title="Choosing split_repay">
    Lower values mean fewer account metas and instructions, a smaller overall transaction, and a higher likelihood of atomic execution without Jito bundling.

    **Start with `1`** for most trades. Only increase if `amount_out` exceeds 0.5% of total token supply. Maximum is `9`. On the non-Jito route, always use `1`.
  </Accordion>
</AccordionGroup>

***

## Next Steps

* [Lending](/guide/integration/lending) - Open a position with funds advanced by Vanish.
* [Error Handling](/guide/handling) - Commit statuses and recovering interrupted flows.