Solana RPC setup with RPC Fast: The complete playbook for bots, HFT, and MEV searchers

Solana bots, HFT systems, and MEV searchers need JSON-RPC for reads and simulation, Yellowstone gRPC for structured live data, Aperture or Shredstream for earlier transaction visibility, and Beam or SWQoS routes for better transaction delivery under congestion. Although HA low-latency Solana RPC setup is mostly an “it depends” story, there are common features and best practices we’ve tested and included in the RPC Fast. 

TL;DR

• Use JSON-RPC for targeted reads, simulation, blockhashes, fee checks, and transaction submission.
• Avoid broad polling for bot signals. Use WebSockets for light updates and Yellowstone gRPC for high-volume backend ingestion.
• Use Aperture or Shredstream when earlier transaction visibility changes execution quality.
• Use Beam when landing rate matters more than simple request success.
• Move to dedicated when shared SaaS limits, regional latency variance, or method profile becomes an obvious bottleneck.
• Measure p95/p99, not averages. For HFT and MEV, the bad tail decides execution quality.

On the infrastructure side, RPC Fast’s Solana stack follows that split: shared SaaS for fast onboarding, Stream and Aperture tiers for real-time and latency-sensitive workloads, and dedicated Solana nodes or HA clusters when isolation, custom plugins, and failover become part of the business model.

Now, let’s proceed from newcomer to advanced-level setup with RPC Fast.

What you need before RPC Fast works in your stack

RPC Fast gives you the Solana infrastructure endpoint, but it does not replace your application-side execution logic. Before you benchmark latency or landing rate, make sure three layers are already in place: access, client integration, and Solana transaction logic.

1. Access: Endpoint, plan, and credentials

First, create an RPC Fast account, open the Solana dashboard, select the appropriate plan, and copy the required endpoint. 

At minimum, you need:

• HTTP JSON-RPC endpoint for reads, simulation, blockhashes, fees, transaction submission, and confirmation.
• WebSocket endpoint if your app uses standard Solana PubSub subscriptions.
• Yellowstone gRPC endpoint and token when using structured, high-throughput streams.
• Aperture / Shredstream access if you need earlier transaction visibility.
• Aperture TxStream for real-time deshredded Solana txs. 
• Beam if your workload depends on transaction delivery performance.

The plan matters. Start works for basic connectivity and discovery, for light PoC projects. Focus unlocks heavier RPC usage. Stream adds Yellowstone gRPC. Aperture adds the low-latency streaming layer and is ideal for HFT teams, trading bots, and finding MEV opportunities. Dedicated or HA infrastructure becomes relevant only when shared SaaS limits, custom plugins, regional latency, or failover become production constraints. 

We’ll review all the details on that below.

2. Client integration: SDKs, stream consumers, and connection handling

RPC Fast will not process your workload correctly unless your client is built for the interface you use. For JSON-RPC, you need a Solana client such as:

• @solana/web3.js for TypeScript/JavaScript systems;
• solana-client / Solana crates for Rust systems;
• Direct HTTP JSON-RPC calls for custom infrastructure.
• Endpoint configuration per environment;
• Request timeouts;
• Retry rules;
• Rate-limit handling;
• Response validation;
• Method-level CU tracking.

Use JSON-RPC for targeted reads, blockhashes, simulation, fee checks, submission, and confirmation. Do not use it as the main event-ingestion layer for trading signals.

For Yellowstone gRPC, you need:

• Use an official Rust client;
• Endpoint URL;
• Access token;
• Yellowstone proto files;
• A gRPC client in Go, Rust, TypeScript, or another backend language;
• Narrow filters for accounts, programs, transactions, or slots;
• Reconnect and backpressure handling.

Yellowstone is the production ingestion layer when polling becomes wasteful. Start with narrow filters, then expand only after measuring event rate, queue depth, and consumer lag.

For WebSockets, you need:

• Subscription lifecycle management;
• Reconnect logic;
• Guardrails for duplicate or delayed events;
• Replay or resync strategy after disconnects;
• Commitment-level strategy: processed, confirmed, or finalized.

WebSockets fit lightweight reactivity. They are not the right default for high-volume transaction intelligence.

For Aperture TxStream, your backend needs:

• Use an official Rust client;
• Aperture TxStream endpoint and credentials;
• gRPC-capable stream consumer;
• Subscription scope for the target transaction flow;
• Decoded transaction processing pipeline;
• ALT-aware handling for versioned transactions;
• Optional real-time simulation handling;
• Deduplication and slot-aware ordering;
• Reconnect, replay, and cache resync logic;
• Metrics for p95/p99 stream lag, queue depth, reconnects, decoded transaction throughput, and missed opportunities.

