Agentic Routing for Web3 RPC Infrastructure

Subtitle: LLM/agent policies for selecting providers, chains, fallbacks, hedging, and caching strategies under latency, cost, and reliability constraints.

Status: living public research draft Published: 2026-08-12 Maintainer: GetBlock strategy lab / rpc.run Canonical URL: https://rpc.run.beinginfuture.com/papers/agentic-routing-rpc.html

Abstract

Web3 applications depend on Remote Procedure Call (RPC) infrastructure to read state, query logs, broadcast transactions, and serve user-facing products across many chains. Production teams rarely rely on a single homogeneous endpoint: they mix shared and dedicated providers, regions, chain-specific endpoints, cache layers, fallback providers, and monitoring systems. Yet routing is often implemented with static priority lists, round-robin load balancing, or simple health checks. This paper proposes agentic RPC routing: an infrastructure control layer where LLM/agent policies periodically synthesize and update provider-selection, fallback, hedging, and cache rules, while a fast deterministic or learned runtime executes per-request decisions.

The central hypothesis is that agentic routing can improve the latency–cost–reliability frontier for Web3 RPC workloads by jointly reasoning over request semantics, chain/provider health, cacheability, consistency requirements, user SLA tier, and failure modes. The paper frames RPC routing as constrained sequential decision-making, defines required telemetry and benchmark logs, proposes baselines and metrics, and outlines an experimental protocol for offline replay, shadow traffic, and live A/B testing.

1. Motivation

RPC routing is no longer a simple endpoint-selection problem. A production Web3 application may need to decide:

Large RPC providers are increasingly describing their own infrastructure in terms of intelligent routing, agent tooling, reliability layers, dedicated clusters, observability, and caching. This suggests that routing itself is becoming a competitive product surface.

2. Hypothesis

H1 — Agentic routing advantage. Agentic routing policies can outperform static, rule-based, and bandit-only RPC routing by jointly reasoning over request intent, chain/provider health, latency/cost budgets, fallback semantics, and cacheability.

H2 — Best architecture. The most practical system is not an LLM called on every RPC request. Instead, an agent periodically reviews telemetry, competitor/provider signals, incident history, and policy outcomes, then emits deterministic routing configurations executed by a low-latency runtime.

H3 — Semantic routing matters. Method-aware routing and caching will outperform generic provider-choice policies, especially for eth_getLogs, archive/debug methods, transaction broadcast, and finalized/historical reads.

H4 — Agentic routing creates enterprise proof. A router that can explain provider selection, fallback, cache safety, and incident adaptation becomes a sales and reliability artifact for enterprise RPC buyers.

3. Problem formulation

Each request is represented as:

x = {
  chain,
  method,
  params_shape,
  block_tag,
  user_tier,
  region,
  latency_budget,
  consistency_requirement,
  freshness_requirement,
  cost_budget,
  retry_allowed,
  cache_allowed
}

The router chooses:

a = {
  provider,
  endpoint_type,
  timeout_ms,
  fallback_order,
  cache_strategy,
  quorum_strategy,
  retry_strategy,
  hedging_strategy
}

Observed outcome:

y = {
  success,
  latency_ms,
  provider_error_code,
  rpc_error_code,
  cost_units,
  stale_result,
  cache_hit,
  fallback_used,
  correctness_check_passed,
  user_sla_satisfied
}

Objective:

minimize:
  α * latency
+ β * cost
+ γ * error_rate
+ δ * stale_or_incorrect_response
+ ε * fallback_penalty

subject to:
  SLA_success_rate >= threshold
  p95_latency <= threshold
  correctness_violation_rate <= threshold
  provider_rate_limit_violation <= threshold

4. Proposed system: Agentic RPC Router

4.1 Runtime path

Incoming RPC request
  → request classifier
  → policy engine
  → provider health + cost + chain-state context
  → route decision
  → execution: primary / fallback / hedge / cache / quorum
  → outcome logger

4.2 Agent policy path

Daily/hourly telemetry window
  → agent review
  → detect provider, method, chain and region regressions
  → update routing rules, fallback trees and cache TTLs
  → publish policy diff
  → monitor post-change outcome

4.3 Request classes

ClassExamplesRouting implication
Latest state readeth_call, eth_getBalance latestfreshness-sensitive, low latency
Finalized/historical readfinalized block queries, archive readscacheable if finality guarantees hold
Logs/indexingeth_getLogsheavy, provider-specific behavior
Transaction broadcasteth_sendRawTransactionno cache; fallback and multi-broadcast need safety rules
Health/simpleeth_blockNumber, net_versioncheap monitoring and block-lag measurement
Trace/archivedebug_traceTransaction, archive block callscapability and cost-sensitive

5. Related-work map

5.1 Adaptive routing and traffic engineering

Classic service routing optimizes availability and latency across servers, regions, and replicas. Web3 RPC adds method semantics, chain finality, archive availability, block freshness, provider rate-limit policies, and transaction-safety concerns.

5.2 Contextual bandits and online provider selection

Provider selection is naturally modeled as a contextual bandit problem: each provider is an arm, with context including chain, method, user tier, health window, and time. Bandits are strong baselines but do not directly express multi-step fallback plans, cache safety, or domain-specific correctness constraints.

5.3 LLM/agent routing

Emerging LLM-agent work studies tool routing, multi-agent routing, cost-aware model routing, and self-healing workflow graphs. RPC routing has a useful advantage over many tool-routing tasks: outcomes are measurable through latency, errors, cost, stale block distance, fallback recovery, and SLA satisfaction.

