FAQ - Direct Shreds
Q. In which regions are your nodes located?
We currently operate nodes in the following regions:
- Frankfurt (FRA)
- Amsterdam (AMS)
- London (LON)
- New York (NY)
- Chicago (CHI)
- Salt Lake City (SLC)
- Tokyo (TY)
- Singapore (SGP)
ERPC measures actual network latency based on real routing paths, automatically selecting the region with the lowest latency rather than relying on straight-line distance. This approach not only improves latency for individual users but also enhances overall network efficiency and strengthens ERPC’s global resilience against potential attacks.
If none of the above regions are close to your location, the Far Point (FAR) node located in Chicago will be automatically selected.
If your environment does not automatically select the optimal region, please contact us on Discord. In most cases, this issue is caused by firewall settings that block ping responses from the endpoint.
Validators DAO Official Discord: https://discord.gg/C7ZQSrCkYR
Q. I've only used WebSocket or Geyser gRPC (YellowStone) before. Do you have samples?
Yes. You can quickly begin testing Shreds connections and application development using SLV.
Please refer to the following guide for details:
Q. Can I register two IP addresses?
You can use one endpoint per subscription. If you wish to use two IP addresses, you must subscribe to two separate subscriptions.
Q. I need latency of at least ~400ms or better.
To achieve latency within approximately 400ms, consider these essential points:
-
Realistic Understanding of Ping Values: Ping values indicate ideal conditions and do not reflect actual latency in streaming communications, which typically experience around 5 times the ping latency. For example, a ping of 100ms across continents realistically results in about 500ms of latency. Thus, infrastructure must be established within the same region to achieve ~400ms latency.
- Typical Ping Value Reference:
- Same network: ~0.1ms
- Private Network Interconnect (PNI): ~0.2ms
- Same data center: ~0.3ms
- Same city: ~1ms
- Neighboring country: ~5–10ms
- Intercontinental: ~100–300ms
- Typical Ping Value Reference:
-
Avoiding the Pitfall of Average Latency: Solana validators are geographically dispersed globally, and the leader schedule changes randomly with each epoch. Relying on average latency to achieve ~400ms is impractical. Instead, you should precisely track validator schedules in your specific region to identify slots with the lowest latency. To consistently achieve minimal latency, infrastructure across all relevant regions is required. Within the same region, data acquisition can occur in tens of milliseconds, with transmission possible in just a few milliseconds.
-
Tracking the Leader Schedule: Continuously monitor the leader validator schedule for your region using the ERPC Leader Slot API (
getLeaderSlots).
It provides real-time data on upcoming leaders, validator geolocations, and reference ping values, allowing you to accurately identify optimal trading slots with minimal latency.
This eliminates the limitations of public data sources such as Solana Beach or native RPC APIs, which have slower update frequencies and lower precision.
Q. How can I achieve zero-block (zero-slot) trading?
Successfully achieving zero-block (zero-slot) trading requires more sophisticated strategies, as follows:
-
Identifying Opportunity Zones: Solana validators are distributed globally, and it is physically impossible to achieve optimal latency for every slot. Therefore, monitor validator leader schedules in the region where your infrastructure is located and identify the most favorable opportunity zones. Deploying infrastructure across multiple regions can also be advantageous. For example, Frankfurt is a key region due to its high validator density, resulting in more frequent leader selection and greater trading opportunities.Use the ERPC Leader Slot API (
getLeaderSlots) to obtain real-time leader schedules, validator geolocation data, and reference ping values with far greater precision than Solana Beach or native RPC APIs. This allows you to predict opportunity zones more accurately and execute near-zero-latency trades. -
Implementing Dedicated Nodes: If you struggle to compete, consider deploying dedicated nodes. Shared nodes experience latency due to traffic from other users, and thus are not recommended. Furthermore, placing your dedicated node within the same network as your application significantly reduces network latency and optimizes performance.
Q. Can I use a specific endpoint?
To maintain a low-latency environment, our system automatically selects the closest available node. If you wish to use a specific endpoint, we recommend renting a server located nearest to that endpoint.
Q. Why are dedicated endpoints faster?
Shared endpoints are used by multiple customers who share the same resources. As traffic increases, latency tends to occur. Server resources have physical limits, and the amount of work they can handle is finite. When too many requests arrive at the same time, they must be processed sequentially, which results in slower response times.
Although we take various measures to optimize performance even on shared endpoints, with dedicated endpoints you are the sole user of the resource. This means you are completely unaffected by other users, ensuring consistently stable and fast responses.
In addition, dedicated endpoints provide communication options without TLS, such as HTTP. By skipping the TLS handshake (around 20ms), communication becomes even faster compared to HTTPS.
Q. I want to pay with crypto
ERPC is currently developing “Subscription NFTs.” This mechanism issues subscription rights as NFTs, allowing ownership, transfer, and resale, thereby greatly improving the crypto payment experience. The release is scheduled for the end of 2025. For more details, please see the following link:
Subscription NFTs Press Release: https://erpc.global/en/news/2025/08/31/erpc-subscription-nfts/
However, since development and release will take time, if you want to start paying with crypto right now, we recommend trying services that allow you to use cryptocurrencies as credit card payments:
- Bybit Crypto Card: https://www.bybit.com/en/cards
- Wirex Card: https://wirexapp.com/card
By using these services, you can immediately start paying with cryptocurrency just like with a regular credit card.
Q. Why doesn't ShredStream include all transactions?
By design, Shreds do not include every transaction on the Solana blockchain. Monitoring all transactions would require deploying numerous proxies globally and receiving Shreds from every validator, which is not practical.
Typically, users operate with a subset of the available data, as this approach is sufficient for most real-world applications. If your use case demands complete data coverage without any loss, Shreds might not be suitable.
For scenarios requiring more comprehensive monitoring, Geyser gRPC provides higher reliability compared to Shreds. However, achieving 100% data coverage on the Solana blockchain still requires deploying numerous edge servers, which may not be realistic in practice.
Geyser gRPC offers reliability exceeding 99%, which is notably higher than Shreds, a fact confirmed by many users, including us. Shreds, however, typically provide over 90% reliability.
While they do not capture every transaction, their key advantage is the ability to rapidly retrieve most transactions faster than Geyser gRPC.
For a deeper understanding, we recommend exploring Solana's Turbine and Gulf Stream protocols:
- Gulf Stream: Solana’s Mempool-less Transaction Forwarding Protocol
- Turbine — Solana’s Block Propagation Protocol Solves the Scalability Trilemma
Q. I want the best possible environment.
For the optimal setup, we recommend combining a dedicated Shreds node with our Bare-Metal servers. Sharing the same network, this setup achieves private, zero-distance communication with latencies around 0.1ms ping.
Please contact us on Discord for more details.
Q. What is the latency like?
Latency varies depending on the measurement method and your specific usage environment. Rather than focusing on exact numerical values, it's crucial to ensure that the latency meets your actual operational requirements.
We offer free trials across all our plans, enabling you to test performance directly in your real-world environment. Additionally, we provide easy-to-use tools in TypeScript and Rust for measuring latency. Feel free to utilize these tools alongside your free trial.
Q. Is this RPC (gRPC, Shreds) faster than others?
We encourage you to try our free trial and compare the performance against other services. If you find our service slower, please let us know the specific conditions and competitors you've compared it against via Discord. We will identify the cause and improve the speed further.
We continually work on improving latency based on customer feedback. If you seek the fastest possible endpoint, please share detailed information with us. Providing specific metrics and comparison conditions against competitors allows us to deliver superior performance. This feedback-driven approach has consistently enabled us to enhance our services.
Q. Which plan offers the fastest performance?
Generally, our highest-tier plan provides the fastest performance due to superior CPUs, higher memory capacities, and robust hardware configurations.
We also offer customized solutions if you require even more powerful servers, but our standard plans are designed to deliver optimal price-to-performance ratios.
We are confident in providing world-class performance at every price level. If you find a faster provider within the same price range, please let us know so we can investigate and make improvements.
Q. I'm experiencing high latency. Why?
Latency significantly increases with distance from the endpoint. We recommend accessing from a server located closer to the endpoint provided. The fastest environments are available via our Bare-Metal servers and VPS services.
Q. Which is the fastest: WebSockets, gRPC, or Shreds?
Based on customer feedback, the performance order is:
Shreds > gRPC > WebSockets
If your experience differs, please inform us.
Q. Latency isn't what I expected.
Performance varies significantly depending on the programming language used. Generally, the performance order is:
Rust > Go > TypeScript (JavaScript) > Python
For detailed comparisons, please see:
We strongly recommend Rust for the highest performance.