ShredQuasar

ShredQuasar sends raw Solana shreds to an address you nominate, as UDP datagrams. There is no connection, no request and no client library: once a destination is registered, packets arrive.

It is the same data ShredPrism works from, one stage earlier. ShredPrism reassembles shreds into entries and delivers them over gRPC; ShredQuasar hands over the shreds themselves and leaves reassembly to the receiver.

Whether this is the right feed

ShredQuasar suits a reader that already has, or will write, code that understands the Solana shred format. There is no filtering, no client library and no delivery guarantee, and the work of turning shreds back into transactions belongs to the receiver.

ShredPrism carries the same data from the same sources with that work already done, over a transport that retransmits what it loses. Where the reassembly is not the point of the exercise, it is the better fit and it is included on Nexus.

What arrives

ShredQuasar combines shreds sourced from the fastest known shred providers with shreds from constant-k's own validator. Combining sources means a fragment missed by one can still arrive.

Regions

ShredQuasar runs in New York, Frankfurt and Amsterdam. Each region is bought separately and sends its own copy of the feed. A destination registered in more than one region receives each region's copy.

Receiving the feed

The destination is registered on the My Account page as an IPv4 address and a UDP port. IPv6 is not accepted.

Two things have to be true at the receiving end:

1. The address is reachable from the public internet. A host behind NAT without a forwarded port does not receive the feed.
2. Something is listening on the port registered. Nothing is sent to establish the session first, so a closed port produces ICMP unreachable replies and nothing else.

A change to the registered destination takes effect within 1 to 2 minutes. Stopping takes the same.

Confirming packets arrive

Because nothing is negotiated, the feed either arrives or it does not. tcpdump on the receiving host, on the port registered (9000 in this example), is the shortest check:

sudo tcpdump -n -i any udp port 9000 -c 20

Twenty datagrams of roughly 1.2 KB each means the feed is arriving and the remaining work is in the reader.

Bandwidth and receiver sizing

The feed tracks network activity rather than a fixed rate. Measured in New York and Frankfurt:

Two consequences worth planning for. A metered or capped connection is unsuitable, and many providers bill egress and ingress together. A receiver also has to drain the socket fast enough: at 7,000 datagrams a second, a reader that blocks on parsing fills the socket buffer and the kernel discards the overflow silently. Reading on one thread and parsing on another, with a raised SO_RCVBUF, is the usual arrangement.

Reassembly

What arrives is shreds, not transactions. Turning them back into entries and transactions is the receiver's work, and it is the reason most readers of this feed are written in Rust against the Agave crates that already model the shred format.

Because coding shreds are on the wire, a set can still be recovered when some data shreds are lost. This is what makes a lossy transport workable, and it is the reason a receiver should implement recovery rather than treat a gap as a gap.

rpcpool/deshred-example is a maintained Rust reference that does the whole pipeline, including recovery, and is a reasonable starting point for a receiver. It is not a constant-k project and carries no support from us.

Entries covers the entry layout and the deserialization that follows, which is identical once reassembly is done. Where that work is not wanted, ShredPrism delivers the result of it.

Access

ShredQuasar is sold per region, separately from the RPC plans, and does not require a Nexus subscription.

A one-hour trial is available per region from the pricing page. It requires an account, it is tied to the IP address it is activated from, and each IP address gets one trial. Checking both regions starts both clocks at once.

A registered destination can be changed once every 24 hours. The page shows the time remaining until the next change is allowed.

Troubleshooting

Kernel-side drops are counted per host rather than per socket, and are the usual cause of gaps that correlate with busy slots:

netstat -su | grep -iE 'packet receive errors|receive buffer errors'

A number that climbs while the feed runs means datagrams are arriving faster than the reader drains them. Raising SO_RCVBUF buys headroom; moving parsing off the receiving thread fixes it.

Measuring the head start

The reason to take this feed is that it arrives before anything else, so the number worth having is your own. Record the first time a transaction signature is seen in a reassembled entry, subscribe to the same signature through Solana RPC at processed, and compare timestamps across a few thousand transactions. The distribution, not a single sample, is the answer, and it is specific to the distance between your host and the region.

ShredQuasar or ShredPrism

Both carry the same stage of data from the same sources. The difference is transport and who does the reassembly.

Related