The RPC Reliability Glossary: Key Terms for Blockchain Infrastructure Teams

Failover, hedging, quorum, block-aware caching: the vocabulary of RPC reliability, defined precisely and linked to the deeper guides on each mechanism.

Jump to: Fundamentals · Failover and resilience · Data correctness · Routing and performance · Observability

RPC reliability has its own vocabulary, and teams often use the same words to mean different things: "failover" alone covers at least five distinct mechanisms. This RPC glossary defines the terms that matter when you run blockchain infrastructure in production, spanning the fundamentals, the failover pipeline, data-correctness controls, routing, and observability. Definitions are grounded in the Smart Router docs; where a term has a deeper article or doc page, it's linked.

Fundamentals

RPC node

A machine running blockchain client software that exposes a remote procedure call interface, letting applications read chain state and submit transactions without running consensus themselves. Every wallet balance, price feed, and transaction broadcast ultimately goes through one. Deep dive: What is an RPC node?

Why it matters: the RPC node is the single choke point between your application and the chain. If it's down, slow, or wrong, your app is too. See the risk of relying on a single RPC provider.

JSON-RPC

The stateless request/response protocol most EVM chains use for RPC: a JSON object with method, params, and id fields, answered with a matching result or error. Other ecosystems speak different dialects (REST, gRPC, Tendermint RPC for Cosmos chains), which is why multi-chain routing needs per-chain specs. Deep dive: JSON-RPC explained

Upstream / provider

The RPC source a routing layer forwards requests to, either a node you run yourself or a commercial provider endpoint (Alchemy, Infura, QuickNode, etc.). "Upstream" emphasizes the direction of traffic; "provider" emphasizes who operates it. A router like Smart Router manages a pool of upstreams per chain and treats them as interchangeable, scored candidates. Related: RPC vs. node vs. API.

Endpoint

The concrete URL (plus interface: HTTP JSON-RPC, WebSocket, gRPC) where an upstream accepts requests. One provider commonly exposes several endpoints per chain. When your app talks to a router, it sees one endpoint and the router fans out behind it.

Chain tip / chain head

The most recent block the network has produced. Individual nodes learn about new blocks at slightly different times, so at any moment upstreams legitimately disagree about the head by a block or so. That's why cross-validating eth_blockNumber is pointless but lag beyond a threshold is a real fault. Smart Router tracks the freshest height observed across the pool (the "seen block") as its reference.

Finality

The point past which a block can no longer be reorganized out of the chain, defined per chain by a finalization distance. Finalized data is immutable, which makes it safe to cache for long periods and makes post-finality disagreement between providers a serious alarm rather than noise.

Stale data

A response computed from out-of-date chain state, typically served by a node lagging behind the chain head during a resync, a deploy, or a hot fork. The node answers confidently and returns no error; the answer is simply old. Why it matters: staleness is invisible to HTTP-level health checks, which is why integrity checks exist.

Failover and resilience

Failover

The umbrella term for everything a routing layer does when a request misbehaves: an upstream is slow, errors out, or falls behind the head. In Smart Router's failover pipeline, it's not one mechanism but five composable policies (retry, hedge, timeout, integrity, and circuit breaker) applied within a single request's lifetime. How-to: set up RPC failover in viem, ethers, and web3.py.

Retry

On a retryable error, resend the request, critically rotating to a different node rather than hammering the one that just failed. Smart Router tolerates a configurable number of errors per relay (--set-relay-retry-limit, default 2) and classifies errors as retryable vs. terminal so it doesn't retry things that can never succeed.

Hedging

Latency insurance: if a request hasn't returned within a tick, fire a parallel attempt at another node and let the first response win. Unlike retry, hedging doesn't wait for a failure; it races the slow case. Why it matters: it converts one provider's bad p99 into a small amount of extra upstream traffic instead of user-visible latency.

Timeout

The budget after which an attempt or an entire request is abandoned. Smart Router distinguishes per-attempt timeouts (bounding each try so retry can rotate) from the overall processing timeout wrapping the whole pipeline, and lets clients tighten the budget per request via the lava-relay-timeout header.

