Deshred transactions: the fastest path to Solana data

TL;DR

• Triton's new Deshred endpoint delivers the earliest on-chain signal, fully deserialised and reconstructed from shreds
• With upcoming protocol upgrades, shaving off milliseconds becomes non-negotiable for arbitrage bots, snipers, liquidators, market makers, copy-traders and HFT systems
• Waiting for a node to execute and replay a slot adds latency that varies with transaction complexity and account contention
• Deshred subscription removes that delay by exposing transaction intent as soon as entries are formed from shreds, bypassing tx execution, account locking, and replay
• It offers server-side filtering to automatically strip vote transactions and target specific accounts (static keys and dynamically loaded addresses from Address Lookup Tables (ALTs))
• Deshred is now available in paid beta as a new subscription type within Triton's Dragon's Mouth (yellowstone-grpc). If you're a Triton customer and want early access, reach out to get on the waitlist.

Introducing Deshred transactions (beta)

In high-frequency environments, execution speed is not the only latency bottleneck. Any trading system is only as profitable as its ability to react fast and accurately to market moves, which, in practice, means tracking and responding to other players' order flow.

Triton built Yellowstone gRPC (Dragon's Mouth) to push events as they happen on-chain, directly from the validator pipeline. However, it still reports only on replayed events, giving you a view of what just happened. Imagine being able to see the transactions before they're executed on the RPC – while the validator is still processing the slot.

With Deshred transactions, now you can.

Deshred is Triton's new streaming solution (currently in paid beta) that shifts data extraction further upstream in the validator pipeline, delivering transaction data to your backend before the node completes slot execution. This gives you a much earlier signal and a tangible advantage in how fast you can react to market events.

How Deshred transactions work (high level)

Before jumping into how exactly this new architecture allows you to be faster than the rest of the market, let's first recap what happens when someone sends a transaction on Solana.

After a validator includes a transaction in a block, it sends the block out as shreds – small, MTU-sized packets (~1,228 bytes) that together form micro-blocks called entries. Shreds are propagated via Turbine, Solana's block-propagation protocol, first to highly staked, co-located validators like Triton's, and then to the rest of the network.

From there, the shreds enter the receiving node's TVU (Transaction Verification Unit), which runs through several distinct stages, each adding its own latency:

The main difference between a Dragon's Mouth gRPC stream and Deshred transactions is when updates are pushed.

Standard Geyser streams emit data only after the node has replayed and executed a transaction. This ensures data integrity and provides full execution context – logs, balance changes, inner instructions, success/failure status – but the step-by-step nature of the Replay stage introduces a delay that scales with transaction complexity and account contention.

For most use cases, that delay is negligible, but for strategies that depend on the earliest possible intent detection and the slightest market activity, even Yellowstone gRPC sometimes arrives too late to act on.

Deshred streams address this by intercepting the pipeline immediately after shred arrival and entry reconstruction, at the CompletedDataSets (Blockstore) stage, bypassing the Replay stage entirely and streaming decoded transactions directly to your backend over gRPC.

Deshred transactions features

Deshred streams are built for one thing: giving you the earliest usable view of on-chain intent. They deliver:

Managed reconstruction. Shred assembly, erasure recovery, and entry deserialisation happen server-side. You receive fully reconstructed transactions over gRPC — no raw UDP packets, no Reed-Solomon decoding, no shred bookkeeping on your end.

Zero-overhead integration. Exposed as the SubscribeDeshred RPC in Yellowstone Dragon's Mouth, so you subscribe the same way you would for any other gRPC stream — no custom infrastructure required.

Noise reduction. Server-side vote filtering lets you drop vote transactions before they ever reach your backend, eliminating the majority of network traffic in a single flag.

Account filtering. Filter by accounts present in the transaction message — both static account keys and dynamically loaded addresses from Address Lookup Tables (ALTs). Isolate specific markets or programs (e.g. Raydium, Orca, Jupiter) while ignoring everything else.

Intercepting the pipeline that early does, however, come at a cost: some information simply isn't available yet. Here's how it stacks up against Triton's Yellowstone gRPC, the ecosystem's go-to streaming standard, on both features and datapoints.

Performance benchmarks: Deshred vs gRPC

As the breakdown above shows, the latency improvement stems directly from the computational work skipped. By avoiding transaction execution (signature verification, account locking, BPF/SVM execution, and state commitment), data is available as fast as the node can reconstruct entries from incoming shreds.

According to our benchmarks, Deshred delivers transactions with a p50 latency of ~6.3 ms and a p90 of ~20 ms from the moment shreds arrive at the node.

The exact advantage over Dragon's Mouth varies per transaction: a simple SOL transfer with no account contention may execute almost instantly in the scheduler, while a complex DeFi swap touching hot accounts can queue behind other transactions for significantly longer. The Replay stage delay is not a fixed number: it depends on instruction complexity, account lock contention, and overall slot load.

What Deshred guarantees is that you always see the transaction before any of that execution overhead occurs.

Who should use Deshred transactions?

We've built Deshred transactions alongside our Yellowstone gRPC to serve very specific latency-sensitive use cases where seeing intent before execution can be more valuable than seeing the result after the fact.

• Arbitrage: Detect price dislocations across AMMs before state updates propagate to the rest of the network.
• Market making: React to incoming order flow and adjust quotes before executions settle – tighter spreads with lower adverse selection.
• Copy trading: Identify target wallet activity at the intent level, ahead of other copy traders who wait for confirmed execution.
• Liquidations: Forecast liquidation events from pending position changes and resolve risky positions faster.
• HFT signal ingestion: Feed models with raw chain intent data for the earliest possible feature extraction.

If your application is not millisecond-sensitive or depends on confirmed account state, use Dragon's Mouth, Whirligig or Fumarole instead. They remain the correct choice for frontends, wallets, explorers, indexers, and analytics platforms.

Getting started

Deshred transactions are integrated directly into Yellowstone Dragon's Mouth as a new gRPC subscription type: SubscribeDeshred.

This endpoint is only available on Triton One's gRPC servers and is currently in paid beta with limited availability. If you want access, please reach out. The Yellowstone gRPC codebase is open-source, but the SubscribeDeshred implementation relies on the Triton fork of the Agave validator's Geyser plugin interface, which adds the deshred transaction notifier to the CompletedDataSets pipeline. It is not part of the default Agave release. Anyone is free to implement the same approach (as the code is public), but it will not work out of the box on a stock Agave node.

Here is a minimal Rust example that subscribes to a deshred transaction:

use {
    futures::{sink::SinkExt, stream::StreamExt},
    solana_signature::Signature,
    std::collections::HashMap,
    tonic::transport::channel::ClientTlsConfig,
    yellowstone_grpc_client::GeyserGrpcClient,
    yellowstone_grpc_proto::prelude::{
        subscribe_update_deshred::UpdateOneof, SubscribeDeshredRequest,
        SubscribeRequestFilterDeshredTransactions, SubscribeRequestPing,
    },
};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let endpoint = std::env::var("ENDPOINT")
        .unwrap_or("http://127.0.0.1:10000".into());
    let x_token = std::env::var("X_TOKEN").ok();

    let mut client = GeyserGrpcClient::build_from_shared(endpoint)?
        .x_token(x_token)?
        .tls_config(ClientTlsConfig::new().with_native_roots())?
        .http2_adaptive_window(true)
        .initial_connection_window_size(8 * 1024 * 1024) // 8 MiB
        .initial_stream_window_size(4 * 1024 * 1024) // 4 MiB
        .connect()
        .await?;

    let request = SubscribeDeshredRequest {
        deshred_transactions: HashMap::from([("deshred".into(),
            SubscribeRequestFilterDeshredTransactions {
                vote: Some(false),
                account_include: vec![],
                account_exclude: vec![],
                account_required: vec![],
            },
        )]),
        ping: None,
    };

    let (mut tx, mut stream) =
        client.subscribe_deshred_with_request(Some(request)).await?;

    while let Some(msg) = stream.next().await {
        match msg?.update_oneof {
            Some(UpdateOneof::DeshredTransaction(update)) => {
                let info = update.transaction.as_ref().unwrap();
                let sig = Signature::try_from(info.signature.as_slice())?;
                println!("slot={} sig={sig} vote={}", update.slot, info.is_vote);
            }
            Some(UpdateOneof::Ping(_)) => {
                tx.send(SubscribeDeshredRequest {
                    ping: Some(SubscribeRequestPing { id: 1 }),
                    ..Default::default()
                }).await?;
            }
            Some(UpdateOneof::Pong(_)) => {}
            None => break,
        }
    }
    Ok(())
}

