Case study: Achieving single-slot Solana execution with 15ms lowest latency

In the high-frequency environment of Solana meme coin trading, the difference between a 10x gain and a missed entry is measured in milliseconds. To challenge this once again, a specialized developer in the HFT and DeFi space asked us to help with a Rust-based copy-trading bot capable of outperforming retail platforms like Axiom Pro and Photon.

The request: Same-slot execution on Solana

The objective was clear: detect target wallet trades, prepare transactions, and fire them with the lowest possible latency. To gain a competitive edge over other bots following high-profile KOL (Key Opinion Leader) wallets, the user needed an infrastructure that eliminated every possible bottleneck between data ingestion and transaction landing.

Solution: Co-located infrastructure and a shred-level parsing

The solution centered on a high-performance architecture leveraging RPC Fast dedicated Solana nodes. By co-locating the bot’s VPS with the RPC Fast node near Frankfurt—a primary Solana network hub—the setup minimized network hop latency.

Instead of relying on standard polling, the bot utilizes a direct stream of shred data and Yellowstone gRPC to intercept network activity before it is even processed into a full block. This allows the bot to parse target wallet activities in real-time, simulating transactions to extract inner instructions and preparing a counter-trade in a single, fluid motion.

Technical stack overview

Technical highlights: Microsecond parsing and multi-path landing

The architecture achieves microsecond-level latencies for parsing and processing. By keeping the API "warm" and utilizing multiple transaction landing paths in parallel, the bot ensures maximum reliability and speed.

Optimized RPC utilization

The bot utilizes a specific set of methods to maintain state without overhead:

• getAccountInfo and getMultipleAccounts: Fetching DEX pool states and Address Lookup Tables (ALT) for V0 transactions.
• simulateTransaction: Used to inspect inner instructions of shreds from target wallets to identify exact swap parameters.
• getLatestBlockhash: Constant monitoring to ensure transactions are ready for immediate broadcast.

The multi-sender strategy

To bypass rate limits and ensure the fastest path to the leader, we implemented a parallel landing strategy. 

While BloXroute is a common choice, the bot primarily used other well-known Solana transaction services’ regional endpoints, which offer ~2 ms latency from the co-located VPS. By rotating multiple API keys to manage rate limits, the bot maintains a consistent 10+ TPS broadcast capability.

Resilience and performance

During stress testing of 100,000 RPC calls, the RPC Fast node maintained sub-1 ms response times. Reliability remained high over a three-month period, with only 2-3 instances of minor downtime lasting a few seconds—monitored via automated Telegram alerts.

Architecture: How it works altogether

The bot’s design strips everything down to the latency-critical path: detect, decode, decide, fire. The description below summarizes the flow.

1. Network and data plane
   • Solana validator/cluster (mainnet) → Shreds/votes/blocks;
   • RPC Fast dedicated Solana node (Frankfurt, non-archive) exposes:
     • Standard JSON-RPC
     • Yellowstone gRPC
     • Shred stream (Jito-compatible feed)
2. Ingestion and parsing layer (VPS co-located with RPC Fast)
   • Co-located VPS (Frankfurt, same DC/region as node)
     
     Rust services:
   • Shred listener—subscribes to shred stream / Yellowstone gRPC and filters for target wallet signatures, relevant programs / DEX pools
   • Instruction decoder:
     • Uses simulateTransaction on candidate shreds
     • Extracts inner instructions: token swap params, pool addresses, amounts/slippage/side (buy/sell)
   • State fetcher, JSON-RPC to RPC Fast node:
     • getAccountInfo → DEX pool state, nonce accounts
     • getMultipleAccounts → ALTs for v0 TXs
     • getBalance → base wallet balance
     • getTokenAccountBalance → PnL and risk checks
     • getMinimumBalanceForRentExemption → nonce account creation
     • getLatestBlockhash, getSignatureStatus(es) → liveness/slot sync
3. Strategy and decision engine
   
   Strategy service (Rust):
   • Maintains in-memory model per tracked wallet: position estimates, risk limits, copy rules (follow size, cap per trade, blacklist tokens);
   • On target activity detection:
     • Validates: Pool liquidity/slippage window, wallet balance/exposure caps;
     • Builds transaction: v0 TX with ALTs from getMultipleAccounts, nonce-account flow when needed.
4. Transaction builder and multi-sender layer
   • TX builder (Rust) signs TX locally and prepares parallel send payloads for:
     • Helius Sender (Frankfurt endpoint, primary)
     • BloXroute trading API (secondary / paid)
     • QuickNode Transaction Fastlane (secondary/free)
   • TX senders
   • Helius Sender:
     • Managing provider-side rate limits through key rotation;
     • Latency from VPS: ~2 ms to endpoint (kept warm);
     • Observed landing: Typical: 200–300 ms, best: ~15 ms, usually within 1 slot.
   • BloXroute—used for redundancy and path diversity;
   • QuickNode Fastlane: Free alternative path;
   • All three run in parallel for each critical TX:
     • First confirmed/landed path “wins”;
     • Others watched via getSignatureStatus(es) for diagnostics.
5. Monitoring, reliability, and alerts
   
   Health and latency watchdog
   • Periodic RPC probes:
     • Burst tests of 10k–100k JSON-RPC calls
     • Observed: sub-1 ms consistent latency, no rate limiting on signatures
   • Node uptime: Over ~3 months: Only 2–3 short outages for a few seconds each, detected via automated Telegram alerts.
     
     PnL and balance tracking
   • Uses: getTokenAccountBalance and getBalance
   • Data storage:
     • Old Faithful for epoch downloads;
     • Used for backtesting and new strategy design.
6. Historical data and research path
   
   For non-real-time analytics and backtesting:
   • QuickNode (archive/historical access);
   • Whole-epoch downloads: Local filtering and transformation for research datasets;
   • RPC Fast node reserved for: Live trading, low-latency reads, avoiding heavy historical workloads on the trading path.

Results: Landing right behind the target

The combination of kernel-level tuning, co-location, and high-performance nodes delivered measurable dominance in the mempool.

• Parsing & Processing latency: Combined microsecond-level execution.
• Transaction landing: Averaged 200-300 ms, with the lowest recorded landing at 15 ms.

• Execution accuracy: Consistently achieved landing in the same slot or the +1 slot immediately following the target wallet.

• Competitive edge: Successfully front-ran or followed well-known Kolscan traders who rely on standard retail infrastructure.

Client perspective: Direct speech

Node performance is great. No complaints here. I initially got the service because I wanted to build one of the fastest copy-trading bots available in the Solana ecosystem, and even for well-known wallets (like Kolscan traders).

I consistently secured the same slot and, in most cases, landed +1 right behind the target wallet. I am currently working on some alternate bot design/strategies, and I see myself retaining and upgrading the service in the near future. 

Support has been great, too. The entire RPCFast team has been very responsive and helpful in solving any issues. 

Build your high-load infrastructure

If you are building HFT bots or DeFi protocols where every millisecond impacts your PnL, your infrastructure is your most important asset. RPC Fast provides the dedicated, low-latency Solana nodes required for professional-grade execution.

‍