> For the complete documentation index, see [llms.txt](https://assay.gitbook.io/assay-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://assay.gitbook.io/assay-docs/how-it-works/privacy.md).

# Privacy

What goes onchain, what stays with you, and what the host sees.

**Where:** the commits in `sdk/src/commit.ts`, the `anchor` and `cosign` calldata on `ReceiptAnchor`, and the host's store in `host/data/`.

The prompt and the output never go onchain. Only salted hashes do, and only the person holding the salt can open them.

## Where each piece of data lives

| Data                       | Onchain                                                           | Host                                             | You                           |
| -------------------------- | ----------------------------------------------------------------- | ------------------------------------------------ | ----------------------------- |
| Prompt and output text     | Never                                                             | Sees them while serving. Stores only the receipt | Yes                           |
| Salt                       | Never                                                             | Receives it in `X-Assay-Salt`                    | Yes. Keep it                  |
| `req.commit`, `res.commit` | Not directly. Only the receipt hash inside a Merkle root          | In the receipt                                   | In the receipt                |
| Receipt hash               | Only when someone co-signs it (calldata and the `Cosigned` event) | Yes                                              | Yes                           |
| Merkle root and count      | Yes, one per batch                                                | Yes                                              | From `GET /v1/receipts/:hash` |
| Passkey public key         | Its hash in `Cosigned`, `qx` and `qy` in calldata                 | Only if you use the relay                        | Yes                           |
| Host identity and keys     | Yes, public by design                                             | Yes                                              | Yes                           |

## Why the salt matters

Without a salt, a short prompt like "yes" could be found by hashing every likely answer. With a fresh 32-byte salt per request, the commit reveals nothing until you hand over the salt.

## How you reveal one receipt

1. Give the verifier the receipt, the salt, and the output (and the messages, if the prompt matters).
2. They run `verifyReceipt` with `salt`, `output`, `messages` and `params`.
3. `outputCommit` and `promptCommit` pass only if every byte matches.

The web app's Vault can also create a disclosure key for one receipt (`assay:reveal:<receiptHash>`), which opens that entry and nothing else.

## Where else this shows up

| Place                                                | What it does                                                                                  |
| ---------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| [Receipts](/assay-docs/how-it-works/receipts.md)     | The commit formulas                                                                           |
| [Mera](/assay-docs/integrations/mera.md)             | Keeps salts encrypted under your passkey, and gives each app its own unlinkable co-signer key |
| [Threat model](/assay-docs/security/threat-model.md) | What a host or observer can still learn                                                       |

{% hint style="warning" %}
Hosts get no privacy, by design. Requesters can stay private, but a co-signature with the same passkey across apps links that activity through one public key. Use a per-app key if that matters to you.
{% endhint %}

Next: [SDK reference](/assay-docs/for-developers/sdk.md)


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://assay.gitbook.io/assay-docs/how-it-works/privacy.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.