> For the complete documentation index, see [llms.txt](https://docs.triton.one/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.triton.one/chains/solana/shred-streaming.md). # Shred Streaming {% hint style="info" %} Triton Shred Streaming is available on request. Contact us through the [Customer Portal](https://customers.triton.one) to have it enabled on your account. {% endhint %} Shred Streaming delivers Solana shreds to you at the lowest latency we can achieve — before a block is assembled, before it is replayed, and before it appears in any RPC or gRPC stream. Shreds are the fragments a leader breaks its block into and fans out across the network. Receiving them directly is the earliest possible view of what a leader is producing, which is why Shred Streams are built for workloads where every millisecond of head start matters. * **Best for:** trading systems, MEV searchers, market makers, and any latency-sensitive backend that reconstructs blocks itself. * **Key feature:** a **full shred feed, deduplicated** — you receive every shred we see, and you (typically) receive each one only once. ### Is Triton Shred Streaming for me? Processing raw shreds is an advanced feature and requires custom software development on your end. It offers no filtering, and relies on forward error correction to handle any potential dropped or missed packages. An alternative to raw shreds is the [gRPC SubscribeDeshred](/project-yellowstone/dragons-mouth-grpc-subscriptions.md) subscription that we offer via our Riptide and other regular gRPC endpoints. SubscribeDeshred uses the same shred sources as our raw shred streams but does the work for you of processing the shreds back to transactions and entries, offers filtering as well as guaranteed delivery of data. ### How to use Triton Shred Streaming To use shred streams you need to run a software on your end that is capable of decoding and processing raw shreds. To get you started we provide a full working code sample of how reassemble incoming shreds to transactions in this repository: {% embed url="" %} You can use this to verify that your shred streaming is working and as a starting point for your own receiver code. ### **Where you can receive shreds** Shredstream is available in five regions: | Region | Location | | ------ | --------- | | US | New York | | EU | London | | EU | Amsterdam | | EU | Frankfurt | | AP | Tokyo | You can enable any combination of regions on your account and receive shreds in each of them independently. ### **Where the shreds come from** Shred Streams aggregates shreds from several sources so that you are not dependent on a single vantage point into the network: * **Triton validators:** shreds observed directly by the validators we operate. * **DoubleZero Edge:** through a special partnership with DoubleZero, we receive shreds from their Edge network. * **Partner validators:** additional validators we work with, spread across the network. * **Turbine:** for any validator we do not partner with and which is not sending their shreds through DoubleZero Edge, we have the lowest latency pathway possible for receiving their shreds via Turbine. Because the same shred usually arrives from more than one of these sources, the feed is deduplicated before it reaches you: whichever copy arrives first is the one you get, and later duplicates are discarded. ### **How it works** Shred Streaming runs on a custom multicast network built specifically for shred distribution. * **Shortest-path ingestion.** Our receivers are positioned so that shreds reach our network over the shortest available path from the leader, rather than over whatever route the public Internet happens to pick. * **Custom low-latency links.** Once a shred is inside our network, we distribute it between regions over our own low-latency links instead of the public Internet. * **Multicast fan-out.** Within each region, shreds are fanned out over multicast, so adding subscribers does not add latency for the ones already connected. * **Dedicated network ports.** We use dedicated shred distribution hosts with multiple dedicated network ports to ensure that there is minimal distribution latency. The result is that a shred picked up in one region is available to subscribers in every other region very shortly after we first see it. ### **Getting started** 1. **Request access.** Contact our customer support through the [Customer Portal](https://customers.triton.one) and ask to have Shred Streams enabled on your account. 2. **Configure your destinations.** Once it is enabled, a Shred Streams section appears in the Customer Portal. There you add the **IP addresses and ports** you want shreds delivered to, for each of the regions you want to receive from. Shortly after adding them you will start receiving shreds from our source IP (67.209.53.15). 3. **Start receiving.** Shreds begin flowing to the destinations you configured. Make sure the hosts you list can accept the traffic — the destination IPs must be reachable and the ports open. If you have an ingress firewall allow traffic originating from 67.209.53.15. {% hint style="warning" %} A full shred feed is high-bandwidth and bursty. Provision the receiving hosts and their network capacity accordingly, and place them as close as possible to the region you subscribe from. {% endhint %} ### **Questions** For help with sizing, region selection, or anything else about Shredstream, reach out through your Triton CS channel or the [Customer Portal](https://customers.triton.one). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.triton.one/chains/solana/shred-streaming.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.