Every Solana RPC Provider Claims to Be Fast

Three articles. One insight. One working system.

In October 2025, I wrote that Solana’s RPC layer had quietly crossed from technical infrastructure to economic infrastructure. From Latency to Value made the uncomfortable argument that routing is not neutral ; it is a market. Who processes your transaction determines as much as what your transaction contains.

In May 2026, the argument got a sharper edge. The Physics of Finality explored what Alpenglow’s sub-150ms finality actually exposed: strip away the software latency, and what remains is the physical network fabric. Propagation delay. Geographic clustering. Synchronization variance. The constraint that does not yield to better code. The paper introduced the geographic event horizon : the point at which physical distance becomes an operational disadvantage that money cannot fully correct and software cannot abstract away. 98.27% of participating validators approved Alpenglow. 65% of stake sits within 50ms of a single European location. The symbolism of decentralization and the physics of coordination are running at different speeds.

Both articles pointed at the same gap without filling it.

This article is about that system.

InfraBench is an evidence-first routing and accountability layer for Solana RPC decisions. It measures independently, publishes evidence publicly, decides deterministically, and refuses to route when evidence does not support it. You can see it working right now at infrabench-ruddy.vercel.app/ledger.

The rest of this piece explains the problem it solves, the philosophy behind its design, and why the most important feature it has is knowing when to say nothing.

The Current State: How Infrastructure Decisions Actually Get Made

Before the architecture, the problem needs to be described honestly.

Most Solana teams choose RPC providers through a combination of Twitter reputation, documentation quality, pricing tiers, and a quick latency check. If they are rigorous, they run a few curl tests from the region where their application is deployed. If they are thorough, they try multiple providers for a week and observe behavior anecdotally.

What they almost never do:

• Measure provider performance from their specific deployment region against their specific workload type
• Score providers on independently collected evidence using the same measurement frame
• Maintain a structured record connecting routing choices to observable outcomes
• Apply governance logic that halts routing when evidence quality is insufficient
• Build an audit trail that answers, after the fact, why a specific provider was chosen at a specific time

For most consumer applications, this is fine. Latency variance of 20ms does not affect user experience in ways that matter.

But the infrastructure stack for a quantitative desk, a high-frequency DeFi protocol, or an institutional trading system operates under completely different stakes:

• A wrong provider choice is not slower UX. It is execution slippage.
• Stale evidence is not an annoyance. It is a capital risk.
• No audit trail is not a documentation gap. It is a procurement and risk management failure.
• A routing system that always returns an answer, regardless of evidence quality is not reliable. It is falsely certain.

That chain of reasoning is why InfraBench exists.

The Blind Selection Problem: The Current Stack

The gaps in that diagram are not engineering oversights. They are the natural consequence of treating RPC as a commodity input rather than a governed infrastructure decision. When stakes are low, the absence of governance is tolerable. When stakes rise and in Alpenglow-era Solana they rise fast ; the absence of governance becomes the risk itself.

The Intellectual Thread: Three Articles, One Architecture

It is worth tracing the line between the two earlier pieces and InfraBench directly, because the connection is not incidental. These are three stages of one argument.

From Latency to Value proposed that RPC performance should be treated as a formal, verifiable economic commodity with workload-segmented SLAs, tokenized access tiers, and aligned incentives across providers, validators, and clients. The implicit prerequisite of that proposal was observable, attributable, comparable evidence. You cannot tokenize what you cannot measure. The article described the destination. It did not describe how to build the measurement layer that makes the destination reachable.

The Physics of Finality changed the urgency. When finality operates at 150 milliseconds, physical topology becomes the dominant constraint and proximity to validator clusters becomes operational power. The paper described why the measurement layer must be geography-aware : why a latency observation from Frankfurt cannot be applied to a routing decision for Singapore as though geography is a label rather than a variable. It described the need. It did not build the system.

InfraBench is the system.

What InfraBench Actually Does

The cleanest description: InfraBench is a governed routing layer for Solana RPC selection.

The system is organized around three trust planes, each with a distinct purpose and a deliberately enforced boundary.

Measure privately. Evidence is collected independently through a private measurement pipeline that is structurally separated from the public-facing system. The public layer never reads private credentials, raw observations, or internal measurement state. It reads only normalized, published evidence artifacts. The private plane cannot be interrogated from outside. It produces evidence. The public layer consumes evidence.

Decide publicly. The routing decision engine operates on the normalized public evidence. Its outputs routing decisions, confidence states, abstentions, rationale are structured, machine-readable, and visible. The decision logic is deterministic: the same evidence, the same request, and the same result. Always. No runtime randomness. No hidden fallbacks.

Account persistently. Every decision whether READY or ABSTAIN is recorded in the accountability ledger with its full evidence context and reasoning. The decision history is traversable, reproducible, and preserved.

The boundary between these three planes is not an implementation detail. It is the core architectural trust guarantee:

The Governance Philosophy: Why Gates Matter More Than Scores

Most infrastructure selection tools think in scores. Higher is better. Route to the winner. The implicit assumption is that the best available option : however weak the evidence behind it , is always preferable to declining to choose.

