Rate limits

Shared 12-second CU burst limits and active websocket connection caps for billed EVMKit usage.

EVMKit applies two independent limits to billed usage:

a daily CU allowance from your selected pricing tier
a shared burst window enforced in 12s windows

Both are enforced per account and shared across API keys and regions.

Window model

the burst limit is measured in compute units (CUs), not raw request count
billed usage across the RPC API and Streams API shares the same 12s CU bucket
the burst window is global across regions for the same account
the daily allowance and the burst window are enforced separately

The authenticated Pipelines control plane is part of plan selection, but the public CU burst model below is about billed RPC and Streams traffic.

Your burst capacity is derived from the daily CU tier:

burst CU / 12s = clamp(round(daily CU / 3,600), min = 1,000, max = 100,000)

If a request costs 1 CU, the rough request-rate equivalent is:

approx req/s = (burst CU / 12s) / 12

That approximation also applies to billed websocket publishes that cost 1 CU.

Burst window by daily tier

Daily CU limit	Burst CU / `12s`	Approx max when `1 CU = 1 request`
`1M / day`	`1,000`	`~83 req/s`
`5M / day`	`1,389`	`~116 req/s`
`10M / day`	`2,778`	`~232 req/s`
`20M / day`	`5,556`	`~463 req/s`
`60M / day`	`16,667`	`~1,389 req/s`
`80M / day`	`22,222`	`~1,852 req/s`
`120M / day`	`33,333`	`~2,778 req/s`
`180M / day`	`50,000`	`~4,167 req/s`
`240M / day`	`66,667`	`~5,556 req/s`
`300M / day`	`83,333`	`~6,944 req/s`
`360M / day`	`100,000`	`~8,333 req/s`

Actual request throughput depends on the CU weight of the request mix. For example, 0.5 CU requests can run at roughly double the 1 CU request rate, while 2 CU requests consume the burst bucket twice as fast.

Reservation behavior

Some requests reserve CU before the final settled usage is known:

billed RPC requests reserve the request CU cost before proxying upstream
websocket connections reserve their connect cost at handshake time; billed publishes spend CU as events are published

Because of this, short bursts can hit the 12s limiter even when the final settled CU for each request is lower.

Active websocket connection caps

Separate from the shared 12s CU burst window, websocket products also have a shared active-connection cap per account.

If the subscription includes Streams API, the cap is derived from the selected daily CU tier:

Daily CU tier	Active websocket connections
`1M / day`	`3`
`5M / day`	`5`
`10M / day`	`8`
`20M / day`	`10`
`60M / day` and above	`20`

selections without Streams API have 0 websocket capacity
the cap is enforced per account, not per API key
the cap is global across regions
websocket handshakes return 435 with Retry-After when the cap is reached
stale websocket slots expire automatically within about 30s if a client disconnects without closing cleanly

Connection details

RPC and websocket usage is shared across regions for quota calculation, so a burst on one region reduces the remaining short-window budget for the same account everywhere.

RPC transport guidance

the public RPC API requires HTTPS with HTTP/2
reuse a stable pool of long-lived HTTP/2 connections instead of creating a new connection for each request
for parallel RPC traffic, keep at most about 32 active HTTP/2 streams per connection. For unary JSON-RPC requests, one active request corresponds to one active stream. If you need more parallelism beyond that, open more HTTP/2 connections instead of concentrating all concurrency on one connection
keep active public HTTP connections at or below 128 per account across all regions combined
when ramping a pool against one RPC hostname, do not open more than about 32 new public HTTP connections per second per account
avoid aggressive reconnect loops. Ramp connection creation gradually and prefer reusing existing connections

Websocket guidance

for websocket traffic, keep the socket open for the full session and avoid reconnecting after each subscribe/reconnect cycle unless needed
cap concurrent open sockets to avoid hitting the active-connection limit and causing avoidable 435 or Retry-After responses

Why this matters for rate limits

creating new connections for each request adds avoidable TCP/TLS churn and makes burst behavior less predictable
reusing connections reduces churn and gives your traffic a steadier profile against both the 12s CU window and connection-related limits
connection-level accounting is independent of request path; all billed traffic within an account shares the same limits and window budget

Error behavior

When the 12s CU window is exhausted:

HTTP endpoints return 434
HTTP responses include Retry-After with the number of seconds until the next window
JSON-RPC responses return error code -32005 with message rate limit exceeded
websocket handshakes are rejected, or an established billed stream can emit an error and close when it cannot reserve more CU

When RPC transport or connection usage is invalid:

RPC hostnames can return 421 if the client does not use TLS SNI with HTTP/2
RPC hostnames can return 430 when connection concurrency is too high; clients should reuse existing connections instead of opening more

When the shared active websocket connection cap is exhausted:

websocket handshakes return 435
handshake responses include Retry-After with the number of seconds until the earliest websocket slot expires or is released

When the account has no remaining daily allowance or no active subscription for a billed action:

billed requests return 402 Payment Required

see Billing & CU pricing for API access fees, daily tiers, and per-endpoint CU weights
see Authentication for API key usage across HTTP and websocket transports
see Pipelines for the managed delivery product overview
see Streams API for stream endpoints and websocket message shapes