Account and destinations

Understand what the account holds

One purchase provides ${OFFER_LINE}. Within the account, its destination record combines one IP address and one UDP port. It is not a login credential, API key, client connection, wildcard port range, or group of receivers.

The account offers a single plan without a trial, tier choices, or rate limiting. Only ${ACCEPTED_ASSETS.join(" or ")} on Solana can fund payment. One customer account holds at most ${MAX_DESTINATIONS_PER_CUSTOMER} destinations. Checkout refuses an attempted sixth purchase.

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. For a receiver behind NAT, forward the public port recorded on the account to the internal process's UDP port.

Every datagram comes from ${SOURCE_IP}. Both proof of control and subsequent shred traffic arrive from this address. Add a source-specific inbound UDP rule before verification. No source UDP port has been published, so leave that field unrestricted.

The account contract does not define supported IP families, hostname handling, or acceptable textual formats. Enter an address the dashboard accepts. The fixed IPv4 source does not establish that IPv6 destinations work.

Configure a new paid destination

1. Choose the account purchase that you will configure.
2. Record its public destination IP address.
3. Record the UDP port used by the receiver.
4. Save this pair on the account.
5. Bind the receiving process on that port.
6. Admit ${SOURCE_IP} at every network firewall.
7. Ask the dashboard to issue a verification challenge.
8. After the datagram arrives, extract its token.
9. Fill the dashboard verification field with this value.
10. Complete submission before ${CHALLENGE_TTL_SECONDS} seconds have elapsed.

Each dashboard request produces a single challenge datagram. If reception fails or time runs out, make the dashboard generate a fresh one. Successful proof marks the account as controlling that IP and port pair. No client connection results because the server continues to push raw UDP.

No exact interval from accepted proof to stream start is published. Leave the receiver open, then inspect a capture whose filters select ${SOURCE_IP} as source and the destination port stored on the account.

Follow the term

The paid term is ${TERM_DAYS} days. Neither its starting event nor the precise expiration timestamp format is documented. Operate from the expiration displayed for this destination in the dashboard.

After expiration, the account keeps that destination's verified address throughout a ${EXPIRED_RETENTION_DAYS} day window. Renewal inside this period preserves proof when the address has not changed, so another challenge is unnecessary. Address retention says nothing about stream delivery while payment is expired.

Product facts leave post-retention handling, renewal grace, reminders, automatic renewal, and partial-term refunds undefined. Account automation must not assume any of those behaviors.

Change an address carefully

An edit to either member of the stored pair creates a new destination address that needs verification. The account allows ${ADDRESS_CHANGES_PER_DAY} address changes for each destination per day. No time zone or reset boundary is published for this daily allowance.

Make the replacement network path ready before committing the account edit. Once saved, it can direct every future datagram away from the former receiver. The contract does not define simultaneous delivery to both addresses while an edit is underway.

1. Start reception at the replacement IP and port.
2. Extend the ${SOURCE_IP} firewall policy to its port.
3. With NAT present, verify the replacement public mapping.
4. Save the replacement address through the dashboard.
5. Ask for proof against the newly stored pair.
6. Read the current token where replacement traffic arrives.
7. Return that value before ${CHALLENGE_TTL_SECONDS} seconds expire.
8. Verify that stream traffic now reaches the replacement 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 relies on IP allowlisting, since these UDP datagrams lack a request header for an API key.

Protect dashboard access with the controls it provides. Published product facts do not enumerate account security controls, session lifetime, password policy, or multi-factor behavior. Wait for a control to appear in the dashboard before documenting or automating it.

Treat verification tokens as short-lived proof material. Do not send a token in a support request after verification. An account-related support case should include its destination ID, IP, port, UTC timestamps, observed source, 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. Account verification can persist even after the customer network stops accepting packets. UDP has no session state that warns the sender that the process is closed.