Delivery guarantees

Rely on the explicit contract

shredstream.sh pushes raw UDP datagrams from ${REGION.city} toward one customer-supplied destination pair. Receipt is passive, with no endpoint connection and no API key carried by packets.

The fixed origin for service datagrams is ${SOURCE_IP}. Verification traffic and shreds both use it. The documented payload limit is ${WIRE.maxPacketBytes} bytes.

Three transport guarantees are explicitly false: ordering, retransmission, and backpressure. A receiver must make those absences normal operating conditions rather than service exceptions.

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.

Downstream processing should derive sequence by interpreting the applicable Solana shred fields. Detailed layout and decoding implementation fall outside the published product source.

A reordered datagram alone does not prove network failure and should not trigger that alert. Track reordering separately from missing packets and decoder failures.

No retransmission guarantee

Missing stream datagrams are never resent by the service. The documented path accepts no receiver acknowledgments or stream replay request.

Advance through gaps, handing available Solana recovery data to downstream logic. No provider replay, historical backfill, packet acknowledgment, or guaranteed recovery threshold is defined.

The dashboard can issue another verification challenge after loss or expiry. This activation control never implies retransmission of stream traffic.

No backpressure guarantee

Filling a customer-side socket or application queue never slows the sender. This feed has no UDP feedback channel.

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.

Customers choose their receive-buffer capacity, queue depth, worker count, and overload behavior. No required values have been published.

Measured rates are not rate guarantees

Feed volume is not fixed. Solana block production and transaction load make it vary during a day and month. Measure the deployed receiver repeatedly instead of planning from one figure.

These observations support capacity planning. Product facts set no minimum, maximum, peak, burst profile, or mandatory headroom. Before calling a low-rate interval an outage, confirm conditions at both feed and receiver.

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

No uptime percentage, monthly availability commitment, service credit, maintenance window, incident channel, or status page is published. Receiver observations alone cannot establish or calculate an SLA.

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. Evidence should record destination ID, bounded UTC interval, source-filtered capture count, application count, and the UDP error delta.

Latency and jitter lack commitments

The source region is ${REGION.city}. No end-to-end latency target, percentile, measurement point, clock method, route, or jitter limit has been published.

Geographic origin cannot be converted into a latency promise. Measure at the receiver with a defined clock and a packet field that supports the calculation. The product source defines no service-added datagram timestamp.

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 checksum behavior still applies. Beyond it, no added delivery checksum, encryption layer, shared secret, or per-packet service signature is specified.

The delivery contract authenticates network origin through a source-IP allowlist. Solana shred validation instead belongs downstream. This product contract defines neither its exact fields nor validation procedure.

Do not alter raw payload bytes before protocol validation. Preserve each datagram boundary and received length up to ${WIRE.maxPacketBytes} bytes.

Duplication and completeness remain undefined

No duplicate-delivery guarantee is published. Make the chosen shred implementation tolerate repeated protocol content downstream.

No completeness percentage, maximum gap, loss rate, or recovery success rate is defined. Measure them locally without labeling those observations as 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

A paid destination covers a single network pair for 30 days. Editing either field requires verification again. Its verified address remains for 90 days after expiration, but that retention makes no continued-delivery promise.

No renewal guarantee, grace period, automatic renewal, refund policy, or service credit is published. For control-plane evidence, retain the state and expiration displayed by the dashboard.

Build the customer reliability layer

1. Permit ${SOURCE_IP} through every firewall.
2. Keep the UDP socket continuously bound.
3. Allocate for ${WIRE.maxPacketBytes} byte payloads.
4. Drain the socket without per-packet blocking work.
5. Queue downstream work with explicit bounds.
6. Tolerate reordered datagrams.
7. Continue through missing datagrams.
8. Apply shred recovery downstream.
9. Count kernel and application drops.
10. 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.