Rate Limits/Connection Limits

Denoted in requests per second

Service Type

RPC

Method	Lite	Basic	Ultra	Elite	Epic
Most Methods	30	100	250	500	1000
sendTransaction	10	25	50	100	250
Lightspeed (sendTransaction)	10	25	50	100	250
Rewind	5	10	15	20	25
sendBundle	X	X	X	X	X
Historical	✅	✅	✅	✅	✅
Websockets	5	10	15	20	25

Staked RPC

Method	Basic	Ultra	Elite
Most Methods	100	250	500
sendTransaction	25	50	100
Lightspeed (sendTransaction)	25	50	100
Rewind	10	15	20
sendBundle	5	10	15
Historical	✅	✅	✅
Websockets	10	15	20

gRPC

	Basic	Ultra	Elite
No. of connections	5	10	15

Additional Limitations

Batched Requests

The Solana RPC API supports standard JSON-RPC 2.0 batching: you can send multiple method calls in a single HTTP POST by submitting a JSON array of request objects. The endpoint processes each one and returns an array of responses.

Like array-batched methods, batch requests are billed per call in the batch, not per HTTP request. A batch containing 50 method calls consumes 50 requests from your per-second budget — the same as sending 50 separate HTTP requests.

Batches must use a single, identical method

Every request object in a batch must call the same RPC method. Mixed-method batches (for example, combining getAccountInfo and getBalance in one array) are not allowed and will be rejected. To call different methods, send them as separate batch requests — one batch per method.

How it's counted

cost = number of method calls in the batch

Because every call in a batch is the same method, the cost is simply the number of items. For example, a batch of 50 getAccountInfo calls counts as 50 requests. If that method is itself array-batched (such as getMultipleAccounts), each call is additionally counted per item — so a batch of three getMultipleAccounts calls carrying 20 pubkeys each counts as 20 + 20 + 20 = 60 requests (see the section above).

Methods that cannot be batched

The following methods are not supported inside a JSON-RPC batch and must be sent as individual requests:

• getProgramAccounts

• getTokenAccountsByDelegate

• getTokenAccountsByOwner

• getTokenLargestAccounts

• getTokenSupply

• getLargestAccounts

• getSupply

Any other method may be batched, provided every call in the batch uses that same method.

What this means for you

• Batching reduces round-trips and connection overhead, but does not discount your rate-limit consumption versus sending the calls individually.

• A large batch can exhaust your per-second limit on its own and return 429 Too Many Requests. Size your batches with your tier's limit in mind (see the tables above).

• If you need to call different methods, or one of the unsupported methods above, send each as its own request rather than combining them.

Batched (array) methods count per item

Several RPC methods accept an array of items in a single call and are billed against your rate limit per item, not per call. Each element in the array is treated as its own sub-request — a single call carrying 100 items consumes 100 requests from your per-second budget.

This applies to methods that take an array of items, including:

• getMultipleAccounts — array of account pubkeys

• getSignatureStatuses — array of transaction signatures

• getInflationReward — array of addresses

How it's counted

The cost of a batched call equals the number of items in the array:

cost = number of items in the array

So a getMultipleAccounts request for 100 pubkeys counts as 100 requests — identical to making 100 individual getAccountInfo calls. A request for 5 pubkeys counts as 5.

What this means for you

• A single oversized batch can exhaust your per-second limit on its own and return 429 Too Many Requests. Size your arrays with your tier's limit in mind (see the tables above).

• Batching is still efficient — it saves round-trips and connection overhead — but it does not discount your rate-limit consumption versus making the equivalent individual calls.

• If you're hitting 429s on these methods, reduce array size, spread items across multiple seconds, or move to a higher tier.