For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

Was this helpful?