Integration

Base URL (Dev): https://core-api-dev.vanish.trade Base URL (Prod): https://core-api.vanish.trade SOL Native Address: 11111111111111111111111111111111 Authentication: All endpoints require an x-api-key header. The Vanish Core injection process adds approximately 200ms to trade finality. Your swap instructions are injected into Vanish’s transaction wrapper, keeping you in full control over route, slippage, and execution.

We recommend 12,000,000 lamports (0.012 SOL) for loan_additional_sol - this covers the cost of any token account (ATA) creation during the trade. Any unused amount is automatically refunded after settlement.

This page covers the three core flows: Deposit, Trade, and Withdraw - plus signing, compliance rules, interrupted flow recovery, and routing guidance.

How It Works

Before trading, your Vanish account must have a funded balance - see the Deposit section to fund it first. When a trade is submitted, Vanish:

Advances funds from its trading accounts to a one-time use wallet to execute the swap.
Wraps your swap transaction - your swap instructions are passed through unchanged, with settlement instructions added around them.
Routes the transaction via Jito bundle (default) or returns a signed payload for self-broadcast.
Settles atomically at the end. If any instruction fails, everything reverts - failed transactions only cost the base network fee.

Compliance

Vanish operates on a same wallet in, same wallet out model. Your connected wallet is the fixed origin for all fund movements - it is the only address from which you can deposit and the only address to which withdrawals are returned. This is enforced at the protocol level and cannot be bypassed.

If a deposit commit returns rejected, the transaction failed compliance or risk screening. Funds will be refunded to the originating wallet after extended screening is completed. Do not re-attempt until the refund is confirmed.

Signing Requests

Write and read endpoints require a signed message proving ownership of user_address. Sign with the user’s Solana keypair (Ed25519) and base64-encode the result. Use the current Unix timestamp in milliseconds - stale timestamps are rejected.

Read Signing Format
Trade Signing Format
Withdraw Signing Format

Used by: /account/balances, /account/pending, /account/points, and all position/transaction endpoints.Pass the result as signature.

By signing, I hereby agree to Vanish's Terms of Service and agree to be bound by them (docs.vanish.trade/legal/TOS)

Details: read:{timestamp}

import * as nacl from 'tweetnacl';
import { Keypair } from '@solana/web3.js';

function readSignature(timestamp: string, keypair: Keypair): string {
  const message = [
    "By signing, I hereby agree to Vanish's Terms of Service and agree to be bound by them (docs.vanish.trade/legal/TOS)",
    "",
    `Details: read:${timestamp}`,
  ].join('\n');
  const sig = nacl.sign.detached(new TextEncoder().encode(message), keypair.secretKey);
  return Buffer.from(sig).toString('base64');
}

Used by: POST /trade/createPass the result as user_signature.

By signing, I hereby agree to Vanish's Terms of Service and agree to be bound by them (docs.vanish.trade/legal/TOS)

Details: trade:{source_token_address}:{target_token_address}:{amount}:{loan_additional_sol}:{timestamp}:{jito_tip_amount}

function tradeSignature(
  source: string, target: string, amount: string,
  loanSol: string, timestamp: string, jitoTip: string,
  keypair: Keypair
): string {
  const message = [
    "By signing, I hereby agree to Vanish's Terms of Service and agree to be bound by them (docs.vanish.trade/legal/TOS)",
    "",
    `Details: trade:${source}:${target}:${amount}:${loanSol}:${timestamp}:${jitoTip}`,
  ].join('\n');
  const sig = nacl.sign.detached(new TextEncoder().encode(message), keypair.secretKey);
  return Buffer.from(sig).toString('base64');
}

Used by: POST /withdraw/createPass the result as user_signature.

By signing, I hereby agree to Vanish's Terms of Service and agree to be bound by them (docs.vanish.trade/legal/TOS)

Details: withdraw:{token_address}:{amount}:{additional_sol}:{timestamp}

function withdrawSignature(
  token: string, amount: string,
  additionalSol: string, timestamp: string,
  keypair: Keypair
): string {
  const message = [
    "By signing, I hereby agree to Vanish's Terms of Service and agree to be bound by them (docs.vanish.trade/legal/TOS)",
    "",
    `Details: withdraw:${token}:${amount}:${additionalSol}:${timestamp}`,
  ].join('\n');
  const sig = nacl.sign.detached(new TextEncoder().encode(message), keypair.secretKey);
  return Buffer.from(sig).toString('base64');
}

