Behind a single bex router endpoint sit multiple underlying RPC nodes per chain. This guide covers how requests get routed to one of them, and how that ranking is kept up to date.
Why rank nodes at all
A single self-hosted node for a chain is a single point of failure: one slow block, one dropped peer connection, and every request behind it slows down or errors. bex router instead maintains a pool of nodes per chain and continuously ranks them so a request lands on whichever node is healthiest right now.
What gets measured
Each node in the pool is scored on:
| Signal | What it catches |
|---|---|
| Response latency | A node falling behind on request handling |
| Sync status / block height | A node lagging the chain tip (stale reads) |
| Error rate | Timeouts, malformed responses, connection resets |
| Availability | Whether the node answers health checks at all |
Scores are recomputed continuously — the ranking that decides where your next request goes reflects node health from the last few seconds, not a static snapshot.
What this means for your requests
- Automatic failover. A node that starts erroring or falling behind drops in the ranking and stops receiving new requests; you don't see the failure, you see a request served by the next-healthiest node instead.
- No pinning required. You never need to track "which node am I on" or retry against a different one — routing to the best-ranked node happens on every request.
- Consistent compute unit cost. Which physical node served a request doesn't change what it costs — routing is an internal reliability mechanism, not a pricing tier.
Related
- Rate Limits & Quotas — the limits that apply regardless of which node serves a request
- Maximizing performance — request patterns that pair well with this routing