shredstream.sh documentation

Start with the delivery model

shredstream.sh pushes raw UDP datagrams from ${REGION.city} to an IP address and UDP port that you supply. Your receiver does not connect to a service endpoint. The data path has no API key, request headers, session, or login. Keep a UDP socket open on the configured destination and permit packets from ${SOURCE_IP}.

Every datagram sent by the service originates from ${SOURCE_IP}. This applies to the verification challenge and the shred stream. Allow inbound UDP from that exact address before requesting verification. A broad rule that admits the whole internet is not required. A rule for a different source address will prevent activation and delivery.

The offer is ${OFFER_LINE}. Payment uses ${ACCEPTED_ASSETS.join(" or ")} on Solana. There are no tiers, no free trial, and no rate limiting. The destination receives one feed with measured characteristics of ${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.

Follow the shortest setup path

1. Read Quickstart.
2. Prepare a public destination in Account and destinations.
3. Permit ${SOURCE_IP} in Firewall configuration.
4. Start the receiver in Five-minute receiver.
5. Complete the challenge in Authentication.
6. Inspect the stream in Your first packet.

Do not request verification until the socket and every firewall layer are ready. The service sends one challenge datagram whose payload begins with ${CHALLENGE_PREFIX}, followed by a destination ID and token. Read the token from that packet and paste it into the dashboard. The token remains valid for ${CHALLENGE_TTL_SECONDS} seconds. Request a resend when the datagram is lost or the token expires.

Use the delivery references during deployment

UDP wire contract defines the behavior inherited from UDP. Delivery has no ordering, retransmission, or backpressure. Design the receiver to tolerate gaps, reordering, and bursts instead of treating a UDP socket as a byte stream.

Packet format records the service-level packet facts. The maximum packet size is ${WIRE.maxPacketBytes} bytes and the observed mean is ${FEED.meanPacketBytes} bytes. The detailed Solana shred payload schema is not currently specified by the product contract.

Source addresses provides the single fixed source IP and identifies fields that are not currently specified, including the source UDP port. IP allowlisting explains why source address filtering is the authentication control in the delivery path.

Destination management covers the paid destination slot, verification, renewal retention, and the customer limit. Changing destinations covers address changes and the required new challenge.

Firewall configuration contains commands for iptables, nftables, ufw, AWS security groups, and GCP firewall rules. NAT traversal explains the static port mapping required when the receiver is behind NAT. MTU configuration gives a conservative sizing check for the ${WIRE.maxPacketBytes} byte UDP payload.

Bandwidth requirements converts the measured feed into host and network capacity requirements without claiming an unspecified peak. Service states distinguishes unverified, active, expired, and retained destination behavior using only published state facts. Delivery guarantees states what raw UDP does and does not promise.

Use the start references for account questions

Glossary defines destination, challenge, source address, datagram, packet, and feed in the terms used throughout these documents. Read it when a networking term is ambiguous.

FAQ answers common commercial and activation questions. Support lists the evidence to collect before contacting support. Include the destination ID, UTC timestamps, destination address, receiver counters, and firewall observations. Do not send a verification token after it has served its purpose.

Keep the contract boundaries clear

The service transports raw UDP. It does not establish a client connection, retry a missing datagram, reorder packets, or slow the sender when your receiver falls behind. The source UDP port, destination activation delay, availability commitment, support response time, resend count, and detailed payload schema are not currently specified.

Treat the measured feed values as capacity inputs, not as a packet-by-packet guarantee. Provision for ${FEED.mbps} Mbps and ${FEED.packetsPerSecond.toLocaleString("en-US")} packets per second as the published observed baseline. Measure headroom in your own environment because a peak multiplier is not currently specified.

Use the exact destination IP and port shown in the dashboard when debugging. The plan covers one IP and port pair. Changing either value changes the destination and requires another proof-of-control challenge. The address change limit is documented on the changing-destinations page.

Validate one layer at a time

Keep control-plane checks separate from data-path checks. The dashboard records the destination pair, paid condition, and proof result. The customer network determines whether a datagram reaches the host. The socket and application determine whether a delivered datagram is consumed. A successful value at one layer does not prove the next layer works.

Start with a source-filtered packet capture when activation stalls. Compare its result with the receiver counter over the same UTC interval. When the capture is empty, inspect the registered pair, route, NAT mapping, and firewalls. When the capture advances but the application does not, inspect the socket binding, namespace, kernel queue, and process. Preserve these observations before changing the destination.

Do not begin payload debugging until the receiver proves network arrival. A binary decoder can reject valid delivery for reasons unrelated to the paid UDP path. Record delivery failures and decoder failures as separate conditions, then use the support page when the documented source, size, or destination behavior does not match the observed traffic.