RPC Node selection
Smart Router doesn't pick RPC nodes randomly. Every relay flows through a QoS-weighted selector that scores nodes on latency, sync freshness, and reliability — then picks one according to the strategy you configure.
How selection works
- The chain parser identifies the request's category (latest vs. archive, heavy vs. light, free vs. paid).
- The provider optimizer narrows the pool to upstreams that support the relevant API interface and category.
- The weighted selector scores each candidate on:
- Latency — recent observed response times.
- Sync — how close the node is to the chain head.
- Availability — recent error and timeout rates.
- The active strategy adjusts those weights (see below).
- A weighted-random pick is made, with a configurable minimum-selection floor that keeps every healthy node in rotation.
Source: protocol/provideroptimizer/provider_optimizer.go, weighted_selector.go.
Strategies
Strategy (--strategy value) |
Optimizes for | When to use |
|---|---|---|
balanced (default) |
latency + sync + availability | most workloads |
latency |
lowest response time | latency-sensitive reads (UI, fast quote) |
sync-freshness |
node closest to chain head | indexers, mempool watchers |
accuracy |
higher accuracy at higher cost — diversifies node selection (like distributed; no direct link to cross-validation) |
financial / critical reads |
distributed |
spread across nodes | avoiding hot spots, fairness |
cost |
cheapest per compute unit | high-volume non-critical traffic |
privacy |
pins to a single provider per stream (not fully implemented) | minimising correlation across calls |
Configuring it
Pick a strategy at startup with the --strategy flag:
To tune the underlying score weights directly, use the --qos-* flags —
--qos-latency-weight, --qos-sync-weight, --qos-availability-weight,
--qos-stake-weight, and --qos-min-selection-chance (the floor that keeps every
healthy node in rotation). These weights are set independently of --strategy: a
strategy reshapes each node's per-score curve, it does not adjust the weights. See
the CLI reference.
Per-request override
Pin a single request to a specific node with the lava-select-provider header. The optimizer is bypassed for that request; failover policies still apply. See Directives.
Related
- Failover & retry — what happens when the picked node fails or returns suspect data
- Hedge — race two nodes in parallel
- Cross-validation — require agreement across RPC nodes