Frequently asked questions
This page lets you resolve common service setup and delivery questions without assuming undocumented behavior.
Before you start
- Identify whether the question concerns purchase, destination setup, verification, delivery, or receiver operation.
- Have the destination ID and configured IP and UDP port available when troubleshooting an active purchase.
Purchase and account
What does $100 buy?
It buys ${OFFER_LINE}. A destination is one customer-supplied IP address and UDP port pair. The product has one plan, no tiers, no free trial, and no rate limiting. One purchase does not cover an address range, a port range, or multiple independently registered receivers.
Which payments are accepted?
Payment is crypto only on Solana. The accepted assets are ${ACCEPTED_ASSETS.join(" and ")}. There is no card payment path. USDC is taken at face value. SOL is quoted. Quote lifetime, confirmation count, refund behavior, and failed-payment recovery are not currently specified.
How many destinations can one customer hold?
The maximum is ${MAX_DESTINATIONS_PER_CUSTOMER}. The service refuses a sixth at checkout. A larger account limit and an exception process are not currently specified.
How long does a destination last?
One paid term lasts 30 days. Use the dashboard's displayed expiration as the operational timestamp because the exact term-start event and timestamp representation are not currently specified.
Destination setup
Does my application connect to shredstream.sh?
No. The service pushes raw UDP from Frankfurt to the destination you supply. Bind a UDP socket on your server and keep the public route open. There is no endpoint to dial, client session to maintain, or API key in the packet path.
Which source address should I allow?
Allow inbound UDP from ${SOURCE_IP} to the registered destination port. Every datagram uses that source address, including the verification challenge and live stream. Do not filter by source UDP port because it is not currently specified.
Can the receiver be behind NAT?
Yes, when the network provides a stable public IP and a static inbound UDP mapping from the registered public port to the receiver. NAT traversal beyond this mapping, including an outbound registration protocol or relay, is not currently specified.
Can I register a hostname or IPv6 address?
Hostname support, accepted address families, and textual address rules are not currently specified. Use the address form accepted by the dashboard and verify the resulting public pair before depending on it.
Verification
Why must I prove control of the destination?
Proof prevents a customer from directing a high-rate UDP feed at an address and port they do not control. The service sends one datagram to the proposed pair. Read its token and submit that value in the dashboard before streaming begins.
What does the challenge contain?
The datagram begins with SHRED-FANOUT-VERIFY/1, followed by a destination ID and token. The field delimiter, complete encoding, token length, and token alphabet are not currently specified. Display the received payload instead of constructing a token parser from an assumed sample.
How long can I submit the token?
The challenge window lasts ${CHALLENGE_TTL_SECONDS} seconds. The service sends one datagram per request. Request a resend when UDP drops it or the window expires.
Do I need to verify after changing the port?
Yes. Changing either the IP or UDP port changes the destination address and triggers another challenge. Each destination permits ${ADDRESS_CHANGES_PER_DAY} address changes per day. The daily reset boundary is not currently specified.
Delivery behavior
Are packets ordered?
No. The raw UDP wire contract does not preserve ordering. Use Solana shred metadata during downstream reconstruction instead of processing arrival order as canonical.
Are missing packets retransmitted?
No. The service does not retransmit UDP datagrams. The receiver must continue through gaps and use the applicable Solana recovery logic. A replay or recovery endpoint is not currently specified.
Does the service slow down for my receiver?
No. UDP delivery has no backpressure. A full socket buffer or application queue can drop datagrams without pausing the sender. Keep the receive loop small and monitor host and application drops.
What is the maximum packet size?
The documented maximum is ${WIRE.maxPacketBytes} bytes. The measured mean is ${FEED.meanPacketBytes} bytes. Do not size a buffer to the mean or assume every payload has that length. Receive with capacity for the documented maximum.
What format is inside the UDP payload?
The service delivers raw shred data without a documented service envelope. The detailed Solana shred payload schema, supported variants, and decoding library are not currently specified in the product contract.
Capacity
How much traffic should I plan for?
The measured feed is ${FEED.mbps} Mbps, ${FEED.packetsPerSecond.toLocaleString("en-US")} packets per second, a ${FEED.meanPacketBytes} byte mean packet size, and approximately ${FEED.terabytesPerMonth} TB per month. Provision the entire path for sustained receipt and add headroom based on your environment.
What peak multiplier should I use?
A peak rate and required headroom multiplier are not currently specified. Measure short-interval traffic and drops on the intended host and network. Do not convert the measured average into an invented peak guarantee.
Is delivery rate-limited?
No. There is no product rate limiting and there are no rate tiers. Receiver drops can still occur because of customer bandwidth, kernel queues, process scheduling, or downstream processing.
Renewal and expiration
Must I verify again after a late renewal?
An expired destination retains its verified address for ${EXPIRED_RETENTION_DAYS} days. Renewal during that retention period does not repeat verification when the IP and port are unchanged. Behavior after retention is not currently specified.
Does traffic continue after expiration?
Delivery behavior for an expired destination is not currently specified beyond the fact that the paid term has ended and the verified address is retained for ${EXPIRED_RETENTION_DAYS} days. Use the dashboard state and renew before relying on continued delivery.
Troubleshooting
Why did verification time out?
The receiver may be closed, the registered pair may be wrong, a NAT mapping may be absent, or a firewall may block ${SOURCE_IP}. Start tcpdump before requesting a resend and inspect each network layer.
Why does tcpdump see packets that my application misses?
The process may be bound to another interface or port, running in another network namespace, blocked by a local policy, or falling behind. Compare the socket binding, application count, and UDP receive-error delta over one interval.
What should I send support?
Send the destination ID, public pair, state, UTC interval, receiver binding, source-filtered capture result, UDP counter delta, firewall rule, and NAT mapping to the documented support address. Do not send wallet secrets or an active verification token.
Parameters
When it goes wrong
Verification does not complete. Example error: `verification timed out`.
Cause. The receiver did not obtain the one challenge datagram from 64.130.40.90 within the active window.
Fix. Correct the socket, firewall, route, and NAT mapping, then request a resend.
Delivery appears in tcpdump but not the application. Example error: `receiver idle: 0 datagrams`.
Cause. The application binding or receive capacity does not match the verified network path.
Fix. Inspect the UDP socket, namespace, host counters, receive buffer, and per-interval application count.
Another destination purchase is refused. Example error: `destination limit reached`.
Cause. The customer already holds 5 destinations.
Fix. Use an existing destination slot; a higher customer cap is not currently specified.
Questions
- What is the shortest path from payment to packets?
- Start a UDP receiver on the chosen port, allow inbound UDP from ${SOURCE_IP}, register the public IP and port, request the challenge, submit its token within ${CHALLENGE_TTL_SECONDS} seconds, and keep the receiver open. Confirm arrival with tcpdump before adding any shred decoder or downstream processing.
- What reliability does raw UDP provide?
- The wire contract provides no ordering, retransmission, or backpressure. A datagram can be missing, reordered, or dropped when the receiver falls behind. Keep the receive loop draining, monitor kernel and application drops, and use downstream shred recovery behavior. An availability guarantee and replay interface are not currently specified.
- What are the measured feed requirements?
- The feed was measured at ${FEED.mbps} Mbps and ${FEED.packetsPerSecond.toLocaleString("en-US")} packets per second, with a ${FEED.meanPacketBytes} byte mean packet size and approximately ${FEED.terabytesPerMonth} TB per month. Peak traffic and a required headroom factor are not currently specified, so measure the intended path under sustained receipt.
- What should I do when a fact is absent from these docs?
- Treat it as not currently specified. Do not infer a guarantee, accepted input, timeout, source port, payload field, support commitment, or state transition from common practice. Contact support with the specific destination and use case when an unspecified behavior affects activation or production design.