Deposit Flow

Get a deposit address

See the full reference for Get Deposit Address.

GET /deposit_address?token_address={token_address}

Pass the token mint you want to deposit. Use 11111111111111111111111111111111 for native SOL.

Response

{
  "address": "7ozoNcVqgptbAUHjLR1vNHgEfKiE5aYufStEHzJhxKeG"
}

Transfer funds on-chain

Send tokens to the returned address. Wait for on-chain confirmation before continuing.

Commit the deposit

See the full reference for Commit Action.

POST /commit

Request body

{
  "tx_id": "<confirmed on-chain transaction signature>"
}

Status
`completed`	Deposit successfully processed - the user’s Vanish balance has been updated
`rejected`	Deposit failed compliance or risk screening - funds will be refunded to the originating wallet after extended screening is completed
`pending`	Waiting for the transaction to land on-chain or undergo compliance screening - check back shortly
`failed`	The transaction was rejected on-chain - the user’s balance is no longer in a pending state
`expired`	The transaction was not confirmed within the required window - the user’s balance is no longer in a pending state

Call /account/balances after a completed status to verify the updated balance.

Trade Flow

Get a one-time wallet

See the full reference for Get One-Time Wallet.

GET /trade/one-time-wallet

Response

{
  "address": "<one-time wallet address>"
}

This wallet is for a single trade only - never reuse it. Set the returned address as the signer for all swap instructions in your (unsigned) transaction.

Prepare your swap transaction

Fetch a route from Titan or another DEX aggregator.
Assemble all swap instructions into a single unsigned transaction.
Set the one-time wallet address as the signer for all swap instructions.

Create the trade

See the full reference for Create Trade.

POST /trade/create

user_address

string

required

The user’s Solana wallet address.

source_token_address

string

required

Input token mint. Use 11111111111111111111111111111111 for SOL.

target_token_address

string

required

Output token mint.

amount

string

required

Input amount in lamports or SPL base units.

swap_transaction

string

required

Base64-encoded unsigned swap transaction.

one_time_wallet

string

required

Address returned by GET /trade/one-time-wallet.

loan_additional_sol

string

required

Amount to cover ATA creation during the trade. We recommend 12000000 (0.012 SOL) - unused amount is automatically refunded.

jito_tip_amount

string

required

Tip in lamports. Minimum recommended: 1000000 (0.001 SOL). Only applied on the Jito route.

split_repay

integer

required

Number of Trading Accounts to distribute purchased tokens across. Max 9. Use 1 when amount_out is less than 0.5% of total supply.

timestamp

string

required

Unix timestamp in milliseconds.

user_signature

string

required

See the Trade Signing Format above.

prefer_non_jito

object

Compute budget for self-broadcast. Omit entirely to route via Jito (default).

Show prefer_non_jito fields

compute_unit_price

string

Micro-lamports per compute unit.

compute_unit_limit

string

Max compute units for the transaction.

custom_tip_address

string

Optional custom tip recipient address.

custom_tip_amount

string

Optional custom tip amount in lamports.

Jito (default)
Non-Jito

Omit prefer_non_jito. Vanish Core builds, signs, and broadcasts via Jito bundle - no further action needed.Response: tx_id + jito_bundle_id - transaction is null

Provide the prefer_non_jito object. Vanish Core returns the fully-signed transaction for self-broadcast.Response: signed transaction - jito_bundle_id is nullThe response wraps your original swap instructions unchanged. Works best with low split_repay values - smaller transactions are more likely to fit in a single transaction without Jito bundling.

All operations revert atomically on failure. Failed transactions only cost the base network fee.

Broadcast (non-Jito only), then commit

If using non-Jito, broadcast the returned transaction through your RPC. Then commit regardless of route or outcome:

POST /commit

Request body

{
  "tx_id": "<on-chain transaction signature>"
}

Response

