Aperture gRPC Explained: How Shred-Level Streaming Actually Works on Solana

See a transaction before the validator finishes executing it. That is the core promise of Aperture gRPC, a structural consequence of where in the Solana pipeline the data is intercepted. 

This article walks through what that means in practice, which systems benefit, and how to wire it up.

What is a shred?

Solana validators do not broadcast full transactions. They broadcast shreds—small, erasure-coded fragments of block data. A transaction gets sliced into shreds, propagated across the network, and only reassembled into a full block after enough shreds arrive and the validator completes execution.

Standard Yellowstone gRPC sits at the end of that pipeline. It delivers transactions after the Geyser plugin processes them—complete with execution metadata, balance changes, logs, and CPI calls. Rich data. But it arrives after the fact.

Aperture gRPC intercepts earlier. It reconstructs transactions directly from validator shreds, before full execution completes, and delivers them in a Yellowstone-compatible format. The result: you see the transaction message as soon as it is decodable—typically 30–40 ms ahead of a standard Yellowstone stream.

That gap is not trivial. On Solana, 30–40 ms is the difference between being first and being irrelevant.

What data you get—and what you do not

Aperture gives you the transaction message itself:

• Signature
• Slot number
• Recent blockhash
• Account keys
• Instructions
• Address table lookups (versioned transactions only, partial resolution)
• is_vote flag

What it does not give you:

• Execution result (success or failure)
• Balance changes
• Inner instructions (CPI)
• Program logs
• Compute unit usage

This is intentional. Aperture is an early transaction stream, not a source of execution truth. A transaction you see in Aperture may still fail, land on a fork, or never confirm. Your system needs to account for that.

If you need post-execution metadata—logs, balance deltas, CPI traces—Yellowstone gRPC is the right tool.

The three-way comparison

A bit of our inner benchmarking: Aperture gRPC provides the same transaction faster in 78% cases compared to the competitor's Yellowstone gRPC, maxing out at 84.7% cases.

Also, Aperture gRPC sends transactions earlier by 12ms (and in some cases by 83 ms) on P90 than the competitor's Yellowstone gRPC.

Summing up: Aperture provides you the lowest latency of the three with the least client-side work. Shredstream gives you slightly higher latency but full low-level control over decoding. Yellowstone gives you the complete post-execution picture at the cost of arriving last.

Here’s how all these tools work together.

Scenario 1: DeFi sniper bot on Pump.fun

A team runs a token launch sniper on Pump.fun. Their strategy: detect a new token mint transaction the moment it hits the network, evaluate it against a set of criteria, and submit a buy transaction before the price moves.

With standard Yellowstone, they see the mint transaction after execution completes. By then, other bots have already acted. The window is gone.

With Aperture, they subscribe to transactions mentioning the Pump.fun program address (pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA). The transaction arrives 30–40 ms earlier. Their evaluation logic runs. If the criteria pass, the buy transaction goes out ahead of the Yellowstone-based competition.

Here is the Aperture subscription filter for that scenario in Rust:

tx_filters.insert(  
    "pumpfun".to_string(),  
    SubscribeRequestFilterTransactions {  
        vote: Some(false),  
        failed: None,  
        signature: None,  
        account_include: vec![  
            "pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA".to_string(),  
        ],  
        account_exclude: vec![],  
        account_required: vec![],  
    },  
);  

Full Rust and TypeScript examples are in the Aperture gRPC docs.

The architecture for this scenario looks like this:

Scenario 2: MEV searcher watching arbitrage opportunities

An MEV searcher monitors DEX pools across Raydium and Orca. Their job: detect a large swap transaction the moment it enters the network, calculate the resulting price impact, and submit a sandwich or arbitrage bundle before the original transaction lands.

The searcher subscribes to Aperture with account_include filters on both DEX program addresses. When a qualifying swap appears in the stream, they extract the instruction data—token amounts, pool accounts—and run their pricing logic.

They do not need execution metadata. They need the instruction payload, fast. Aperture delivers exactly that.

The filter logic follows Yellowstone semantics: multiple values in account_include are combined with OR, so a single subscription covers both programs simultaneously.

Scenario 3: Real-time analytics ingestion pipeline

A DeFi analytics platform tracks every transaction touching a set of protocol addresses—lending markets, perpetuals, and liquid staking. Their backend ingests the stream, parses instruction data, and writes structured events to a time-series database for dashboards and alerts.

They do not need to be first. But they do need low-latency ingestion with minimal bandwidth overhead.

Here, Aperture's server-side filtering is the key feature. Instead of receiving the full Solana firehose and discarding 95% of it client-side, they send a targeted account_include filter and receive only relevant transactions. Bandwidth drops. Processing load drops. The pipeline stays lean even at high slot throughput.

The architecture for this scenario:

How filtering works

Aperture follows Yellowstone's subscription model exactly. You send a SubscribeRequest over a bidirectional gRPC stream and receive matching updates continuously.

Transaction filter fields:

• vote—include or exclude vote transactions
• signature—match a specific transaction signature
• account_include—stream transactions mentioning any of these accounts (OR logic)
• account_exclude—drop transactions mentioning any of these accounts
• account_required—only stream transactions mentioning all of these accounts (AND logic)

Different fields combine with AND. Values within each array are combined with OR. If all fields are empty, all transactions stream through.

One important constraint: Aperture always streams at processed commitment level. Specifying a higher commitment level is ignored.

Keeping the connection alive

For long-lived subscriptions—which are most production use cases—configure both TCP keepalive and HTTP/2 keepalive. Without them, load balancers and NAT devices silently drop idle connections.

The Rust client example from the docs shows the recommended configuration:

GeyserGrpcClient::build_from_shared("https://aperture-grpc.rpcfast.com:443")?  
    .http2_keep_alive_interval(Duration::from_secs(30))  
    .keep_alive_timeout(Duration::from_secs(10))  
    .keep_alive_while_idle(true)  
    .tcp_keepalive(Some(Duration::from_secs(30)))  
    .tcp_nodelay(true)

This matters especially for pipelines with uneven traffic—quiet periods followed by bursts. A dropped connection during a quiet window means missed transactions when volume spikes.

When not to use Aperture

Aperture is the wrong tool when your system depends on:

• Transaction success or failure status
• Balance changes after execution
• Inner instructions from CPI calls
• Program logs
• Fully resolved address lookup tables

For those requirements, use Yellowstone gRPC. It delivers the complete post-execution picture at slightly higher latency.

The decision is straightforward: if your logic needs to know what happened, use Yellowstone. If your logic needs to know what is about to happen, use Aperture.

Getting started

Aperture gRPC is available on RPC Fast SaaS for Solana. The endpoint is aperture-grpc.rpcfast.com:443. Authentication uses the same x-token header as Yellowstone.

Full subscription examples in Rust, TypeScript, and grpcurl are in the Aperture gRPC documentation.

If you are already running a Yellowstone integration that covers only transaction subscriptions, the migration surface is minimal—same subscription model, same filter semantics, different endpoint, earlier data. If your Yellowstone integration also uses account subscriptions, block metadata, or entries, those are not available in Aperture. Keep Yellowstone running for those streams and route only transaction-latency-sensitive paths through Aperture.