RPC Fast launches Aperture TxStream: Decoded Solana transactions with real-time simulation

What do you choose when building your Solana infrastructure—receive raw shreds early and build a decoding stack, or consume structured transaction data later from a replay-based stream?

We at RPC Fast created Aperture TxStream so you don’t have to choose. It reconstructs transactions directly from Solana shreds, decodes them server-side, resolves Address Lookup Table data, applies filters, and streams structured transactions over gRPC. An optional simulation mode also attaches a predicted execution result before the TX reaches normal confirmation workflows. Performance is on par with non-decoded ShredStream.

The result is a pre-execution data feed designed for HFT systems, MEV searchers, liquidation engines, DEX infrastructure, copy-trading platforms, and other applications where the distance between receiving a TX and understanding it affects execution outcomes.

TL;DR

• Raw shreds go in; decoded transactions come out. TxStream handles shred reconstruction, transaction decoding, and loaded ALT address resolution.
• Filtering happens before delivery. Clients subscribe by signature, account, vote status, or account inclusion rules instead of processing an unrestricted firehose.
• Real-time simulation is optional. TxStream attaches predicted status, errors, and simulation timing.
• Simulation is a signal, not confirmation. RPC Fast benchmarks report approximately 95% agreement with actual execution, with 791 µs median delivery overhead in its published benchmark.
• TxStream complements Yellowstone and RPC. Use TxStream for the earliest actionable signal, then use Yellowstone or JSON-RPC for processed state, confirmation, and recovery.

RPC Fast’s broader Solana stack already separates direct RPC reads, structured Yellowstone streams, early shred-level data, and TX delivery into distinct infrastructure layers. TxStream strengthens the early-data layer by moving decoding and simulation into the provider-side pipeline.

The common problems TxStream solves

Raw data shifts complexity into your infrastructure

Raw shreds are useful when a team wants full control over reconstruction and has the engineering capacity to operate the pipeline. They fit infrastructure providers, specialized searchers, and teams with protocol-level requirements.

For many trading systems, that control does not produce a strategic advantage. The strategy needs transaction accounts, instructions, signatures, and relevant metadata—not an internal shred-recovery subsystem.

This creates an unfavorable trade:

Having deshredded transactions out of the box reduces operational load and provides greater clarity to take action faster. 

ALT references issue: Are there any accounts your filters need?

Versioned Solana transactions reduce message size by referencing accounts through Address Lookup Tables. Instead of storing every 32-byte public key directly in the transaction, a v0 message stores compact indices into on-chain lookup tables. Validators resolve those indices into full account addresses before execution.

This creates a quiet data-quality problem.

A filter that inspects only static account keys misses transactions where the relevant wallet, pool, vault, or program account appears through an ALT. The stream remains fast, but the strategy receives incomplete coverage.

For a trading system, missed ALT-loaded accounts lead to:

• Missed pool interactions;
• Incomplete wallet tracking;
• False negatives in copy-trading logic;
• Incorrect protocol exposure;
• Gaps in market and risk monitoring.

TxStream returns resolved ALT-loaded addresses and reports whether resolution is complete. Consumers should inspect alt_resolution before treating the account list or account-filter results as exhaustive.

The TxStream reports alt_resolution as FULL or PARTIAL. With PARTIAL, one or more lookup-table entries were not resolved. Account filtering and instruction account mapping must not be treated as complete in that case.

This matters most for transaction-dense DeFi flows, where v0 transactions often reference many accounts and routes.

Early-data TX: Is an early transaction the same as an executable transaction?

A deshredded TX appears before validator execution. At that point, the strategy sees intent, not outcome.

Solana’s validator pipeline still performs signature checks, sanitization, age and compute-budget checks, fee-payer validation, account loading, instruction execution, and commit. A transaction might fail at several stages after it first appears in a low-latency stream.

This distinction creates false signals. An arbitrage bot might react to a swap that later fails. A liquidation bot might spend compute evaluating a TX that never changes the account state. A copy-trading platform might reproduce an action based on a transaction that fails and rolls back its state changes. Since Solana transactions execute atomically, one failed instruction prevents all state changes, while the TX fee still applies. 

The traditional simulateTransaction helps evaluate a TX against the chain state without broadcasting it. It still requires the application to submit a separate RPC request and wait for the response.

TxStream moves simulation into the incoming transaction stream.

What real-time simulation changes

The simulation-enabled stream adds a predicted execution result to the decoded TX before normal on-chain confirmation.

That changes the decision loop.

The latency benefit comes from removing reconstruction, ALT resolution, and a separate simulation round trip from the client’s critical path.

Our benchmarks report approximately 95% agreement between simulation status and the subsequently observed execution status in its internal benchmark. That figure should be treated as a product benchmark, not a universal guarantee. Teams should measure accuracy by program, region, event type, slot conditions, and workload before using the result as a hard execution gate.

A simulation result also remains a prediction. State, ordering, and competing transactions might change between the simulation snapshot and validator execution. This follows from the difference between simulating against available state and the validator’s later execution pipeline.

