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

# Privacy and identity

Store almost nothing about people. Erase it in one action.

What a person researches hints at what they hold and what they plan to do. LensAI treats research history as sensitive, stores as little as possible, and makes erasure a first-class, one-action path.

## Sign-in

* **Today:** a wallet, proven by an off-chain signature (Sign-In With Ethereum). No transaction, no gas, and no private key ever touches LensAI's servers. Login nonces are single-use and short-lived, and each signature is verified against the address, domain and chain before a session is issued.
* **Next:** email and Google sign-in, so nobody needs a wallet to use a free research product.

Anyone can read the live pulse without signing in. Asking a question requires sign-in, which lets the desk apply fair daily caps and keep free research from being farmed by bots.

## What is stored

| Stored                                             | Why                                                |
| -------------------------------------------------- | -------------------------------------------------- |
| Wallet address                                     | Identity. No name, password or identity documents. |
| Email address or Telegram chat id                  | Only if that alert channel is turned on.           |
| Conversations (scrubbed text, anchor, claim audit) | History. Automatically purged after 90 idle days.  |
| Watches and their trigger log                      | The feature itself.                                |
| Watchlist symbols, timezone, last-seen anchor      | Personalisation and "what changed".                |
| Daily usage counters                               | Fair caps on free usage.                           |
| API key hashes                                     | The key itself is shown once and never stored.     |
| Claim-check submissions                            | Only when the user chooses to save one.            |
| Answer feedback                                    | Calibration.                                       |

**Never stored:** private keys or signing permissions, balances or on-chain activity (the address is never enriched), exchange keys, payment data, IP addresses, ad trackers.

All user data lives in a separate user database, cascades from the account, and is erased with it. Export and erasure are each one action.

## Three boundaries enforced in code

1. **No user identifier ever reaches a model.** User text is scrubbed, and the model router refuses any prompt that still carries a wallet address, an email or a known identifier of that user. Tested.
2. **Nothing derived from a user enters the permanent record.** The corpus, briefs and calls are append-only, so anything placed there could never be erased. Shared briefs and calls are keyed to market state; question-specific answers are never written there.
3. **The session never leaves the website.** The browser receives a short-lived, audience-bound token (15 minutes) for the engine; the session cookie stays on the web origin.

## Security

All secrets live server-side and are never sent to the browser. Requests are rate-limited, inputs are validated, and usage caps are enforced on the server, never in the browser.


---

# 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://docs.scanbylens.xyz/trust/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.