Privacy policy

This policy covers the Wuraw website, the inference API, the app surfaces (chat, catalog, playground, settlement ledger, usage) and the SDK. It applies to anyone who sends a request to the router, whether a human using the app or autonomous software using a key of its own.

It does not cover the upstream model providers that ultimately serve your request (clause 7), the wallet software you sign with, or the facilitator that settles a payment (clause 6). Those are independent parties with their own policies, and we describe what they receive rather than speaking for them.

There is no registration step. We do not ask for and cannot store: a name, an email address, a phone number, a postal address, a date of birth, an identity document, a selfie, a card number, a bank account, or an employer. We run no KYC process and no identity-verification vendor.

This is architectural rather than a policy choice we could quietly reverse. The router authenticates nothing; a paid request is authorized by a signature over an amount, and an unpaid free-tier request is authorized by nothing at all. There is no user record for personal data to attach to.

Conversations, prompts, completions, saved presets and app preferences are written to your browser’s local storage on your own device. They are not uploaded, not synced, not backed up by us and not readable by us. Clearing your browser storage deletes them permanently, and we cannot help you recover them — we never had a copy.

The practical consequences are worth stating plainly: your history does not follow you to another device or another browser, and a shared or managed device shares that history with whoever else uses it. If you need durable multi-device history, export it yourself from the app and store it where you control it.

A request necessarily passes through the router on its way to a provider. We process request and response bodies for exactly as long as it takes to normalize, route and stream them. We do not retain prompt or completion content, we do not log it, and we do not use it to train, fine-tune or evaluate any model.

What we do retain from a request is operational metadata with no content in it: the resolved model, the tier and provider that served it, token counts, timing, status code and whether a fallback occurred. This is what makes the status page and the health-based routing in clause 5 possible.

Our edge sees what any HTTP server sees: an IP address, a user agent, a timestamp and the requested path. IP addresses are used for abuse mitigation and for the free tier’s rate limiting, are not joined to wallet addresses, and are discarded within 30 days. Aggregated request metrics are kept indefinitely because they contain no identifiers.

We do not use advertising trackers, third-party analytics scripts, session recording or fingerprinting. The site sets no cookies for tracking; local storage is used only for the app state described in clause 3 and for your interface preferences.

Paid requests settle through a facilitator: an independent service that verifies your signed EIP-3009 authorization off-chain and submits the transfer onchain. The facilitator receives the authorization payload and what is needed to validate it — payer address, payee address, amount, asset, network, validity window and nonce — plus the resource identifier being paid for, which is an endpoint path such as /v1/chat/completions.

The facilitator does not receive your prompt, your completion, your conversation or the specific model parameters. It sees that an address paid a stated amount for a stated endpoint at a stated time. Which facilitator handled a given transfer is recorded on the settlement record so the path is auditable rather than opaque.

The router does not run models. Your prompt is forwarded to the upstream tier that serves the model you requested, and that provider processes it under its own terms and its own retention policy. We negotiate for zero-retention handling where a provider offers it and we identify each model’s serving provider in the catalog and in the routing object on every response, so you can always determine who processed a given request.

We do not forward your wallet address, your IP address or any identifier of yours to upstream providers. From the provider’s perspective the traffic comes from us. That is a meaningful privacy property — it is also why provider-side abuse policy applies to the router in aggregate, and why we enforce acceptable use as described in the terms of service.

The one durable identifier in this system is the address that signs a payment. It is a pseudonym, not an identity: it is not linked by us to a name, a jurisdiction or an instrument, and we do not attempt to deanonymize it.

It is not, however, anonymous. An address that pays for many requests over time accumulates a public spending history, and anyone who separately learns who controls that address can read that history. If unlinkability matters to your use case, use a distinct signer per agent and rotate it per period.

Every metered request settles as a transfer of USDG on Robinhood Chain. The payer address, the payee address, the amount, the timestamp, the transaction hash and the resource identifier are written to a public ledger and are readable by anyone, forever, with no involvement from us.

Nothing about the content of your request is written onchain: not the prompt, not the completion, not the conversation, and in most cases not the specific model. What is permanent is the fact and shape of a payment.

This cannot be undone. A blockchain record cannot be edited, redacted or deleted on request — not by you, not by us, not by a regulator instructing us. We would rather you understood that before your first paid request than after it.

Deletion requests are usually about an account record. We hold none, so there is nothing to delete on our side. Concretely, the way to remove each category of data is:

Conversations and app state — clear your browser storage, or use the delete action in the app. Immediate and complete. Prompt and completion content — already not retained by us; ask the upstream provider about theirs. IP-derived abuse logs — expire automatically within 30 days. Onchain settlement records — cannot be deleted by anyone, for the reasons in clause 9. Stop using an address and it stops accumulating history, but its past remains public.

We do not sell, rent or share data, because the data that would be worth selling does not exist here. If we receive a valid legal demand, we can only produce what we hold: aggregate operational metrics, and short-lived abuse logs if the demand arrives inside the retention window. We cannot produce conversations, prompts, completions, account records or identity information, and we will say so.

Settlement records do not require legal process to obtain from us at all. They are already public on Robinhood Chain.

Requests are served from infrastructure in multiple regions and routed to providers in multiple regions, so a request may be processed outside the country it originated in. We do not impose geographic restrictions on who may use the router; upstream providers may impose their own on specific models, and the router routes around such a restriction where an alternative provider exists.

The service is not directed at children and is not designed for use by anyone under the age at which they can lawfully enter into the terms of service in their jurisdiction. Because we operate no accounts, we have no age-verification mechanism and no way to identify a minor’s traffic — a limitation we state rather than obscure.

Material changes to this policy will be published on this page with a revised effective date, and — because there is no mailing list to notify — announced on the blog and in the release notes. This version is effective 1 August 2026.

Privacy questions, including requests for detail about a specific settled transaction, go to the contact channel listed in the site footer. Please do not include prompts, completions or private keys in the message.