Aperture TxStream

RPC Fast's optimised protocol for real-time deshredded Solana transactions and transaction simulation.

TxStream is RPC Fast's purpose-built gRPC protocol for receiving decoded Solana transactions directly from the shred pipeline. It is a highly flexible protocol with transaction filtering, real-time transaction simulation, signatures-only responses, and batch transaction delivery.

We reinvented shred-level transaction streaming: RPC Fast reconstructs, recovers, deshreds, decodes, filters, and streams transactions through one optimised path, before normal validator replay metadata is available.

Use TxStream when transaction arrival time matters more than confirmed post-execution metadata.

For a limited time, Aperture TxStream is also available on the Stream plan – without transaction execution simulation. The full version with real-time simulation is included in the Aperture plan.

Starting September 1, the Aperture TxStream protocol will become exclusive to the Aperture plan.

Why Use TxStream?

• Faster transaction delivery. The protocol is optimised specifically for transaction streaming, with compact payload and batch delivery modes.

• Lower client overhead. Transactions arrive decoded, with no raw shred or Solana Entry reconstruction required in your application.

• Server-side filters. Filter by vote status, signature, included accounts, excluded accounts, or required accounts before data crosses the network.

• Compact modes. Use signatures_only for timing and monitoring workloads, or batch transaction delivery to reduce per-message gRPC overhead.

• Resolved Address Lookup Tables. RPC Fast was one of the first providers to resolve ALTs for deshredded transactions. Loaded writable and read-only addresses are included when available and participate in account filters.

• Real-time transaction simulation. RPC Fast is the first provider to offer real-time simulation of deshredded transactions. Transaction-status simulation achieves approximately 95% accuracy compared with actual execution results.

Performance Comparisons

RPC Fast compares identical transaction signatures received at the same observer. The comparison uses local receive timestamps.

TxStream vs ShredStream

This comparison measures when the decoded transaction becomes available to the client. TxStream delivered the decoded transaction first in most matched races.

TxStream mode	TxStream arrived first	TxStream median lead when first	TxStream p90 lead when first
Signatures only	77.6%	231 us	531 us
Full transaction payload	75.6%	197 us	463 us

TxStream vs Aperture Yellowstone interface

TxStream mode	TxStream arrived first	TxStream median lead when first	TxStream p90 lead when first
Signatures only	96.3%	280 us	641 us
Full transaction payload	93.8%	232 us	509 us

TxStream vs Yellowstone gRPC

TxStream mode	TxStream arrived first	TxStream median lead when first	TxStream p90 lead when first
Signatures only	99.97%	7.77 ms	22.35 ms
Full transaction payload	99.97%	7.72 ms	22.28 ms

Protocol Reference

Full protocol reference can be found at https://github.com/dysnix/aperture-grpc-proto

TxStream uses the aperture.Aperture gRPC service and a single request format for both delivery modes.

Request Format

Both subscription methods accept SubscribeTransactionsRequest:

Field	Type	Default	Description
vote	VoteFilter	VOTE_FILTER_ALL	Stream all transactions, votes only, or non-votes only.
signature	bytes	empty	Match one 64-byte primary transaction signature.
account_include	repeated bytes	empty	Match when any listed 32-byte static or loaded account is present.
account_exclude	repeated bytes	empty	Reject when any listed 32-byte static or loaded account is present.
account_required	repeated bytes	empty	Match only when every listed 32-byte static or loaded account is present.
signatures_only	bool	false	Return only transaction identity and timing fields.
include_simulation	bool	false	Add a transaction-status simulation result to each response.

Different filter fields are combined with logical AND. Values inside account_include and account_exclude use OR, while every account_required value must match. With no filters, TxStream delivers all transactions.

Non-Batch and Batch Delivery

	Non-batch mode	Batch transaction delivery
RPC	/aperture.Aperture/SubscribeTransactions	/aperture.Aperture/SubscribeTransactionBatches
Response stream	DecodedTransaction	DecodedTransactionBatch
Delivery behavior	Emits each matching transaction in its own gRPC message.	Immediately emits available matching transactions, up to 64 per batch, without waiting for the batch to fill.
Best suited for	Minimum transaction-by-transaction delivery delay.	High-throughput consumers that want fewer protobuf and gRPC messages.
Ordering without simulation	Transactions are delivered in stream order, with indexes 0, 1, 2, ….	Transactions remain ordered within each batch and across consecutive batches.
Ordering with simulation	Transactions are delivered as soon as their simulations complete. Delivery may therefore be out of order—for example, 1, 2, 0—while index preserves the original stream order.	Transaction order is preserved. A batch is delivered only after all simulations in that batch finish, so its latency is determined by the slowest simulation.

