> For the complete documentation index, see [llms.txt](https://docs.theacompute.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.theacompute.com/core-concepts/privacy.md).

# Privacy Model

For me, privacy is how I'm built, not a setting I offer. You won't find a toggle to flip or a policy you have to trust: I'm designed so that no single party, me included, can read what's in your prompts or responses. I keep no logs of your content, and I add no filters. Ask me anything, and it stays yours.

Below is my exact accounting: what I encrypt, what each participant can see, and what the on-chain record really contains.

***

## How I encrypt your prompt

Encryption happens on your end, inside your browser or application, before your prompt goes anywhere at all.

**Scheme:** AES-256-GCM, using a one-time ephemeral session key.

**How each key lives and dies:**

1. Your client generates a fresh ephemeral keypair for every single job.
2. ECDH combines that ephemeral public key with the chosen worker's registered public key to derive a shared secret.
3. Your client uses that shared secret to encrypt the prompt before sending it.
4. My orchestrator delivers the encrypted payload to the worker.
5. The worker pairs its private key with the ephemeral public key from the payload envelope and decrypts, fully in memory.
6. Once the job is over, the ephemeral key gets discarded. I never reuse a key.

**What that means for you:**

* My orchestrator only ever sees an opaque encrypted blob. It has no way to read your prompt.
* My own servers aren't in the encryption path at all. I couldn't read your prompts even if I wanted to.
* The worker's decrypted copy lives only in memory, and only while inference is running. Nothing gets written to a file.
* If someone compromises a worker after your job is done, they get nothing, because the session key is already gone.

***

## Your responses are protected the same way

The same session key encrypts the response stream while it travels. Tokens go from the worker, through my orchestrator, to your client, which decrypts and shows them to you.

Nobody keeps the response. Workers never write outputs to disk, and my orchestrators pass the stream along without buffering it. The one thing that survives is the SHA-256 hash of the output, which the worker signs and posts on-chain to prove it finished the job. A hash tells nobody anything about the content.

***

## Who can see what

| Party                            | What they can see                                                                                                           |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| TheaCompute (as an organization) | Nothing. I have no access to what's in your prompt or response.                                                             |
| Orchestrator nodes               | The encrypted payload (opaque bytes), job ID, model tier, and source and destination routing metadata. None of the content. |
| Worker                           | Your decrypted prompt and the response it generates, in memory only, and only for as long as the job runs.                  |
| Other workers                    | Nothing. I send each job only to the worker I picked for it, never broadcast across the mesh.                               |
| Anyone with a block explorer     | Job ID, model tier, unit amount, worker address, timestamp, and proof hash. None of the content.                            |
| You                              | Your own prompts and responses, and nobody else's.                                                                          |

***

## Staying anonymous

To use my web app, you sign up for an account with an email and password. That account stays with the app: the only identity my network ever sees is an Ethereum wallet address. During the beta, there's no KYC anywhere in the flow.

Any wallet can fund units, even one you created a minute ago with no on-chain history at all. If you use a wallet that isn't tied to your real identity, nothing on my network or on-chain connects your usage back to you. Keep in mind that your app account does hold the email you signed up with.

Workers see even less than that. All they get is the encrypted payload; I keep the requesting wallet address and any identifying metadata away from them. My orchestrator sends the response back to you by job ID, not by wallet address.

***

## Exactly what goes on-chain

For each job, the Robinhood Chain transaction record contains:

| Field          | Value                                                            |
| -------------- | ---------------------------------------------------------------- |
| Job ID         | A unique identifier for your job                                 |
| Model tier     | Lite / Standard / Pro / Max                                      |
| Units charged  | How many units (credits, on-chain) were locked and then released |
| Worker address | The Robinhood Chain address that got paid                        |
| Timestamp      | The block number and roughly when it happened                    |
| Proof hash     | The SHA-256 of the output stream                                 |

And it never contains:

* What your prompt said
* What the response said
* Your requesting wallet address (I don't write it on-chain)
* Any metadata about who you are

***

## I don't keep your content in logs

Nowhere in my stack writes logs that include prompt or response content.

* My API servers log request metadata for operational monitoring: model tier, job ID, timestamp, and unit usage. Never the content.
* My orchestrator nodes log routing events: job ID, which worker got picked, and latency. Never the content.
* My workers log completion events: job ID, duration, and the proof hash they submitted. Never the content.
* I don't keep a central inference history anywhere. Once a job is finished, it's gone.

***

## I don't pick sides on models

The closed AI stack decides what you're allowed to ask. I don't: I apply no content filtering at the model level. Every model on my network is open-weight, and it's hosted because some worker chose to host it. My protocol never inspects, scores, or gates your prompts or responses.

Every worker chooses which models it runs, and none of them has to host any particular model. $THEA holders set the recommended list through on-chain votes, not through anybody's content policy.

***

## Where my protections stop

My privacy properties are strong. They still have limits, though, and I want you to know exactly where they are.

**The worker sees your prompt in plaintext.** Inference can't happen otherwise: the worker has to decrypt and process what you sent. My protocol keeps that exposure as small as it can (ephemeral keys, memory-only handling, a no-logging requirement), but one trust assumption is left: that the worker doesn't log your content. A worker that gets caught doing that loses reputation and becomes eligible for slashing.

**What's on-chain stays there forever.** The proof hash, model tier, unit amount, and timestamp are permanent records on Robinhood Chain. Anyone can see that a job of some size and cost ran at some point in time. What that job was about stays hidden.

**I can't protect a compromised client.** If malware reads your browser before encryption happens, no protocol can save you, mine included. Securing your client side is a precondition I have no way to enforce for you.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.theacompute.com/core-concepts/privacy.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.