Skip to main content
Dark Sv
For the full implementation walkthrough, see the Integration Guide. For code examples, see the Quickstart.

​
Getting Started

API keys are provisioned during onboarding. Contact the Vanish team via Discord to get started. Keys are scoped to your team and should be kept server-side - never expose them in client-side code.
Any DEX aggregator that outputs a standard Solana transaction body. Titan is the primary recommended aggregator. Jupiter is also supported. The swap instructions are passed through unchanged - Vanish Core only injects loan and repay instructions around them.

​
Creating a Trade

Call GET /trade/one-time-wallet - Vanish Core returns a fresh single-use Solana keypair address. You do not generate this yourself. Never reuse a one-time wallet address across transactions.
Submit your unsigned swap transaction along with the one-time wallet address. Vanish Core automatically injects loan instructions at the beginning and repay instructions at the end, borrowing the required amount from its Trading Accounts. If any instruction fails, all operations revert atomically - you are never left with partial state.The one-time wallet must be a regular Solana wallet (not an ATA) and must be set as the signer for all swap instructions.
An unsigned Solana transaction containing all DEX/swap instructions for your route, with the one-time wallet address set as the transaction signer. Do not include loan or repay logic - Vanish Core injects these and returns the full wrapped transaction.The transaction body is passed as swap_transaction (base64-encoded) in POST /trade/create.
On the Jito route (default), Vanish Core returns tx_id + jito_bundle_id. No broadcast required - Vanish handles it.On the non-Jito route, Vanish Core returns a signed transaction payload containing your original swap instructions (unmodified), with loan instructions prepended and repay instructions appended. Broadcast through your RPC.
All operations revert atomically if any instruction fails. Failed transactions only cost the base network fee.You must still call POST /commit with the failed transaction’s tx_id. This resolves the user’s balance from its pending state.
Yes. On the non-Jito route, the API returns the complete signed transaction bytes. Deserialise the transaction and inspect the instruction list before broadcasting to confirm:
  • Your original swap instructions are present and unchanged
  • Only loan and repay instructions were added
  • No unauthorised modifications were made

​
Authentication & Signing

All API endpoints require an x-api-key header. Keys are provisioned during onboarding.
Write operations (/trade/create, /withdraw/create) and read operations (/account/balances, /account/pending, etc.) require a user-signed message proving ownership of user_address.Sign with the user’s Solana keypair (Ed25519) and base64-encode the result. The message format varies by endpoint - see Signing requests for the exact format for each operation.Timestamps must be Unix time in milliseconds. Stale timestamps are rejected to prevent replay attacks.
Malformed signatures. The most frequent issues are:
  • Using seconds instead of milliseconds for the timestamp
  • Missing or incorrect newlines in the message string
  • Base58 or hex encoding instead of base64
  • Signing with the wrong keypair
See Error handling - 401 for a full checklist.

​
Balances & Commit

Vanish Core places a portion of the user’s balance in a pending state when a transaction is submitted. Calling /commit - with any outcome - tells Vanish Core to resolve that balance, either applying the change or reverting it. Without a commit, the balance remains in a pending state indefinitely.Use POST /account/pending to detect any transactions awaiting commit, including after app crashes.
If already_processed: true, this tx_id was already committed in a previous call. The response still contains the correct status and balance_changes. This is by design - /commit is idempotent and safe to retry.
StatusMeaning
completedAction processed successfully - the user’s Vanish balance has been updated
rejectedDeposit failed compliance or risk screening - funds will be refunded to the originating wallet after extended screening is completed
pendingWaiting for the transaction to land on-chain or undergo compliance screening - check back shortly
failedThe transaction was rejected on-chain - the user’s balance is no longer held in a pending state
expiredThe transaction was not confirmed within the required window - the user’s balance is no longer held in a pending state

​
Fees & Network

loan_additional_sol covers the cost of creating any token accounts (ATAs) needed during the trade. The safe default is 12000000 lamports (0.012 SOL). 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 work - but the default is safe for all cases.
Platform fees are deducted within the swap instruction and factored into the repay. Vanish Core automatically deducts its protocol fee within the repay instruction. Speak to the Vanish team during onboarding to configure your fee address and basis points.
Specify priority fees in your transaction body as you would for any standard Solana transaction. For non-Jito routes, set compute_unit_price and compute_unit_limit inside the prefer_non_jito object. Vanish Core preserves your compute budget settings when injecting loan/repay instructions.
The injection process adds approximately 200ms to trade finality on top of your existing RPC/node submission time.
1 SOL = 1,000,000,000 lamports. All amounts in the Vanish API are in lamports for SOL, or the token’s smallest base unit for SPL tokens.
const LAMPORTS_PER_SOL = 1_000_000_000;
const solToLamports = (sol: number) => Math.floor(sol * LAMPORTS_PER_SOL).toString();
const lamportsToSol = (lam: string) => parseInt(lam) / LAMPORTS_PER_SOL;

​
Compliance

Vanish enforces a strict compliance model: funds can only be withdrawn to the same wallet they were deposited from. Users cannot redirect funds to a different address. This is required by Vanish’s AML framework and ensures a clear, auditable trail for all fund movements.
A rejected commit status means the deposit failed compliance or risk screening. Funds will be refunded to the originating wallet after extended screening is completed. Do not re-attempt the deposit until the refund is confirmed.