Account and destinations

Understand what the account holds

One purchase provides ${OFFER_LINE}. A destination is one IP address and one UDP port considered as a pair. It is not a login credential, API key, client connection, wildcard port range, or group of receivers.

The service has one plan. There are no tiers, no free trial, and no rate limiting. Payment is crypto only, using ${ACCEPTED_ASSETS.join(" or ")} on Solana. A customer can hold at most ${MAX_DESTINATIONS_PER_CUSTOMER} destinations. The behavior of an attempted sixth purchase is refusal at checkout.

Each destination has its own address, verification state, and ${TERM_DAYS} day paid term. Do not assume that verification of one destination proves control of another IP or port. Complete a separate challenge for every destination.

Prepare a destination

A usable destination requires a public route to a UDP socket. The registered IP must identify the network edge that receives the service datagrams. The registered port must reach the process that consumes them. When the receiver is behind NAT, forward the registered public UDP port to the internal receiver's UDP port.

Every datagram comes from ${SOURCE_IP}. This includes the proof-of-control challenge and the live shred stream. Add a source-specific inbound UDP rule before verification. Do not restrict the source UDP port because it is not currently specified.

The supported IP address families, hostname support, and accepted textual address formats are not currently specified. Use the address form accepted by the dashboard. Do not infer IPv6 support from the fixed IPv4 source address.

Configure a new paid destination

1. Open the paid destination in the dashboard.
2. Enter the public destination IP address.
3. Enter the receiver's UDP port.
4. Save the destination.
5. Bind the receiver to the matching UDP port.
6. Permit ${SOURCE_IP} through every network firewall.
7. Request the verification challenge.
8. Read the token from the received datagram.
9. Paste the token into the dashboard.
10. Submit the token within ${CHALLENGE_TTL_SECONDS} seconds.

The service sends one challenge datagram for a request. Request a resend when that packet is lost or when the token expires. A successful proof confirms control of the IP and port pair. It does not create a client connection because delivery remains server-pushed raw UDP.

The exact delay between accepted verification and stream start is not currently specified. Keep the receiver open and use a packet capture filtered to source ${SOURCE_IP} and the registered destination port.

Track the paid term

The paid term is ${TERM_DAYS} days. The starting event and exact expiration timestamp representation are not currently specified. Use the expiration shown in the dashboard as the operational value.

An expired destination retains its verified address for ${EXPIRED_RETENTION_DAYS} days. Renewal during that retention period does not require another challenge for the unchanged address. Retention preserves the verified address; it does not state that stream delivery continues while the destination is expired.

The behavior after ${EXPIRED_RETENTION_DAYS} days, the renewal grace period, renewal reminders, automatic renewal support, and partial-term refunds are not currently specified. Do not build automation around an undocumented assumption.

Change an address carefully

Changing either the IP or the UDP port changes the destination address and requires re-verification. Each destination permits ${ADDRESS_CHANGES_PER_DAY} address changes per day. The time zone and reset boundary used for that daily counter are not currently specified.

Prepare the new network path before saving the new pair. A change can redirect all future datagrams away from the old receiver. Parallel delivery to the old and new address during a change is not currently specified.

1. Start a receiver on the new IP and port.
2. Add the ${SOURCE_IP} firewall rule for the new port.
3. Confirm the public NAT mapping when NAT is present.
4. Change the address in the dashboard.
5. Request the new verification challenge.
6. Read the current token on the new receiver.
7. Submit the token within ${CHALLENGE_TTL_SECONDS} seconds.
8. Confirm stream traffic on the new receiver.

Do not consume changes while testing speculative configurations. The cap exists per destination per day, and no additional address changes beyond ${ADDRESS_CHANGES_PER_DAY} are documented.

Separate account access from delivery authentication

Dashboard access lets a customer configure and verify a destination. It does not place credentials inside each UDP packet. Delivery authentication uses IP allowlisting because UDP datagrams have no request headers that could carry an API key.

Protect dashboard access according to the controls provided there. The available account security controls, session lifetime, password policy, and multi-factor authentication behavior are not currently specified in the product facts. Do not document or automate a control until the dashboard exposes it.

Treat verification tokens as short-lived proof material. Do not send a token in a support request after verification. For support, provide the destination ID, destination IP and port, UTC timestamps, observed source IP, firewall rule, and packet counters.

Audit each destination

Maintain an inventory with one row per paid destination. Record the dashboard destination ID, public IP, UDP port, internal NAT target when applicable, paid expiration shown in the dashboard, last successful verification time, and responsible receiver owner. This local inventory is an operational recommendation, not a product feature.

Review the inventory before firewall, routing, or receiver deployments. A destination can remain verified while the customer network stops accepting its packets. UDP has no session state that warns the sender that the process is closed.