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

# Privacy Model

RobinMesh treats privacy as something the protocol enforces, not something a product team promises. The architecture is built so that no single party, RobinMesh included, can read the content of your prompts or responses.

Below is a precise accounting: what gets encrypted, what each participant can observe, and what the on-chain record actually holds.

***

## How prompts are encrypted

Encryption happens on your side, in your browser or application, before a prompt goes anywhere.

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

**Key lifecycle:**

1. For every job, your client generates a brand new ephemeral keypair.
2. The ephemeral public key and the selected worker's registered public key derive a shared secret through ECDH.
3. That shared secret encrypts the prompt before transmission.
4. The orchestrator carries the encrypted payload to the worker.
5. The worker combines its private key with the ephemeral public key from the payload envelope to decrypt, entirely in memory.
6. When the job ends, the ephemeral key is thrown away. No key is ever used twice.

**Consequences:**

* To the orchestrator, the payload is an opaque encrypted blob. It has no way to read the prompt.
* RobinMesh's own servers sit outside the encryption path entirely, so RobinMesh cannot read your prompts either.
* The worker's decryption exists only in memory and only while inference runs. Nothing is written to a file.
* A worker compromised after the job finishes yields nothing, because the session key no longer exists.

***

## Responses get the same treatment

The same session key encrypts the response stream in transit. Tokens travel from the worker through the orchestrator to your client, which decrypts and displays them.

Response content is stored by no one. Workers never write outputs to disk, and orchestrators pass the stream through without buffering it. The only artifact that survives is the SHA-256 hash of the output, which the worker signs and posts on-chain as its proof of completion. A hash reveals nothing about the content.

***

## Visibility, party by party

| Party                          | What they see                                                                                              |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------- |
| RobinMesh (as an organization) | Nothing. No access to prompt or response content.                                                          |
| Orchestrator nodes             | Encrypted payload (opaque bytes), job ID, model tier, source and destination routing metadata. No content. |
| Worker                         | Decrypted prompt and generated response, in memory only, for the duration of the job.                      |
| Other workers                  | Nothing. A job goes to its selected worker only, never broadcast to the mesh.                              |
| Anyone with a block explorer   | Job ID, model tier, credit amount, worker address, timestamp, proof hash. No content.                      |
| You                            | Your own prompts and responses. No one else's.                                                             |

***

## Anonymity

The only identity the network ever asks for is an Ethereum wallet address. No email, no phone number, and no KYC anywhere in the flow during the beta.

Any wallet can fund credits, including one generated a minute ago with zero on-chain history. Use a wallet with no tie to your real identity, and RobinMesh has nothing to link your usage to you.

Workers, for their part, receive only the encrypted payload. The requesting wallet address and any identifying metadata are withheld from them; the orchestrator uses the job ID, not the wallet address, to route the response home.

***

## The on-chain record, exactly

Each job's Robinhood Chain transaction record holds:

| Field           | Value                                             |
| --------------- | ------------------------------------------------- |
| Job ID          | A unique identifier for the job                   |
| Model tier      | Lite / Standard / Pro / Max                       |
| Credits charged | The amount locked and released                    |
| Worker address  | The Robinhood Chain address that received payment |
| Timestamp       | The block number and approximate time             |
| Proof hash      | SHA-256 of the output stream                      |

And it never holds:

* Prompt content
* Response content
* The requesting wallet address (not written on-chain)
* Any metadata about who the user is

***

## Nothing retained in logs

No part of the stack writes logs containing prompt or response content.

* API servers record request metadata for operational monitoring: model tier, job ID, timestamp, credit usage. Content is never among it.
* Orchestrator nodes record routing events: job ID, which worker was picked, latency. No content.
* Workers record completion events: job ID, duration, the proof hash they submitted. No content.
* No central inference history exists anywhere. A job is gone when it is done.

***

## Model neutrality

The RobinMesh protocol applies no content filtering at the model level. Every model on the network is open-weight and hosted because a worker chose to host it. Prompts and responses are never inspected, scored, or gated by the protocol.

Each worker decides which models to run; none is obligated to host any particular one. What appears on the recommended list is settled by on-chain votes of $RMESH holders, not by anyone's content policy.

***

## The honest limits

The privacy properties here are strong, but they have edges you should know about.

**Your prompt is plaintext to the worker.** Inference requires it: the worker decrypts and processes what you sent. The protocol shrinks the exposure as far as it can (ephemeral keys, memory-only handling, no logging requirement), yet a trust assumption remains: that the worker does not log your content. A worker caught doing so loses reputation and becomes eligible for slashing.

**Chain data is forever.** The proof hash, model tier, credit amount, and timestamp are permanent entries on Robinhood Chain. Anyone can observe that a job of some size and cost ran at some moment. What the job was about stays invisible.

**A compromised client is out of scope.** Malware that reads your browser before encryption happens defeats any protocol. Securing the client side is a precondition RobinMesh cannot 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.robinmesh.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.