Aperture TxStream architecture

1. Ingestion & Recovery—Capture and reconstruct transactions from Solana leaders.
2. Optional simulation enrichment—Optionally simulate with Agave Bank to predict execution outcomes.
3. TxStream output—Stream enriched transactions over gRPC via Aperture TxStream.
4. Execution & Confirmation—Feed strategies and builders, and track confirmations via Yellowstone or JSON-RPC.

TxStream sits between Solana’s shred propagation path and your strategy engine. We receive shreds, reconstruct transactions, resolve the data required for instruction interpretation, apply subscription filters, and optionally run the TX against a simulation environment.

This architecture deliberately separates two jobs:

• TxStream answers: “What TX is propagating, and what is it likely to do?”
• Yellowstone or RPC answers: “What did the network process and confirm?”

That distinction matters. Pre-execution signals support decisions. Confirmed state supports accounting, reconciliation, and final strategy outcomes.

Where TxStream changes the economics

The primary savings come from reducing wasted work in the client and strategy layers.

The exact ROI depends on event volume and current architecture. A team processing a few hundred filtered transactions per day sees limited benefit. A searcher evaluating thousands of candidates per second has a larger cost surface across CPU, memory, outbound RPC calls, and failed submissions.

Use cases that benefit most

MEV searchers

Searchers need to separate executable state changes from transactions that only look profitable at first inspection. Simulation results provide another filter before bundle construction, route selection, and capital allocation.

Arbitrage bots

A failed upstream swap does not create the state transition the bot expects. Execution-aware input reduces false arbitrage signals and unnecessary TX construction.

Liquidation systems

Liquidation bots need confidence that a preceding TX will move an account into a liquidatable state. TxStream helps rank candidates before committing simulation and submission capacity.

Market makers and HFT systems

Market makers react to TX flow before later account or block updates arrive. Decoded transactions reduce parser work; simulation adds confidence that the observed event will affect market state.

Copy-trading platforms

Copy-trading systems often need pre-confirmation visibility without maintaining a shred reconstruction stack. ALT resolution also reduces missed wallet interactions in versioned transactions.

Risk engines

Risk services monitor pending changes to liquidity, collateral, vault balances, and protocol exposure. Predicted execution status helps separate credible state transitions from failed TX noise.

What your application receives

TxStream exposes single-transaction and batched gRPC subscriptions:

/aperture.Aperture/SubscribeTransactions

/aperture.Aperture/SubscribeTransactionBatches

Each decoded TX includes the slot, transaction index, vote flag, timestamp, signatures, transaction version, message header, account keys, recent blockhash, and compiled instructions. Versioned transactions include their loaded writable and readonly addresses.

For instruction processing, the complete indexed account list follows this order:

This removes the separate ALT lookup stage from the hot path. Your client still interprets program-specific instruction data, but it receives the accounts required to do so.

Real-time simulation turns TX visibility into an execution signal

A decoded TX tells you what someone intends to execute. It does not tell you whether that execution will succeed against the current state.

Traditional Solana infrastructure handles this through a separate simulateTransaction JSON-RPC request. That call runs a TX without broadcasting it and returns execution information from the node’s available bank state.

For latency-sensitive systems, that approach introduces three problems:

• Another network round trip.
• Another endpoint and queue.
• A state-timing gap between receiving and simulating the transaction.

TxStream moves simulation into the stream pipeline. When include_simulation is enabled, TxStream performs each TX simulation in the background and carries the result in the same gRPC message.

The simulation payload includes:

• Predicted success or failure status
• Execution error
• Program logs
• Compute units consumed
• TX fee
• Program return data
• Bank slot used for simulation
• Simulation timestamp
• Processing time

What this changes for you

Consider a liquidation engine monitoring a lending protocol.

Without in-stream simulation, the engine receives a transaction, decodes it, updates an internal model, sends an RPC simulation request, waits for the result, and then decides whether to build its response transaction.

With TxStream, the same engine receives the decoded TX and predicted execution result together. It routes likely successful state changes into the strategy engine and suppresses transactions already expected to fail.

The same pattern applies to:

• Copy-trading systems avoiding failed source trades;
• DEX aggregators updating routes after executable swaps;
• MEV searchers prioritizing state transitions that affect an opportunity;
• Risk systems separating valid activity from spam;
• Monitoring platforms classifying transaction outcomes before confirmation.

Simulation accuracy and latency tradeoff

We state approximately 95% agreement between TxStream simulation and actual transaction execution. In our July 17, 2026 benchmark, enabling simulation added 791 µs median delivery overhead.

This creates a clear engineering choice:

Simulation feature stays optional. For example, a searcher racing solely on first-seen signatures has a different latency budget from a liquidation engine that needs execution confidence.

What simulation does not provide

TxStream simulation is not:

• Confirmation
• Finality
• A guarantee of TX inclusion
• A guarantee that account state will remain unchanged
• Confirmed balance or token-balance metadata
• Confirmed inner instructions or rewards

