Destination management

Treat a destination as one pair

One paid slot covers ${OFFER_LINE}. Its destination pairs one IP address with a single 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 service fanout across several customer addresses. The lifecycle manager may contain up to ${MAX_DESTINATIONS_PER_CUSTOMER} destinations for one customer. Checkout rejects destination number six.

A single plan governs every slot. It has neither tier choices, a trial period, nor rate limiting. Purchase uses ${ACCEPTED_ASSETS.join(" or ")} on Solana. The contract leaves automatic renewal, invoices, refunds, and payment-confirmation requirements undefined.

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}. That source delivers proof first and shreds later.

In the dashboard, store the public pair exposed by the service-facing edge. If NAT translates its port, document external and internal pairs separately. Only the external pair belongs in the destination record.

No product definition covers allowed IP families, port restrictions, or hostname use. Save values the dashboard accepts, then validate the resulting pair by receiving its challenge.

Activate a new slot

1. Select the newly purchased slot in the dashboard.
2. Assign its public destination IP.
3. Assign the UDP port for that destination.
4. Save both fields as one pair.
5. Start reception on the assigned port.
6. Ask the slot to issue its challenge.
7. From the arriving datagram, read the token.
8. Enter it through the slot's verification control.
9. Finish verification before ${CHALLENGE_TTL_SECONDS} seconds elapse.
10. Confirm that stream packets reach this same pair.

A request emits one challenge datagram. When it is lost or expires, the slot must issue a new one. Product facts define no exact activation interval after a successful submission.

A verified state records completed destination proof, not ongoing receiver health. UDP maintains no connection whose status could update that state. Continue monitoring packet arrival and local drops.

Maintain the paid term

Each slot has a 30-day paid term. Use its dashboard expiration when operating the lifecycle. No publication defines the start event, displayed time zone, renewal window, or reminder schedule.

Renew before production becomes dependent on a term nearing expiration. The contract makes no delivery commitment after expiry. Address retention is separate and cannot establish a grace period.

Upon expiration, lifecycle state retains address proof throughout a ${EXPIRED_RETENTION_DAYS} day window. Renewing the same pair during this period keeps its proof, avoiding another challenge. Nothing is defined for the period after retention.

Change a destination deliberately

Editing either address field requires fresh verification. Each managed destination allows ${ADDRESS_CHANGES_PER_DAY} such edits daily. Its counter has no documented reset boundary.

Ready the replacement pair before committing its lifecycle change. Where your policy permits, leave the former receiver available until arrival is confirmed at the replacement. This transition has no published service behavior for parallel delivery.

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. No account API, lifecycle API, webhook, or bulk operation is documented.

Give each record an unambiguous label. Alerts and support reports should use its destination ID. The packets have no documented service envelope containing that ID.

Remove or retire a path safely

The lifecycle contract does not define deletion. Removing a receiver, firewall rule, or NAT mapping cannot therefore be treated as deleting its paid slot. Those actions stop customer receipt without documenting any dashboard transition.

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.

Filter tcpdump by ${SOURCE_IP} plus the port stored on this destination. Compare its result against application counters and kernel UDP errors. Record a bounded UTC interval before changing configuration.

A lifecycle support report needs its destination ID, public pair, current state, displayed expiration, latest address edit, latest verification attempt, capture result, and matching firewall policy. Exclude wallet secrets and live challenge tokens.