TxStream belongs in the latency-sensitive path. Its value is not only earlier access to transaction flow. It streams decoded transactions, resolves Address Lookup Tables (ALT) for versioned transactions, and supports opt-in real-time simulation for better trading signals. RPC Fast has also announced ALT resolution for Aperture gRPC, reducing client-side work around versioned transactions.

That changes the client-side architecture. With raw Shredstream, your team still owns more decoding and transaction reconstruction work. With TxStream, the consumer receives a cleaner signal and spends more engineering time on filtering, strategy logic, simulation decisions, and routing.

For Beam, SWQoS, or Jito paths, your application still needs:

• Transaction construction;
• Fresh blockhash management;
• Signing;
• Compute-budget logic;
• Priority-fee strategy;
• Route-specific tip logic;
• Submission policy;
• Confirmation tracking;
• Retry and expiry handling;
• Landed / failed / dropped metrics per route.

The split is simple: RPC Fast provides the transport and infrastructure path. Your system provides the client logic that turns RPC responses, streams, decoded transactions, simulations, and route results into execution decisions.

3. Solana execution logic: Signing, fees, simulation, and confirmation

RPC Fast does not build, sign, price, or validate your transactions. Your system must handle that. A working bot or MEV pipeline needs:

For transaction-heavy systems, this is the minimum execution loop:

Beam, with SWQoS and Jito inside, gives users plenty of routing choices. They do not fix stale blockhashes, bad signatures, underpriced compute, broken simulations, or weak retry logic.

Setup rule

RPC Fast handles the infrastructure path to Solana. Your side must handle the execution path inside your application.

The clean split is:

The practical test is simple: before optimizing latency, confirm that your app can fetch a blockhash, simulate a transaction, sign it, send it through the selected route, track confirmation, and explain every failure state.

The correct Solana RPC setup layers

A production Solana trading stack should not push every task through a single HTTP endpoint. That creates polling pressure, stale reads, noisy retries, and limited transaction observability during periods of volatility.

We need to map out all the available options here:

With these features implemented, your project will experience fewer stale signals, fewer wasted retries, better route selection, and a clearer path from prototype to production.

Start with JSON-RPC, but do not design the bot around polling

JSON-RPC is still the base layer. Your bot needs it for:

‍

We state JSON-RPC as the direct Solana node interface for reads, simulation, transaction submission, fees, balances, signatures, blocks, and account data. Most Solana RPC methods cost 1 Compute Unit on RPC Fast SaaS, while getProgramAccounts costs 10 CU and belongs in the “heavy method” category.

A safe first test:

curl -X POST "YOUR_RPC_FAST_SOLANA_ENDPOINT" \
-H "Content-Type: application/json" \
-d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getLatestBlockhash",
  "params": [
    {
      "commitment": "confirmed"
    }
  ]
}'

For bots, this call is not a demo. It is part of the execution loop. A stale blockhash means failed or dropped transactions. A slow blockhash path means weaker reaction time.

The heavy methods matter, and that’s why 

getBalance and getLatestBlockhash are targeted. getProgramAccounts, getTokenAccountsByOwner, getTokenAccountsByDelegate, and getTokenLargestAccounts scan broader state and return larger payloads.

RPC Fast places these heavy methods behind paid plans; on Start, getProgramAccounts returns an upgrade-required error, and some heavy program IDs remain restricted even on paid plans.

The most common setup mistake is treating all Solana RPC methods as operationally equal. They are not.

For execution teams, this matters because broad account scans degrade precisely when your system needs clean signals. Use this pattern instead:

For bots and MEV systems, JSON-RPC should answer specific questions. It should not act as the main event bus.

Choose the RPC Fast tier by workload shape

Choose your tier based on the infrastructure capabilities your workload needs, not by team size. 

RPC Fast’s Solana SaaS plans are structured by workload maturity: Start includes 1.5M monthly CU and 15 req/s; Focus includes 12M CU and 50 req/s; Stream includes 60M CU and 150 req/s; Aperture includes 120M CU and 500 req/s. Yellowstone gRPC starts on Stream, while Shredstream and Aperture access sit in the Aperture tier.

The important threshold is not “more users,” but a change in dependency:

• When live data becomes central, move to Stream. 
• When latency competition begins, move to Aperture. 
• When shared variance becomes unacceptable, move to the dedicated node option.

Recommended setup by team maturity

Do not start with the most complex setup. Start with the lightest layer that solves the current bottleneck, then upgrade when the bottleneck changes.

WebSocket vs Yellowstone gRPC vs Aperture

Solana WebSockets use JSON-RPC 2.0 over a persistent connection and support methods such as accountSubscribe, programSubscribe, logsSubscribe, signatureSubscribe, and slotSubscribe. Many subscription methods accept a commitment parameter and default to finalized where applicable.

