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}. The supplied destination combines the customer's single IP address with a UDP port. Every customer receives the same plan, without a trial, rate cap, or tier selection. 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 ")}. Cards cannot be used. USDC is taken at face value, while SOL receives a quote. The contract omits quote lifetime, confirmation count, refunds, and failed-payment recovery.
What destination count can a customer reach?
The maximum is ${MAX_DESTINATIONS_PER_CUSTOMER}. The service refuses a sixth at checkout. No larger limit or exception process is published.
How long does a destination last?
Each payment covers a 30-day destination term. Treat its dashboard expiration as authoritative for operations, since neither the precise start event nor timestamp format is defined.
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. The packet path contains no dialable endpoint, maintained client session, or API key.
Which source address should I allow?
Admit traffic from ${SOURCE_IP} as inbound UDP at your destination port. The same address carries the initial challenge and subsequent shreds. Because no source port is published, do not add one to the filter.
Can the receiver be behind NAT?
Yes, provided the network gives you a stable public IP plus a static mapping from the registered external UDP port into your receiving process. No outbound registration protocol, relay, or other NAT traversal method is documented.
Can I register a hostname or IPv6 address?
The published contract defines neither hostnames, address families, nor textual formats. Enter a value the dashboard accepts, then prove control of the resulting public pair before relying 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. One datagram goes to the proposed pair. Streaming starts only after you read its token and return the value through the dashboard.
What does the challenge contain?
Look for SHREDCAST-VERIFY at the start of its payload. After the prefix comes the destination ID, then its token. No published contract defines their delimiter, full encoding, token length, or alphabet. Display what arrived instead of building a parser around an assumed sample.
How long can I submit the token?
You have ${CHALLENGE_TTL_SECONDS} seconds to return the challenge token. A request produces only one datagram. Lost packets or expired tokens therefore require you to ask again.
Do I need to verify after changing the port?
Yes. An IP edit or UDP-port edit creates a different destination address, which triggers another challenge. You may make ${ADDRESS_CHANGES_PER_DAY} such edits on each destination daily. The counter's reset boundary has no published definition.
Delivery behavior
Are packets ordered?
No. The raw UDP wire contract does not preserve ordering. During reconstruction, derive sequence from shred metadata rather than treating network arrival as canonical.
Are missing packets retransmitted?
No. The service never retransmits a missing UDP datagram. Receivers must pass gaps onward to applicable Solana recovery logic. No replay or provider recovery endpoint is documented.
Does the service slow down for my receiver?
No. UDP provides no way for this receiver to slow delivery. Full socket buffers or application queues may discard traffic without interrupting the sender. Drain reception promptly and track drops in both the host and application.
What is the maximum packet size?
Payloads top out at ${WIRE.maxPacketBytes} bytes under the documentation. Smaller sizes occur as well. Allocate for the maximum rather than an average or a fixed length.
What format is inside the UDP payload?
The service delivers raw shred data without a documented service envelope. Solana's detailed payload schema, accepted variants, and a decoding library all sit outside this product contract.
Capacity
How much traffic should I plan for?
Solana activity drives feed volume, so establish a baseline by capturing traffic at your receiver. Provision every stage for sustained receipt, with environment-specific headroom. Use the capacity worksheet in the Learn section to convert your observation into link, buffer, and monthly storage figures.
What peak multiplier should I use?
No peak rate or mandatory headroom multiplier has been published. Measure brief intervals and drops on the intended host and network. Do not turn an observed average into an invented peak guarantee.
Is delivery rate-limited?
No. The product applies neither a rate limit nor rate tiers. Customer bandwidth, kernel queues, process scheduling, and downstream work can still make a receiver drop traffic.
Renewal and expiration
Must I verify again after a late renewal?
Expiration leaves address proof in place through a ${EXPIRED_RETENTION_DAYS} day retention window. Renewal inside that window preserves verification only if both IP and port remain unchanged. Later behavior is undefined.
Does traffic continue after expiration?
The contract says only that payment has ended and address proof remains for ${EXPIRED_RETENTION_DAYS} days. It makes no delivery commitment while expired. Check the dashboard state, and renew before your system depends on further traffic.
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?
Report the destination ID, its public pair and state, the UTC interval, receiver binding, source-filtered capture, UDP counter delta, firewall policy, and NAT mapping. Keep wallet secrets and active verification tokens out of support mail.
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 203.23.178.228 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 promises none of ordering, retransmission, or backpressure. Datagrams may go missing, arrive out of order, or be discarded during receiver overload. Continue draining the socket, observe host and application losses, and apply shred recovery downstream. No availability guarantee or replay interface is published.
- What are the measured feed requirements?
- Because Solana activity changes feed volume, no fixed rate describes it. Capture a baseline at your receiver. Peak traffic and mandatory headroom remain undefined, so observe the intended path during sustained receipt.
- How should I handle a fact absent from these docs?
- Treat an absent fact as undefined. Common practice cannot establish a guarantee, accepted input, timeout, source port, payload field, support commitment, or state transition. Contact support with the specific destination and use case when missing information affects activation or production design.