Service states
This page lets you determine which destination condition to inspect when verification or delivery does not proceed.
Before you start
- Have access to the destination in the dashboard.
- Know the configured public IP and UDP port.
- Have receiver and firewall telemetry for the same destination.
Use conditions, not invented dashboard labels
The product facts define behaviors around paid, configured, verified, changed, expired, and retained destinations. They do not currently specify a formal state enum or exact dashboard label set. Use the visible dashboard state as the interface authority and map it to the conditions described here.
Do not automate against a state name that appears only in this explanation. No destination API, webhook, or machine-readable transition contract is published.
Paid but not configured
A purchase provides one destination for ${TERM_DAYS} days. Before configuration, its slot lacks the customer network pair needed for proof. Because no precise term-start event is defined, use the dashboard's displayed expiration.
Next action: prepare a public receive path, enter the IP and port, and save the pair. Allow UDP from ${SOURCE_IP} before moving to verification.
Possible symptom: the receiver has no traffic because no verified delivery target exists. Do not investigate shred decoding in this condition.
Configured but not verified
The dashboard has an IP and UDP port, but proof of control has not completed. Streaming starts only after the customer receives a challenge token at that pair and submits it in the dashboard.
Every challenge originates from ${SOURCE_IP}. Start the socket and allow that address through every firewall. Request the challenge only after the path is ready.
No exact dashboard label is published for this condition. A verification prompt, absent proof, or outstanding challenge means normal delivery is not ready.
Challenge pending
One UDP datagram results from a challenge request. Its first bytes are SHREDCAST-VERIFY; the destination ID appears after this prefix, then the token. Submission remains open for ${CHALLENGE_TTL_SECONDS} seconds.
Keep both receiver and capture active during this window. If no packet arrives before it closes, ask again. No product rule sets a resend count or pace.
Only the current request's token should be used. Its structure and any reuse semantics beyond the stated window remain undefined.
Verified with a paid term
Successful token submission proves control of the configured pair. With a paid term, this is the condition expected before normal streaming. No exact delay is published between proof acceptance and the first stream packet.
Leave the receiver bound, and retain the ${SOURCE_IP} firewall rule. Verification records proof without establishing a persistent UDP connection or monitoring receiver health.
Confirm stream arrival with tcpdump and application counters. If the dashboard appears ready but packets do not arrive, inspect the network path independently.
Address changed and awaiting new proof
An edit to the IP address or UDP port triggers another challenge. Until its token is accepted, treat the replacement pair as unverified. Three address edits are permitted daily for each destination.
Before saving, prepare the replacement receiver plus its NAT mapping and firewall policy. The service defines no parallel delivery toward the former pair.
After token acceptance, confirm traffic at the replacement pair before removing obsolete customer rules. No rollback guarantee is published.
Expired with retained address
After expiration, the destination keeps its verified address for ${EXPIRED_RETENTION_DAYS} days. Renewal in this period does not repeat verification when the address is unchanged.
Address retention is not a statement that stream traffic continues after the paid term ends. Delivery behavior while expired is not currently specified. Renew before relying on ongoing delivery.
Use the dashboard's expiration timestamp because the exact time-zone presentation, grace period, and renewal event are not currently specified.
Beyond address retention
Once expiration exceeds ${EXPIRED_RETENTION_DAYS} days, subsequent state is undefined. Product facts do not say whether the slot, destination ID, address, or proof record is deleted, disabled, or recoverable.
Do not promise reactivation without proof after this point. Consult the dashboard and contact support with the destination ID when the behavior affects an expired slot.
Conditions not defined by the contract
Paused, suspended, canceled, deleted, payment-pending, degraded, maintenance, and disabled states are not currently specified. An operator may see an interface message, but these documents cannot assign transition rules absent from the source of truth.
Availability incidents and receiver-side outages are also not destination states. A customer socket can be closed while the destination remains verified. A firewall can block traffic while the paid term remains active.
Diagnose by condition
- Read the destination's visible dashboard state.
- Record the displayed expiration.
- Compare the configured public IP.
- Compare the configured UDP port.
- Confirm the receiver binding.
- Confirm the ${SOURCE_IP} firewall rule.
- Capture traffic from ${SOURCE_IP}.
- Compare the application packet counter.
Keep one action per diagnostic observation and record UTC timestamps. Do not change the address before preserving the current evidence because destination changes are capped.
If the challenge is absent from tcpdump, inspect routing, NAT, and firewalls. When tcpdump alone sees it, trace the local socket path. A rejected token requires a fresh challenge. Stream traffic visible only to tcpdump points toward receive capacity or bindings.
Monitor state and delivery separately
Track dashboard expiration and verification status as control-plane observations. Track packet capture, interface counters, kernel UDP errors, socket health, and application counts as delivery observations.
No monitoring API, state-change webhook, status page, polling interval, or alert threshold is part of the published product. Build customer alerts from available dashboard and receiver evidence without representing them as guarantees.
Parameters
When it goes wrong
A configured destination does not stream. Example error: `verification required`.
Cause. The pair has not completed the current proof-of-control challenge.
Fix. Open the UDP path from 203.23.178.228, request a challenge, and submit its token within 600 seconds.
A verified destination has no application packets. Example error: `receiver idle: 0 datagrams`.
Cause. The destination state is ready but the customer firewall, NAT, socket, or receive path blocks delivery.
Fix. Compare a source-filtered capture with the receiver binding and counters over one UTC interval.
An expired destination is inactive. Example error: `destination expired`.
Cause. The paid term ended; retained verification does not document continued stream delivery.
Fix. Renew the unchanged pair within the documented retention period when avoiding another challenge.
Questions
- What state must a destination reach before streaming?
- Streaming expects three conditions: a paid term, configured network pair, and accepted proof of control. No exact dashboard label or activation interval is published. Keep reception bound and its firewall open, then confirm actual packets instead of treating a control-plane label as receiver health.
- Does a verified state mean my receiver is healthy?
- No. Verification proves that a challenge reached the configured pair and its token was submitted. A later firewall change, NAT change, closed socket, full queue, or process failure can stop receipt without changing that proof. Monitor packets from ${SOURCE_IP}, kernel UDP errors, and application counters separately.
- What is retained after expiration?
- The destination retains its verified address through ${EXPIRED_RETENTION_DAYS} days after expiry. Renewal of that same pair during retention needs no new challenge. Neither expired stream behavior nor post-retention state is defined. The dashboard's current state and expiration form your operational record.