RPC node rate-limiting you (429 / -32005) or returning -32601? How to handle blockchain RPC errors

Blockchain RPC is where a lot of on-chain agents quietly break — not with a revert, but with the node itself pushing back. Rate limits, unsupported methods, and stale reads all look different and need different handling. Here's the short guide.

Rate limited: 429 / -32005 'limit exceeded'

The most common RPC failure. HTTP 429 or JSON-RPC -32005 means the provider is throttling you. It's transient — but only retryable with backoff.

Fix: back off on the Retry-After header with exponential backoff + jitter; don't retry immediately (you'll just get limited again). For sustained load, rotate across providers or cache reads that don't need to be live.

-32601 method not found

The node doesn't support the method you called — a different client implementation, a pruned node missing archive methods, or a provider that gates the method behind a higher tier.

Fix: confirm the method is available on your provider/tier, or route that call to a node that supports it. This is NOT transient — retrying won't make an unsupported method appear.

Stale reads: the node is behind the chain tip

A subtler failure: the RPC returns successfully, but the data is stale because the node lags behind the tip. Your agent reads a balance or nonce that's already changed and acts on it.

Fix: check block height / freshness for reads that matter, and for writes, expect and handle the resulting nonce or state errors rather than trusting a possibly-lagging read.

For on-chain agents

diagnose_infra_error returns the rpc family and tells the agent which RPC error it hit and the matching handling — so it backs off a 429, reroutes a -32601, and doesn't retry the ones that aren't transient.