shredstream.sh documentation

Start with the delivery model

From ${REGION.city}, shredstream.sh pushes raw UDP datagrams toward the destination pair you supply. Nothing in the receiver initiates that delivery. Its data path has no API key, request headers, session, or login. Keep a UDP socket open on the configured IP and port, with ${SOURCE_IP} permitted.

Every service datagram originates at ${SOURCE_IP}. That fact covers initial verification as well as shred traffic. Before verification, install a narrow inbound-UDP rule for this address. Internet-wide admission is unnecessary, while selecting a different source prevents both activation and delivery.

The offer is ${OFFER_LINE}. Payment uses ${ACCEPTED_ASSETS.join(" or ")} on Solana. A single plan provides the full feed without tier selection, a trial, or rate limiting. Since volume changes with Solana activity, capture traffic at the intended machine before sizing its receiver.

Follow the shortest setup path

1. Read Quickstart.
2. Prepare a public destination in Account and destinations.
3. Permit ${SOURCE_IP} with the firewall guide.
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. One challenge datagram then arrives with ${CHALLENGE_PREFIX} at the front of its payload. Next comes the destination ID, followed by the verification token. Return that token through the dashboard within ${CHALLENGE_TTL_SECONDS} seconds. Packet loss or token expiry requires another request.

Use the delivery references during deployment

UDP wire contract defines inherited transport behavior. The receiver gets no ordering, retransmission, or backpressure from UDP. Its design must tolerate gaps, reordering, and bursts rather than treating the socket as a byte stream.

Packet format records service-level facts. A packet can contain at most ${WIRE.maxPacketBytes} bytes. Size reception for that limit rather than a mean. This product contract does not define Solana's detailed shred payload schema.

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.

The firewall reference supplies host commands as well as rules for GCP and AWS security groups. NAT traversal explains the receiver's required static port mapping. 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 without establishing a client connection. It neither retries a missing datagram nor restores order, and receiver overload cannot slow its sender. No product definition covers the source UDP port, activation delay, availability, support response, resend count, or detailed payload schema.

Treat an observed rate as capacity evidence, never a per-packet guarantee. Establish your own capture baseline and provision above it, since block production can create peaks beyond the mean. The capacity arithmetic page works through the calculation.

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 the layers separately

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.

When activation stalls, begin with a capture restricted to the fixed source. Compare its count against receiver counters for one bounded UTC period. An empty capture points toward the registered pair, route, NAT mapping, or firewalls. If capture counts rise while application counts do 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.