TL;DR:
- Solana produces a block every 400 ms — your bot must detect, build, sign, and deliver a transaction inside that window.
- Public RPC endpoints put you ~200 ms behind before your code runs. Production bots pair a low-latency VM with a premium Solana RPC provider (ThorNode, Helius, QuickNode) or a self-hosted node.
- A single-strategy bot needs 4 vCPU / 8 GB RAM — and a dedicated network port, not shared bandwidth.
- The latency stack: same-region RPC,
skipPreflight: true, cached blockhash, parallel submission to 2–3 endpoints, dynamic priority fees. - Arct Cloud's vm.tiny ($34.99/mo) ships a dedicated 10 Gbps uplink, AMD EPYC Zen 4, and NVMe Gen4 — the right baseline for a bot server.
A Solana trading bot is an automated program that watches on-chain state and submits transactions faster than competing traders. On Solana, the difference between a profitable bot and a consistently losing one often comes down to milliseconds. Strategy logic matters, but if your transaction reaches the leader validator 80ms after a competitor's, you lose. The RPC layer is where most builders bleed latency without realizing it.
This guide covers the full stack: server selection, RPC node setup, transaction submission mechanics, and the configuration decisions that actually reduce end-to-end latency in 2026.
Why RPC Infrastructure Determines Your Bot's Edge
Solana produces a block every 400ms. Inside that window, your bot has to detect an opportunity, construct a transaction, sign it, and get it to the current or upcoming leader. Every millisecond of avoidable latency shrinks that window.
Three sources account for most of it:
- Network distance between your server and the Solana leader validator
- RPC node response time for
getLatestBlockhash, account subscriptions, and transaction forwarding - Transaction propagation from your RPC node to the leader
Running your bot on a shared cloud instance with a shared network port and a public RPC endpoint puts you roughly 200ms behind before your code executes.
Architecture Overview
Most production Solana trading bots in 2026 follow one of two patterns:
Architecture A: Bot + Dedicated RPC Node on the same server or LAN
- Your bot connects to
localhost:8899 - Zero network hop for RPC calls
- High memory requirement — Solana RPC nodes need 256 GB+ RAM for full state
Architecture B: Bot on a low-latency VM + Premium RPC provider via WebSocket
- Practical for most builders who can't justify a full validator node
- Works well when your RPC provider has a node in the same region as your bot server
- Requires careful provider selection and solid connection management
Most teams start with Architecture B and move toward A once volume justifies the cost.
Choosing Your RPC Strategy
Everything your bot does goes through the Solana RPC API — JSON-RPC over HTTP plus WebSocket subscriptions. Where that API is served from sets your latency floor.
Public RPC Endpoints
Don't use them in production. api.mainnet-beta.solana.com is rate-limited, shared across thousands of clients, and will drop WebSocket subscriptions under load. Fine for testing. That's it.
Dedicated Private RPC Nodes
Running your own node gives you full control over request priority, no rate limits, and the ability to co-locate with your bot. The trade-off is operational overhead and hardware cost.
Minimum specs for a Solana RPC node in 2026:
- 256 GB RAM (512 GB recommended for the accounts index)
- High-core-count CPU with strong single-thread performance
- NVMe storage with sustained write throughput above 2,000 MB/s
- 1 Gbps+ network uplink, ideally 10 Gbps
The storage requirement alone disqualifies most budget VPS providers. You need consistent NVMe performance — not burst-capable shared storage that degrades under concurrent load.
Third-Party RPC Providers
Providers like ThorNode, Helius, QuickNode, Triton One, and Alchemy offer dedicated Solana RPC endpoints with staked connections and transaction forwarding optimizations. If you're not running your own node, these are worth using. Look for:
- WebSocket subscriptions with low reconnect latency
sendTransactionwithskipPreflightand direct leader forwarding- Staked validator connections for priority transaction propagation
- Regional endpoints close to major Solana validator clusters
ThorNode, for example, checks all four boxes: staked connections backed by 4M+ SOL for stake-weighted QoS, an optimized transaction sender, and gRPC streaming (ThorStreamer) with ShredStream support for HFT-grade data feeds across three continents.
Pair a quality RPC provider with a bot server in the same geographic region. A Tokyo RPC endpoint paired with a Frankfurt bot server adds 200ms+ in round-trip time. That's not recoverable.
Setting Up Your Bot Server
Hardware Requirements
Your bot process is lightweight compared to a full RPC node — but that doesn't mean a 1 vCPU shared instance cuts it. You need:
- At least 4 vCPU with strong single-thread performance
- 8 GB RAM minimum for a single-strategy bot; 16 GB+ if you're running multiple strategies or maintaining local account state
- NVMe storage for fast log writes and local caching
- A dedicated network port, not shared bandwidth
The network port matters more than most builders account for. If your VM shares a 1 Gbps uplink with 50 other tenants, transaction submission latency becomes unpredictable. You want dedicated throughput with no contention.
Arct Cloud includes a dedicated 10 Gbps port on every plan — including the entry-level vm.tiny at $34.99/mo. DDoS protection is included by default. No shared bandwidth pool. For a Solana bot where consistent sub-millisecond network jitter matters, that's the right baseline.
The vm.tiny (4 vCPU, 8 GB RAM, 80 GB NVMe) handles most single-strategy bots. The vm.medium (8 vCPU, 16 GB RAM, 160 GB NVMe at $69.99/mo) gives you room for multiple strategies and local account caching. Every plan runs on AMD EPYC Zen 4 with NVMe Gen 4 storage — up to 7,000 MB/s read/write.
OS and Runtime Setup
Ubuntu 24.04 LTS is the most practical choice in 2026. Solana tooling, Rust, and Node.js all have well-tested paths on it.
# Update and install dependencies
apt update && apt upgrade -y
apt install -y build-essential pkg-config libssl-dev curl git
# Install Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env
# Install Node.js 22 via nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
nvm install 22
nvm use 22
# Install Solana CLI
sh -c "$(curl -sSfL https://release.solana.com/stable/install)"
export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH"
Verify your Solana CLI version:
solana --version
# solana-cli 1.18.x (or later)
Running a Solana Validator or RPC Node
Running your own RPC node requires 256 GB+ RAM — outside the scope of a standard VPS plan. If you need a high-memory dedicated setup, contact the Arct Cloud sales team for a custom configuration.
For most bot builders, the practical path is a bot server on a standard VM paired with a third-party RPC provider.
If you do run your own node, the key flags for a non-voting RPC node:
solana-validator \
--no-voting \
--rpc-port 8899 \
--rpc-bind-address 0.0.0.0 \
--enable-rpc-transaction-history \
--enable-extended-tx-metadata-storage \
--account-index program-id \
--account-index spl-token-owner \
--account-index spl-token-mint \
--full-rpc-api \
--private-rpc \
--limit-ledger-size 50000000 \
--log /var/log/solana/validator.log
--private-rpc keeps your node out of the public validator set. --limit-ledger-size controls disk usage — tune it against your available storage.
Bot Logic and Transaction Submission
Listening for Opportunities
WebSocket subscriptions are the right mechanism for real-time opportunity detection. Polling getAccountInfo on an interval adds unnecessary latency and burns through rate limits.
Using @solana/web3.js v2 (the current standard in 2026):
import { createSolanaRpc, createSolanaRpcSubscriptions, address } from '@solana/web3.js';
const rpc = createSolanaRpc('https://your-rpc-endpoint.com');
const rpcSubscriptions = createSolanaRpcSubscriptions('wss://your-rpc-endpoint.com');
// Subscribe to account changes
const subscription = await rpcSubscriptions
.accountNotifications(address('YourTargetAccountPubkey'), { commitment: 'processed' })
.subscribe({ abortSignal: AbortSignal.timeout(60_000) });
for await (const notification of subscription) {
handleAccountChange(notification);
}
Use commitment: 'processed' for opportunity detection — it's the fastest confirmation level. Only validate with confirmed or finalized when you need certainty about a completed trade.
Building and Sending Transactions
import {
createSolanaRpc,
createKeyPairSignerFromBytes,
pipe,
createTransactionMessage,
setTransactionMessageFeePayerSigner,
setTransactionMessageLifetimeUsingBlockhash,
appendTransactionMessageInstructions,
signTransactionMessageWithSigners,
getBase64EncodedWireTransaction,
} from '@solana/web3.js';
const rpc = createSolanaRpc('https://your-rpc-endpoint.com');
async function sendTransaction(instructions: any[], signer: any) {
const { value: latestBlockhash } = await rpc
.getLatestBlockhash({ commitment: 'processed' })
.send();
const transactionMessage = pipe(
createTransactionMessage({ version: 0 }),
(tx) => setTransactionMessageFeePayerSigner(signer, tx),
(tx) => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, tx),
(tx) => appendTransactionMessageInstructions(instructions, tx),
);
const signedTransaction = await signTransactionMessageWithSigners(transactionMessage);
const encodedTransaction = getBase64EncodedWireTransaction(signedTransaction);
const signature = await rpc
.sendTransaction(encodedTransaction, {
encoding: 'base64',
skipPreflight: true,
maxRetries: 0,
preflightCommitment: 'processed',
})
.send();
return signature;
}
skipPreflight: true removes the simulation round-trip before submission. You're trading preflight safety for speed. For a bot with well-tested instruction logic, that's the right call. maxRetries: 0 hands retry control back to you — which matters when you're submitting to multiple RPC endpoints simultaneously.
Priority Fees and Compute Units
In 2026, priority fees are not optional for competitive strategies. Set them wrong and your transactions sit at the bottom of the queue.
import {
ComputeBudgetProgram,
TransactionInstruction,
} from '@solana/web3.js';
// Set compute unit limit
const computeLimitInstruction = ComputeBudgetProgram.setComputeUnitLimit({
units: 200_000, // Measure actual usage and set this tightly
});
// Set priority fee (microlamports per compute unit)
const priorityFeeInstruction = ComputeBudgetProgram.setComputeUnitPrice({
microLamports: 100_000, // Adjust based on current network conditions
});
Measure actual compute unit consumption with simulateTransaction during development. Too high and you waste fee budget. Too low and the transaction fails mid-execution.
For dynamic priority fees, query recent prioritization fees on the accounts your transaction touches:
const fees = await rpc
.getRecentPrioritizationFees([address('TargetProgramOrAccount')])
.send();
const p75Fee = fees
.map((f) => f.prioritizationFee)
.sort((a, b) => Number(a) - Number(b))[Math.floor(fees.length * 0.75)];
Use the 75th percentile as your floor under normal conditions. During congestion, move to the 90th.
Reducing Latency at Every Layer
Work through each layer in order:
Region selection. Deploy your bot server where Solana validator stake is concentrated. As of 2026, that's primarily North America and Europe. For strategies targeting Asian DEX liquidity, Tokyo or Singapore makes sense. Arct Cloud has regions across North America, Europe, and Asia Pacific — you can match server location to validator geography without switching providers.
Connection management. Keep WebSocket connections alive. Reconnection costs 50–200ms. Send heartbeat pings every 30 seconds to prevent idle disconnects.
Parallel submission. Send your transaction to multiple RPC endpoints at the same time. The first one to land wins. Two or three endpoints in the same region is a reasonable setup.
// Submit to multiple endpoints in parallel
const results = await Promise.allSettled([
rpc1.sendTransaction(encodedTx, opts).send(),
rpc2.sendTransaction(encodedTx, opts).send(),
rpc3.sendTransaction(encodedTx, opts).send(),
]);
Blockhash caching. Don't fetch a fresh blockhash on every transaction at high submission frequency. Cache it and refresh every 5–10 seconds. A blockhash is valid for 150 blocks (~60 seconds). Fetching per-transaction adds a full RPC round-trip to your critical path.
Process priority. Set your bot process to high CPU priority on the host OS.
nice -n -10 node bot.js
# or for real-time priority
chrt -f 50 node bot.js
On a dedicated VM with no noisy neighbors, this matters less. On shared hardware, it can recover 5–20ms under load.
Monitoring and Reliability
A bot that goes down during a high-volume period and sits unnoticed for 20 minutes is a bot that loses money. Instrument everything.
Transaction confirmation tracking. Log every signature you submit. Track confirmation status asynchronously. Alert on anything that doesn't confirm within 3 slots.
RPC endpoint health. Monitor getLatestBlockhash response times per endpoint. If p95 latency on any endpoint exceeds 100ms, route around it automatically.
Process supervision. Use systemd or pm2 to restart on crash.
# systemd unit file: /etc/systemd/system/trading-bot.service
[Unit]
Description=Solana Trading Bot
After=network.target
[Service]
Type=simple
User=bot
WorkingDirectory=/home/bot/trading-bot
ExecStart=/usr/bin/node dist/index.js
Restart=always
RestartSec=5
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target
systemctl enable trading-bot
systemctl start trading-bot
journalctl -u trading-bot -f
Metrics. Track transactions per minute, success rate, average confirmation time, and priority fee spend. A Prometheus + Grafana stack on the same VM works well. The vm.medium at $69.99/mo has enough headroom to run your bot, a local metrics stack, and a log aggregator without resource contention.
FAQs
What server specs do I actually need to run a Solana trading bot? For a single-strategy bot without a local RPC node, 4 vCPU and 8 GB RAM is sufficient. Running multiple strategies or caching account state locally pushes that to 8 vCPU and 16 GB RAM. The network port matters as much as compute — you want a dedicated uplink, not shared bandwidth.
Do I need to run my own Solana RPC node? Not necessarily. A dedicated RPC node requires 256 GB+ RAM and real operational overhead. Most bot builders start with a quality third-party provider and move to self-hosted only when volume justifies it. The critical factor is co-locating your bot server with your RPC provider in the same region.
What's the difference between processed, confirmed, and finalized commitment?
processed reflects the latest block the node has seen — fastest, but not yet voted on. confirmed means the block has received a supermajority of stake votes. finalized means it's irreversible. Use processed for opportunity detection, confirmed or finalized when you need certainty about a completed trade.
Why use skipPreflight: true when sending transactions?
Preflight simulation adds a full RPC round-trip before submission. For a bot with well-tested instruction logic running in production, that round-trip costs latency without adding meaningful safety. Disable it in production, keep it on during development.
How do I set priority fees dynamically?
Query getRecentPrioritizationFees on the accounts your transaction touches and use the 75th percentile as your floor. During congestion, move to the 90th. A static fee means you're either overpaying during quiet periods or losing priority when it counts.
Can I use this same stack for a Solana sniper bot? Yes. A sniper bot — one that targets new token launches and liquidity adds — is the same architecture with a different detection layer: you subscribe to pool-creation events instead of price or account updates. Detection and submission latency matter even more, so the dedicated-port and same-region-RPC guidance applies doubly.
Should I build my own bot or use a Telegram bot like Trojan? Telegram bots such as Trojan are the fast path: no infrastructure to run, but shared execution, per-trade fees, and no control over routing or latency. Building your own bot costs setup time and a server, and buys you private strategy logic, your own RPC path, and full fee control. This guide is for the second path.
What regions should I deploy my bot server in? Match your server region to where Solana validator stake is concentrated. For most strategies, North America or Europe is correct. For strategies targeting Asian liquidity pools, deploy in Asia Pacific. Arct Cloud covers all three, so you can match precisely without switching providers.
Can I pay for a VPS with crypto to keep infrastructure costs off traditional payment rails? Yes. Arct Cloud accepts Bitcoin, Ethereum, and USDT alongside Visa and Mastercard. Monthly billing, no contracts, cancel anytime.
What This Stack Comes Down To
Get the infrastructure right first. Strategy logic is irrelevant if your transactions arrive late. Deploy in the right region, use a dedicated network port, cache your blockhash, submit to multiple endpoints in parallel, and set priority fees dynamically.
The rest is execution.
If you're ready to deploy a bot server with a dedicated 10 Gbps port, AMD EPYC Zen 4 hardware, and NVMe Gen 4 storage, Arct Cloud provisions in under 60 seconds. Pick your region, pick your OS, and your server is SSH-ready before you finish reading the docs.