An RPC endpoint is both the eyes and the mouth of a trading bot, and the two roles have different requirements. Reads need freshness and generous rate limits; writes need a reliable path to the current leader. Choosing on advertised latency alone is the usual mistake, because the figure that predicts outcomes is the landing rate of a real workload measured over the tail of the distribution, not the median ping of a health check.
The read path and the write path
Separating these two roles is the single most useful mental model in this area, because they can be served by different providers and frequently should be.
The read path answers questions: what pools exist, what is in this account, what did this transaction do, what is the current slot. It is bursty, it dominates request volume, and its failure mode is stale or missing data leading to a decision based on a world that no longer exists.
The write path does one thing: get a signed transaction to a leader. Its volume is trivial next to reads, its cost is negligible, and its failure mode is the expensive one, since a dropped transaction is a trade that never happened.
Once separated, an obvious asymmetry appears. It is entirely reasonable to run reads through a cheaper shared endpoint while sending writes through a better-connected one, or through several in parallel. Many operators pay for a single expensive plan to fix a write problem, when the read volume was what pushed them into the higher tier and the write path could have been solved separately for far less. The same split is the reason a managed product can be cheaper than self-hosting at moderate activity: the read load behind a professional Solana volume bot is shared across every account on the platform, while a single operator pays for that capacity alone.
Provider classes compared
Named vendors change their offerings constantly, so compare classes rather than brands. Every provider fits one of these four patterns.
| Class | Latency profile | Rate-limit behaviour | Ops burden | Sensible use |
|---|---|---|---|---|
| Public cluster endpoint | Unpredictable, degrades sharply under load | Aggressive and undocumented in practice | None | Development and one-off queries only |
| Shared commercial plan | Good median, long tail during market events | Credit or request quotas, noisy neighbours | Low | Read path for most strategies; write path for non-contested trades |
| Dedicated node | Consistent, and you own the variance | Effectively yours alone | Medium: monitoring and version upgrades | Latency-sensitive strategies with steady volume |
| Self-hosted node with streaming plugin | Best achievable, no third party in the data path | None beyond your own hardware | High: a continuous infrastructure commitment | Professional operations where the edge is the data path |
The honest framing for most readers is that the second row is sufficient and the fourth row is a business decision disguised as a technical one. Running your own node means bandwidth, storage that grows continuously, version upgrades on the cluster's schedule rather than yours, and someone available when it fails at an inconvenient hour. It removes a dependency and creates a job.
Where latency actually lives
Latency is not one number, and the components behave differently under stress. Four contributions matter:
- Transport. Network round trip between you and the endpoint. Stable, easy to measure, and usually the smallest term for anyone not already co-located.
- Queueing at the provider. Time spent waiting behind other customers' requests. Near zero when quiet, and the dominant term exactly when a popular market opens.
- Node processing. How long the node takes to answer. Trivial for a slot query, substantial for a large program account scan with filters.
- Data freshness. Not a delay in answering but a delay in the answer itself. A node several slots behind returns a fast, confident, wrong picture of the world.
Providers advertise the first term because it is flattering and easy. The second and fourth are what change outcomes, and neither appears on a pricing page. This is why the recipe below measures behaviour under your own workload rather than trusting a benchmark.
Polling, WebSockets and gRPC streams
How you learn about state changes determines the ceiling on your detection speed, and there are three practical options.
Polling
Ask repeatedly on a timer. Simple, robust, and bounded by the poll interval: your average detection delay is roughly half the interval and your worst case is the whole of it. Shortening the interval to compensate consumes request quota quadratically across a watchlist and is the fastest route to rate limiting. Adequate for anything with a horizon measured in minutes.
WebSocket subscriptions
Standard RPC offers subscriptions that push notifications when accounts change or a program emits logs. This is the default choice for event-driven bots. Its weaknesses are specific and worth designing for: notification delay grows under provider load, subscriptions can stop delivering without closing the connection, and log parsing is brittle against program changes. Every production WebSocket client needs a heartbeat that measures time since the last message and reconnects on silence, because the failure is silence rather than an error.
gRPC account and transaction streams
Validators can run a plugin that emits account writes, transactions and slot updates as the node processes them, which commercial providers resell as a gRPC stream. This removes a queueing layer and delivers structured data instead of log text that must be parsed. It costs more, and integrating it is a real engineering task rather than a configuration change.
A useful rule: upgrade the stream only after you have shown, with measurements, that detection is your binding constraint. If your landing rate is the problem, a faster stream delivers your losses sooner. The landing-rate measurement tells you which of the two you are dealing with.
A measurement recipe you can run today
Six steps, no special tooling, and it produces comparable numbers across any set of candidate endpoints. Run each step against every candidate over the same period, including at least one busy period, because quiet-hour results are not predictive.
- Transport round trip. Issue a trivial request such as a health or slot query a few hundred times and record the full distribution. Report the median and the ninety-fifth percentile. The gap between them is more informative than either figure alone.
- Slot freshness. Query the current slot from the candidate and from an independent endpoint in the same loop. A candidate that is persistently one or more slots behind is serving you a stale world, and no amount of transport speed compensates for that.
- Notification delay. Subscribe to a busy program, and for each notification compare arrival time against the block time of the slot it belongs to. This is the number that actually determines detection speed, and it is the one nobody publishes.
- Heavy read cost. Time the specific queries your strategy issues in its decision stage, not a synthetic call. Filtered program scans and large multi-account fetches behave nothing like a slot query under load.
- Submission acknowledgement. Record the time from issuing the send call to receiving a signature, using an identical payload across endpoints. This isolates the write path from everything else.
- Landing rate on identical workload. Send the same real transaction workload through each candidate and compute the share that reaches a confirmed block. This is the decisive test, and it is the only one that captures how the provider is treated by the network rather than how it treats you.
Two endpoints can share a median and behave completely differently at the ninety-fifth percentile, which is where contested entries are decided. Always report both. An average that looks excellent while one request in twenty takes several hundred milliseconds is describing a system that fails precisely when the market is interesting.
Record the results in a plain table with one row per endpoint and one column per step. Keeping that table and re-running it quarterly turns provider selection into evidence rather than loyalty, and it makes renewal conversations short. Protocol method behaviour and the exact call names are documented at solana.com/docs/rpc, which is the reference to check when a provider's behaviour and your expectation disagree.
Rate limits and credit models
Pricing is rarely a simple request count. Providers meter in credits, weight expensive methods more heavily, and impose separate ceilings on concurrent connections and subscriptions. Two plans with the same headline request allowance can differ by an order of magnitude for a bot whose workload is dominated by heavy reads.
Before committing, count your real workload: requests per market watched, per second, at peak, multiplied by the number of markets, plus subscription slots, plus the burst that occurs when a launch triggers every filter at once. That burst is what breaches the limit, and it arrives at the worst possible moment.
Three practices reduce consumption without reducing information: cache anything immutable such as mint decimals and account addresses, batch status queries rather than polling signatures individually, and move steady-state monitoring onto subscriptions so that polling is reserved for the things that genuinely need a pull. Applied together these typically cut request volume enough to change which plan tier you need, which is a real line in the cost model.
RPC failure modes that hide inside a good average
| Failure | How it presents | Guard |
|---|---|---|
| Silent subscription death | No errors, no notifications, bot appears idle in a busy market | Heartbeat on time since last message; reconnect on silence |
| Lagging node | Fast responses containing old state; stale blockhashes | Continuous slot comparison against a second endpoint |
| Throttling storm | Errors cluster exactly during launches | Client-side rate budget, backoff, and a fallback endpoint |
| Load-balanced node hopping | Consecutive reads disagree with each other | Pin sessions where offered; tolerate non-monotonic reads in logic |
| Partial method support | A method works in development and fails on the paid tier | Verify the exact method set against the plan before migrating |
| Cached responses | Account data lags reality by seconds with no error | Cross-check a known-changing account against a second provider |
Every one of these presents as intermittent bad luck to an operator without instrumentation. That is the recurring theme of this section of the site: the difference between a working system and an unlucky one is almost always the presence of a measurement, and the same pattern reappears in the failure-mode catalogue.
What to ask before you sign
Provider sales pages are written around latency claims and credit allowances. The questions that actually predict how a plan will behave under your workload are rarely answered there, and all of them can be asked in a single support ticket before any money changes hands.
- Is the write path shared with the read path? If submissions queue behind other customers' heavy reads, your fee policy is being undermined by someone else's analytics job.
- What happens at the limit: hard rejection, queueing, or degraded service? A rejection you can detect and route around. Silent queueing looks like network latency and is far harder to diagnose.
- Are subscriptions counted separately from requests, and what is the ceiling? Watchlists grow, and subscription ceilings are the limit most often discovered in production.
- Is the endpoint a single node or a load-balanced pool? A pool means consecutive reads can disagree, and any logic assuming monotonic state needs to tolerate that.
- Which methods are excluded or weighted heavily on this tier? Filtered program scans and historical queries are the usual exclusions, and they are often exactly what a strategy depends on.
- What is the actual retry behaviour on submitted transactions? You need to know whether the provider rebroadcasts on your behalf, and at what cadence, before you build your own loop on top of it.
- What does the status history look like, and is it published? A provider that publishes incidents honestly is more useful than one that has never admitted to any.
Keep the answers alongside your measurement table. Providers change their infrastructure without announcing it, and a written record of what you were told is the fastest way to notice that behaviour has drifted from the agreement.
Geographic placement, honestly
Placement advice in this niche is frequently overstated. The leader rotates among validators distributed worldwide, so there is no single physical location that is close to the leader in general. What you can do is shorten the distance to your own submission infrastructure and choose providers whose forwarding path to leaders is good.
The defensible version of the advice is therefore modest. Put your bot in the same region as your primary endpoint, because that hop is the one you control. Avoid running latency-sensitive automation from a home connection where transport variance dwarfs every other term. Beyond that, additional geographic tuning delivers diminishing returns compared with improving the detection stream or the fee policy, and it is usually pursued because it feels technical rather than because it was measured.
If you take one habit from this page, take the measurement table. Endpoint choice made from a table of your own numbers, refreshed occasionally, will outperform endpoint choice made from a comparison article, including this one.