processed returns the newest state with the lowest latency but weakest certainty, confirmed waits for a supermajority vote, and finalized waits until the state is effectively irreversible.

Use processed for speed-sensitive monitoring, confirmed for most production workflows, and finalized when correctness matters more than latency.

‍

That is enough for lightweight reactivity. It is not enough for high-volume search infrastructure.

RPC Fast offers Yellowstone gRPC as the first major real-time upgrade beyond standard RPC and WebSockets. The documented setup uses a Stream plan, Aperture plan, or dedicated node; an endpoint; an access token; grpcurl; Yellowstone proto files; and a geyser.Geyser/GetSlot connectivity test.

Minimal Yellowstone test:

X_TOKEN="YOUR_TOKEN"
YELLOWSTONE_ENDPOINT="YOUR_YELLOWSTONE_GRPC_ENDPOINT"

grpcurl \
  -proto geyser.proto \
  -H "x-token: ${X_TOKEN}" \
  ${YELLOWSTONE_ENDPOINT} geyser.Geyser/GetSlot

After that, subscribe narrowly. Do not subscribe to everything because “more data” feels safer. More unfiltered data means more queue pressure, higher memory usage, slower consumers, and larger replay windows after reconnects.

Aperture and Shredstream belong in the latency path

Aperture and Shredstream have different endpoints and serve a different purpose: earlier transaction visibility. Yellowstone gRPC stays as a strong default for structured backend streams.

‍

We describe Aperture TxStream as a custom low-latency Solana data and shred streaming tool, available in the Aperture plan.

Please note: Aperture gRPC in its Yellowstone-compatible version remains available for existing Aperture plan users, although it will be deprecated in the near future as Aperture TxStream becomes our primary low-latency streaming protocol.

‍

Aperture TxStream delivers ready-to-consume, decoded Solana transactions instead of raw shreds, removing the deshredding and transaction-reconstruction layer required with a standard Shredstream integration. 

It resolves ALT before delivery, giving trading systems complete account context without additional RPC lookups or local ALT-resolution logic. With opt-in real-time simulation, TxStream adds execution results directly to the feed, helping bots reject weak opportunities and act on higher-quality trading signals.

We also state that Shredstream provides reconstructed entries from Solana shreds and delivers transactions roughly 50–100 ms earlier on average than Yellowstone gRPC, while also including more transactions such as failed transactions and votes.

That difference matters in:

‍

The tradeoff: earlier signals need stronger downstream discipline. You need deduplication, slot-aware ordering, replay protection, and a clear rule for when early data becomes actionable.

Aperture is not the right first integration for a simple app. It is the right evaluation path when your system already consumes live Solana data and now needs lower-latency variance.

Priority fees need account-local context

For transaction-heavy systems, fee estimation should be account-aware. Solana’s getRecentPrioritizationFees returns recent prioritization-fee samples and accepts optional writable account addresses. If you pass accounts, the response reflects observed fees for transactions that locked all supplied accounts as writable. The node fee cache stores samples from up to 150 blocks.

That matters because many bots overpay by treating fee pressure as global.

A better execution loop:

1. Identify writable accounts touched by the strategy.
2. Query recent prioritization fees for those accounts.
3. Simulate the transaction.
4. Set compute unit limit based on simulated CU usage.
5. Add a safety margin.
6. Set priority fee and route-specific tip.
7. Submit through one or more delivery routes.
8. Track confirmation and landing results by route.

Solana’s compute-budget guidance recommends simulating the transaction, then adding a 10% safety margin to the measured CU consumption. Priority fee is based on the requested compute unit limit, not the actual units used, so overestimating the limit means paying for unused compute.

For HFT, fee efficiency compounds. Overpaying on every attempt reduces strategy margin. Underpaying during congestion reduces landing rate. The correct target is not the lowest fee. It is the cheapest fee that preserves execution quality for the accounts you touch.

Beam: Transaction sending is routing, not an API call

A fast RPC response does not guarantee transaction landing. Under congestion, the transaction still needs a good route to the current or upcoming leader.

RPC Fast separates this from standard sendTransaction. Standard sending fits ordinary dApps and backend flows that are not competing on milliseconds. Beam addresses the harder problem of delivery performance under congestion.

Stake-Weighted Quality of Service, as a part of Beam, gives stake-weighted priority to validator traffic. Solana’s own SWQoS guide says a validator with 1% stake gets the right to transmit up to 1% of packets to the leader, and SWQoS should be enabled between trusted RPC nodes and validators rather than by staking RPC servers directly. The same guide states that SWQoS applies stake-weighted priority to 80% of a leader’s TPU capacity.

RPC Fast’s docs describe SWQoS benefits through partner providers, including a bloXroute integration with a 0.001 SOL tip per transaction plus Solana network priority fees.

