Overview
TheSubscribeDeshred method subscribes to deshred transaction updates, which are transactions received BEFORE execution. These transactions are emitted when entries are formed from network shreds, before any execution or status metadata is available.
What are Deshred Transactions?
Deshred transactions represent the earliest possible point to observe transactions in the Solana validator:- Pre-execution: Transactions are captured when shreds are assembled into entries, before any execution occurs
- No execution metadata:
TransactionStatusMetais not available (no logs, compute units, or error information) - Address lookup tables resolved: Both static account keys and dynamically loaded addresses from ALTs are available for filtering
- Earliest signal: Get the fastest possible notification that a transaction has been received by the validator
Use Cases
MEV Detection
Monitor transaction flow before execution to detect MEV opportunities or sandwich attacks.
Latency-Critical Apps
React to transactions with minimal latency, before execution completes.
Transaction Analysis
Analyze transaction patterns and account interactions before results are known.
Front-Running Detection
Detect potential front-running attempts by observing transaction order before execution.
SubscribeDeshredRequest
The request message defines filters for deshred transactions.Map of deshred transaction filters. Key is a user-defined filter name, value contains filter criteria.
Send a ping request. Server will respond with a pong message containing the same ID.
Deshred Transaction Filters
Filter vote transactions. Set to false to exclude vote transactions (recommended for most use cases).
List of account public keys. Receive transactions that mention any of these accounts in either static keys or ALT-loaded addresses.
List of account public keys. Exclude transactions that mention any of these accounts.
List of account public keys. Receive transactions that mention ALL of these accounts (static or ALT-loaded).
SubscribeUpdateDeshred
The server responds with a stream of deshred update messages.Names of the filters that matched this update.
One of the following update types:
deshred_transaction: Pre-execution transaction dataping: Server-initiated ping for keepalivepong: Response to client ping
Timestamp when the update was created on the server.
Deshred Transaction Update
Transaction signature (64 bytes).
Whether this is a vote transaction.
Full transaction data including message, signatures, and account keys. Note:
meta field is not populated for deshred transactions.Account addresses loaded from address lookup tables with writable permissions. These addresses are resolved and available for filtering.
Account addresses loaded from address lookup tables with read-only permissions. These addresses are resolved and available for filtering.
Slot number where this transaction was deshredded.
Examples
Key Differences from Subscribe
Timing
Timing
SubscribeDeshred provides transaction data at the earliest possible point - when shreds are assembled into entries, before execution. Regular Subscribe transactions include execution results.Metadata Availability
Metadata Availability
Deshred transactions do NOT include
TransactionStatusMeta, so there are no logs, compute units consumed, error information, or account state changes. You only get the raw transaction data.Address Lookup Tables
Address Lookup Tables
ALT addresses are fully resolved and available for filtering in deshred transactions. This makes filtering by program interactions reliable even with versioned transactions.
Use Case Focus
Use Case Focus
Deshred is optimized for latency-sensitive applications that need to react before execution completes, such as MEV detection or transaction ordering analysis.
Filtering by ALT-Loaded Addresses
One powerful feature of deshred transactions is that address lookup table (ALT) addresses are resolved and available for filtering:- Static account keys (regular transaction accounts)
- Loaded writable addresses (from ALTs)
- Loaded readonly addresses (from ALTs)
Latency Considerations
Deshred transactions provide the lowest latency signal:- Network shreds received → Shreds arrive at validator from the network
- Entry assembled → Shreds are assembled into an entry
- 🔔 Deshred transaction emitted ← You are here (SubscribeDeshred)
- Transaction executed → Validator executes the transaction
- Regular transaction emitted ← Regular Subscribe sees it here
Best Practices
- Filter out votes: Always set
vote: falseunless you specifically need vote transactions - Use specific account filters: Deshred can produce high volumes; filter to reduce bandwidth
- Don’t expect execution results: Remember that deshred transactions haven’t executed yet
- Handle duplicates: You may see the same transaction in both SubscribeDeshred and Subscribe
- Combine with regular Subscribe: Use deshred for early signals, then correlate with executed transactions
- Monitor memory: Buffer deshred transactions carefully if storing them for later correlation