5.4 Caching and semantic caching

LLM systems increasingly use semantic and plan caching to reduce cost and latency. RPC caching is related but stricter: cacheability depends on method, block tag, finality, chain reorg risk, user freshness tolerance, and whether a response is deterministic.

5.5 Web3 RPC reliability and provider competition

Provider docs and competitor messaging show strong emphasis on uptime, multi-chain support, dedicated clusters, status/SLA transparency, routing, observability, and developer workflow. A research benchmark for agentic RPC routing can turn these commercial claims into measurable infrastructure questions.

6. Data needed

Minimum viable request log schema:

timestamp
request_id
user_or_tenant_hash
user_tier
chain
method
params_shape_hash
block_tag
provider_selected
endpoint_region
success
http_status
rpc_error_code
provider_error_code
latency_ms
response_size_bytes
cost_units
retry_count
fallback_used
cache_hit
cache_key_type
block_number_returned
latest_known_block
staleness_blocks

Stronger telemetry:

provider_health_snapshot_at_decision
rate_limit_remaining
provider_region
client_region
request_timeout_ms
is_archive_request
is_write_request
is_idempotent
is_cacheable
finality_requirement
correctness_check_result
quorum_disagreement

Transaction-specific fields:

tx_hash
broadcast_provider
mempool_seen_time
included_block
time_to_inclusion
duplicate_broadcasts
replacement_tx
revert_or_dropped_status

7. Baselines

BaselineDescription
Static priorityTry provider A, then B, then C
Round-robinUniform provider distribution
Weighted round-robinManual weights by provider quality/cost
Latency-onlyChoose provider with best recent p50/p95
Error-awareChoose provider with lowest recent failure rate
Cost-awareChoose cheapest provider satisfying basic SLA
Contextual banditLearns provider choice from request and health context
OracleBest observed provider after the fact; non-deployable upper bound

8. Proposed methods

Method A — rule-based semantic router

A deterministic policy uses chain/method taxonomy:

if method == eth_sendRawTransaction:
    cache = never
    fallback = transaction-safe multi-broadcast or conservative primary-only
elif method == eth_getLogs:
    prefer provider with best logs success and range behavior
elif block_tag is finalized or historical:
    allow finalized-block cache
elif user_tier == enterprise:
    stricter timeout, hedging, and fallback policy

Method B — LLM-generated policy router

The LLM receives summarized telemetry, provider capabilities, chain/method taxonomy, and constraints. It emits versioned YAML policies:

routing_rules.yaml
fallback_trees.yaml
cache_policy.yaml
risk_guardrails.yaml

Runtime execution remains deterministic.

Method C — agentic adaptive router

A scheduled agent loop reviews the latest telemetry and competitor/provider signals, detects regressions, updates method-specific fallback rules, adjusts cache TTLs, and writes a policy diff.

Method D — hybrid agent + contextual bandit

A contextual bandit selects providers per request within an agent-defined safe action set. The agent controls eligible providers, reward weights, cache/fallback templates, and incident guardrails.

9. Metrics

Reliability

Latency

Cost

Cache

Composite metric

SLA utility = success_rate
              - λ1 * normalized_latency
              - λ2 * normalized_cost
              - λ3 * stale_or_wrong_response

The paper should emphasize Pareto frontiers: reliability at fixed cost, cost at fixed p95, and p95 at fixed success threshold.

10. Experiment design

E1 — offline replay

Use historical RPC logs to compare routing policies on the same request distribution. Address counterfactual bias by using shadow probes or logged propensities where available.

E2 — shadow traffic

The router makes decisions but does not serve production responses. Alternative providers receive duplicate probes for a safe subset of methods, generating counterfactual outcome data.

E3 — controlled live A/B

A small percentage of eligible traffic uses the agentic router. Enterprise and transaction-broadcast traffic should initially be excluded or heavily guarded.

E4 — incident simulation

Replay or simulate provider outage, chain-specific degradation, method-specific errors, and rate-limit events. Measure recovery time, failed requests, cost overhead, and tail latency.

E5 — cache ablation

Compare no cache, fixed TTL cache, finalized-block cache, negative cache, and agentic method-aware cache policies.

11. Expected results and figures

Planned figures:

  1. system architecture diagram;
  2. latency–cost–reliability Pareto frontier;
  3. p95/p99 latency by policy;
  4. success rate under incident simulation;
  5. cache cost savings vs stale violation risk;
  6. ablation table;
  7. policy diff example generated by the agent.

12. Limitations

13. Two-week execution plan

Week 1

  1. Freeze log schema and request taxonomy.
  2. Extract 7–30 days of RPC logs or create a synthetic probe dataset.
  3. Implement request classifier.
  4. Implement static, round-robin, latency-only, error-aware, cost-aware baselines.
  5. Implement contextual bandit baseline.
  6. Implement rule-based semantic router.
  7. Produce first results table and paper skeleton.

Week 2

  1. Implement hybrid agent + bandit policy.
  2. Run cache experiments.
  3. Run fallback and incident simulations.
  4. Evaluate enterprise SLA slice.
  5. Run ablations.
  6. Generate figures.
  7. Draft paper v0 and appendix.

14. Living update log

This section is updated by the daily RPC competitor monitor when new evidence suggests material changes to the paper framing, related-work map, experiment plan, or benchmark assumptions.