ERPC Adds HTTPS to Solana Shared Shreds and Geyser gRPC Endpoints — Choose HTTPS or HTTP per Use Case
ELSOUL LABO B.V. (Headquarters: Amsterdam, the Netherlands; Representative Director and CEO: Fumitake Kawasaki) and Validators DAO, the operators of ERPC, have added HTTPS support to the shared Shreds gRPC and Geyser gRPC endpoints. Together with the HTTP transport we have always offered, you can now choose between HTTPS and HTTP.
This applies to Direct Shreds Connect and Direct Shreds Turbo on the Shreds gRPC side, and to the Standard, Premium, and Burst tiers of Shared Geyser gRPC Stream.
You can pick an encrypted, secure HTTPS endpoint, or an HTTP endpoint that carries no TLS processing at all. In gRPC terms, the former is gRPC over TLS and the latter is plaintext HTTP/2. That covers a far wider range of use cases — from workloads where latency is the only thing that matters, to workloads where the confidentiality of what you subscribe to matters most.
The endpoint hostname does not change. Only the scheme and the port differ: HTTPS uses port 443, HTTP uses port 80. You switch between them in the ERPC Web Dashboard.
HTTPS Is What's New — Existing HTTP Continues Unchanged
ERPC's shared stream endpoints have been served over HTTP until now.
What has been added is the HTTPS side. Existing HTTP connections are unchanged in both specification and behavior, and you can keep using them exactly as before. Customers already connecting over HTTP do not need to do anything.
We have no plans to retire HTTP. It remains available as the option for workloads where latency comes first.
HTTPS — Encrypted, Secure Connections
On an HTTPS endpoint, the entire exchange between your client and ERPC is encrypted with TLS.
Both the contents of your subscription request and the stream data returned to you are encrypted with TLS, so the payloads normally cannot be read along the path. In the ERPC Web Dashboard, HTTPS is the transport selected by default.
The TLS handshake happens principally when the connection is established. Encryption and decryption of the stream data continue after that, but a typical long-lived gRPC stream does not pay that handshake cost over and over.
HTTP — The Low-Latency Option Without TLS Processing
On an HTTP endpoint, there is no TLS handshake and no encryption or decryption work at all.
In Solana real-time processing, every piece of work along the path from where the data is produced to where your application receives it affects latency. Because it requires no TLS encryption or decryption, HTTP suits low-latency workloads that aim to cut processing on the path wherever possible.
HTTP has the edge in setups that re-establish connections frequently, or in setups that cannot tolerate any overhead on the path whatsoever.
When the Shape of a Subscription Filter Carries Meaning
HTTP is the lower-latency option, but depending on how a project uses it, the group of addresses being requested is exposed along the path — and for some projects that is a problem.
The data on the blockchain is public in itself. Yet when the grouping is exposed, it can carry meaning that no single item carried on its own.
Suppose a project wants to filter and monitor every one of its customers' wallets. The list of addresses in that subscription request can itself be sensitive information for that project. Even when each individual address is public, knowing which set of addresses is monitored as a single group can offer clues to the project's customer base, what it watches, and where its business interests lie.
This is exactly where the HTTPS endpoint helps. In return for the encryption and decryption work that TLS requires, the payloads of both your subscription request and the stream data are encrypted.
Latency first, or confidentiality of the subscription first? That call differs from project to project. ERPC now leaves that choice to you, to make according to your own use case.
Scope: Shared Endpoints
HTTPS support covers the following shared endpoints:
- Direct Shreds Connect
- Direct Shreds Turbo
- Shared Geyser gRPC Stream — Standard
- Shared Geyser gRPC Stream — Premium
- Shared Geyser gRPC Stream — Burst
HTTPS is enabled across the shared stream endpoints in every region, and the existing HTTP endpoints are preserved as they were. Shared endpoints included in Shreds Bundle and ERPC Bundle can use HTTPS as well.
Dedicated endpoints are not part of this change. Dedicated Geyser gRPC and the dedicated Shreds products keep their existing connection method, unchanged.
Switch in the Dashboard — the IP Allowlist Is Shared
You switch transports from the endpoint display in the ERPC Web Dashboard.
Switch between HTTPS and HTTP; the endpoint URL for the selected transport is shown. Configure your client with the URL exactly as displayed.
Both transports use the same registered-IP allowlist. Authentication is still based on your registered IP address, so there is no need to re-register IPs in order to move to HTTPS, and no token or Authorization header to add.
ERPC's Shared Shreds Products Continue After Jito ShredStream Ends
Jito ShredStream ends service on September 5, 2026. ERPC's shared Shreds products, by contrast, continue after that date.
Direct Shreds Connect and Direct Shreds Turbo — both covered by this HTTPS rollout — along with the Shreds Bundle multi-IP plans and the Direct Shreds Connect included in ERPC Bundle, all remain available beyond September 5.
For clarity: the September 5 end of service announced on August 21, 2026 applies to the dedicated Shredstream products and Stream Bundle. The shared Shreds products are not included in it. Migration guidance for customers on dedicated plans continues to be handled individually, as before.
If you are reviewing how your project receives Shreds, this is a natural moment to look at the options. We would be glad for you to try them.
Test It on Hourly Billing, From One Hour
ERPC shared endpoints are available from one hour, billed hourly.
Without committing to a monthly plan, you can try both HTTPS and HTTP against your real workload and see for yourself how latency and confidentiality balance out in your own environment.
Start with a short evaluation, then choose your plan based on what you measure.
A Renewed UDP Forwarding Product Is Coming Soon
For UDP Forwarding — which simplifies the Shreds delivery path itself — a renewed product is coming soon.
The goal is a lineup where you can pick the delivery method that fits the job: UDP for workloads that put low latency above everything else, and Shreds gRPC for stream subscription over the existing gRPC interface.
Supported regions, pricing, detailed specifications, and the official release date will be announced once they are ready.
Infrastructure You Choose to Fit the Job
ERPC does not judge Solana infrastructure performance on server specifications alone. Proximity to the data source, network path, hardware, OS and kernel, and the final delivery method to the user are all designed together as a single low-latency system.
This HTTPS rollout widens the choice within that final delivery method. There is no single fastest option that is right for every project; how much weight to give latency versus confidentiality depends on the nature of the product.
If you have any questions, please reach out through the support chat in the ERPC Web Dashboard.
