DEX–Solana Vault: operation and security
CoinRobot can trade on Solana DEXs through Jupiter using a dedicated, user-owned Vault Program account and a separate bot wallet. Your owner wallet initializes the Vault; you keep control of the trading capital without disclosing a private key to CoinRobot.
Read the complete CoinRobot trading flow for the common route from market data and strategy decisions to execution and balance monitoring.
In one minute: own the Vault, never share a private key
The Vault is created from your Phantom owner wallet. It holds the trading token accounts behind a program-derived authority (PDA); CoinRobot never needs your seed phrase or private key. The separate bot may call constrained trades and an aggregate withdrawal only. That withdrawal can return assets only to the immutable owner address. The owner retains the stronger, direct management and withdrawal rights.
Execution route: the Vault uses the Jupiter router, which selects among Solana liquidity routes. Solana’s typically low network cost and Jupiter routing aim to keep execution fees low; the final route, price impact, and fees always depend on the live quote and network conditions.
Verified program and public code
The deployed Solana Vault Program is visible on Solana Explorer, including its Verified Build status. The source used by this integration is available in the repository as bo/SolanaTradingVault.rs. Verified build information and public source make the program independently inspectable; they are not a guarantee against market loss, software defects, compromised wallets, or third-party protocol risk.
Three addresses: do not confuse them
| Address | Purpose | What to send |
|---|---|---|
| Vault account | Program state and owner/bot/router configuration. | Do not send USDC here. A direct USDC transfer to the Vault account is not a transfer to its token account and can be unrecoverable. |
| Vault USDC deposit token account | The associated token account used as trading capital. | Solana-mainnet USDC for trading. This is the exact USDC address displayed in Connectors and sent by email after setup. |
| Bot fee wallet | Separate technical wallet that signs trade calls and pays network fees. | Only the small SOL/USDC fee funding requested by the interface; it is not the Vault. |
Critical funding rule
Never send USDC to the Vault account address. Send trading USDC only to the USDC deposit token account shown for the Connector. The exact Vault account, owner, USDC deposit account, and fee-wallet information is also delivered by email when the Connector is created. Use Solana mainnet and first send a small test amount.
Set up the Connector
- Install Phantom or another compatible Solana wallet, select Solana mainnet, and keep a small SOL balance in the owner wallet for Vault/token-account rent and your own signed transactions.
- Open Connectors, select DEX Solana Vault, choose the assets, and start Vault initialization. Phantom asks the owner wallet to approve setup transactions.
- After saving, copy the displayed USDC deposit token account, not the Vault account, and fund it with Solana USDC. Keep the setup email for the same addresses and instructions.
- Create a Plan, select this Connector, review the strategy and amount, then start it. The bot executes trades through Jupiter inside the Vault’s permitted token accounts.
Bot fee wallettrade call →Vaultwithdraw all →owner wallet
Balance and network-fee information
Check the live balance in the Dashboard: open Dashboard and use Open position balances by connector. Select this Connector and load the full balance to see the current Vault assets and the part used by the robot in open positions.
Fees are handled by the robot: Solana network fees are paid in SOL from the separate bot fee wallet. When its SOL is low, the robot can buy SOL from available USDC in that fee wallet. The trading capital remains in the Vault USDC deposit token account; keep fee funding separate and follow the notification email for fee warnings.
Permission model
| Operation | Owner | Bot | Limit |
|---|---|---|---|
| Trade | Yes | Yes | Allowed mints, configured Jupiter router, exact Vault token accounts, input and minimum-output checks. |
| Withdraw all allowed assets | Yes | May initiate | Receiver must be the stored owner. |
| Withdraw one token/native SOL to a chosen recipient | Yes | No | Owner signature is required. |
| Change bot, router, or token allowlist; close Vault | Yes | No | Owner signature is required. |
Program instructions and safeguards
initialize_vault(bot, jupiter_router, initial_mints)
Creates one Vault PDA account for the owner, records the bot and Jupiter router, normalizes the initial allowlist, and creates the corresponding associated token accounts. The owner pays setup rent and signs the initialization.
Token readers and allowlist: get_allowed_tokens, is_allowed_token, allowed_tokens_length, add_token, remove_token
Public readers expose the current allowlist. Only the owner can add allowed mints and their token accounts; a token can be removed only after its Vault token account is empty, then that account is closed and rent returns to owner.
set_bot_address and update_routers
Owner-only configuration. The program rejects default/empty bot and router addresses and emits an event for each change.
trade(token_in, token_out, amount_in, min_amount_out, Jupiter data)
Only owner or bot may call it. Both mints must be different and allowlisted, the configured Jupiter program must match, and both input/output accounts must be the expected Vault PDAs. The program checks balance before and after the Jupiter CPI: it cannot spend more than amount_in and must receive at least min_amount_out.
withdraw_all
Owner or bot may initiate it, but the receiving wallet is required to equal the stored owner. It transfers allowed Vault token balances to the owner’s corresponding token accounts and returns withdrawable SOL above the rent minimum to that owner.
withdraw_token and withdraw_native
Owner-only targeted withdrawals. The owner can select a compatible token recipient or native-SOL recipient; native withdrawal preserves the Vault rent minimum.
close_empty_token_accounts and close_vault_account
Owner-only cleanup. Empty associated token accounts can be closed to recover rent; the Vault itself can close only after its allowlist is empty, returning its account rent to owner.
Audit trail and practical checklist
The program emits TokenStatusUpdated, BotAddressUpdated, RouterUpdated, TradeExecuted, FundsWithdrawn, and TokenAccountClosed events. Review the program, account state, and transaction logs in the Explorer when independently auditing activity.
- Verify the program ID, owner, bot, router, and allowed mints before funding.
- Fund only the displayed USDC deposit token account; direct USDC sent to the Vault account may be lost.
- Never share the owner wallet seed phrase or private key; CoinRobot does not need it.
- Keep a small SOL balance in the owner wallet for setup/owner actions, and only the indicated fee funds in the bot wallet.
- For an emergency stop the Plan, then use the Connector withdrawal with the owner wallet. The bot fee wallet is separate from the Vault withdrawal.