TL;DR
- Triton now offers the fastest streaming on Solana. Powered by Riptide, our new low-latency endpoint.
- Triton Shred Streaming is live in beta from New York, London, Amsterdam, Frankfurt, and Tokyo, in partnership with DoubleZero.
- Riptide is live and waiting for you: same Dragon's Mouth service, same features, same price, same tokens. Just a new URL and more SPEED!
- Together, they give you the earliest data on the network and the quickest path to your machine
- Prove the difference yourself in an open trading competition, coming soon!
Riptide + Triton Shred Streaming = the fastest gRPC streaming for Solana
Two solutions shorten the gap between something happening on Solana and you knowing about it.
The first is Riptide, a new dedicated endpoint for gRPC streaming. It's generally available on mainnet now. It carries the same subscriptions, filters, and SDKs you already use, and your existing tokens work without any changes. The only thing that changes is how quickly the stream reaches you.
The second is Triton Shred Streaming: raw shreds, the smallest unit of Solana block data, forwarded directly to your servers. It's live from five cities: New York, London, Amsterdam, Frankfurt, and Tokyo. We've built it in collaboration with the engineers at DoubleZero and Malbec Labs.
Fastest path, fastest data
Every millisecond between an event happening on Solana and your system reacting to it comes from one of two places: how early the data exists at a point you can listen to, and how long the delivery path is from that point to your process.
Shreds are the fastest data that exists on Solana; shreds are what the network itself uses to move blocks around. Riptide is the fastest way we deliver a stream to you: the same Dragon's Mouth feed, on a shorter path through our infrastructure.
Each one on its own gives you an edge. The combination closes the whole latency budget: you see events at the earliest point they exist on our network, delivered over the shortest path we can offer to your machine. If you're competing on reaction time, that's the whole game.
What shreds are, and who brings them to us
Solana doesn't send blocks around the network as blocks. A block would be far too slow to move quickly as a single unit, so the leader (the validator currently producing the block) serialises transactions into entries and slices them into shreds: packets of at most 1,228 bytes, sized to fit inside a standard network packet so they can be forwarded without fragmentation as transactions are processed by the leader.
Shreds come in two kinds. Data shreds carry the actual transaction data. Coding shreds carry redundancy, generated with erasure coding, so that a receiver can reconstruct missing data shreds if some packets get lost along the way. Both kinds are signed by the leader, so a receiver can verify their origin.
Shreds propagate through Turbine, Solana's fan-out distribution protocol. The leader sends each shred to a small set of nodes, which forward it on to further layers in a tree. Where you sit in that tree is decided largely by stake: validators with more stake tend to sit closer to the leader and receive shreds sooner. In other words, how early you hear about a transaction depends on where you're listening from. That's a sourcing problem, and it's exactly the problem our shred network is built to solve.
Our shred distribution network
Triton runs a shred distribution network across all the locations we serve. It ingests from our own high-stake validators, from partner validators, and from Turbine itself.
Each shred enters the network at the point of presence closest to the validator that produced it, and from there we redistribute internally so that every data centre receives a full feed. The latency you get from any given validator is the lowest we can achieve.
Our partnership with DoubleZero
Shred latency is decided in two places: where you're listening from, and how the data travels once you've heard it. With DoubleZero, we've improved both.
DoubleZero is a dedicated fibre network that moves validator and data centre traffic off the public internet and onto point-to-point private links, built on true multicast, so a single shred reaches every point of presence at once rather than being re-sent copy by copy. That removes the retransmission overhead and routing congestion that normally add latency when data fans out across multiple locations, so shreds travel the shortest physical path between where they originate and where Triton's points of presence pick them up. The result is a more direct, more consistent route for shred data at every location Triton serves.
Why the earliest data wins
By the time a block is assembled, executed, and confirmed, hundreds of milliseconds have passed; a Solana slot alone is around 400 ms. Nothing that trades, liquidates, or quotes on Solana can afford to wait that long. If you're running arbitrage, market making, liquidations, an RFQ desk, or an oracle, you live or die on how early you see intent on the network, and shreds are the earliest form that intent takes.
Raw shreds do take work to consume. You need to verify signatures, recover missing packets from the coding shreds, reassemble entries, and deserialise transactions before you have anything actionable. Teams that want that level of control now get the raw feed directly from us.
A more direct networking approach
Riptide, Triton Shred Streaming and DoubleZero share a design philosophy: solve the latency problem at the network layer, rather than stacking more software on top of it.
Riptide keeps the failover and redundancy you already get from our edge load balancers. If a Riptide path is unavailable, your client reconnects through the standard Dragon's Mouth path automatically, including through the loss of an entire datacentre or region. An event that severe interrupts an open stream, the same as it does today, but there is always a path back. The worst case is the performance you already have.
Getting access to Riptide is as simple as changing your connection URL if you’re a Triton customer already. Same features, same filters, same SDKs, same tokens. It runs over HTTP/2, as gRPC requires, and it's available on mainnet now.
Full chain streams, faster than ever
Working with streams of both shreds and validated data at lower network layers is what lets us minimise latency and maximise throughput at the same time. The multicast network keeps every point of presence fed with the earliest data, and Riptide keeps the delivery path to your servers as short as it can physically be.
Riptide is available now on mainnet; if you already have a token, you're one URL change away. Triton Shred Streaming is available from New York, London, Amsterdam, Frankfurt, and Tokyo: contact us to get your servers whitelisted.
→ Change your existing streaming URL to get more speed at the same price on Riptide
→ Talk to us to get your server whitelisted for Triton Shred Streaming
FAQ
Do I need both Riptide and Shred Streaming? No, they solve different halves of the latency problem, and you can use either one on its own. Riptide gives you the fastest delivery of the structured Dragon's Mouth gRPC stream. Triton Shred Streaming gives you the rawest, earliest data on the network. Latency-critical systems benefit most from running both.
Is Riptide a replacement for Dragon's Mouth? Riptide is Dragon's Mouth on a faster path. The subscriptions, filters, and SDKs are identical, and your existing tokens work. The stream itself is identical; only the delivery path changes.
Does Riptide cost more? No. Riptide is the same price as Dragon’s Mouth streaming: nothing changes except your speed!
Which regions are available? Riptide is available on mainnet endpoints. Triton Shred Streaming is live from New York, London, Amsterdam, Frankfurt, and Tokyo.
Do I need anything from DoubleZero to use Shred Streaming? No. DoubleZero is how the shreds reach us early; you connect to Triton, and we handle the sourcing side.
Whether you take the raw signal, the structured stream, or both, you're running on the same network our own systems run on. Get in touch and we'll get you set up.