The same filters, signatures_only mode, and simulation option are available in both delivery modes.

Use the non-batch stream when the lowest possible simulation latency is the priority. Use the batch stream when preserving delivery order is more important.

Transaction Response Format

DecodedTransaction contains:

Field	Type	Description
slot	uint64	Solana slot containing the transaction.
index	uint64	Transaction index within the subscription.
is_vote	bool	Whether this is a vote transaction.
created_at_unix_nanos	uint64	Transaction stream timestamp in Unix nanoseconds.
signatures	repeated bytes	Transaction signatures; each signature is 64 bytes.
version	TransactionVersion	TRANSACTION_VERSION_LEGACY or TRANSACTION_VERSION_V0.
header	MessageHeader	Required-signature and read-only-account counts.
static_account_keys	repeated bytes	Static 32-byte account keys from the transaction message.
loaded_writable_addresses	repeated bytes	Resolved writable 32-byte ALT addresses.
loaded_readonly_addresses	repeated bytes	Resolved read-only 32-byte ALT addresses.
recent_blockhash	bytes	The transaction's 32-byte recent blockhash.
instructions	repeated CompiledInstruction	Compiled transaction instructions.
simulation	TransactionSimulation	Present when include_simulation is enabled.

MessageHeader contains num_required_signatures, num_readonly_signed_accounts, and num_readonly_unsigned_accounts. CompiledInstruction contains program_id_index, the instruction's account indexes, and its raw instruction data.

Instruction account indexes refer to the following concatenated key list:

static_account_keys + loaded_writable_addresses + loaded_readonly_addresses

When signatures_only is enabled, responses retain slot, index, is_vote, created_at_unix_nanos, signatures, version, and an optional simulation result. Transaction message fields are omitted.

Batch Response Format

DecodedTransactionBatch contains one field:

Field	Type	Description
transactions	repeated DecodedTransaction	One to 64 transactions matching the subscription request.

Each transaction has the same format as a non-batch response.

Simulation Response Format

When requested, TransactionSimulation contains:

Field	Type	Description
bank_slot	optional uint64	Slot used for the simulation result.
status	SimulationStatus	Simulation outcome.
error	optional string	Error details when simulation is not successful.
simulated_at_unix_nanos	uint64	Simulation timestamp in Unix nanoseconds.
processing_time_nanos	uint64	Simulation processing duration in nanoseconds.

SimulationStatus values:

Status	Meaning
SIMULATION_STATUS_SUCCEEDED	The simulation succeeded.
SIMULATION_STATUS_FAILED	The simulation failed.
SIMULATION_STATUS_INVALID_TRANSACTION	The transaction is invalid.
SIMULATION_STATUS_BANK_NOT_AVAILABLE	The required Bank state was unavailable. The transaction may still be valid, but no simulation outcome is available.
SIMULATION_STATUS_SERVER_OVERLOADED	Simulation exceeded its time limit. RPC Fast limits simulation time to preserve TxStream delivery performance.
SIMULATION_STATUS_INTERNAL_ERROR	An internal error occurred during simulation.

Use the Official Rust Client

As a best practice, use the official dysnix/aperture-grpc-client. It provides byte-safe filters, tuned HTTP/2 flow control, TLS native roots, keepalives, X-Token authentication, and automatic reconnection.

Set APERTURE_X_TOKEN to your RPC Fast token before running the example.

use aperture_grpc_client::{
    ApertureClientConfig, ApertureGrpcClient, SubscribeFilters, VoteFilter,
};
use futures_util::StreamExt;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let token = std::env::var("APERTURE_X_TOKEN")?;
    let config = ApertureClientConfig::new("https://aperture-txstream.rpcfast.com:443")
        .with_x_token(token);
    let client = ApertureGrpcClient::new(config);

    let filters = SubscribeFilters::default().vote(VoteFilter::NonVoteOnly);
    let mut stream = Box::pin(client.subscribe_with_reconnect(filters));

    while let Some(message) = stream.next().await {
        let transaction = message?;
        println!(
            "slot={} index={} signatures={}",
            transaction.slot,
            transaction.index,
            transaction.signatures.len()
        );
    }

    Ok(())
}

An empty filter streams all transactions. Apply the narrowest server-side filter that serves your workload to reduce bandwidth and client-side work.

Request Real-Time Simulation

Set the client's include_simulation option when you need a predicted result for every matching deshredded transaction.

