Skip to main content
Base API URL (Dev): https://core-api-dev.vanish.trade Base API URL (Prod): https://core-api.vanish.trade SOL Native Address: 11111111111111111111111111111111 (For submission to API) Authentication: All endpoints require x-api-key header with your API key. The Vanish Core injection process adds approximately 200ms to your trade finality. The system utilises one-time use trading wallets and loan/repay mechanisms to enable private trading while keeping you in full control over swap parameters and transaction speeds.
A reserve balance of 0.012 SOL is required to ensure sufficient coverage for the user’s rent and transaction fees.

​
Deposit Flow

​
1: Get Deposit Address

GET /deposit_address?token_address={token_address}

​
2: Deposit Funds

  • Transfer the SOL/SPL tokens to the provided deposit address.

​
3: Commit Deposit

POST /commit
Implementation Flow:
  1. Once the deposit transaction is confirmed on-chain, call /commit .
  2. If a deposit commit status returns: rejected, the user’s deposit transaction has failed initial compliance or risk screening, and can notify that funds will be refunded to the user’s wallet after extended screening is completed.
  3. If completed, Vanish Core processes the deposit and updates internal balances.
  4. Call /account/balances to verify updated balances.

​
Trade Flow

​
1: Retrieve One-Time Wallet

GET /one-time-wallet
  • Retrieve a new Solana keypair for each trade.
  • This wallet is used exclusively for one transaction.

​
2: Prepare Swap Transaction

  1. Fetch route from Titan or other DEX aggregators.
  2. Assemble all swap instructions into a single transaction body.
  3. Set one-time wallet address as the signer for all swap instructions.

​
3: Create Trade

POST /trade/create
Purchased tokens can be distributed across trading accounts (e.g., if amount_out is <0.5% of total supply, split_repay = 1 is typically sufficient) to reduce per-wallet concentration. split_repay defines how many trading accounts are to be used. Lower values reduce account metas, instructions, and overall transaction size, increasing the likelihood that the swap + repay executes as a single atomic transaction instead of requiring Jito bundling. Routing Behavior (2 Routes):
  • 1: Using Jito: Vanish Core submits and broadcasts the transaction via a Jito bundle (response includes tx_id + jito_bundle_id; transaction is null).
  • 2: Not using Jito (prefer_non_jito): Vanish Core returns the fully-signed transaction payload for self submission/broadcasting (jito_bundle_id is null).

​
4: Sign and Broadcast

  1. Using Jito: No broadcast necessary - Vanish Core broadcasts via Jito (response is tx_id + jito_bundle_id).
  2. Not using Jito: Receive the signed transaction payload from Vanish Core, then broadcast through your existing RPC/Node infrastructure.
Response: Returns a fully-signed trade transaction or a Jito bundle reference, built from:
  • Your original swap instructions (unmodified).
  • Injected loan instructions (at the beginning).
  • Injected repay instructions (at the end).

​
5: Commit Trade

POST /commit
Response: Returns the recognised trade status and internal balances changes.
The /commit endpoint must be called for all transactions, regardless of their final status (success, failure, or expiration). This is to ensure balances are unfrozen and reverted if a transaction has failed.

​
Technical Details:

  • All operations revert atomically if any instruction fails.
  • Failed transactions only cost the base network transaction fee.

​
Withdraw Flow

​
1: Create Withdraw

POST /withdraw/create
Validation:
  • Verify user has sufficient balance using /account/balances .
  • Validate destination address format.

​
2: Broadcast Withdraw

Response: The API returns a withdrawal transaction body that:
  • Transfers from Vanish to user’s destination address.
  • Routes through user’s initial deposit wallet for compliant fund flow.

​
3: Commit Withdraw

POST /commit
Response: Returns the recognised withdrawal status and internal balances changes.
The /commit endpoint must be called for all transactions, regardless of their final status (success, failure, or expiration). This is to ensure balances are unfrozen and reverted if a transaction has failed.