Introducing shredTransactionSubscribe: Solana Transaction Visibility Before Execution

Quicknode

June 30, 2026 — 9 min read

Share

Add as preferred source

Solana is fast partly because blocks don't travel through the network as single large objects. Validators split block data into small pieces called shreds and send them out before the block is fully replayed. That happens before normal RPC subscriptions can show any execution data.

Blazar, Quicknode's Solana WebSocket engine, now includes shredTransactionSubscribe. It turns that early signal into a WebSocket method developers can use. It subscribes to transactions seen during shred and entry ingestion, before execution.

shredTransactionSubscribe is in beta, and what is described in this post may change.

What Is a Shred?

A shred is a fixed-size piece of a Solana block, sent across the network while the block is being produced. Reading shreds lets you see transaction data as it moves through the network, before the finished block can be queried through post-execution RPC methods.

Shreds can be rebuilt into entries. Entries contain Solana VersionedTransaction values: signatures, messages, static account keys, instructions, recent blockhashes, and references to Address Lookup Tables for v0 transactions.

The key distinction is timing:

• Shred/entry ingestion happens before replay/execution.

• Normal transaction metadata is available only after execution.

Shred-time data can arrive earlier than execution data. But it can't include execution results such as meta, err, logs, token balances, compute units, or inner instructions.

How Blazar Obtains and Normalizes Data

Working with raw shred data has two gaps most developers can't easily fill.

First, the tooling. A raw SubscribeEntries stream needs gRPC, bincode decoding, transaction parsing, and Address Lookup Table resolution. You also need to know exactly what is and isn't known before execution. Most app developers just want a WebSocket JSON-RPC subscription.

Second, account filtering needs lookup tables. Most Solana v0 transactions use Address Lookup Tables (ALTs). Without resolving ALTs locally, account filters can miss a transaction that touches an account only through a lookup table. Blazar resolves static keys plus loaded ALT addresses when filtering by account.

Blazar gets an early Solana transaction feed from shred-streaming infrastructure. It turns that low-level network signal into a standard WebSocket JSON-RPC subscription. Blazar can see transactions before normal post-execution RPC methods do. It then sends a structured shredTransactionNotification with the transaction body, slot, signature, version, and resolved loaded addresses when available.

Treat the stream as an early, best-effort signal. Notifications arrive in roughly upstream order, with no strict ordering guarantee. The same transaction can occasionally appear more than once, so dedupe on signature if you need exactly-once delivery.

Blazar also enriches the shred-derived data before sending it. Instead of passing along a raw signal and making every client do the same work, it normalizes the transaction format and resolves lookup table addresses when it can. Subscribers get a fuller pre-execution view of accounts without running special Solana networking infrastructure or building their own shred parser.

Shreds on the Solana Transaction Timeline

Shred-time visibility adds a new, earlier point to the Solana data timeline:

Transaction broadcast -> shreds observed -> entries decoded -> replay/execution -> processed/confirmed/finalized RPC data

Most Solana WebSocket methods work after execution or around validator state changes. shredTransactionSubscribe exposes the earlier point where entries are decoded.

It doesn't replace transactionSubscribe. It's an earlier, pre-execution companion for workflows that benefit from seeing transaction intent as soon as possible.

Example Use Cases

shredTransactionSubscribe supports use cases that post-execution methods can't cover, and it improves others by delivering data before execution.

Early Transaction Intent

Trading systems, DEX analytics, routing engines, and market infrastructure can see transactions before they execute. That reveals account pressure, program activity, and incoming order flow earlier than standard post-execution streams.

Account-Aware Pre-Execution Monitoring

A client can subscribe to transactions that touch specific accounts, including accounts loaded through Address Lookup Tables. Use it to watch hot accounts, pools, token accounts, vaults, or protocol state accounts.

Signature-Level Lifecycle Tracking

Pair it with signatureSubscribe and enableReceivedNotification: true to see when a signature was first seen before execution, and later whether it landed or failed.

Operational Diagnostics

Support and infrastructure teams can answer questions like: Was the transaction seen before execution? Did it land later? Was it never seen? Did it use lookup-table addresses? This makes transaction lifecycle issues easier to diagnose.

Vote And Slot Signals

Blazar uses the same shred and entry ingestion path for pre-execution vote notifications and new-slot signals. shredTransactionSubscribe is the transaction-specific method built on that same early data source.

