Skip to content

Solana RPC for trading bots

A trading bot's RPC problem is not throughput. It is that the two calls that decide whether you make money — the account read that spots the opportunity and the sendTransaction that takes it — have completely different failure modes, and a provider that is healthy for one can be useless for the other.

What this workload costs

Modelled on 50% getAccountInfo, 15% getMultipleAccounts, 13% sendTransaction, 12% getSignatureStatuses, 10% getLatestBlockhash — no history calls — computed from the pricing dataset:

Provider Blended $/M At 129.6M calls/month (~50 req/s)
Helius $5.00 $648
dRPC $6.00 $778
Alchemy $6.21 $805
Chainstack $10.00 $1,296
Triton One $10.00 $1,296
QuickNode $15.00 $1,944
OnFinality — cannot serve this mix

This is the mix Helius is priced for: no archival calls, so nothing triggers its 10× multiplier and you pay its flat $5.00 across the board. Compare the indexer page, where the same provider is the most expensive on the board — the workload decides, not the brand.

OnFinality is disqualified rather than expensive. sendTransaction does not appear in its published method table, so there is no rate for it in the dataset and no way to price this workload. A provider that cannot take your writes is not a candidate no matter what its reads cost.

Rates verified 2026-09-06 against each provider's published pricing; overage/pay-as-you-go basis. See price per method for the weights.

sendTransaction is not free on Helius

This is worth stating plainly because it was wrong in these docs until 2026-09-05 and the mistake is common elsewhere: Helius charges 1 credit for sendTransaction, the same as any standard call. It is not free, and a routing strategy built on the assumption that writes are free is built on nothing.

At a 13% write share that is 16.8M writes a month in the table above — $84 of the $648. Worth knowing before you turn on write broadcast, which multiplies it.

Broadcast writes, and what it costs

The highest-value thing a proxy does for a bot is send your transaction to every provider at once and return the first success. Solana deduplicates by signature, so duplicate submissions are harmless — you are buying landing probability with provider spend.

[routing]
strategy         = "failover_ordered"   # pin reads to one provider, don't flap
broadcast_writes = true                 # but fan every write out to all of them
write_methods    = ["sendTransaction"]
max_retries      = 1

With three providers configured, broadcast_writes = true bills your write volume three times — the 16.8M writes above become 50.4M. On the mix in the table that is roughly $84 → $252. For a bot where a missed fill costs more than $168 a month, that is an easy trade; state it explicitly rather than discovering it on the invoice.

simulateTransaction is not a write by default. It is read-only and not in the landing path, so it routes as an ordinary read. Add it to write_methods only if you specifically want it broadcast.

Pin reads, don't flap

For a latency-sensitive bot, failover_ordered beats best_score — and the reason is not latency, it is consistency. Score-driven strategies hop between providers whose slot views and pending transaction sets differ slightly from one request to the next. You want one hot connection pool and one consistent view of the chain tip, and you want to leave it only when it actually breaks.

[health]
interval_ms           = 500   # detect failure in under a second
circuit_open_failures = 3
circuit_cooldown_secs = 15

See routing strategies for the full comparison and health scoring for how a provider gets demoted.

The proxy's own latency cost

Measured 2026-05-17 against a backend with a realistic ~20 ms RTT: +0.41 ms at the median, +1.93 ms at p99, and −2.3% throughput. Full conditions are on the FAQ.

If your budget is a 5–50 ms provider round trip, that is inside the noise. If you are colocated with a dedicated node and counting microseconds, it is not — measure it before you adopt it, and consider binding to a Unix socket, which measured faster than direct TCP in the same run.

Where splitting by method does not pay

The per-method cheapest provider for this mix:

Method Share Cheapest $/M
getAccountInfo 50% Alchemy $4.50
getMultipleAccounts 15% Helius $5.00
sendTransaction 13% Helius $5.00
getSignatureStatuses 12% Alchemy $4.50
getLatestBlockhash 10% Helius $5.00

Perfect method-splitting saves 6.2% over just using Helius — $648 → $608. That is not worth managing two vendor relationships for. Use multiple providers here for redundancy and write broadcast, not to shave the bill.

RPC Plane does not route by cost

It routes by health, score, config order or weight — never by price. Any cost split is one you encode yourself. Cost-aware routing is on hold and the binary carries no pricing table.