July’s RPC Fast releases target two expensive failure points in Solana systems: receiving a signal too late and submitting a transaction through a weak route. The update set adds Nozomi to Beam, publishes deeper performance evidence, reduces Yellowstone gRPC latency, and introduces Aperture TxStream with optional pre-confirmation execution simulation.
For HFT teams, MEV searchers, liquidators, wallets, and data platforms, the result is a shorter and more observable path from shred arrival to execution decision. The 20% Summer Sale also lowers the cost of testing the complete stack in production-like conditions.
What was happening on Solana in July?
Solana entered July with a broader financial workload. The Foundation’s June ecosystem report, published in July, recorded more than $3B in real-world assets, over $10B in cumulative tokenized-stock volume, and a $683M daily tokenized-stock volume record. These flows create sustained demand for fresh account state, complete transaction context, and predictable execution rather than short-lived traffic peaks.
Protocol work also moved forward. Agave v4.1.0 advanced RPC 2.0 and Alpenglow preparation, while the July 23 changelog reported new Agave and Firedancer releases plus acceptance of the Resource and Inclusion Fees proposal. Fee logic, validator behavior, and data interfaces are changing together, which raises the value of measured infrastructure rather than static endpoint claims.
Solana’s status history reported no incidents during July. That stable base shifts attention from chain-wide availability toward provider-level latency, stream completeness, tail behavior, and transaction-route variance.
RPC Fast updates and integrations
Summer Sale: 20% off paid Solana plans
RPC Fast’s Summer Sale reduces the current monthly prices of all paid SaaS plans:
The Start plan remains free. Before checkout, ask in the RPC Fast Telegram and Discord communities whether an additional community promo code is active. The public pricing page displays the reduced prices and plan limits.
The sale is most useful as a benchmark window. Run the same filters, payloads, regions, and submit logic used in production; then compare p50, p95, p99, coverage, reconnect behavior, and landing rate before selecting a long-term plan.
Beam adds Nozomi by Temporal as another transaction route
Beam now routes signed transactions through Nozomi by Temporal alongside its other delivery providers. Nozomi is designed around optimized Solana transaction routing and staked connections, giving Beam another independent path toward the current and upcoming leaders.
The integration matters because route quality changes by slot, congestion level, leader, and geography. A provider that wins one interval often loses the next. Beam’s value lies in separating route selection from the strategy engine and keeping multiple delivery paths behind one submission layer.
Operationally:
- Select Nozomi explicitly with
provider=nozomi, or let Beam apply its provider-selection logic. - Include the provider-specific tip instruction required by Nozomi.
- Track acknowledgment time separately from landed time and landed slot.
- Compare Nozomi against the same transaction, fee, blockhash age, and market window used for other routes.
Explore more in the Beam docs.
New performance hub: Internal tests plus independent checks
RPC Fast published a consolidated performance and benchmarking layer for streaming and transaction delivery. The benchmark hub exposes distributions rather than one average: p50, p95, p99, test dates, sample sizes, node details, scoring logic, and links to full runs.
The evidence now has two distinct roles:
CompareNodes supports JSON-RPC, WebSocket, and Yellowstone gRPC measurements from up to 30 locations across six continents. Regional testing matters: a Frankfurt result does not describe Singapore, New York, or a colocated trading server.
The benchmark page is not a universal provider ranking. Its stronger role is reproducibility: teams select a region, test equivalent endpoints, inspect full latency distributions, and rerun the measurement when infrastructure or routing changes.
Yellowstone gRPC: Lower median latency and a larger p95 improvement
RPC Fast’s internal before-and-after measurements show Yellowstone gRPC improving by 0.5 ms at the median and roughly 4 ms at p95.
The p95 change matters more than the headline median. Trading and indexing systems rarely fail because every event is slow; they fail when a small share of updates arrive late enough to produce stale state, missed opportunities, queue buildup, or incorrect ordering assumptions. Here, the tail improvement is roughly eight times the median reduction.
Treat these figures as a service-change benchmark, not a universal client result. Measure from your deployment region with your filters, consumer code, network path, and backpressure behavior.
Aperture TxStream adds decoded shreds and real-time execution simulation
Aperture TxStream is the new primary low-latency streaming protocol from RPC Fast. It reconstructs transactions directly from Solana shreds, decodes them, resolves Address Lookup Tables, applies server-side filters, and streams the result before validator replay completes.
Optional in-stream simulation attaches a predicted success or failure outcome before onchain execution.
The July 17 benchmark raced 44,574 shared transactions. TxStream arrived before Jito ShredStream in 82% of races with a 284 µs median lead.
Against Yellowstone, the full decoded mode won 68.4% of races with a 62 µs median lead; signatures-only mode recorded a 7.77 ms median lead.
Simulation reached about 95% agreement with actual execution and added 791 µs median delivery time. That tradeoff suits strategies where filtering likely failures saves more time and compute than sub-millisecond raw-feed speed alone.
For a liquidation or arbitrage system, this changes the decision loop:
- Observe a deshredded transaction.
- Resolve its complete account set, including ALTs.
- Receive a predicted execution result.
- Reject likely failures before transaction construction.
- Submit only qualified opportunities through Beam.
The main benefit is not simulation as a separate feature. It is simulation inside the early-data path, before the strategy spends its latency budget on a signal that is unlikely to execute.
Aperture gRPC vs Aperture TxStream
Existing Aperture plan users retain access to the Yellowstone-compatible Aperture gRPC service during the transition. New integrations should start with TxStream.
Existing consumers should run both feeds in parallel, compare schema and filter parity, validate downstream ordering, and switch only after production metrics match.
What changes in the production architecture
The July releases reinforce a split architecture: one path detects executable opportunities; another path lands the resulting transaction.
.png)
This separation reduces coupling. TxStream improves the quality and timing of the signal. Beam improves route diversity after the decision. Yellowstone gRPC remains the structured state and confirmation layer for workloads that prioritize compatibility and broad event coverage.
Each layer now has a separate performance question:
Practical priorities for August
- Benchmark from your own region. Match production payloads, filters, connection counts, and consumer behavior.
- Track tails, not averages. p95 and p99 expose jitter, queue pressure, and provider degradation.
- Score routes by landing. Fast acknowledgment does not equal fast inclusion.
- Plan the TxStream migration. Keep Aperture gRPC running during parity tests, then move new low-latency workloads to TxStream. Aperture gRPC will be deprecated (we'll announce the exact date later).
- Use the sale for controlled validation. Test Stream or Aperture against a defined latency and coverage budget before committing.
Looking forward: Your August with RPC Fast
July moved RPC Fast beyond endpoint speed as a standalone metric. Nozomi expands transaction-route diversity. Published benchmarks make performance claims easier to inspect. Yellowstone tuning reduces tail latency. TxStream adds execution context to pre-confirmation data.
.jpg)
.jpg)