Method Overview

shredTransactionSubscribe subscribes to pre-execution transaction notifications from shred and entry ingestion. It's deliberately not a config option on transactionSubscribe. The payload is different because the data comes from a different stage.

It accepts one optional filter object as the first and only parameter.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "vote": false,
      "signature": "optional-signature",
      "accounts": {
        "include": ["optional-pubkey"],
        "exclude": ["optional-pubkey"],
        "required": ["optional-pubkey"]
      }
    }
  ]
}

All fields are optional. Each accounts list (include, exclude, required) accepts up to 50,000 entries.

Supported Filters

vote

• true: only simple vote transactions.

• false: exclude simple vote transactions.

• omitted: include both vote and non-vote transactions.

The vote filter uses Agave's "simple vote" transaction classification. It doesn't mean "any transaction with a Vote program instruction." Mixed transactions that include a vote instruction aren't classified as simple votes. voteSubscribe is a separate method with its own gossip-vote parsing.

signature

• Delivers only the transaction with the given signature.

accounts.include

• Delivers transactions that touch at least one listed account.

• Matches static account keys plus resolved ALT-loaded addresses.

accounts.exclude

• Drops transactions that touch any listed account.

• Matches static account keys plus resolved ALT-loaded addresses.

accounts.required

• Delivers only transactions that touch all listed accounts.

• Matches static account keys plus resolved ALT-loaded addresses.

Unsupported Parameters

commitment, encoding, transactionDetails, showRewards, maxSupportedTransactionVersion, and failed aren't supported. Shred-derived transactions are pre-execution JSON payloads, so they have no execution results or commitment levels.

Example Requests

Subscribe To All Pre-Execution Non-Vote Transactions

{
  "jsonrpc": "2.0",
  "id": 11,
  "method": "shredTransactionSubscribe",
  "params": [
    { "vote": false }
  ]
}

Subscribe To A Specific Signature

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "signature": "5VERv8NMvzbJMEkV8xnqLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"
    }
  ]
}

Subscribe To Transactions Touching An Account

{
  "jsonrpc": "2.0",
  "id": 13,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "accounts": {
        "include": ["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"]
      }
    }
  ]
}

Require Multiple Accounts And Exclude Another

{
  "jsonrpc": "2.0",
  "id": 14,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "accounts": {
        "required": [
          "AccountA11111111111111111111111111111111111",
          "AccountB22222222222222222222222222222222222"
        ],
        "exclude": [
          "AccountC33333333333333333333333333333333333"
        ]
      }
    }
  ]
}

Subscription Response

On success, the server returns a subscription ID. Use this ID to unsubscribe.

{
  "jsonrpc": "2.0",
  "result": 123,
  "id": 14
}

Unsubscribe

{
  "jsonrpc": "2.0",
  "id": 15,
  "method": "shredTransactionUnsubscribe",
  "params": [123]
}

Notification Shape

A notification uses the standard JSON-RPC PubSub envelope, but the inner transaction value is pre-execution data.

{
  "jsonrpc": "2.0",
  "method": "shredTransactionNotification",
  "params": {
    "result": {
      "context": { "slot": 418437508 },
      "value": {
        "slot": 418437508,
        "signature": "5VERv8NMvzbJMEkV8xnqLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW",
        "transaction": {
          "signatures": [
            "5VERv8NMvzbJMEkV8xnqLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"
          ],
          "message": {
            "header": {
              "numRequiredSignatures": 1,
              "numReadonlySignedAccounts": 0,
              "numReadonlyUnsignedAccounts": 2
            },
            "accountKeys": [
              "FeePayer11111111111111111111111111111111111",
              "Program111111111111111111111111111111111111"
            ],
            "recentBlockhash": "Eit7...",
            "instructions": [
              {
                "programIdIndex": 1,
                "accounts": [0],
                "data": "3Bxs4NN8M2Yn4TLb",
                "stackHeight": 1
              }
            ]
          }
        },
        "version": "legacy"
      }
    },
    "subscription": 123
  }
}

Versioned Transaction Example With Loaded Addresses

For v0 transactions, transaction.message.addressTableLookups preserves the lookup-table references, and value.loadedAddresses carries the resolved pubkeys.

