Shreds
Receive raw Solana ledger fragments at your server over UDP. Shreds gives custom ingestion systems control over reconstruction and transaction decoding before execution results are available.
What you receive
A shred is a fragment of a leader's block data. Your application collects fragments, recovers missing data where possible, reconstructs entries, and decodes transactions. This feed does not contain executed account state, transaction logs, or confirmation results.
UDP packets may be lost, duplicated, or reordered. Observing a transaction does not prove it executed successfully or finalized. Verify outcomes using RPC or an executed-data stream.
Register your receiver
- Activate a Shreds service in the dashboard and choose its region.
- Run a UDP receiver on a server with a publicly reachable IPv4 address.
- In the service details, register
IPv4:port, such as203.0.113.42:8001, using your own public address. - Allow inbound UDP on that port in your host and network firewalls.
- Wait for the destination to become active and verify receipt.
The dashboard shows destination limits and permitted ports. Trials with managed destinations require support to register or change the receiver.
Shreds has no public connection URL or access key. Packets are pushed to the registered destination. RPC and Yellowstone gRPC URLs do not receive raw UDP shreds.
Verify packet arrival
On a Linux receiver with tcpdump installed:
sudo tcpdump -ni any 'udp dst port 8001' -c 20
Replace 8001 with your selected port. Packet arrival verifies delivery, not correct decoding or reconstruction.
Operate the pipeline
Monitor socket drops, incoming traffic, reconstruction failures, queue growth, and decoder latency. Keep the receive loop lightweight and handle incomplete data explicitly. Validate your decoder against the network's Solana shred format.
For structured account and transaction events without your own reconstruction pipeline, use Yellowstone gRPC.