Solana Shred Stream

The Bitquery Solana Shred Stream delivers Solana transactions, DEX trades and token transfers over Kafka as soon as validators propagate the shreds that carry them. This happens before the block closes. Every message is parsed protobuf, with USD values added. You do not run a node and you do not decode raw shreds yourself.

What is a Solana shred?

On Solana, a shred is the smallest piece of a block. The leader splits the entries it produces into shreds and sends them to other validators through Turbine. Validators rebuild the block from those shreds. Shreds are the first form block data takes on the network, so data read at this stage arrives earlier than data read after the block is complete.

Bitquery reads transactions at the shred level, parses them, and publishes them to Kafka. Because messages go out before the block closes:

• transactions can arrive before the block is finalized;
• the block header in a message may be incomplete; only Slot is guaranteed to be set;
• messages are not guaranteed to arrive in slot order, and duplicates can occur, so deduplicate on transaction signature.

Solana Shred Stream topics

Three Kafka topics carry shred-level Solana data. All of them are protobuf. The schema is in streaming_protobuf/solana.

Topic	Message type	What it carries
solana.transactions.proto	ParsedIdlBlockMessage	Transactions, parsed instructions, logs, instruction-level balance updates
solana.tokens.proto	TokenBlockMessage	Token and SOL transfers, supply changes, account and instruction balance updates
solana.dextrades.proto	DexParsedBlockMessage	DEX trades, order events and liquidity pool changes for Pump.fun, PumpSwap, Raydium, Meteora, Orca and other venues

Amounts carry USD equivalents (AmountInUSD, FeeInUSD, PostBalanceInUSD and similar). The full field reference is on the Solana protobuf stream page. Perpetual futures are on a separate topic, the Solana perpetuals stream.

Solana Shred Stream latency compared with gRPC and GraphQL

Bitquery delivers real-time Solana data in three ways. All three read from the same pipeline. They differ in transport, filtering and how much data reaches you.

	Kafka Shred Stream	gRPC (CoreCast)	GraphQL subscription
Transport	Kafka, protobuf	gRPC, protobuf	WebSocket, JSON
Server-side filtering	No, full topic	Yes, by address, program and token	Yes, full GraphQL filters
Replay	From an offset within the 4-hour retention	No	No
Runs in a browser	No	No	Yes
Best for	Trading systems, indexers, consumers that cannot miss a message	Low-latency feeds filtered to a few programs or wallets	Prototypes, dashboards, filtered alerts

This was measured on Solana token transfers, with solana.tokens.proto and a GraphQL subscription consumed at the same time from the same server. Latency runs from block timestamp to application code:

	p50	p99
Kafka (solana.tokens.proto)	383 ms	1847 ms
WebSocket (GraphQL subscription)	405 ms	2013 ms

Kafka arrived first for 77% of slots. Broker-to-consumer delivery alone was 17 ms at p50. Kafka also sends the complete message, about 33 times more bandwidth than a subscription that requests only some fields. The full method is on the Kafka streaming concepts page.

If you need a narrow, filtered feed, the Solana gRPC streams filter on the server and send less data.

How to connect to the Solana Shred Stream

1. Get Kafka credentials from sales through the official Telegram or the website form. IDE tokens do not work on Kafka.
2. Connect to the brokers rpk0.bitquery.io:9092,rpk1.bitquery.io:9092,rpk2.bitquery.io:9092 with SASL SCRAM-SHA-512. Port 9093 is the SSL variant.
3. Use a consumer group ID that starts with your username.
4. Subscribe to one of the three topics and parse messages with the bitquery-pb2-kafka-package for Python, or with the generated protobuf classes in Go or JavaScript.

from confluent_kafka import Consumer
from solana import dex_block_message_pb2

conf = {
    'bootstrap.servers': 'rpk0.bitquery.io:9092,rpk1.bitquery.io:9092,rpk2.bitquery.io:9092',
    'security.protocol': 'SASL_PLAINTEXT',
    'sasl.mechanism': 'SCRAM-SHA-512',
    'sasl.username': 'YOUR_USERNAME',
    'sasl.password': 'YOUR_PASSWORD',
    'group.id': 'YOUR_USERNAME-shred',
    'auto.offset.reset': 'latest',
}

consumer = Consumer(conf)
consumer.subscribe(['solana.dextrades.proto'])

while True:
    msg = consumer.poll(1.0)
    if msg is None or msg.error():
        continue
    block = dex_block_message_pb2.DexParsedBlockMessage()
    block.ParseFromString(msg.value())
    for tx in block.Transactions:
        for trade in tx.Trades:
            print(block.Header.Slot, trade.Dex.ProtocolName,
                  trade.Buy.Currency.Symbol, trade.Sell.Currency.Symbol)

Read all partitions in parallel and keep the poll loop running. Messages for one slot share a partition. Messages stay on the broker for 4 hours. Full consumer guides: Python, Go, JavaScript. For offsets and lag, see the Kafka operations cookbook.

Preview the data with a GraphQL subscription

The same DEX trades are available as a GraphQL subscription, so you can inspect the data in the Bitquery IDE before you request Kafka access. This stream returns Pump.fun trades:

subscription {
  Solana {
    DEXTrades(where: { Trade: { Dex: { ProtocolName: { is: "pump" } } } }) {
      Block {
        Time
        Slot
      }
      Transaction {
        Signature
      }
      Trade {
        Dex {
          ProtocolName
        }
        Buy {
          Amount
          Currency {
            Symbol
            MintAddress
          }
        }
        Sell {
          Amount
          Currency {
            Symbol
            MintAddress
          }
        }
      }
    }
  }
}

In the Kafka topic, the same trades are DexTradeEvent records in solana.dextrades.proto, with Dex.ProtocolName set to pump.

Video tutorials

• Low-latency Solana data via Kafka
• Track Pump.fun and PumpSwap trades with Kafka

Frequently Asked Questions

What is a Solana Shred Stream?

A feed of Solana transactions read at the shred level, the smallest piece of a block that validators propagate. Bitquery parses these transactions and publishes them to Kafka before the block closes, so they arrive earlier than block-based feeds.

Which Kafka topics carry Solana shred-level data?

solana.transactions.proto (ParsedIdlBlockMessage), solana.tokens.proto (TokenBlockMessage) and solana.dextrades.proto (DexParsedBlockMessage).

Do I need to run a Solana node or decode raw shreds?

No. Bitquery runs the infrastructure and sends parsed protobuf messages with USD values.

Is the Solana Shred Stream faster than GraphQL subscriptions?

Yes, slightly. In a side-by-side test on token transfers, Kafka had a p50 of 383 ms against 405 ms for WebSocket and arrived first for 77% of slots. Kafka also allows replay from an offset, but it sends the full message and cannot be filtered on the server.

Can I filter the Solana Shred Stream?

Not on the server. Your consumer filters the messages. For server-side filtering, use the Solana gRPC streams or a GraphQL subscription.

How long are Solana Shred Stream messages kept?

Four hours. Within that window a consumer can replay from an offset.

Related pages

• Solana protobuf stream field reference
• Real-time Solana data: Geyser, GraphQL and Kafka compared
• Kafka streaming concepts
• Solana gRPC streams (CoreCast)
• Filtering Kafka streams