Adaptive Routing
How 256 Blocks ensures reliable blockchain access through intelligent provider routing
256 Blocks automatically routes your requests across multiple RPC providers to maximize reliability and performance. This page explains how adaptive routing works and what happens when providers fail.
How It Works
At a glance, here's what happens when a request arrives at our endpoints:
- We use DNS level routing to route your request to the nearest region based on latency (Europe, US, Singapore, or South America)
- We evaluate your request against our policy engine
- We select a provider using weighted scoring - higher-scoring providers are more likely to be chosen
- Finally, we execute the request, with automatic failover if the provider fails
This happens transparently on every request, regardless of whether this was an RPC call or an agentic workflow using our MCP integrations.
Provider Scoring
Each provider is scored based on two factors:
| Factor | Impact |
|---|---|
| Success rate | Failed requests heavily penalize a provider's score |
| Latency | Slow responses reduce score, so degrading providers naturally receive less traffic |
Scores are calculated per region, per chain, and per provider. A provider might perform well in Europe but poorly in Singapore, or handle Ethereum reliably but struggle with Polygon.
Scores update within seconds of each request completing. Subsequent requests immediately benefit from the latest performance data.
Degraded providers
When a provider's score drops below a threshold, it is temporarily removed from the available pool. This prevents requests from being routed to a provider that is likely to fail.
Scores gradually recover over time, allowing providers to re-enter the pool slowly. This prevents a recovering provider from being overwhelmed with traffic before it is fully stable.
Automatic Failover
256 Blocks only retries requests when the provider's response indicates it is safe to do so:
| Response | Action |
|---|---|
| 2xx | Success, return response |
| 401 (Unauthorized) | Retry with next provider (transient auth issue) |
| 403 (Forbidden) | Retry with next provider (transient issue) |
| 429 (Rate Limited) | Retry with next provider |
| 5xx (Server Error) | Retry with next provider |
| Other 4xx (Client Error) | Do not retry - the request itself is likely invalid |
| Timeout | Do not retry (avoid double-charging) |
| Connection Error | Retry with next provider (request never reached provider) |
When failover occurs, each available provider is tried in score order until one succeeds or all providers have been tried.