The stream is pre-execution by default. Account contention, competing transactions, fork changes, slot progression, or a different leader execution order still affect the final outcome. The protocol also exposes explicit states for unavailable banks, overloaded simulation servers, invalid transactions, and internal errors.

Treat simulation as a high-value feature for ranking and filtering decisions, not as a replacement for confirmation tracking.

TxStream versus other Solana data paths

These layers solve different problems. TxStream does not replace JSON-RPC for historical queries, account reads, confirmation, or application-owned transaction simulation. It also does not replace Yellowstone for broad account, slot, block, and post-processing streams.

TxStream vs ShredStream vs Yellowstone gRPC

These products occupy different points in the TX lifecycle.

Short takeaways:

• Choose ShredStream when your team wants raw data and owns the entire reconstruction stack.
• Choose TxStream when you need shred-level timing without operating the decoding and simulation pipeline.
• Choose Yellowstone when your system requires processed events, account state, commitment levels, or confirmation metadata.
• Run TxStream and Yellowstone together when both early detection and state correctness affect the product.

Published latency results

We at RPC Fast tested TxStream against ShredStream and Yellowstone gRPC on 44,574 transactions observed by every participating feed on July 17, 2026.

These results need to be read with their conditions:

• The test compared shared transactions, not unrelated samples.
• The comparison used an intersection of 44,574 signatures observed by every participating feed. It does not measure network-wide transaction coverage.
• Full decoded and signatures-only payloads represent different workloads.
• Network location, source topology, consumer region, and your implementation still affect observed latency.
• The feed-race results and the simulation-overhead measurement are separate benchmark results.

The important result is not a universal microsecond guarantee. It is that TxStream delivered a decoded and filtered payload while remaining competitive with a raw shred feed in the published environment.

Server-side filtering protects the rest of your pipeline

A low-latency feed becomes an operational problem when every transaction enters your queues, parsers, caches, and strategy workers.

TxStream supports raw-byte filters for:

• A specific primary signature
• Any matching included account
• Any excluded account
• All required accounts
• Vote-only transactions
• Non-vote transactions
• All transactions

Filtering loaded ALT accounts as well as static transaction accounts is important for versioned Solana transactions. Filters match static accounts and successfully resolved ALT-loaded accounts. Check alt_resolution when complete matching is required. 

A DEX program, liquidity pool, wallet, or market account referenced through an ALT still participates in matching.

A production filter strategy should start narrowly:

1. Exclude vote transactions unless the strategy needs them.
2. Include only relevant programs, pools, markets, or wallets.
3. Require multiple accounts for high-specificity patterns.
4. Use signatures-only mode for first-seen monitoring.
5. Expand subscriptions after measuring event rate and queue pressure.

This reduces bandwidth, deserialization work, garbage collection, queue depth, and false strategy triggers.

What your team needs to integrate TxStream

As of August 5, 2026, Stream plan includes limited TxStream access without simulation; simulation-enabled access is available through the Aperture plan. Verify current plan availability before integration. 

The public Rust client uses the production endpoint below with X-Token authentication.

Integration checklist

• RPC Fast account with TxStream access
• TxStream endpoint and access token
• Rust client or generated gRPC bindings from the public protobuf schema
• Account, signature, and vote filter definitions
• Consumer capable of decoding program-specific instructions
• Bounded queues and backpressure handling
• Automatic reconnect and duplicate handling
• Separate Yellowstone or RPC confirmation path
• Metrics for stream lag, delivery latency, simulation time, and reconnect gaps

The official Rust client ships with tuned HTTP/2 defaults, keepalives, TCP_NODELAY, adaptive flow-control windows, 16 MiB message limits, and automatic reconnect with exponential backoff from 100 ms to 5 seconds.

These defaults provide a production-oriented starting point. Teams using another language should reproduce the same operational properties rather than relying on basic generated gRPC settings.

Production metrics to track

Average latency alone hides most stream failures. Monitor the full distribution and the quality of the data reaching your decision engine.

The benchmark that matters is not only “which stream arrived first?” It is: How often did the earlier signal produce a correct and actionable decision?

When TxStream fits—and when it does not

‍

A consumer wallet, accounting system, or compliance archive usually gets more value from Yellowstone, WebSockets, or indexed RPC data. TxStream is built for systems that act before normal processed-state workflows finish.

From early transaction data to an execution-ready signal

Aperture TxStream changes the boundary of responsibility between the data provider and you.

Instead of delivering raw shreds and leaving reconstruction, decoding, ALT resolution, filtering, and simulation to your infrastructure, RPC Fast performs those stages before the transaction reaches your application.

Your team still owns:

• Program-specific interpretation
• Strategy logic
• Risk controls
• TX construction
• Fee and tip strategy
• Route selection
• Confirmation tracking
• Final outcome measurement

That is the intended separation. TxStream shortens the data path; yet, it does not replace the execution stack.

To evaluate it, race TxStream against your current feed from the same host and region. Measure shared-transaction coverage, first-seen frequency, p95/p99 latency, reconnect gaps, simulation agreement, and the effect on actual landing outcomes.