InfraBench rejects this assumption at the design level.

The routing decision is not a ranking problem. It is a governance problem. The right question is not which provider scores highest right now? The right question is: is the evidence sufficient to make a defensible, capital-safe routing decision right now?

Those are not the same question. They do not have the same answer.

Consider the difference:

A ranking system says: Provider A scored 0.72, Provider B scored 0.61. Route to A.

A governance system says: Provider A has a score based on evidence that is 12 days old, collected from a single measurement window, with low regional coverage. This evidence does not meet the freshness or coverage standard required to make a capital-safe routing decision. The answer is abstention ; not a stale recommendation.

The first answer is always available. The second answer is actually useful.

InfraBench governs routing decisions through three categories of constraint, each protecting against a distinct failure mode:

Evidence quality constraints protect against routing on evidence that is too thin to be reliable. Evidence can be statistically present : a provider can have a score while still being insufficient for governance purposes. Too few observations, too little coverage distribution, too much staleness: the score becomes noise dressed as signal, and InfraBench will not route on noise.

Geographic relevance constraints protect against applying evidence across contexts it was not collected from. A provider’s observed performance in one region is not a reliable proxy for its performance in a different region. Mismatched geography creates false certainty. The system will not apply geographically irrelevant evidence to a live routing decision.

Performance threshold constraints protect against routing to a provider that cannot meet the client’s specified requirements, even if it is the best currently available. If no provider in the current evidence meets the stated latency threshold, the system does not lower the bar. It abstains.

Safe Failure as a Design Feature, Not a Fallback

This deserves its own section because it runs directly counter to the design instinct of most engineers building routing systems.

The instinct is: always return something. Graceful degradation. Best-effort routing. Never leave the client without an answer. Keep traffic moving.

That instinct is appropriate for many systems. It is the wrong instinct when the client is making capital-sensitive infrastructure decisions.

In those environments, the cost structure is asymmetric:

The cost of abstention is operational friction. The client must wait. They may need to wait for a fresher measurement cycle, seek alternative routing, or escalate to a human review. This cost is real, measurable, and bounded.

The cost of a bad route is execution risk. Wrong provider selection. Degraded latency. Higher slippage probability. Weakened incident response. Possible capital loss. This cost is also real, often unmeasurable until after the fact, and significantly higher on a risk-adjusted basis than the cost of waiting.

InfraBench is built around a deliberate preference: abstention is cheaper than a bad route when evidence is insufficient. This preference is not a runtime configuration. It is an architectural commitment. The governance constraints are not soft guidelines or adjustable thresholds. They are hard gates. You cannot route around them by passing a parameter.

This is what the live ledger reflects today. At infrabench-ruddy.vercel.app/ledger, every current decision row shows ABSTAIN. The rationale is explicit: the current snapshot is 12 days old, coverage quality is low, and the evidence is outside the governance freshness tolerance. That is not a system malfunction. The system is working exactly as designed, protecting operators from routing on evidence that does not meet the required standard, while documenting precisely why in a form that can be reviewed after the fact.

The system is not stuck. It is honest.

The Accountability Ledger: Making Decisions Defensible

Most routing systems are stateless in their decision surface. They make a choice and return it. There is no preserved reasoning. There is no way to answer, weeks later: why did the system route to this provider at that moment?

The accountability ledger answers that question.

Every routing decision : every READY and every ABSTAIN , produces a ledger entry that captures the full context of the decision. Every field visible in the live system today is observable directly at the product URL:

• Timestamp — When the decision was made
• Region — The geographic context of the request
• Workload — The operational intent: reads, trading, or indexing
• Provider — The evaluated provider
• Latency — The observed latency at decision time, in milliseconds
• Confidence — The evidence quality state at the moment of decision
• Decision state — READY or ABSTAIN
• Rationale — Machine-readable, human-legible explanation of every factor that contributed to the decision

This is not logging in the conventional sense. Logging records that something happened. The ledger records why something happened, with the evidence context that justified the decision preserved alongside the outcome.

For procurement teams, risk managers, and quantitative desks, this distinction changes the nature of infrastructure accountability. Routing decisions move from opaque operational choices to defensible, traceable governance acts. When a trade misses, when an incident surfaces, when a contract is reviewed : the reasoning trail exists.

Confidence Without False Certainty

One of the design choices in InfraBench that is most counterintuitive to people familiar with ML-based systems is this: confidence is not a prediction.

In most scoring systems, a confidence score expresses how likely it is that a recommendation is correct. InfraBench confidence expresses something different: how much the current evidence deserves to be trusted as the basis for a routing decision.

These are not the same thing. And conflating them is the source of a specific, common failure mode.

A provider with a high confidence state in InfraBench means the evidence for that provider is well-sampled, geographically relevant, and fresh. It does not mean the provider is definitely performing well right now. It means there is sufficient evidence to make a defensible claim about its behavior.

A provider with a low confidence state means the evidence is insufficient. Too few observations, poor coverage distribution, stale measurements, or weak geographic relevance. The routing engine will abstain ; even if the provider’s available statistics look strong on their face. A strong result from thin evidence is still thin evidence. The system will not route on it.

