Solana Trading Bot RPC Requirements by Workload

Buying "the fastest RPC" is not an architecture. A copy bot watching ten wallets, a DLMM worker maintaining pool state, and a searcher competing on the earliest shred all use Solana data. Their failure budgets are different.

This guide turns the workload into a requirements sheet. Use it before a provider comparison so the test measures the product you are building, not the largest feature list.

Every bot has three separate paths

Treat these as independent contracts:

READ:   bootstrap state -> quotes -> simulation -> authoritative reconciliation
EVENT:  account/transaction/slot updates -> local model -> decision trigger
SEND:   signed transaction -> delivery path -> signature status -> final outcome

The same endpoint may provide all three. The software should still measure and fail them separately. A healthy read path does not prove the stream has no gap. A successful sendTransaction response does not prove inclusion.

Solana's current provider assessment criteria use the same broad separation: standard JSON-RPC coverage, transaction forwarding and landing reliability, latency, operational history, capacity, and streaming support are evaluated as distinct capabilities. See the Solana provider assessment criteria.

Match the stack to the workload

RPCEdge's immediate shared-plan fit is strongest in the middle rows: applications, copy bots, DLMM automation, and teams adopting filtered gRPC. A searcher that already buys the earliest specialized shred source needs a separate qualification. Do not assume a standard gRPC plan can replace that upstream.

Stage 1: prove the strategy with ordinary RPC

For a prototype, optimize for correctness and observability:

• Use JSON-RPC for account reads, recent blockhashes, simulation, submission, and signature status.
• Keep the state model rebuildable from RPC.
• Persist every intended action and resulting signature.
• Record the decision time, submit time, accepted response, and confirmed outcome.

Public or low-cost shared endpoints can be enough while the bot has few reads and no contested execution. The prototype should reveal which constraint appears first: stale detection, rate limits, stream fan-in, unreliable recovery, or transaction landing.

Do not upgrade because the strategy is called a bot. Upgrade when a measured requirement fails.

Stage 2: add push when polling creates stale decisions

Polling cost and staleness grow with the number of watched accounts. A poll every 500 milliseconds has structural delay even on a zero-latency network, and most responses report that nothing changed.

Choose the smallest push model that works:

The streaming decision matrix explains the full ladder. The filter cookbook gives TypeScript request shapes for wallets, programs, accounts, and blocks.

Stage 3: make recovery part of the subscription

A production stream needs more than auto-retry:

1. A checkpoint tied to complete slot progress.
2. A known provider replay window and from_slot behavior.
3. Overlap plus event-level deduplication.
4. Durable idempotency before any external side effect.
5. An RPC reconciliation procedure when replay cannot cover the gap.

The reconnect and replay guide contains the recovery state machine. If the product cannot explain what happens after a 30-second disconnect, the stream is still a prototype.

Stage 4: separate transaction acceptance from landing

sendTransaction checks and relays a signed transaction. The response signature proves acceptance by that RPC method, not that a leader included the transaction. Solana's RPC documentation tells clients to use signature status for outcome tracking.

The send requirements change by job:

• App transfer: simulate, use a fresh blockhash, set a bounded fee, submit, and reconcile.
• Copy action: reject stale signals, rebuild from a fresh quote, cap slippage, submit once, and link target and mirror signatures.
• DLMM action: build against reconciled pool state, simulate, enforce inventory limits, and pause on uncertain local state.
• Atomic multi-transaction action: use a bundle only when ordering and all-or-nothing execution are required. Jito documents that bundle acceptance does not guarantee on-chain inclusion.

Read why Solana transactions fail and the Jito transaction documentation before tuning a sender.

Capacity and price should follow the filter

Collect these inputs before choosing a plan:

Use the Yellowstone bandwidth field note to turn the exact subscription into a monthly estimate. A credit total without the filter and workload is not enough to predict cost.

Run a provider proof before moving production traffic

Use one captured workload and one acceptance sheet. A 72-hour run is more useful than a synthetic ping alone because it crosses quiet and busy periods.

Record:

• JSON-RPC p50 and p95 for the methods on the decision path;
• error, timeout, and rate-limit counts;
• stream last-update age, gaps, reconnects, replayed events, and duplicates;
• average and peak received bytes per second;
• queue age and decode throughput;
• accepted sends, landed signatures, confirmation time, and expired actions;
• total cost under the measured traffic shape.

Keep the client region fixed during comparison. Change one path at a time. If two providers are in different regions, the result measures geography and service together.

The buying rule

Choose the smallest stack that passes the workload test and has a credible recovery path. Add latency tiers only when the measured outcome depends on them. That keeps early bots affordable and gives the infrastructure team a clear reason for every upgrade.