use aperture_grpc_client::{
    ApertureClientConfig, ApertureGrpcClient, SimulationStatus, SubscribeFilters,
    VoteFilter,
};
use futures_util::StreamExt;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let token = std::env::var("APERTURE_X_TOKEN")?;
    let config = ApertureClientConfig::new("https://aperture-txstream.rpcfast.com:443")
        .with_x_token(token);
    let client = ApertureGrpcClient::new(config);

    let filters = SubscribeFilters::default()
        .vote(VoteFilter::NonVoteOnly)
        .include_simulation();
    let mut stream = Box::pin(client.subscribe_with_reconnect(filters));

    while let Some(message) = stream.next().await {
        let transaction = message?;
        let Some(simulation) = transaction.simulation else {
            continue;
        };
        let status = SimulationStatus::try_from(simulation.status)
            .unwrap_or(SimulationStatus::Unspecified);

        println!(
            "slot={} status={status:?} bank_slot={:?} error={:?}",
            transaction.slot,
            simulation.bank_slot,
            simulation.error
        );
    }

    Ok(())
}

Simulation results can include:

• simulation status and error

• simulation slot

• simulation timestamp and processing time

Enabling simulation adds latency. Simulation results are predictive and may differ from the transaction's eventual execution outcome; transaction-status simulation accuracy is approximately 95% compared with actual execution results.

Clients that do not request simulation remain on the immediate pre-execution path. For a compact prediction feed, combine include_simulation with signatures_only.

Simulation Delivery Latency

The matched-signature comparison measured simulation-enabled TxStream against the equivalent non-simulation stream:

TxStream mode	Median added delivery time	p90 added delivery time
Signatures only	832 us	1.72 ms
Full transaction payload	791 us	1.62 ms

Receive Transaction Batches

Use the batch stream when throughput and lower protobuf/gRPC overhead matter more than emitting each transaction in its own message.

use aperture_grpc_client::{
    ApertureClientConfig, ApertureGrpcClient, SubscribeFilters, VoteFilter,
};
use futures_util::StreamExt;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let token = std::env::var("APERTURE_X_TOKEN")?;
    let config = ApertureClientConfig::new("https://aperture-txstream.rpcfast.com:443")
        .with_x_token(token);
    let client = ApertureGrpcClient::new(config);
    let filters = SubscribeFilters::default()
        .vote(VoteFilter::NonVoteOnly)
        .signatures_only();
    let mut stream = Box::pin(client.subscribe_batches_with_reconnect(filters));

    while let Some(message) = stream.next().await {
        let batch = message?;
        println!("transactions={}", batch.transactions.len());
    }

    Ok(())
}

Important Semantics

TxStream is an early transaction feed, not a final source of execution truth.

• A streamed transaction can fail, never confirm, or land on a fork that does not survive.

• The normal pre-execution stream does not contain confirmed balances, inner instructions, rewards, execution status, or final program logs.

• ALT addresses are emitted when resolved. You must tolerate unresolved addresses and must not treat the stream as authoritative replay state.

• Reconnect after transport failures. The official client does this automatically with exponential backoff.

Use Yellowstone gRPC when you need confirmed execution metadata, account updates, blocks, or other replay-derived data.

Test TxStream with grpcurl

Download the official txstream.proto file to your current directory, set APERTURE_X_TOKEN, and start a non-vote transaction stream:

grpcurl \
  -proto txstream.proto \
  -H "x-token: ${APERTURE_X_TOKEN}" \
  -d '{
    "vote": "VOTE_FILTER_NON_VOTE_ONLY",
    "signaturesOnly": true
  }' \
  aperture-txstream.rpcfast.com:443 \
  aperture.Aperture/SubscribeTransactions

Set "includeSimulation": true in the request body to test the simulation-enabled stream.

When to Use TxStream

The use cases can be split into two categories:

1/ Decoded, reconstructed transactions – better developer experience, less engineering work.

Key benefit: less custom infrastructure, faster integration, and no need to decode shreds or reconstruct transactions yourself.

Best for

• HFT bot developers looking for the fastest path to production with minimal engineering effort.

• Trading platforms that need transaction parsing without maintaining their own decoder.

• Wallets tracking pending user transactions.

• Analytics & monitoring platforms consuming structured real-time transaction data.

• Copy trading platforms monitoring market activity before block confirmation.

• Solana developers who need pre-confirmation data without building a shred reconstruction pipeline.

2/ Real-time execution simulation – decision-making edge for latency-sensitive applications).

Key benefit: fewer wasted transactions, fewer false positives, lower compute costs, and faster decision-making under tight latency constraints.

Best for

• MEV searchers filtering profitable opportunities from transactions that will actually execute.

• Arbitrage bots avoiding failed swaps and reducing false-positive signals.

• Liquidation bots confirming liquidation candidates before committing capital.

• High-frequency trading (HFT) systems making routing decisions with higher confidence.

• Market makers reacting only to executable market events.

• Copy-trading platforms replicating only transactions likely to succeed.

• Risk engines estimating execution outcomes before block inclusion.