Delivery guarantees
This page lets you separate documented delivery behavior from guarantees that the service does not currently specify.
Before you start
- Understand the difference between a transport property, a measured characteristic, and a service guarantee.
- Have receiver-side metrics when evaluating an active destination.
- Know the registered destination IP and UDP port.
Rely on the explicit contract
shredstream.sh pushes raw UDP datagrams from ${REGION.city} to one customer-supplied IP address and port. The receiver does not connect to an endpoint, and no API key appears in the data path.
Every service datagram originates from ${SOURCE_IP}. This includes verification and the shred stream. The documented maximum payload is ${WIRE.maxPacketBytes} bytes.
The transport explicitly provides no ordering, no retransmission, and no backpressure. Build these three absences into the receiver instead of treating them as exceptional service behavior.
No ordering guarantee
UDP datagrams can arrive in an order different from transmission. The service contract does not restore order before delivery. Arrival position is not a canonical shred sequence.
Use the applicable Solana shred metadata in downstream processing. The detailed shred layout and decoding implementation are not currently specified by the product source.
Do not alert on a reordered datagram as if it proves network failure. Track reordering separately from missing packets and decoder failures.
No retransmission guarantee
The service does not resend missing stream datagrams. The receiver sends no acknowledgments and has no stream replay request in the documented path.
Continue through gaps and use the applicable Solana recovery data downstream. A provider replay endpoint, historical backfill, per-packet acknowledgment, and guaranteed recovery threshold are not currently specified.
The dashboard can resend the one-time verification challenge when it is lost or expired. That control is limited to activation and does not imply stream retransmission.
No backpressure guarantee
The sender does not slow down when the customer socket or application queue fills. UDP provides no feedback channel for this feed.
Keep the receive loop draining, move expensive work downstream, and monitor kernel and application drops. A blocked receive loop can lose packets without creating a service-visible error.
Queue depth, receive-buffer size, worker count, and overload behavior are customer design choices. Required values are not currently specified.
Measured rates are not rate guarantees
The feed was measured at ${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. The measurement date is ${FEED.measuredOn}.
These values support capacity planning. A minimum rate, maximum rate, peak rate, burst profile, and required headroom factor are not currently specified. Do not infer an outage from a short interval below the measured packet rate without confirming feed and receiver conditions.
There is no product rate limiting. That fact means the product does not intentionally apply a customer rate tier; it does not promise a constant packet rate.
Availability is not currently specified
An uptime percentage, monthly availability commitment, service credit, maintenance window, incident notification channel, and status page are not currently specified. Do not state or calculate an SLA from receiver observations alone.
Monitor the customer path and keep evidence for support. A lack of packets can result from destination state, provider delivery, internet routing, customer firewall, NAT, host queue, socket binding, or application failure.
Separate provider-facing questions from customer-controlled observations. Record the destination ID, UTC interval, source-filtered capture count, application count, and UDP error delta.
Latency and jitter are not currently specified
The source region is ${REGION.city}. An end-to-end latency target, percentile, measurement point, clock method, route, and jitter limit are not currently specified.
Do not convert geographic origin into a latency promise. Measure at the receiver with a defined clock and packet field only when the selected payload format supports that calculation. The product source does not specify a service timestamp added to each datagram.
Avoid comparing application processing time with network latency. Record separate timestamps for socket arrival, queue entry, decode completion, and downstream action under the customer's measurement design.
Packet integrity boundaries
Normal UDP/IP mechanisms include checksums according to protocol and operating-system behavior, but the product does not specify an added delivery checksum, encryption layer, shared secret, or per-packet provider signature.
Source-IP allowlisting is the documented delivery authentication. Solana shred validation belongs to downstream protocol processing. Its exact fields and validation procedure are not currently specified by this product contract.
Do not alter raw payload bytes before protocol validation. Preserve each datagram boundary and received length up to ${WIRE.maxPacketBytes} bytes.
Duplication and completeness are not currently specified
A duplicate-delivery guarantee is not currently specified. Make downstream processing tolerant of repeated protocol content according to the chosen shred implementation.
A completeness percentage, maximum gap, loss rate, and recovery success rate are not currently specified. Measure local observations without labeling them provider guarantees.
Do not represent one clean packet capture as proof of future completeness. UDP path behavior and receiver capacity can change over time.
Destination and term boundaries
One paid destination is one IP and UDP port for 30 days. Changing either field requires re-verification. An expired destination retains its verified address for 90 days, but continued delivery during expiration is not currently specified.
A renewal guarantee, grace period, automatic renewal, refund policy, and service credit are not currently specified. Use the dashboard's displayed state and expiration as the operational control-plane evidence.
Build the customer reliability layer
- Permit ${SOURCE_IP} through every firewall.
- Keep the UDP socket continuously bound.
- Allocate for ${WIRE.maxPacketBytes} byte payloads.
- Drain the socket without per-packet blocking work.
- Queue downstream work with explicit bounds.
- Tolerate reordered datagrams.
- Continue through missing datagrams.
- Apply shred recovery downstream.
- Count kernel and application drops.
- Record bounded UTC incident intervals.
These steps reduce customer-side loss and make incidents observable. They do not create provider guarantees beyond the published contract.
Escalate with evidence
When delivery differs from the explicit contract, preserve the destination ID, source and destination tuple, UTC timestamps, capture metadata, payload length, firewall rule, and receiver counters. For an oversized service payload, retain a controlled sample according to customer policy.
For unspecified behavior, state the required property and ask support whether a current commitment exists. Do not present an informal response as a published guarantee unless the source of truth is updated.
Parameters
When it goes wrong
The decoder blocks waiting for an absent sequence position. Example error: `waiting for packet 4182`.
Cause. The application assumes ordered, retransmitted delivery.
Fix. Continue through transport gaps and use downstream shred metadata and recovery behavior.
Receive errors grow during processing spikes. Example error: `packet receive errors: 4096`.
Cause. The application expects backpressure and stops draining the UDP socket.
Fix. Keep the receive path short, use bounded downstream work, and monitor overload drops.
A monitoring check declares an SLA breach. Example error: `availability below 99.9%`.
Cause. The check assumes an availability target that is not currently specified.
Fix. Report the measured receiver symptom and UTC evidence without attributing an undocumented guarantee.
Questions
- Does shredstream.sh guarantee every packet arrives?
- No completeness guarantee is currently specified. The raw UDP contract provides no retransmission, so a datagram can be lost in transit or in the customer receive path. Keep the socket draining, monitor drops, continue through gaps, and apply the applicable Solana shred recovery behavior in downstream processing.
- Is there an uptime or latency SLA?
- An uptime percentage, latency target, percentile, service credit, and maintenance commitment are not currently specified. The documented region is ${REGION.city}, but location is not a latency promise. Measure the customer receiver path with defined timestamps and report bounded UTC evidence without assigning an undocumented service guarantee.
- Are the published bandwidth numbers guaranteed?
- No. ${FEED.mbps} Mbps, ${FEED.packetsPerSecond.toLocaleString("en-US")} packets per second, ${FEED.meanPacketBytes} mean bytes, and approximately ${FEED.terabytesPerMonth} TB per month are measured characteristics. A minimum, maximum, peak, burst profile, and required headroom factor are not currently specified. Use the measurements for planning and observe the deployed path.
- What delivery properties can I depend on?
- Depend on raw UDP from ${SOURCE_IP} to the configured IP and port, with payloads no larger than ${WIRE.maxPacketBytes} bytes under the documented contract. Also depend on the explicit absence of ordering, retransmission, and backpressure. Treat availability, latency, jitter, duplication, completeness, replay, and peak rates as not currently specified.