Rate limits

EVMKit applies a shared short-window rate limit to billed public API usage.

Window model

• rate limits are enforced in 12s windows
• the limit is measured in compute units (CUs), not raw request count
• billed usage across the Search API, RPC API, and Streams API shares the same window budget
• the limit is enforced per account; if you use more than one API key under the same account, they share the same window
• the limit is global across regions

Your daily included CU allowance is still enforced separately. The short-window cap controls bursts; the daily allowance controls how much CU you can consume over the full billing period.

CU per 12-second window

Core APIs

Selection	CU / 12s window
Streams API	3,000
RPC API	4,000
Search API	6,000

Core API combinations

Combination	CU / 12s window
Streams + RPC	5,000
Streams + Search	7,000
RPC + Search	7,500
All 3 APIs	8,400

Bundles

Bundle	CU / 12s window
Professional	50,000
Advanced	100,000

All billed usage shares the same CU bucket. For example, evmkit_call, POST /v1/size, websocket connection costs, and billed websocket publishes all count toward the same 12s limit.

Reservation behavior

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

• billed RPC requests reserve the request CU cost before proxying upstream
• POST /v1/size reserves the per-item base plus the maximum gas-priced simulation cost implied by each item’s profile cap and then settles to actual gas-based CU
• 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 window, websocket products also have a shared active-connection cap per account.

Core APIs

Selection	Active websocket connections
Streams API	2
Search API	0
RPC API	0

Core API combinations

Combination	Active websocket connections
Streams + RPC	3
Streams + Search	3
RPC + Search	0
All 3 APIs	3

Bundles

Bundle	Active websocket connections
Professional	5
Advanced	10

• the cap is enforced per account, not per API key
• the cap is global across regions
• the cap is shared across the Streams API and GET /v1/monitoring/unhealthy/ws
• 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 and POST /v1/size both require 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 and sizing 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 or Search sizing 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.
• POST /v1/size uses the same public HTTP connection leasing path as the RPC API, so connection reuse and ramp discipline matter in the same way for both surfaces.

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/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
• Search hostnames can return 421 if POST /v1/size does not use 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

Related pages

• see Billing & CU pricing for daily included CU and per-endpoint pricing
• see Authentication for API key usage across HTTP and websocket transports
• see Streams API for stream endpoints and websocket message shapes