drm3-rpc-pool: an order of magnitude more usable RPC from free tiers

A single hardcoded RPC URL is one point of failure. Public providers 429 you, lag under load, and go down without warning, and when yours does, your app does. We hit this often enough building on Base that we factored the fix into a small library and open-sourced it.

drm3-rpc-pool [3] puts a pool of endpoints behind one `call`. It retries the next healthy endpoint on any 429, error, or timeout, demotes repeat failures into exponential-backoff cooldown, and restores them on the next success. It works on any EVM chain, ships as a Rust crate [1] and an npm/WASM package [2], and needs no sidecar process. MIT licensed.

What an order of magnitude actually means here

There are two throughput numbers, and conflating them is where people get burned. The honest one is usable throughput: the calls that actually complete, not the calls you attempt. A single free public endpoint under a burst fails most of its requests, so the rate that lands is a fraction of what you fire. A pool routes around the failures and lands almost all of them.

One live Base sweep (300 requests, concurrency 80, median of two runs) makes the gap concrete:

pool size   success    raw req/s   usable req/s
  1          ~25%        196         ~49
  2         ~100%        522        ~522
  3         ~100%        172         ~172
  4         ~100%        184         ~184
  5         ~100%        173         ~173

Going from one endpoint to a small pool took usable throughput from ~49 to ~522 successful requests per second, about a 10x jump, because the single endpoint was dropping three calls in four under load. That is the order of magnitude: an order of magnitude more calls that actually complete.

And the honest caveat, because it matters: raw request rate does not scale linearly. Notice it peaks at two endpoints and then falls. Free public RPCs rate-limit per IP and some are slow or flaky, so piling on more of them drags a spread-routed pool down. Two or three quality endpoints is the throughput sweet spot. Past that you are buying redundancy, not speed. Raw rate only aggregates linearly across endpoints with their own independent capacity, your own keyed providers on separate accounts. [4]

How failover works

Every call walks the pool in priority order, skipping endpoints that are in cooldown or locally rate-limited, and returns the first success. A failure demotes the endpoint and the call fails over to the next healthy peer, all behind a single `await`.

Use it

Pool the free public endpoints as peers and any one of them can fail over for the others. Add a keyed provider only when you genuinely outgrow the free tier, and cap it so bursts spill onto the free endpoints instead of your metered bill.

cargo add drm3-rpc-pool

use drm3_rpc_pool::{RpcPool, presets};

let pool = RpcPool::from_config(presets::peers_for("base")?)?;
let block = pool.call("eth_blockNumber", json!([])).await?;

npm i @drm3labs-oss/rpc-pool

import init, { RpcPool } from "@drm3labs-oss/rpc-pool";
await init();

const pool = new RpcPool({ endpoints: [
  { url: "https://base.llamarpc.com", priority: 0 },
  { url: "https://base-rpc.publicnode.com", priority: 0 },
  { url: "https://base.drpc.org", priority: 0 },
]});
const block = await pool.call("eth_blockNumber", []);

Why we built it

DRM3 runs its own infrastructure on Base, and RPC reliability is load-bearing for everything downstream. We were tired of a single rate-limited provider taking a sync loop with it, so we built failover that is honest about what it does: it buys you reliability and an order of magnitude more usable calls on free tiers, and it defers the day you have to pay for a bigger plan. It does not magically multiply raw capacity, and we say so in the docs. [4]

Code, benchmarks, and the full methodology are on GitHub [3]. Install from crates.io [1] or npm [2].