1. Who we are and what this policy covers
Katara Labs, Inc. is a Delaware corporation with a mailing address in Las Vegas, Nevada. In this policy, “Katara,” “we,” and “us” mean Katara Labs, Inc.
This policy covers personal information handled by Katara in operating katara.com, chat.katara.com, docs.katara.com, Katara Cortex, our API, x402 access, and our compute provider interfaces when they link to this policy. It also covers information you send us when requesting help.
Katara Cortex routes inference requests to compute providers. An application built by someone else, a wallet service, or a model provider may handle information under its own privacy notice. Our responsibility for processing we control is not removed by using a third party.
2. Router processing and content retention
During ordinary inference routing, the Katara Cortex router processes prompts, chat messages, code, and model responses without retaining their content after the request completes. Temporary incident capture is an exception, with a maximum retention period of seven days.
The gateway receives readable request content, forwards it to the compute provider performing inference, and relays the response. Encrypted transport does not prevent the gateway or the serving provider from reading content needed to process the request. In-flight handling can include waiting for payment, retries, and streaming a response.
The router does not maintain a routine conversation archive. We generally cannot retrieve past prompts or responses from ordinary router processing. Incident captures, saved chat history, and managed fallback have the separate handling described below.
The Katara chat application separately saves conversation history to your account. Router processing, account storage, provider processing, operational records, and public blockchain transactions each have different data practices.
3. Temporary incident capture
Incident capture is off by default. A founder or security lead may authorize temporary capture of inference content, including prompts and model responses, for a specific service or security incident. Capture is limited to the scope needed for that investigation. This is an exception to ordinary router processing without content retention.
Only engineers assigned to the incident may access captured content, and that access is logged. We notify affected users promptly unless a lawful security reason requires delaying notice; any delay is limited to the period that reason applies.
Captured inference content is automatically deleted within seven days of capture, including copies. Incident captures are excluded from longer-lived backups. The purpose of this capture is incident investigation. It does not create a general chat-history feature or permission to sell the captured content or use it for model training.
The seven-day limit applies to Katara’s incident captures. It does not describe the retention period for saved account conversations, operational metadata, or information handled by a managed fallback vendor.
4. Saved chat history and account content
When you use chat.katara.com, the chat application saves conversations and messages, including your inputs and the model’s replies, in the Katara account database so you can return to them. This application storage is separate from the transient handling of the same request by the inference router.
Chat data can include conversation titles, message content, model selections, timestamps, and associated usage information. Enabled features can also store settings, saved prompts, agents, projects, and files you choose to upload.
Saved conversations remain until you delete them or close your account. Deleted chat content is removed from active systems within seven days and from backups within 30 days of deletion. These deadlines also cover associated uploaded files when they are no longer part of another conversation or feature you have chosen to keep.
Temporary chats are retained for up to 24 hours from creation, then automatically deleted. They are excluded from backups that would extend that period. Temporary chat does not mean the request is never stored or that a serving provider cannot read it.
You can use the chat application’s conversation-deletion controls or contact [email protected] about access or deletion. Archiving or hiding a conversation is not the same as deleting it. Separate incident captures, operational records, and managed fallback processing follow the relevant sections of this policy.
5. Account, service, and contact information
Chat users and compute providers have accounts. We process the account and access information needed to provide those features. Billing is settled onchain in USDC; account or usage information used to display and administer a payment remains distinct from the public transaction itself.
- Account and access information: information used to identify an account or administer access, such as an email address, account identifier, wallet address, or credential identifier, if collected.
- Agreement and eligibility records: the terms version accepted, acceptance timestamp, and associated account or wallet reference, together with age-eligibility and guardian-acceptance records where applicable. We use a neutral age screen and do not collect identity documents by default.
- Usage, verification, and payment records: request, job, and receipt identifiers; cryptographic commitments (hashes); model and provider identifiers; token counts; timing; prices; and settlement information, where retained. These records support request verification, metering, and payment. Some commitments are derived from request or response content; they are not readable copies of that content and should not be treated as automatically anonymous.
- Security and connection records: information generated when connecting to the service, such as an IP address, device or browser information, response status, and security events, if logged.
- Correspondence and provider administration: information you separately give us for support, privacy requests, or provider participation.
Do not send private keys, recovery phrases, or unneeded inference content in a support request. Content voluntarily sent to support is a separate submission, not a copy retrieved from the router.
6. Why information is processed
Inference content is processed to fulfill your request, and account chat history is saved so you can manage and return to conversations. Temporary content capture supports incident investigation. Operational information, where collected, is used to administer access, match requests to providers, measure usage, calculate and settle charges, protect the service, investigate payment or security issues, respond to you, and meet applicable recordkeeping obligations. Google Analytics helps us understand use of our public marketing and documentation pages.
Katara does not sell personal information, use it for behavioral advertising, or train models on your content. We improve the service using aggregate operational metrics and feedback you explicitly submit. Submitting feedback does not give Katara permission to use your content for model training.
Marketing emails are optional and include an easy way to unsubscribe. Declining marketing does not prevent service, account, security, or legally required communications. Marketing choices, analytics choices, and acceptance of the Terms of Use are separate.
Any use of personal information for a separate purpose must be explained before that use and supported by an appropriate legal basis.
7. Compute providers and connected applications
The selected independent compute provider receives readable request content. This can include messages, conversation history, tool definitions, tool results, and other fields included in your request. Retries and later turns can send the included context to a different provider.
The router does not forward your authentication headers or client-IP headers to an independent provider. This does not make the payload anonymous: names, identifiers, document contents, or other personal details included in the request remain visible.
Independent inference providers must accept obligations prohibiting retention of prompts and outputs, model training on that content, inspection beyond execution needs, and content in persistent logs. We record provider acceptance. The router’s temporary incident-capture exception does not give independent providers permission to keep their own content copies.
Providers must report incidents affecting Katara traffic without undue delay and within 24 hours of discovery. Katara may immediately suspend routing to a provider when content misuse is suspected, investigate the matter, and provide a way to dispute the decision.
Validation does not prove that a provider deleted your content. Validators use synthetic test requests and check service behavior, receipts, token accounting, availability, and timing. Customer prompts and responses are not sent to validators for these tests. A provider operator can still inspect or copy content on its host; the current request path does not use an attested confidential-computing boundary that hides the content from that operator.
When you use an application, agent, tool, or wallet supplied by someone else, its operator may receive information directly from you or from the workflow you authorize. Review its notices and permissions. In particular, an agent you configure may send information to other agents and tools.
8. Managed fallback providers
Managed fallback is enabled for supported models. When an eligible request cannot be served by the independent provider network, it can be sent to a managed fallback provider. We use multiple fallback providers, including DeepSeek.
Katara selects fallback providers at its discretion and may add, remove, or replace them at any time. We do not guarantee a particular provider or a fixed provider list. Provider changes remain subject to our privacy commitments and any notice, consent, or other requirements imposed by applicable law or a separate agreement.
A fallback provider receives the inference payload needed to answer your request, which may include conversation history and tool content. Identifying details you include in that payload remain visible to the recipient. Processing locations, retention periods, and permitted data uses, including model improvement or training, can differ by provider and the API agreements and settings applicable to Katara’s traffic. The independent-provider no-storage requirement does not establish a no-retention commitment by managed fallback vendors.
For example, requests routed through the DeepSeek API are processed by Hangzhou DeepSeek Artificial Intelligence Co., Ltd. DeepSeek’s published policy states that it processes and stores personal data in the People’s Republic of China. See its Privacy Policy and Terms of Use for its published practices.
Katara has opted out of DeepSeek using its production API traffic for model training. This statement is specific to DeepSeek and does not describe every fallback provider’s terms or settings. A training opt-out does not establish zero retention. We do not promise a uniform retention period or training policy across all fallback providers.
We require no-training terms or a verified training opt-out wherever available, and disclose exceptions before affected use. Our provider directory is maintained separately from these terms so recipient and processing details can be kept current. Contact [email protected] for the current directory or information about a particular route.
Where a business data-processing agreement requires advance notice of subprocessor changes or an opportunity to object, we follow that agreement. Our discretion to select providers does not remove those obligations.
9. USDC and public blockchain records
Payments for Katara Cortex are made in USDC and settled onchain. Depending on the payment path, public records can expose buyer and provider wallet addresses, settlement amounts, transaction identifiers, timing, and job-ticket hashes. A wallet address can become associated with a person even if it does not contain a name.
Settlement uses payment and verification records rather than publishing readable prompts or outputs. Job-ticket hashes can indirectly commit to request-derived data, and offchain protocol records also contain content-derived commitments. A hash is not a readable copy of a message, but hashing alone does not guarantee anonymity.
Blockchain records may remain available indefinitely and may be copied by people and services outside Katara’s control. Katara cannot erase or change records already committed to a public blockchain. Deleting a Katara account does not delete those records.
Do not include prompts, code, personal details, or confidential information in transaction memos or other public transaction fields.
11. Disclosures and service providers
We transmit inference content to the independent provider or managed fallback vendor fulfilling a request and send public-site analytics information to Google Analytics. Service information may also need to be disclosed to vendors performing the corresponding authentication, hosting, payment, support, or security function.
Information we hold may also need to be disclosed in response to a valid legal requirement or to address fraud, a security incident, or a legal claim, subject to applicable law. A legal request does not make historical inference content available if we never retained it.
If a corporate transaction involves personal information we hold, its handling remains subject to applicable law and the commitments governing that information. We will provide notice or obtain consent when required.
12. Retention and security
Ordinary router processing does not retain inference content after a request completes. Temporary incident captures are deleted within seven days. Chat history is stored separately by the account application, and managed fallback vendors have separate data practices. Public blockchain records have the separate characteristics described above.
- Saved conversations and account content: retained until deletion or account closure, then removed from active systems within seven days and backups within 30 days of deletion.
- Temporary chats: deleted within 24 hours of creation, without longer-lived backup copies.
- Incident content: deleted within seven days of capture, including copies, and excluded from longer-lived backups.
- Routine request metadata: retained for up to 30 days after the request.
- Security logs: retained for up to 90 days after the event.
- Support tickets: retained for up to 12 months after the ticket is closed.
- Account information: retained while the account exists. On closure, ordinary account information follows the seven-day active-system and 30-day backup deletion periods, subject to the separate recordkeeping purposes below.
- GA4 user-level and event-level data: the two-month retention setting applies as described in the analytics section; standard aggregated reports are separate.
Necessary financial, tax, accounting, and agreement records follow separate schedules based on applicable recordkeeping requirements and the period needed to establish or defend legal rights. We limit those records to their purpose; retaining them does not authorize a routine archive of inference content or extend the incident-capture limit. Public blockchain records cannot be deleted by Katara, and managed fallback vendors follow their separately disclosed practices.
We require administrator multi-factor authentication, access limited to authorized personnel who need it, encryption in transit and at rest for retained personal information under Katara’s control, and access logs. We assign responsibility for privacy requests and technical incidents. No system can promise absolute security. Protect your account credentials, wallet, and devices, and contact us about suspected unauthorized access.
13. Your requests and regional rights
Email [email protected] or write to the mailing address below about personal information we hold. Depending on the law applicable to you and the processing involved, you may have rights to access, correct, delete, or receive a copy of information, restrict or object to processing, withdraw consent, or opt out of certain uses. Applicable law may also provide an appeal or a right to complain to a regulator.
Our privacy contact is monitored daily. We aim to acknowledge requests within two business days and respond substantively within the applicable legal deadline. Acknowledgement is not the same as completing a request.
We will verify requests proportionately, explain any lawful exception, and respond within the applicable legal deadline. Where the law permits, an authorized representative may act for you. We will not penalize you for exercising a protected privacy right.
We cannot retrieve content that was never retained or has already been deleted, and we cannot delete public blockchain records. These limits do not remove rights concerning saved chat history, incident captures, or other information Katara actually holds.
14. Processing locations and international transfers
Katara is a U.S. company, and independent and managed fallback providers may process information in other countries. Those locations can change as providers change. DeepSeek fallback involves processing in the People’s Republic of China as described above. A provider’s processing location can affect which laws protect information. International processing must follow the safeguards required by the laws that apply to the particular transfer.
15. Age eligibility
The Services are not intended for children under 13 or below a higher minimum age required by applicable local law. Users who are eligible but under 18 need permission from a parent or legal guardian under the Terms of Use.
If you believe someone below the applicable minimum age has provided personal information to Katara, contact [email protected] so we can investigate and take the steps required by law, including deletion where required.
16. Updates and contact
Revisions to this policy will carry an updated effective date. For ordinary material changes, we provide at least 30 days’ advance notice through the relevant service or available account contact channel. A faster change may be necessary to comply with law or address an urgent security issue; we provide notice as soon as reasonably possible in those cases. We obtain consent where required before using information in a materially different way.
For privacy correspondence, email [email protected] or write to Katara Labs, Inc., Attention: Privacy:
Katara Labs, Inc.1930 Village Center Cir 3-9815
Las Vegas, NV 89134
United States
[email protected]
This is our mailing address. Katara Labs, Inc. is incorporated in Delaware.