Destination management

Treat a destination as one pair

One paid slot covers ${OFFER_LINE}. The destination consists of one IP address and one UDP port. Keep the pair together in inventories, firewall rules, NAT mappings, receiver configuration, and incident reports.

The plan does not include a destination range, multiple ports, or provider-side fanout to several customer addresses. A customer can hold at most ${MAX_DESTINATIONS_PER_CUSTOMER} destinations. Checkout refuses a sixth.

There is one plan with no tiers, no free trial, and no rate limiting. Payment uses ${ACCEPTED_ASSETS.join(" or ")} on Solana. Automatic renewal, invoice behavior, refunds, and payment-confirmation requirements are not currently specified.

Create the network path first

Build the receiving path before requesting proof of control. Bind the UDP socket, create any static NAT mapping, and add a source-specific firewall rule for ${SOURCE_IP}. The verification challenge and stream both originate from that address.

Use the public address and port at the service-facing edge as the dashboard pair. When NAT translates the port, document both the external and internal pairs. The dashboard receives the external pair.

The supported IP address families, port restrictions, and hostname support are not currently specified. Use values accepted by the dashboard and confirm them with a received challenge.

Activate a new slot

1. Open the paid destination in the dashboard.
2. Enter the public destination IP.
3. Enter the destination UDP port.
4. Save the pair.
5. Start the receiver.
6. Request the challenge.
7. Read the token from the received datagram.
8. Paste the token into the dashboard.
9. Submit the token within ${CHALLENGE_TTL_SECONDS} seconds.
10. Confirm stream packets at the same pair.

One challenge datagram is sent for each request. Request a resend when it is lost or expires. The exact activation delay after successful submission is not currently specified.

Do not interpret a verified state as proof that the receiver remains healthy. It records destination proof, while UDP has no persistent connection. Continue monitoring packet arrival and local drops.

Maintain the paid term

The paid term lasts 30 days. Use the dashboard expiration as the operational timestamp. The event that starts the term, time zone display, renewal window, and reminder schedule are not currently specified.

Renew before production depends on an expiring slot. Delivery after expiration is not currently specified. Do not assume a grace period from the separate address-retention behavior.

When a destination expires, the verified address remains retained for ${EXPIRED_RETENTION_DAYS} days. Renewing within that window does not require another challenge if the address is unchanged. The post-retention behavior is not currently specified.

Change a destination deliberately

Changing the IP or UDP port requires re-verification. A destination permits ${ADDRESS_CHANGES_PER_DAY} address changes per day. The daily counter's reset boundary is not currently specified.

Prepare the new pair before saving it. Keep the old receiver available until traffic is confirmed on the new pair when your operational policy permits. Provider-side parallel delivery during the transition is not currently specified.

1. Bind the receiver at the new target.
2. Permit ${SOURCE_IP} to the new port.
3. Configure the new NAT mapping when required.
4. Capture the existing destination state.
5. Save the new pair.
6. Request the new challenge.
7. Submit the received token within ${CHALLENGE_TTL_SECONDS} seconds.
8. Confirm packets from ${SOURCE_IP} at the new target.
9. Remove obsolete customer firewall rules after confirmation.

Do not use repeated address changes as a packet-path probe. Test routing and firewall behavior locally before consuming the limited dashboard changes.

Inventory multiple slots

Create one local record per destination ID. Record the public pair, internal pair when NAT is present, receiver owner, dashboard state, displayed expiration, last verification time, firewall policy reference, and monitoring target.

This inventory is a customer operational practice, not a documented dashboard export feature. An account API, destination-management API, webhook, and bulk operation are not currently specified.

Avoid sharing one ambiguous label across destinations. Use the destination ID in alerts and support reports. A packet itself does not carry a documented provider envelope containing that ID.

Remove or retire a path safely

Destination deletion behavior is not currently specified. Do not claim that removing a receiver, firewall rule, or NAT mapping deletes the paid slot. Those actions stop customer receipt but do not document a dashboard state change.

Before retiring a customer path, record the destination state and expiration. Stop downstream consumers, stop the UDP receiver, remove the NAT mapping, and remove the narrow firewall rule according to your own change policy. Each instruction is a separate customer-side action and none changes the commercial term by itself.

Diagnose state and path independently

When no packets arrive, inspect both the dashboard state and the network path. An unverified destination cannot begin normal streaming. A verified destination can still be blocked by a firewall or closed socket. An active paid term does not make a customer receiver available.

Use tcpdump filtered to ${SOURCE_IP} and the registered destination port. Compare the result with application counters and kernel UDP errors. Record a bounded UTC interval before changing configuration.

When contacting support, provide the destination ID, public pair, current state, displayed expiration, last address change, last verification attempt, capture result, and matching firewall rule. Do not provide wallet secrets or active challenge tokens.