Shred Stream WebSocket API
Stream Solana transactions in real-time directly from the shredstream, receiving transactions as they're gossiped across the network before they're processed. Included for free in all RPC plans.
Connection
Connect to the WebSocket endpoint with your API key like for the regular RPC Websocket:
Important Limitations
Shredstream transactions have significant limitations compared to Yellowstone gRPC or RPC Websockets:
-
No Transaction Metadata: Shreds arrive before transactions are processed, so there is no
meta
field. This means:- No fee information
- No pre/post balances
- No inner instructions
- No logs
- No compute units consumed
- No error information
-
Unresolved Address Lookup Tables: Address lookup tables (ALTs) are not expanded. You'll see the lookup table addresses, not the actual accounts they reference.
-
No Confirmation Status: Transactions may still fail during execution. You're seeing them as they're gossiped, not after they're confirmed.
-
Placeholder Values: Some fields like
fee
will have placeholder values (typically 5000 lamports).
Subscribe to Transactions
Subscribe using the shredSubscribe
method with optional filters:
Basic Subscription
Response
Filters
Filters use AND logic - all specified filter conditions must match for a transaction to be sent.
Filter Fields
accountInclude
(OR logic)
At least one of these accounts must be present in the transaction.
accountExclude
(Rejection filter)
If any of these accounts are present, the transaction is rejected.
accountRequired
(AND logic)
All of these accounts must be present in the transaction.
vote
Filter vote transactions.
Options
encoding
How transaction data is encoded. Default: "base64"
Options:
"base64"
- Base64 encoded transaction"json"
- JSON parsed transaction (larger response size)"jsonParsed"
- JSON with parsed instructions (largest response size)
transactionDetails
Level of detail to include. Default: "full"
Options:
"full"
- Complete transaction with all details"signatures"
- Only signatures"accounts"
- Only account keys"none"
- Minimal details
maxSupportedTransactionVersion
Support for versioned transactions (v0 transactions with address lookup tables).
Even with maxSupportedTransactionVersion: 0
, address lookup tables are not resolved in shredstream data.
showRewards
Include block rewards information. Default: false
Complete Examples
Example 1: Monitor Token Program Transactions
Stream all transactions involving the Token Program:
Example 2: Monitor Specific Wallet
Track all transactions for a specific wallet address:
Example 3: Monitor DEX with Multiple Programs
Track Raydium transactions (requires both Raydium program and Token Program):
Example 4: Exclude Vote Transactions
Stream all non-vote transactions:
Example 5: Complex Filter
Monitor Jupiter swaps (include Jupiter program, exclude vote program):
Notification Format
When a matching transaction is found, you'll receive a notification:
Note: The meta
field is always null
or a placeholder for shredstream transactions.
Unsubscribe
To stop receiving notifications:
Response:
Best Practices
-
Use Specific Filters: Avoid subscribing to all transactions - use filters to reduce bandwidth and processing.
-
Handle Missing Metadata: Don't rely on
meta
fields. If you need transaction outcomes, fees, or logs, you'll need to fetch the transaction from RPC after confirmation. -
Decode Transactions Carefully: With
encoding: "base64"
, you'll need to decode the transaction yourself. Consider using"jsonParsed"
for easier parsing. -
Monitor Subscription Count: Keep track of your active subscriptions to avoid hitting the 100 subscription limit.
-
Implement Reconnection Logic: WebSocket connections can drop. Implement automatic reconnection with exponential backoff.
-
Use Account Filters Efficiently:
- Use
accountInclude
for broad matching (OR logic) - Use
accountRequired
when you need multiple specific programs (AND logic) - Use
accountExclude
to filter out unwanted transactions (like vote txs)
- Use
Common Use Cases
Pump.Amm Monitoring
Error Handling
Performance Considerations
- Base64 encoding is most efficient for bandwidth
- jsonParsed encoding is easier to parse but uses more bandwidth
- Empty filters will stream ALL transactions (very high volume)
- Use
accountInclude
to reduce unnecessary traffic - Consider batching processing on the client side for high-volume streams