Key points about the example:

• http2_adaptive_window(true) enables dynamic HTTP/2 flow control, letting the window grow automatically under high throughput instead of staying at the 64 KiB default. Combined with explicit initial window sizes (8 MiB connection, 4 MiB stream), this prevents back-pressure stalls on bursty deshred streams.
• vote: Some(false) drops vote transactions server-side. Votes make up the majority of on-chain transactions and are rarely useful for trading strategies.
• The response includes loaded_writable_addresses and loaded_readonly_addresses – these are addresses resolved from Address Lookup Tables for V0 transactions, giving you the full account set even before execution.

FAQs

What is a shred in Solana?

A shred is the smallest unit of block data propagation in Solana: a signed packet that carries a fragment of block data (or parity for recovery) for UDP broadcast via Turbine. Blocks are serialized into entry batches, and each batch is split into fixed-size chunks that become data shreds; coding shreds are generated over groups of data shreds (FEC sets) using Reed–Solomon erasure coding to enable recovery from packet loss. The maximum serialized shred size (SHRED_SZ_MAX) is 1228 bytes, derived from the IPv6 minimum link MTU (1280) minus IPv6+UDP headers (48) and an additional 4 bytes reserved for an optional nonce; with Merkle authentication, coding shreds remain 1228 bytes while data shreds may be smaller (e.g., 1203 bytes).