Integrity (lag check)

A pre-request filter: before selection, each candidate's last-observed block height is compared against the freshest height seen across the pool, and nodes behind by more than a per-chain threshold (roughly 10 blocks on Ethereum) are skipped for that request. Integrity catches out-of-sync nodes before they can serve stale data; it does not compare response contents, which is cross-validation's job.

Circuit breaker

When the node pool is effectively exhausted (every candidate failing or excluded), the circuit breaker trips the request early instead of retrying forever. Why it matters: during a real outage, fast, clean failures are far easier to handle than requests that hang until every retry budget drains.

Data correctness

Cross-validation / consensus

Send the same request to multiple upstreams in parallel and require agreement before returning a response, catching a lying or buggy node before its answer reaches your client. It's opt-in per method or per request because it multiplies upstream cost: worth it for eth_getLogs and critical reads, pointless for inherently divergent calls like eth_blockNumber. Walkthrough: how to detect and handle bad RPC data. Why it matters: "the node answered" and "the answer is correct" are different claims. See why availability isn't enough.

Quorum (MaxParticipants / AgreementThreshold)

The two knobs that define a cross-validation quorum: MaxParticipants is how many nodes are queried in parallel; AgreementThreshold is how many must return matching responses before one is accepted. Operators can set floors and caps per method so clients can widen the fan-out but never shrink the quorum below policy. The defaults (1/1) leave cross-validation effectively off.

Group diversity

A guard against correlated faults in a quorum: nodes sharing a vendor, client image, or data source can all agree on the same wrong answer. Group-diversity policies label each upstream (group-label) and require the agreeing set to span min-groups independent groups, optionally with each group reaching quorum on its own (per-group-quorum). Why it matters: three agreeing nodes prove little if they're the same infrastructure three times.

Routing and performance

Proxy (RPC proxy / reverse proxy)

An intermediary that sits between your app and upstream endpoints and forwards requests, giving you one URL instead of many. A plain reverse proxy (nginx, HAProxy) balances traffic blindly: it sees connections, not JSON-RPC, so it can't tell a synced node from a lagging one or a correct response from a wrong one. An RPC routing layer is a proxy plus protocol awareness, adding the selection, failover, validation, and caching policies in this glossary; Smart Router's overview spells out the difference. Why it matters: teams that put a generic proxy in front of RPC nodes inherit every failure mode a proxy can't see. More: why round-robin isn't enough.

Selection policy

The strategy that decides which upstream gets each request. Rather than round-robin, a QoS-weighted selector scores candidates on latency, sync freshness, and availability, then picks according to the configured strategy: Balanced by default, or alternatives like Latency, SyncFreshness, Accuracy, Distributed, Cost, and Privacy. Background: what is RPC load balancing (and why round-robin isn't enough).

Block-aware caching

Caching that keys entries by (chain, interface, method, params, resolved block) and sets lifetimes by finality: responses at or beyond the finalization distance are immutable and cached long-term, while "latest" reads get a very short TTL, and writes aren't cached at all. Why it matters: it's the biggest single lever on upstream cost and tail latency, and it makes cross-validation affordable by exempting cache hits from the fan-out multiplier.

Observability

Observability (Prometheus metrics / OpenTelemetry traces)

The ability to see what your RPC layer is actually doing: Prometheus metrics for every policy (retries, hedges, lag skips, circuit-breaker trips, cache hits, and cross-validation outcomes such as smartrouter_cross_validation_mismatch_total), OpenTelemetry traces spanning the full relay lifecycle, and an error-code taxonomy with retryability. Guide: monitoring RPC health, and the metrics that actually matter. Why it matters: without per-provider correctness and lag signals, you're grading providers on uptime alone, one item on the enterprise RPC checklist most teams miss.

Every term above maps to a mechanism you can run today: Smart Router is open source and starts with three commands via the quickstart. If you'd rather walk through your setup with us, book a demo.