ERPC Expands Solana Leader Slot API with Ping Measurement from 7 Global Regions — Validators Information API Also Launched
ERPC Expands Solana Leader Slot API with Ping Measurement from 7 Global Regions — Validators Information API Also Launched
ELSOUL LABO B.V. (Headquarters: Amsterdam, the Netherlands; Representative Director and CEO: Fumitake Kawasaki) and Validators DAO, the operators of ERPC, have enhanced the APIs for understanding Solana leader information, estimated locations, and latency, adding support for reference RTT (ping measurement) from 7 global regions to the Leader Slot API and launching the new Validators Information API.
First, we have expanded the Leader Slot API (
getLeaderSlots) so that reference RTT can be obtained from 7 ERPC observation regions around the world (Frankfurt, Amsterdam, New York, London, Tokyo, Singapore, and Sydney). Previously, measurements were taken from Frankfurt only.Alongside this, we have launched the new Validators Information API (
getValidatorsInformation). This API lists, in a single call, every validator holding at least one leader slot in the current epoch. In addition to slot count and active stake, it also returns, where available, the estimated location, network endpoints, client version, and reference RTT from the 7 regions.Both APIs are available to all ERPC users through the standard JSON-RPC interface.
- Leader Slot API documentation: https://erpc.global/en/doc/rpc/leader-slot-api/
- Validators Information API documentation: https://erpc.global/en/doc/rpc/validators-information-api/
How Solana Differs from Traditional Trading Infrastructure: The Destination Changes Dynamically
In traditional exchanges and financial systems, the destinations to which orders are sent — exchanges, gateways, matching engines — are typically fixed to specific data centers or networks.
As a result, once users know the connection destination, they can continuously optimize their network path to it. Because the locations of the target servers do not change frequently, infrastructure placement and communication routes can be designed relatively statically.
On Solana, by contrast, the leader — the validator responsible for producing blocks — rotates every few slots according to the leader schedule. Because the validators serving as leaders are distributed around the world, both the destination your transactions must reach and the network path closest to that destination change continuously.
In other words, on Solana, the communication destination to optimize for cannot be treated as a fixed, single connection point.
You first need to identify the current and future leaders from the leader schedule. On top of that, you check which region or network each validator is most likely located in, and how much latency there is from each sending location, before deciding on a sending route.
Correctly understanding this structure is the starting point for low-latency transaction delivery and global infrastructure design on Solana.
Treating the Leader Schedule and Network Locations as Data
In an environment where the destination changes dynamically, it is not practical for a person to check the leader and sending location each time and switch routes manually.
What is needed is to continuously obtain the following information and build it into the decision logic of your applications and infrastructure.
- The leaders responsible for current and upcoming slots
- The number of slots each validator is responsible for
- Each validator's estimated country, city, and region
- Network endpoints such as TPU and QUIC
- Reference RTT collected from each observation region
- The time each measurement was taken and its response status
Estimated location and measured latency each play a different role.
Location information can be used for medium- to long-term decisions about where to place infrastructure and capacity. Reference RTT from each region, on the other hand, provides input for judging which location is currently most likely to offer a short path.
A physically or geographically close location is not always the shortest path on the network. For this reason, it is important to make decisions by combining the estimated location with actual observed values.
ERPC's Leader Slot API and Validators Information API are APIs designed to let you program these decisions based on data.
Leader Slot API: Measuring Reference RTT from 7 Global Regions
The Leader Slot API returns upcoming leader slots together with validator identity, active stake, network endpoints, estimated location, reference RTT, and more.
Until now,
pingToLeaders measurements were collected from the Frankfurt origin only — a single observation point against a globally distributed Solana network.With this update, you can now obtain reference RTT measured from the following 7 regions.
frankfurtamsterdamnylondontokyosingaporesydney
By comparing the reference RTT from the 7 observation regions for each leader, you can judge which sending location is most likely to offer a short network path.
This serves as decision-making input not only for transaction routing, but also for deciding in which regions to place capacity for RPC, gRPC, Direct Shreds, transaction sending servers, and more.
The measurement results include
icmpReplied, which indicates whether the validator responded to ICMP, and measuredAt, which indicates the time when the last successful measurement was obtained.A validator that does not respond to ICMP may still be operating services such as TPU and QUIC normally. For this reason, when
icmpReplied is false, it should be treated not as "distant" but as "not measurable via ICMP."In addition, when a successful measurement cannot be obtained at refresh time, the entry is not overwritten with an unmeasured value — the last successfully measured value and its measurement time are retained.
Validators Information API: Listing Leader Information Across the Entire Epoch
The Leader Slot API is suited to slot-level decisions — "who is the leader responsible for the next slots?"
Infrastructure placement and capacity planning, on the other hand, require a broader view.
- Which validators are serving as leaders in the current epoch
- How many slots each of them is responsible for
- Which countries and regions they are distributed across
- Where to place infrastructure to get closer to more leaders
The new Validators Information API (
getValidatorsInformation) is the API built to answer these questions.Called with no parameters, it returns every validator serving as a leader for at least one slot in the current epoch, one row per validator. By default, results are returned in descending order of the number of leader slots held.
Each row includes the following information.
slotCountstakeWeight(active stake in SOL)- Validator identity
Where available, the following information is also returned.
- Estimated region, city, and country
- Network endpoints
- Client version
- Reference RTT from the 7 regions
Because the data is refreshed regularly, calling the API on a regular basis keeps your planning dataset up to date.
You can also narrow the results using the optional
limit (1–2000), country, and region parameters.Billing is based on the number of validators returned. The number of leader validators varies from epoch to epoch; in the example at the time of writing, fetching all 673 validators uses 6,800 API tokens (ERPC API usage credits), and fetching up to 10 validators uses 100 API tokens.
Toward Programmable, Data-Driven Routing
These APIs are not meant simply for displaying a list of validators or reference RTT.
The ultimate goal is to let you build the leader schedule, validators' estimated locations, and reference RTT from each observation region into the decision logic of your applications.
For example, an application can fetch the upcoming leader schedule, compare the reference RTT from the 7 observation regions for each leader, and then select the RPC or transaction sending route to use.
You can also analyze the leader distribution across the entire epoch and place infrastructure in advance in regions close to validators with high slot counts.
Typical uses include the following.
- Selecting sending routes at the slot level
- Capacity planning at the epoch level
- Analysis of leader validators by region
- Prioritization that accounts for active stake and slot count
- Monitoring changes in geographic and network distribution across epochs
- Automatic selection among RPC and sending servers deployed across multiple regions
On Solana, where the destination changes dynamically, static network optimization alone is not enough.
It becomes important to continuously track the changing leader and dynamically select sending routes and infrastructure according to its location and network conditions.
Toward Solana Infrastructure Designed for Global Operation
ERPC is high-performance infrastructure for Solana, designed from day one with global operation in mind.
Our edge network, bare metal and VPS, Direct Shreds, Geyser gRPC, SWQoS endpoints, and these operational intelligence APIs are all provided in service of a common purpose.
That purpose is to provide both data and infrastructure to builders who demand low-latency, efficient execution in an environment where users and leaders are distributed around the world.
Reference RTT from 7 global regions and epoch-wide validator information can now be obtained through simple RPC calls. Solana applications can now select sending locations and network routes based on data, in response to the constantly changing leader.
For builders seeking low-latency delivery, global infrastructure placement, and dynamic routing optimization on Solana, this is decision-making input that connects directly to real-world operations.
We hope this helps with selecting low-latency sending routes, designing infrastructure that reduces unnecessary long-distance transfers, and planning global capacity placement.
For details, see the documentation.
- Leader Slot API: https://erpc.global/en/doc/rpc/leader-slot-api/
- Validators Information API: https://erpc.global/en/doc/rpc/validators-information-api/
- ERPC Web Dashboard: https://dashboard.erpc.global/en
News