Why is deshredding needed?

Deshredding reconstructs complete entries from raw shreds, making transaction data readable before the node's Replay stage processes it. Without deshredding, the transaction data is scattered across multiple UDP packets and mixed with erasure-coding redundancy. This reconstruction is essential for ultra-low-latency applications like HFT, arbitrage, and MEV.

What is Yellowstone gRPC?

Yellowstone gRPC (Dragon's Mouth) is a high-performance Geyser plugin for streaming Solana data via gRPC over HTTP/2, providing real-time updates on accounts, transactions, slots, blocks, and entries with advanced server-side filtering. Built, open-sourced, and maintained by Triton, it has become a standard across the Solana ecosystem.

Can Deshred transactions and Dragon's Mouth be combined?

Yes. Use Deshred for earliest signal detection, to see what is about to be executed, and Dragon's Mouth for the confirmed result with full execution context (status, balance changes, logs, inner instructions). Many strategies benefit from both: Deshred for speed, Dragon's Mouth for confirmation.

How does Deshred compare to raw shred streaming in latency?

Deshred adds a small amount of server-side processing (entry reconstruction and ALT resolution) compared to receiving raw shreds, but it eliminates the substantial client-side complexity of shred assembly, erasure recovery, and entry deserialisation. The net latency difference is negligible (microseconds) while the engineering effort saved is significant.

Is this private order flow?

No. Deshred transactions are extracted from shreds that have already been propagated to the network via Turbine. Every validator receiving those shreds has access to the same data. Deshred simply makes it easier to consume by handling reconstruction server-side and exposing it over gRPC.

How does the Transaction Validation Unit (TVU) process a block?

The table below shows each stage in order, with stream tap-in points marked.

Are there any disadvantages to using Deshred transactions?

Yes. Because Deshred intercepts the pipeline before execution, you only receive the signed instruction data and the accounts referenced: no execution metadata: success/failure status, logs, balance changes, inner instructions, compute units, or return data.

You also get no finality guarantees. A deshredded transaction may fail execution, land on a forked slot, or never confirm. Your application needs to handle all of these scenarios the same way it would when using processed.