MeterCall’s L4 router is live against more than 30 chains. We pay zero dollars per month for RPC. Every endpoint behind the router is a public, rate-limited, sometimes-flaky, occasionally-dishonest free RPC served by a provider who has every incentive to throttle us and no contractual obligation to keep us running. This is a deliberate choice. It is also the most expensive-to-get-right part of the stack.
This post is the field guide. How to use free RPCs and not wake up to silence when one of them vanishes at 3 AM.
Three reasons. First, PCP economics require the router to be cost-neutral at the floor, and paid RPC eats the floor. Second, charging merchants for traffic we pay out to Alchemy is unattractive arbitrage. Third, and most important: if we cannot survive on free RPC, the ecosystem cannot be credibly decentralized. The whole point of the seed-node rollout is to replace our public-RPC dependency with community-run infrastructure. Until we get there, we treat every public endpoint as a hostile neighbor.
For each chain we maintain a pool of four to eight public endpoints. The pool is stored in the chains registry with three attributes per entry: URL, observed p95 latency, observed trust score. Requests are dispatched via a router that enforces four rules.
Any read that influences a settlement decision — balance checks, nonce queries, gas oracle lookups — is fan-out to three endpoints and resolved by majority. If the three disagree, we escalate to five. If five still disagree, we circuit-break the chain and log a Sniper flag. This is basic, but most projects skip it because majority-quorum doubles their free-tier burn. We pay that cost because the alternative is a single lying endpoint directing funds to the wrong address.
Transactions are broadcast to all endpoints in the pool. The first confirmation wins. We keep a local mempool mirror so a vanished endpoint cannot make the tx look lost to the others. If no endpoint confirms within a chain-specific timeout, we re-sign with incremented gas and replay.
We run a multi-tier cache: Redis for hot reads (block height, gas price, ERC-20 decimals), SQLite for warm historical data (contract code, logs windows), and an S3-compatible store for cold archives. Roughly 80% of reads never touch an RPC. That is what makes 30-chain coverage possible on free tiers. The storage docs cover the TTL matrix.
// Cache key pattern
{namespace}:{chainId}:{method}:{argsHash}:{freshness}
// Freshness tiers
hot = 3s // gas, nonces, pending
warm = 30s // balances, block height
cold = 5m // logs, blocks
frzn = inf // historical reads of finalized blocksEach endpoint has a three-state breaker: closed, half-open, open. We track error rate over a sliding window. Above 20% error rate, it trips open. After a cooldown, the breaker half-opens and lets one canary request through. If the canary succeeds, we reclose. This is a classic pattern. What makes it work for cross-chain routing is that the breaker state is per endpoint and per chain, because a provider can be fine on Ethereum and silently broken on Polygon zkEVM.
In our logs from the last sixty days, failure modes break down approximately:
When we add a new public RPC to the pool, it is run through a six-step pre-flight before any real traffic sees it.
1. eth_chainId -> must match expected
2. eth_blockNumber -> must be within 10 blocks of quorum
3. eth_getBlockByNumber(earliest) -> must match genesis hash
4. eth_call to known contract -> result must match reference
5. eth_getLogs small range -> must return known event
6. eth_sendRawTransaction (dust) -> broadcast observable elsewhereAny failure bans the endpoint until re-scored. Step 4 is the one that catches intentionally wrong endpoints most often.
Quorum catches most dishonest reads. For writes, the defense is different. We sign everything client-side, so a lying endpoint cannot alter the transaction payload. The worst it can do is refuse to broadcast, and rule 2 handles that. For balance-dependent decisions, we additionally cross-check against the chain’s native state via an independent light client where available, or against another chain’s canonical bridge (for example, pulling USDC balance from Circle’s canonical minter contract rather than trusting an individual RPC).
We do burn some money. The quorum multiplier means our effective read volume is 2.4x nominal, which pushes us past the free tiers of the most aggressive providers on the largest chains. We handle that by rotating API keys, running our own seed nodes for the top five chains (which is what genesis-nodes.html documents), and spraying traffic across enough providers that no one’s free-tier limit is breached. The effective cash cost today is somewhere between zero and a few hundred dollars a month depending on volume spikes. The engineering cost is real: about 30% of our infra codebase exists to survive free RPCs.
If you are doing high-frequency MEV, free RPCs will lose you money on latency alone. Pay for private endpoints. If you are a solo app with low traffic and a single chain, one free endpoint with a single-endpoint retry is probably fine. The quorum-plus-breaker pattern pays off specifically when you are serving aggregated traffic across many chains and you cannot tolerate a single provider going dark. That is our situation. It may not be yours.
For everyone else, and especially anyone building a x402-style merchant layer, the cost of downtime is not your downtime. It is a forgotten transaction that goes to the wrong address because one endpoint lied. Quorum, cache, circuit-break, attest. That is the whole playbook.