{
  "jsonrpc": "2.0",
  "method": "shredTransactionNotification",
  "params": {
    "result": {
      "context": { "slot": 418437509 },
      "value": {
        "slot": 418437509,
        "signature": "7rYg...",
        "transaction": {
          "signatures": ["7rYg..."],
          "message": {
            "header": {
              "numRequiredSignatures": 1,
              "numReadonlySignedAccounts": 0,
              "numReadonlyUnsignedAccounts": 1
            },
            "accountKeys": [
              "FeePayer11111111111111111111111111111111111",
              "Program111111111111111111111111111111111111"
            ],
            "recentBlockhash": "AbCd...",
            "instructions": [
              {
                "programIdIndex": 1,
                "accounts": [0, 2, 3],
                "data": "3Bxs4NN8M2Yn4TLb",
                "stackHeight": 1
              }
            ],
            "addressTableLookups": [
              {
                "accountKey": "LookupTab1e11111111111111111111111111111111",
                "writableIndexes": [12],
                "readonlyIndexes": [3]
              }
            ]
          }
        },
        "version": 0,
        "loadedAddresses": {
          "writable": ["Writab1eLoaded11111111111111111111111111111"],
          "readonly": ["Readon1yLoaded11111111111111111111111111111"]
        }
      }
    },
    "subscription": 124
  }
}

If Blazar cannot resolve one or more lookup tables from cache, v0 notifications set:

"loadedAddresses": null

Even with startup warmup and live Solana gRPC updates, a table that was just extended can race the cache. When that happens, Blazar sets loadedAddresses: null for v0 transactions whose loaded addresses are incomplete, so the notification stays accurate.

Legacy transactions omit loadedAddresses.

What The Payload Does Not Include

Because this is pre-execution data, the notification does not include:

• meta

• err

• logs

• inner instructions

• pre/post balances

• pre/post token balances

• compute units consumed

• return data

• rewards

• final transaction index in the block

shredTransactionSubscribe is an early observation method, not an execution result method.

Getting Started

1. Log in to your Quicknode dashboard.

2. Select your Solana endpoint.

3. Copy your WSS endpoint URL (wss://your-endpoint-name.solana-mainnet.quiknode.pro/abc123) and connect using your existing WebSocket client code.

4. See the Example Requests above to send a shredTransactionSubscribe request with an optional filter.

5. Process shredTransactionNotification messages as they arrive.

New to Solana WebSockets? The How to Create Solana WebSocket Subscriptions guide covers everything you need.

For teams that need lower-latency Solana streaming beyond WebSockets, Quicknode's Solana gRPC product provides Yellowstone-compatible real-time streams from the same endpoint ecosystem.

FAQs

Is shredTransactionSubscribe the same as transactionSubscribe with an earlier commitment?

No. transactionSubscribe is post-execution and carries transaction status metadata. shredTransactionSubscribe is pre-execution and does not have logs, meta, err, balances, or compute units.

Can a shred transaction fail later?

Yes. A transaction observed from shreds may later fail execution, expire, or not appear in the final ledger. This method is an early observation signal, not a finality signal.

Do account filters include Address Lookup Table accounts?

Yes. Account filters match static account keys plus resolved ALT-loaded addresses from Blazar's local lookup-table cache.

What happens when an ALT is deactivated?

A deactivated ALT can still be used during its SlotHashes cooldown window. Blazar resolves deactivated tables during that cooldown and treats tables that have clearly expired as unresolved.

Who should use this method?

Use it when early transaction intent matters more than execution outcome: low-latency analytics, account activity monitoring, transaction lifecycle diagnostics, trading infrastructure, and pre-execution observability.

Who should not use this method?

Do not use it if you need final transaction status, logs, balances, token balance changes, compute units, rewards, or finalized block membership. Use post-execution RPC/WebSocket methods for that.

The Bottom Line

Until now, pre-execution transaction data needed custom Solana networking infrastructure: gRPC clients, bincode decoding, and shred parsing pipelines. Blazar's shredTransactionSubscribe removes that need. It delivers transaction intent before execution as a standard WebSocket JSON-RPC subscription.

It is available on every Quicknode Blazar WebSocket endpoint today. Log in to your Quicknode dashboard to get started, or create a Quicknode account if you do not have one yet.

Since shredTransactionSubscribe is currently in beta, we invite you to share any feedback or suggestions you have. Please email us at solana@quicknode.com or reach out to us on Discord.