> For the complete documentation index, see [llms.txt](https://thesium.gitbook.io/thesium-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://thesium.gitbook.io/thesium-docs/transparency/privacy.md). # Privacy The privacy posture is stated explicitly because it is a structural property of the product, not a marketing claim. ## What the extension does not require * **No wallet connect.** The product is fully usable without ever connecting a wallet, signing a message, or providing any wallet address. * **No personal information.** Beyond the email and password used to create the account, the extension does not ask for and does not transmit any user identity. * **No phone, no KYC.** Email + password is the whole sign-up. ## What the backend sees per data request For each data request, the backend sees: * The token address being looked up. * The chain. * Optionally, the pool address when the URL surfaced one. * The access token attached to the request. * The IP address of the request (unavoidable property of HTTPS). The backend does **not** see: * The URL the user is on. * The browser tab the user has open. * Other tokens the user has looked at recently (the snapshot cache is local-only). * The user's other browsing activity. ## What the backend stores about the account * Email (used as the login identifier and for security communications only). * Password hash (memory-hard, salted; the plaintext password is never persisted). * Active session records (refresh-token hash, IP, user-agent, timestamps) so that "sign out everywhere" works and so anomalous sessions can be revoked. The backend does **not** store a per-user history of which tokens a user has looked up. Address queries are processed as independent lookups. There is no per-user research-history product, and there is nothing to sell. ## Account security * **Passwords are never stored in plaintext.** They are hashed at sign-up time with a memory-hard, salted algorithm and only the hash is persisted. A database breach does not yield usable passwords. * **Refresh tokens are single-use.** Every refresh issues a new refresh token and invalidates the old one. Replaying a previously-rotated token revokes the entire session, defending against token-theft replay. * **Sign out everywhere.** A single action revokes every active session for the account in one call - useful if a device is lost or a session is suspected of being compromised. * **Rate limits.** Sign-in and sign-up are rate-limited per IP, and sign-in additionally per email, to make credential-stuffing and account-spam expensive without inconveniencing real users who occasionally fumble a password. * **Session restoration is transparent.** Access tokens are short-lived and refreshed silently in the background; the user does not need to re-sign-in unless their session is genuinely invalid. ## Transport security * All backend traffic is HTTPS with TLS. The extension does not accept self-signed certificates or fall back to plaintext. * The production backend host is fixed at build time and not modifiable at runtime by user input or page content. * Auth tokens are transmitted only as `Authorization: Bearer` headers. They are never exposed to the host page, the content script, or any third party. ## What runs on the user's machine The extension stores in `chrome.storage.local`: * **Snapshot cache** - up to 200 token snapshots, the user's recently-viewed tokens. Local-only, never transmitted. * **Recently-viewed list** - per-terminal list of tokens the user has researched. Local-only. * **Auth session** - access and refresh tokens for the current account. Local-only. * **Settings** - user preferences. Local-only. This data is scoped to the Chrome profile and is removed when the extension is uninstalled or the profile is reset. ## What the extension does not do, explicitly * It does not ask for a seed phrase. No legitimate Chrome extension ever should. * It does not request transaction signatures for verification. The phrase "sign this transaction to verify" is the universal red flag of a wallet-drainer; Thesium will never trigger it. * It does not run third-party analytics SDKs. No Google Analytics, no Mixpanel, no fingerprinting libraries inside the extension surface. * It does not read the user's browser history. It has no history permission and never will. * It does not interact with wallets. No `eth_requestAccounts`, no Solana wallet adapter, no signature requests. * It does not submit transactions on behalf of the user, execute trades, or store private keys or wallet addresses associated with the user. The extension is read-only with respect to the user's wallet state and on-chain identity. It is, by design, incapable of moving funds. ## Content rendered safely The extension does not execute, evaluate, or interpret content read from terminal pages or from backend responses. Token names, symbols, lore text, AI summaries, KOL handles, post bodies - all are treated as untrusted strings, rendered into the DOM via React's safe-by-default text nodes. Never via `dangerouslySetInnerHTML`, never via `eval`, never via string-to-element construction. The content script runs in Chrome's isolated content-script world. Variables defined by the content script are not accessible to the host page's JavaScript, and vice versa. When the in-page card is rendered, it is mounted into a closed Shadow DOM root attached to the page body, isolating its styles and DOM from the host page. ## Permissions, justified The MV3 manifest declares five permissions. Each has a specific purpose: | Permission | Why it is needed | | ----------- | --------------------------------------------------------------------------------- | | `storage` | Persist snapshot cache, recents, auth session, settings between browser restarts. | | `activeTab` | Read the URL of the currently active tab to identify token pages. | | `tabs` | Detect navigation events across tabs. | | `alarms` | Run the polling loop reliably across service-worker shutdowns. | | `sidePanel` | Open and manage Chrome's native side panel. | Host permissions are scoped to the five supported terminal domains plus the Thesium backend. The extension does not request access to arbitrary websites. --- # 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://thesium.gitbook.io/thesium-docs/transparency/privacy.md?ask=&goal= ``` `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.