.jpg)
September updates reduced the distance between receiving Solana data, understanding what a transaction does, sending a response, and measuring whether that response landed.
We partnered with Raiden for an additional raw-shred source, expanded Aperture TxStream with Solana v1 transaction support and richer simulation output, and added landing-rate and latency tracking for QUIC sendTransactionFast. At the same time, the streaming product line became simpler: TxStream moved fully to the Aperture plan, while the older Aperture gRPC interface was deprecated.
For trading systems, MEV infrastructure, execution-sensitive DeFi backends, and teams benchmarking transaction routes, we worked for observability across the execution path.
TL;DR
- RPC Fast partnered with Raiden to integrate raw shreds into its gRPC infrastructure and improve data-stream performance.
- Aperture TxStream now supports Solana v1 transactions, increasing the supported maximum transaction size from 1232 to 4096 bytes.
- RPC Fast now measures landing rate and latency for QUIC
sendTransactionFast, with status tracking performed asynchronously so monitoring stays outside the transaction-sending critical path.
- TxStream simulation output got richer, giving consumers more information from the real-time simulation stage.
- Aperture TxStream is now exclusive to the Aperture plan, while the older Aperture gRPC product has been deprecated in favor of TxStream.
- The documentation now includes an updated Shredstream gRPC section.
Raiden adds another raw-shred path into RPC Fast
RPC Fast partnered with Raiden in September to integrate raw Solana shreds into its gRPC infrastructure.
For latency-sensitive infrastructure, another shred source matters for first-byte latency, coverage, regional behavior, and variance when one upstream path slows down.
The useful production tests answer these points:
- Which source arrives first across a meaningful shared sample?
- What do p50, p95, and p99 look like?
- How many transactions are missing or duplicated?
- Does the result change by consumer region?
- What happens during reconnects or upstream degradation?
RPC Fast already separates Yellowstone gRPC, Shredstream gRPC, and Aperture TxStream by workload rather than treating every real-time feed as equivalent. We see Yellowstone as the structured high-throughput layer and shred-derived products as the earlier-signal path.
TxStream now handles Solana v1 transactions up to 4096 bytes
September also expanded the transaction formats Aperture TxStream handles.
Solana v1 transactions are now supported, with the maximum supported transaction size increasing from 1232 bytes to 4096 bytes.
That matters because TxStream sits before application-level strategy logic. It reconstructs shred-derived transaction data and provides a structured transaction stream so consumers do not need to maintain the entire deshredding and reconstruction stage themselves.
The existing TxStream architecture already performs transaction reconstruction, server-side decoding, Address Lookup Table resolution, filtering, and optional simulation.
The example of the enlarged TX format.
Larger transaction support therefore affects the ingestion boundary itself. A consumer does not want the early-data path to stop supporting a transaction merely because newer transaction formats exceed the older size envelope.
TxStream transaction envelope
The early-data pipeline now accepts a broader transaction format before strategy processing starts.
QUIC sendTransactionFast now has landing-rate and latency metrics
Sending a transaction quickly and landing it successfully are different metrics.
RPC Fast now tracks both landing rate and latency for QUIC sendTransactionFast transactions. Submitted transactions stay in memory while RPC Fast monitors their status in the background.
The key implementation detail is that this tracking stays outside the sending path. Status monitoring therefore adds no synchronous step before the transaction leaves the sender.
Users will see these transactions and their landing metrics in the RPC Fast dashboard.
This may influence how a team should evaluate a transaction route.
A 200 OK from the transaction API is not the execution result your strategy cares about.
RPC Fast's production guidance already treats landing rate, confirmation latency, route, and provider-level variance as the metrics that matter for transaction-heavy systems.
TxStream simulation results got richer
Aperture TxStream also received an update to its real-time simulation results.
The important architectural role stays the same: simulation moves information that would normally require a separate request closer to the early transaction signal.
Without that model, a latency-sensitive project often needs to:
receive transaction → decode → prepare simulation request → send request → wait for response → evaluate result
TxStream combines the early transaction feed with optional predicted execution information before the normal confirmation workflow. September's richer simulation output gives strategy code more information at that decision point.
RPC Fast simplified the Aperture streaming line
Two product changes also landed in September:
- Aperture TxStream is now exclusive to the Aperture plan.
- Aperture gRPC has been deprecated and replaced by Aperture TxStream.
The distinction matters because these were different interfaces, even though they shared the Aperture name.
The older Aperture gRPC product was a low-latency streaming interface. TxStream moves further up the processing stack by delivering reconstructed and decoded transaction data rather than making consumers build the same processing pipeline themselves.
RPC Fast had already documented TxStream as the direction replacing the older Aperture gRPC interface.
For new integrations, that makes the streaming hierarchy clearer:
The operational benefit is fewer overlapping interfaces to evaluate when designing a new latency-sensitive consumer.
Shredstream belongs in a different part of the architecture from ordinary RPC reads.
Standard JSON-RPC works for direct account reads, simulation, transaction lookups, and historical queries. Yellowstone gRPC provides continuously processed structured events. Shredstream targets systems where earlier transaction visibility matters enough to work closer to the shred path.
This includes:
- HFT engines,
- MEV searchers,
- Liquidation systems,
- Copy-trading infrastructure,
- Latency-sensitive monitoring,
- Transaction intelligence pipelines.
RPC Fast joined the Colosseum Crypto World’s Fair Hackathon and other events
September was also a builder-focused month. RPC Fast joined the Colosseum Crypto World’s Fair Hackathon, providing participants with free access to high-performance infrastructure for the hackathon and the post-hackathon evaluation period. RPC Fast was added as a recommended RPC provider in the hackathon dashboard.
There is also an additional reward path through the Superteam Infrastructure Sidetrack.
We’ll select one participant to win a Solana Breakpoint ticket; don’t forget to register on our form. Any RPC Fast paid plan and Solana project qualify; one ticket per plan. Upgrades during the campaign also count. We'll announce the winner on October 9.
Quarterly RPC Fast billing now saves 10%
RPC Fast also introduced quarterly discounts across paid SaaS plans. Pay for three months upfront, and the effective monthly price is reduced by 10%. The current pricing page
RPC Fast bills the three-month period upfront.
This is a simpler cost lever than changing infrastructure architecture to reduce a bill. If the workload already fits the same SaaS tier and traffic profile for the next quarter, the discount reduces spend without changing rate limits, stream architecture, or integration code.
What the September updates mean for production Solana architecture
September's changes fit into one execution pipeline:
.jpg)
Around that pipeline, RPC Fast also reduced product overlap: TxStream becomes the main Aperture streaming interface, while the dedicated Shredstream makes the lower-level early-data path easier to integrate.
The pattern is the same one behind the August architecture work: specialized execution paths work better than treating account reads, real-time ingestion, early signals, and transaction delivery as one generic RPC workload.
Test the full signal-to-landing path
September's strongest update is the ability to work on more stages of the same latency-sensitive loop: ingest earlier data, handle newer transaction formats, inspect richer simulation results, submit through a fast QUIC path, and then measure what landed instead of stopping at send-request latency.
For a production benchmark, keep the test end-to-end:
- First transaction signal,
- Complete decoded payload,
- Simulation completion,
- Strategy decision,
- Send timestamp,
- Landed transaction,
- Confirmation,
- p50/p95/p99 by route and region.
That exposes where the remaining latency budget sits.
.jpg)
.jpg)