Speed First

FASTEST

BEAM scores every provider in real time — landing rate and latency — so your tx takes the best-scoring path that slot. Best path wins.

Protection First

MEV_PROTECT

Sandwich-proof submission. Propagates through protected infra that kills front-running by design.

Beam modes

‍

Use Beam when the transaction is already built correctly, and the remaining bottleneck is route performance. Beam does not replace:

‍

For searchers, the metric is not HTTP 200. The metric is a landed transaction per opportunity, by route, under congestion.

Where Jito from Beam fits for MEV searchers

Jito is a separate execution path for searchers using bundles and the Block Engine via Beam. Jito docs describe bundles as groups of up to 5 transactions executed sequentially and atomically. They compete on tips, and Jito runs parallel auctions at 50 ms ticks based on account locking patterns.

Jito docs also state a minimum 1000 lamport tip for bundles, with higher tips often needed during high demand.

The practical recommendation: do not use bundles by default. Use them when atomic execution or revert protection changes the strategy outcome. For simple swaps, liquidations, or routing flows, Beam plus correct priority fees often gives a simpler operating model.

Production architecture for a Solana trading bot

A production-grade Solana bot with RPC Fast should look like this:

The cache is not optional. If every opportunity triggers fresh RPC reads, the bot becomes slow and expensive. Keep hot account state in memory, feed it from streams, then use JSON-RPC for validation, simulation, blockhashes, and confirmation.

When shared SaaS stops being enough

Shared SaaS is the right starting point for most teams. Dedicated infrastructure starts making sense when the workload needs isolation, custom plugins, no shared SaaS constraints, or HA design.

RPC Fast dedicated Solana nodes are positioned for validators, blockchain analytics, trading, HFT, real-time transaction tracking, and high-load systems. 

Dedicated setups support requirements such as Yellowstone gRPC/Geyser, Jito Shredstream, Jupiter Metis / Raptor binary, SWQoS integration, custom indexing, node-level tuning, and direct infrastructure support. 

RPC Fast lists Agave as the default node client, with Jito client support available on request. EU dedicated Solana node pricing starts from $2,200/month for a 512 GB RAM setup including bare-metal server cost, setup, and maintenance.

Use a dedicated node when:

• Shared rate limits affect execution quality;
• You need custom Geyser plugins;
• Regional placement affects p95/p99 latency;
• Method mix creates noisy-neighbor sensitivity;
• Compliance or internal policy requires isolation;
• Your team needs direct DevOps-level communication.

Use an HA cluster when downtime, maintenance, or regional failover affects revenue. RPC Fast’s docs describe HA clusters with 2+ nodes, load balancing, autoscaling, speed optimization, geo-distribution, and maintenance handled by the RPC Fast team.

Production readiness checklist for bots, HFT, and MEV

A working endpoint is not a production setup. Track the system by failure mode.

We recommend tracking CU usage, heavy-method frequency, rate-limit errors, WebSocket concurrency, gRPC streams, retries, stream lag, send latency, confirmation latency, landing rate, failed transactions, dropped transactions, blockhash expiration, priority fee, tip, route, and provider-level variance.

The operator rule: benchmark routes against each other during congestion. A route that performs well during quiet periods tells you little about meme coin volatility, liquidation bursts, or major market moves.

Brush up your setup. Ask us for support

Solana RPC setup for bots, HFT systems, and MEV searchers should match the workload stage, not a generic “fast endpoint” checklist.

• For correctness, use RPC Fast JSON-RPC for blockhashes, simulation, fee checks, targeted reads, submission, and confirmation. Keep this layer narrow. Broad polling turns RPC into a bottleneck.
• For signal freshness, move live data into WebSockets, Yellowstone gRPC, Aperture, or Shredstream. WebSockets fit lightweight updates and front-end apps. Yellowstone fits structured backend ingestion. Aperture and Shredstream fit latency-sensitive systems where earlier transaction visibility affects execution.
• For transaction landing, treat sending as route selection. SWQoS partner paths, standard RPC, and Jito serve different execution cases. Measure landing rate by route rather than assuming a single path wins under every market condition.
• For infrastructure control, move from shared SaaS to dedicated nodes or HA clusters only when the workload proves the need: custom plugins, isolated hardware, regional latency targets, failover, or lower p95/p99 variance.
• For operating discipline, track the metrics that expose execution quality: stream lag, stale blockhashes, dropped transactions, confirmation latency, route variance, fee efficiency, and landed cost per opportunity.

The practical setup path is simple: start with targeted JSON-RPC, add streaming when polling becomes wasteful, add Beam when landing variance hurts execution, and go dedicated when shared infrastructure limits business performance.