{
  "status":            "completed",
  "action_type":       "trade",
  "already_processed": false,
  "vanish_fee":        "5000",
  "tx_fee":            "5000",
  "user_address":      "<string>",
  "balance_changes": [
    { "token_address": "<string>", "change": "<string>" }
  ]
}

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

If already_processed is true, this tx_id was already committed in a previous call. The response still contains the correct status and balance_changes - safe to use for idempotency checks.

Withdraw Flow

Create the withdrawal

Verify the user’s balance via /account/balances before proceeding. See the full reference for Withdraw.

POST /withdraw/create

user_address

string

required

The user’s Solana wallet address.

token_address

string

required

Token mint to withdraw.

amount

string

required

Amount in base units.

additional_sol

string

required

Lamports for destination ATA creation, if required.

timestamp

string

required

Unix timestamp in milliseconds.

user_signature

string

required

See the Withdraw Signing Format above.

Response

{
  "tx_id":            "<string>",
  "transaction_data": "<serialized withdrawal transaction>"
}

transaction_data is routed through the user’s initial deposit wallet for compliant fund flow. Broadcast this via your RPC.

Broadcast and commit

Broadcast transaction_data through your RPC or node, then commit:

POST /commit

Request body

{
  "tx_id": "<on-chain transaction signature>"
}

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

Handling Interrupted Flows

If a transaction is submitted but /commit is never called - due to a crash, timeout, or network issue - the user’s balance remains in a pending state. Use /account/pending to detect and recover these states:

POST /account/pending

Request body

{
  "user_address": "<user's wallet address>",
  "timestamp":    "<unix ms>",
  "signature":    "<Read Signing Format>"
}

Response

[
  {
    "tx_id":                  "<string>",
    "action_type":            "trade",
    "status":                 "pending",
    "created_at":             "2025-01-01T00:00:00Z",
    "frozen_balance_changes": [{ "token_address": "<string>", "change": "<string>" }]
  }
]

Call /commit with each returned tx_id to resolve balances from their pending state - whether the original transaction succeeded or failed on-chain. /commit is idempotent, so it is safe to retry.

Routing Guidance

When to use Jito vs non-Jito

Use Jito (default) when:

You want Vanish Core to handle broadcasting entirely
You are trading high-value amounts where MEV protection matters
Simplicity is preferred over control

Use non-Jito when:

You have your own RPC infrastructure optimised for low latency
You want full control over broadcasting and retry logic
Transaction size is small (low split_repay) and atomic execution is likely

Choosing split_repay

split_repay controls how many Trading Accounts purchased tokens are distributed across. 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, which may require spreading holdings to reduce per-wallet concentration. Maximum value is 9.

Setting loan_additional_sol

We recommend 12000000 lamports (0.012 SOL) for loan_additional_sol - this covers ATA creation costs during the trade. Any unused amount is automatically refunded after settlement.If the target token’s ATA already exists in the user’s wallet, a lower value may be sufficient - but the recommended value is safe for all cases.

Lamport Reference

All amounts are denominated in lamports - the smallest unit of SOL (1 SOL = 1,000,000,000 lamports). SPL token amounts use the token’s own decimal precision.

Amount	Lamports
1 SOL	`1,000,000,000`
0.012 SOL (loan_additional_sol)	`12,000,000`
0.001 SOL (minimum recommended Jito tip)	`1,000,000`

Next Steps

New to Vanish? Start with the Quickstart for working code examples.
Hitting errors? See Error Handling for status codes, commit statuses, and debugging.
Have questions? The FAQ covers common integration questions.

Getting Started

Guides

Health Check

Account

Fund Management

Trade

Commit Action

How It Works

Compliance

Signing Requests

Deposit Flow

Trade Flow

Withdraw Flow

Handling Interrupted Flows

Routing Guidance

Lamport Reference

Next Steps

Getting Started

Guides

Health Check

Account

Fund Management

Trade

Commit Action

​How It Works

​Compliance

​Signing Requests

​Deposit Flow

​Trade Flow

​Withdraw Flow

​Handling Interrupted Flows

​Routing Guidance

​Lamport Reference

​Next Steps

How It Works

Compliance

Signing Requests

Deposit Flow

Trade Flow

Withdraw Flow

Handling Interrupted Flows

Routing Guidance

Lamport Reference

Next Steps