ERPC Publishes "How to be faster on Solana?" — a Report Visualizing What Determines Speed on Solana as the Physics of Network Distance, With Live Data
ERPC Publishes "How to be faster on Solana?" — a Report Visualizing What Determines Speed on Solana as the Physics of Network Distance, With Live Data
ELSOUL LABO B.V. (Headquarters: Amsterdam, Netherlands; CEO: Fumitake Kawasaki) and Validators DAO, which operate ERPC, are pleased to announce the publication of "How to be faster on Solana?", a report page that lays out — in a single, top-to-bottom walk that even a non-specialist developer can grasp at a glance — how to get faster on Solana.
In recent years, a growing number of developers and teams have taken up high-frequency trading (HFT) and real-time financial infrastructure on blockchains, and on Solana in particular. Yet the knowledge behind the most basic questions — why some are faster, and how to get faster — has remained scattered across individual technical blog posts and fragmentary explanations, with few resources that let you grasp the whole picture quickly. This report reorganizes the core of the technical articles ERPC has published over time into one continuous "line of physics."
This report shares practical understanding for using the network more efficiently and at higher speed — even on a decentralized network whose participants are spread across the world. We believe that systematically sharing where, and why, differences in speed arise contributes to the efficiency and healthy growth of the broader blockchain ecosystem, including Solana, beyond the interest of any single provider.
How to be faster on Solana? (the report): https://erpc.global/en/how-to-be-faster/
ERPC Official Site: https://erpc.global/en
ERPC Dashboard: https://dashboard.erpc.global/en
What Determines Speed Is Not Your Code or Your Machine — It Is the Unseen Third Layer
"I run the same strategy, yet only my bot gets filled late." "Prices update fine, but only my transactions do not make it." "I switched RPC providers, and nothing changed." — the complaints developers competing on speed voice on Solana are strikingly similar.
The first suspect is always "maybe my code is slow" or "maybe my specs are not good enough." Optimizing your code and your machine does help, of course. But in many cases where you have already tuned both thoroughly, what remains to the very end — and is the most overlooked — is an invisible third layer: your network distance to Solana.
Once your execution path is well optimized, what instruction-level CPU tuning can still shave off lives in the world of nanoseconds to at most a few microseconds. Network distance, by contrast, governs hundreds of milliseconds — a lever on the order of about 1,000× sits sleeping in the layer people overlook most. Past the point where you have polished your code and your machine, the largest remaining headroom is in that third layer.
On Solana, the "Fastest Place" Moves Around the World Every Slot
On Solana, a slot advances roughly every 400 milliseconds, and each slot has a validator assigned as its "leader" to build that slice of the block. Leaders switch rapidly (the same validator may hold several consecutive slots), and the server closest to that leader gains a large advantage for that slot.
This is what makes it fundamentally different from traditional high-frequency trading. In equities or FX, placing your servers next to the exchange's single matching engine — a fixed point that does not move — kept you ahead for good. On Solana, the leader moves around the world slot by slot. The fastest seat is somewhere different every time. Camping next to one spot once and being done with it simply does not work here.
In the report, a globe driven by live data from ERPC's Leader Slot Information API (getLeaderSlots) shows the current leader, and its dizzying turnover, exactly as it happens. "The fastest place keeps moving" — this is not a metaphor, but a fact you can observe live.
Distance Is Latency — From ~0.1ms on the Same Network to 100–300ms Across Continents
The speed of light through fiber, and the number of router hops along the path, set a floor that no hardware can beat. Distance takes effect roughly in the following orders of magnitude:
- Same network: ~0.1ms
- Same datacenter: ~0.3ms
- Same city: ~1ms
- Neighboring country: ~5–10ms
- Across continents: ~100–300ms
A single slot is only about 400 milliseconds. The 100–300 milliseconds of crossing a continent eats up the window of an entire slot on its own. When the leader is on your doorstep you make it inside the window; when it is on the far side of the planet, you have already missed it before you send. Being fast for every slot means always being "near" wherever the leader lands.
Note that the contrasts in the report — "~0.1ms on the same network" versus "on a roundabout path the number of relay hops (hops = the routers a signal passes through) rises to about 7, and latency widens to about 70×" — are round figures meant to convey, intuitively, the gap between a near route and a far one. The large measured swings appear in the live data from ERPC's Leader Slot Information API: the measured latency from a given node to the leader changes greatly depending on where the leader is (which slot), and swings on the order of tens of times between near and far slots have been observed. A single "average latency" number is often just a fast slot and a slow slot taking turns; the average frequently hides the reality.
And a "city name" is not the network path itself. Even within the same city, if external transit or extra hops are inserted, latency piles up by that much alone. That is exactly why you choose the nearest node by measured arrival time (ping), not by distance on a map.
One City Is Not Enough — Multi-Region, Always Near the Leader
The city where Solana's validators cluster most densely is Frankfurt. Even so, in a measured snapshot at the time of publication, the validators gathered in Frankfurt account for only about a quarter of the network as a whole — by validator count and by stake alike. The remaining roughly three quarters of slots are led from somewhere other than Frankfurt.
In other words, even if you place your single best machine in the most crowded city, that alone can never make you "always fastest." Standing by in several regions (for example Frankfurt / Amsterdam / New York / Tokyo / Singapore), receiving near whichever leader is live, and handing off as the leader moves — this is the way to be fast for every slot.
When Your Transactions Do Not Land, You Are Stuck in the Spam Lane
Speed is not only a matter of where your server sits. Which lane you deliver your transaction through also decides success or failure.
Of the capacity of the TPU (Transaction Processing Unit) that receives transactions, the leader allocates up to about 80% to stake-weighted priority — that is, to connections backed by SOL committed to a validator (stake) (SWQoS / Stake-Weighted Quality of Service). The remaining roughly 20% is shared by every other connection. The latter is a crowded lane packed with spam. Note that this ~80% allocation is decided on the leader side as a matter of Solana's protocol, not something ERPC sets.
Firing transactions straight at the leader feels like the fastest move. But without the backing of stake, that means queuing in the crowded ~20% lane, and under load your transaction ends up never making the block. The essential answer is to send over a stake-backed path — from an RPC connected to a staked validator through a trusted-peer relationship. ERPC operates a top-tier staked validator, connected to high-quality RPC lines, as the backing for this (Shinobi Performance Pool).
Hardware Only Matters When It Runs at Full Power
Even a server placed in the right spot cannot make use of the closeness it gained if the box itself does not run flat-out. A virtualized VPS shares a hypervisor, so it is prone to jitter and stalls from "noisy neighbors" precisely when things get most crowded. Dedicated bare metal does not have that. The clock-speed floor a Solana validator must meet is 2.8GHz; ERPC's bare metal runs well above that, at a high 5.7GHz-class clock, while keeping utilization at 30–40% — because a CPU pinned at 95% generates jitter like a jammed road.
This difference is not limited to top-tier bare metal. In the report, we place ERPC's VPS (VPS++) side by side with a comparably specced major-cloud virtual machine (both AMD Turin / 4 vCPU) using an actual benchmark (node_bench). This is not a production; it is a "measurement" anyone can reproduce with the same method. ERPC consistently emphasizes demonstrating delivery quality and speed through measurement, not through subjective claims or marketing copy.
The Final Answer: Same Network = Zero Distance
Where this whole line of reasoning arrives is a single point: being "on the same network" as Solana's infrastructure — RPC, validators, and the real-time paths involved in trading, such as Jito and Shredstream. On the same network it is ~0.1ms, and packets never cross the public internet at all. "Over the public internet," the default for most people, is exactly why most people are slow. Zero distance is the conclusion that ties together location, machine, and stake.
ERPC — Every Optimization the Physics Demanded, on One Platform
For each answer the report derives as physics, ERPC has a corresponding means in place: VPS and bare metal on the same network (zero distance), standing by in multiple regions (FRA / AMS / NY / TYO / SGP) (always fastest), routing based on measured ping (to the truly nearest node by path, not by map), the getLeaderSlots API (knowing the leader's position slot by slot), and 5.7GHz-class bare metal tuned with the open-source SLV (full power).
ERPC was born because we needed it ourselves in the first place. Running the open-source Epics DAO (a card game on Solana), we could not buy this kind of infrastructure even when we tried, so we had no choice but to build it ourselves. Now you can stand on that same foundation.
On ERPC, you can combine Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, bare-metal servers, dedicated RPC, SWQoS, a Pyth-enabled Price API, and Jet Analytics & Indexed RPC on a single platform.
Using Decentralized Networks Faster and More Efficiently
There is a part of speed that can be improved through the right infrastructure investment. But what this report consistently tries to convey is that understanding "where, and why, the difference arises" is the real edge. Once you understand where you are losing time — location, path, machine, or stake — you can then choose the right resources and focus on your core work: strategy, coding, and development.
Even on a decentralized network, the network can be used efficiently. Sharing that reality in a systematic way should contribute to the efficiency and growth of the broader blockchain ecosystem, including Solana, beyond the interest of any single provider.
R&D and Continuous Improvement of Solana-Specific Infrastructure
Behind ERPC is the research and development of Solana-specific infrastructure that ELSOUL LABO continues to pursue. ELSOUL LABO has been approved for five consecutive years since 2022 under WBSO, the Netherlands' government R&D support program. It continues R&D on Solana RPC infrastructure, validator operations, real-time data delivery, and AI-agent-assisted operations and development, and those results are reflected across services including ERPC, SLV, SLV AI, and the AS200261 Solana-specific data center. The publication of this report, too, is an effort that follows directly from this continuous research and development. ERPC will continue to publish its results in a systematic way.
Usage and Consultation
For questions about the content of this report, consultation on improving the speed of your own setup, help selecting resources or planning a migration, or questions about benchmarks, please create a support ticket on the official Validators DAO Discord.
How to be faster on Solana? (the report): https://erpc.global/en/how-to-be-faster/
ERPC Dashboard: https://dashboard.erpc.global/en
ERPC Official Site: https://erpc.global/en
Validators DAO Official Discord: https://discord.gg/C7ZQSrCkYR
We sincerely thank all of our users for their continued use of ERPC.
Links
- How to be faster on Solana? (the report): https://erpc.global/en/how-to-be-faster/
- ERPC Official Site: https://erpc.global/en
- ERPC Dashboard: https://dashboard.erpc.global/en
- ERPC Pricing: https://erpc.global/en/price/
- SLV Official Site: https://slv.dev/en
- SLV GitHub: https://github.com/validatorsDAO/slv
- Validators DAO Official Discord: https://discord.gg/C7ZQSrCkYR
News