This distinction prevents a failure mode that is common in scoring systems: the confident-but-wrong recommendation. InfraBench trades the appearance of certainty for the substance of defensibility. It will not tell you where to route unless it can show you why and the why has to be grounded in evidence that meets the governance standard.

The Enterprise Translation Layer

Technical architectures need to translate to business outcomes. The table below is the explicit mapping between what InfraBench does at the system level and what that means for the teams evaluating it.

The governance ROI is not about speed. It is about defensibility.

• Fewer bad routing decisions made on evidence that does not support them
• Fewer blind provider choices made without measurement
• Faster, evidence-backed selection for procurement workflows
• An audit trail connecting routing decisions to observable evidence
• A safe failure mechanism that halts routing when the evidence cannot support it

This is not a billing system. It does not invoice, chargeback, or reconcile spend. The economic model today is decision governance : rigorous control over how providers are selected, with full accountability for those choices. That is the foundation layer. The billing and financial governance layers are what come next.

What Is Running Today

The live system at infrabench-ruddy.vercel.app is a working, deployed product not a prototype.

The Accountability Ledger shows 42 decision rows across three providers : Helius, QuickNode, and Solana Public RPC in the Frankfurt region, across three workload types: reads, trading, and indexing. Average observed latencies in the current snapshot: Helius at 56.4ms, QuickNode at 76.9ms, and Solana Public RPC at 80.5ms. Every row carries a full rationale. Every row is in ABSTAIN state ; correctly, because the current snapshot is 12 days old and outside the governance freshness tolerance.

The Route API at /api/v1/route is live. It accepts typed requests and returns structured READY or ABSTAIN responses with full reasoning. The decision logic is deterministic and stateless at the API level : the same request on the same snapshot always produces the same result.

The Decision UI, Coverage, and Methodology pages expose what regions are currently supported, how evidence quality is assessed, and what the evidence state looks like ; making the governance model transparent, not just the decisions it produces.

The architecture intentionally avoids complexity in its public deployment. There is no runtime database, no message bus, and no service mesh in the deployed path. The system knows exactly what it knows, serves it deterministically, and makes no claims beyond what its evidence supports.

The measurement pipeline is operational. Expanding regional coverage adding Asia-Pacific, North America, and Southeast Asia measurement nodes is the immediate next step, building a genuinely global evidence base rather than a single-region snapshot.

The Future Direction

The current system is the foundation. The architecture is designed to expand in layers.

Near-term: Multi-region evidence. Frankfurt is one vantage point. Adding geographic depth transforms a single-region snapshot into a globally comparative evidence base enabling routing decisions that are geography-aware in substance, not just in labeling.

Near-term: Live event-sourced ledger. The current ledger is seeded from snapshots. The next evolution is a continuously updated ledger that records every API routing decision as it happenscreating a real-time operational history and an analytics substrate for governance reporting.

Mid-term: Cost accounting and SLA tracking. The economic architecture blueprint is already designed. The next layer adds spend reconciliation by workload and team, contract-level SLA performance tracking, and formal provider accountability. This moves InfraBench from decision governance to financial governance.

Mid-term: Agent-native routing. As autonomous agents become economic actors on Solana executing DeFi strategies, managing protocol operations, handling cross-program invocations they need infrastructure routing that is machine-readable, latency-aware, workload-specific, and auditable. The headless API is already designed for this. InfraBench becomes the routing primitive that agents call before they submit transactions.

Long-term: On-chain settlement and verifiable SLAs. The first article in this series proposed tokenizing RPC performance. The architecture that makes tokenization meaningful : independent measurement, formal scoring, transparent evidence, traceable decisions — is now built. On-chain settlement becomes an extension of an existing governance model, not a greenfield design problem. The destination the first article described now has a road leading to it.

Why the Router That Says No Is the Right Router

There is a design philosophy embedded in almost every routing system ever built: when in doubt, pick something. Best-effort. Graceful degradation. Keep traffic moving. The instinct is well-intentioned. It comes from a legitimate design value: availability over correctness.

InfraBench is built on the opposite instinct.

The two earlier pieces in this series argued that infrastructure decisions have economic consequences. The Physics of Finality described how geography becomes governance when finality operates at 150 milliseconds. From Latency to Value described how routing asymmetry becomes economic asymmetry when access to execution quality is unevenly distributed.

InfraBench is what those articles were implicitly arguing for: a layer of infrastructure that treats routing decisions as governance acts that measures independently, decides deterministically, fails safely, and preserves an auditable record of every choice it makes.

The governance layer that Solana’s institutional infrastructure stack is missing is not a better dashboard. It is not a smarter ranking algorithm. It is a system that can look at the evidence in front of it and say, with full explanation: not yet.

That is what InfraBench is built to do.

Vishnu Govind explores the intersection of distributed systems, infrastructure economics, and blockchain governance. InfraBench is live at infrabench-ruddy.vercel.app

Every Solana RPC Provider Claims to Be Fast was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.