sotta — Privacy Policy

Effective date: 2026-10-08.

This policy covers the Sotta Chrome extension, its reader account and payment services at app.sotta.app, Sotta code on approved publisher pages, and the optional beta waitlist at sotta.app.

1. Who we are and the beta’s single purpose

Sotta is published by Rhexia Labs, Inc. The extension’s single purpose is paying for clean editions on approved publishers.

This invite-only beta uses promotional credits on the Base Sepolia test network. Adding the user’s own funds is disabled. The Chrome release does not include cookie-consent automation, Global Privacy Control, personalized advertising, or a general-purpose browsing-history feature.

2. Information handled by the extension

2.1 Information stored in Chrome

The extension stores the following information in chrome.storage.local:

• global and approved-publisher payment choices and spending ceilings;
• the current daily-spend ledger and all-time committed-spend total;
• promotional-credit and payment-availability state;
• non-secret metadata for an active, origin-scoped 24-hour pass;
• a random per-install identifier;
• the signed approved-publisher registry, its rollback-protection state, and pending rule removals; and
• the selected wallet-provider state needed to reconnect to the reader’s account.

An active pass credential may also be kept in chrome.storage.session as a same-browser-session fallback. It is available only to the extension’s background payment flow and is removed when invalid or expired, or when the browser session ends. The release extension does not store an extractable wallet private key.

At install, the extension’s required host access is limited to Sotta’s own service at edge.sotta.app. Access to a publisher website is optional: Chrome asks the reader to allow it, one approved site at a time, when the reader enables that publisher. Even with that access, the release dynamically registers Sotta code only for origins that are both in Sotta’s signed approved-publisher registry and allowed by the reader. Missing, invalid, expired, rolled-back, or revoked registry data, or removal of the reader’s site access, disables payment behavior on that site and removes Sotta’s registered page code.

2.2 Account authentication and wallet information

The reader sets up or signs in to a passkey-backed account on app.sotta.app. Privy provides passkey and optional email one-time-code authentication and an embedded wallet. If the email option is used, Privy receives the email address and authentication-code interaction. Sotta’s first-party app verifies the Privy session and handles provider user/session identifiers, authentication status, and the wallet address needed for the payment feature.

The extension receives the wallet address and signing result through a first-party app.sotta.app bridge. The extension does not receive the reader’s passkey, password, email one-time code, or extractable wallet key.

2.3 Payment and 24-hour-pass information

For a purchase, the extension and participating publisher handle:

• the approved publisher, origin, and requested clean-edition resource;
• payer and recipient wallet addresses;
• the exact amount, asset contract, Base Sepolia network and chain ID;
• token name/version, authorization validity window, and random nonce;
• the EIP-3009 signature and settlement result; and
• pass ID, publisher ID, origin, purchase/expiry time, settlement reference, and transaction hash when available.

The extension independently checks the publisher’s signed configuration and shows an extension-owned confirmation before requesting one exact, single-use payment signature. Per-site ceilings and the daily cap are enforced by the app; this beta does not claim that an on-chain session key enforces them. Sotta does not hold the reader’s funds.

The participating publisher and its selected x402 facilitator receive the signed payment authorization to verify and settle it. The resulting Base Sepolia transaction is public and cannot be deleted by Sotta.

2.4 Promotional-credit information

To request promotional testnet credit, the extension sends the wallet/payout address, timestamp, random nonce, request signature, and a SHA-256 device fingerprint. The fingerprint is calculated on the device from user agent, time zone, language, and dimensions available to the extension service worker. Sotta stores the fingerprint hash, not those raw inputs.

The credit service adds the server-observed IPv4 /24 or IPv6 /48 subnet and stores grant, replay-prevention, payout, raw signed transaction, transaction-result, and reconciliation records. Sotta does not retain the raw IP address in this ledger. The request signature is verified but is not stored.

3. Activity on approved publisher pages

The extension handles only the origin and resource information needed for the clean-edition feature on an approved publisher. It does not build a log of the reader’s activity on unrelated websites.

On a page carrying the publisher’s Sotta SDK, the publisher service records:

• publisher ID and normalized path without query string or fragment;
• a first-party random visitor identifier;
• page view and dwell duration;
• clean-edition prompt, choice, payment, and delivery events; and
• a salted 128-bit HMAC of the server-observed IP and an IPv4 /24 or IPv6 /48 subnet added by the Sotta service.

The publisher service uses those records for clean-edition operation, publisher reporting, product reliability, and abuse prevention. It does not put the raw IP, query string, fragment, page body, form fields, mouse position, or keystrokes in the publisher-measurement database.

The extension and connected publisher service process the requested protected resource and returned clean edition to provide the feature. Page bodies are not placed in Sotta product analytics or used to create an advertising profile.

4. Product analytics

The Chrome reader flow can produce the following schema-filtered events:

Unknown event names and properties are rejected or removed by the Sotta edge relay. Extension-private events use the raw random install identifier as their analytics identifier, so that identifier leaves the device and is sent to Sotta and PostHog. Events correlated with an approved publisher use an origin-scoped HMAC-derived identifier so different publishers receive unrelated identifiers.

Before or without an extension identity handshake, the publisher SDK uses a random anon- identifier that exists only in the current page’s window memory. It can be sent to Sotta and PostHog for an event from that page but is not written to browser storage.

The relay accepts only the documented event fields, does not add the request IP to product-event properties, and sends $ip: 0 to PostHog. No PostHog browser SDK or session-replay recorder runs on approved publisher pages or sotta.app. The separate publisher-page measurement described in section 3 does retain an IP HMAC and coarse subnet.

5. Optional beta waitlist

If a visitor submits the optional form at sotta.app, Sotta stores the normalized email address, submission time, and source in Cloudflare D1 only to send beta-access information. Cloudflare KV receives salted coarse-network rate-limit counters, never the email address.

The waitlist is separate from extension analytics. A subscriber can remove their address at any time from sotta.app/delete-my-data (see section 8), or ask at m@sotta.app; Sotta targets completion within seven days after a verified user-specific request. The waitlist table is not subject to a post-invitation bulk deletion clock.

6. How we use information

Sotta uses the information described above only to:

• authenticate the reader and connect the passkey-backed wallet;
• verify an approved publisher and deliver the requested clean edition;
• authorize, settle, and reconcile exact testnet payments and promotional credits;
• enforce reader choices, caps, replay protection, and fraud/abuse controls;
• provide publisher reporting and reader support; and
• measure and improve the reliability and performance of the single-purpose Chrome feature.

Sotta does not sell user data. It does not use or transfer it for personalized advertising, data-broker activity, unrelated purposes, creditworthiness, or lending.

7. Who receives information

• Rhexia Labs, Inc. / Sotta operates the extension, account bridge, edge relay, payment checks, promotional-credit service, and publisher reporting.
• Cloudflare hosts sotta.app, the Sotta edge services, D1/KV data, and network delivery. Cloudflare may process connection information, including IP addresses, as the infrastructure provider.
• Privy provides passkey and optional email authentication, session handling, and the embedded wallet.
• PostHog receives schema-filtered product events from Sotta’s server-side relay. It does not receive Sotta page-measurement rows.
• Coinbase Developer Platform signs promotional-credit treasury transactions. It receives the treasury address and an unsigned testnet transaction containing the token, payout address, and amount.
• The configured Base Sepolia RPC providers and public Base Sepolia network receive public addresses, transaction data, fee/nonce/balance queries, and transaction receipts needed for testnet payments and credits.
• Approved publishers receive the requested resource information and signed payment payload for their own clean edition.
• The publisher-selected x402 facilitator receives the signed payment payload needed to verify and settle it.

Sotta may also disclose information when required by law, to protect users or the service from fraud or security threats, or as part of a corporate transaction with the consent required by the Chrome Web Store Limited Use rules.

8. Retention and deletion

• Extension-local rules and identifiers remain until changed or removed, Chrome storage is cleared, or the extension is uninstalled. Expired or malformed pass state is removed during normalization; the credential fallback ends with the browser session at the latest.
• Approved-publisher SDK state remains in that publisher origin’s local storage until it is cleared. A pending install-referral record is removed after conversion or after its 30-day window is found to have expired.
• The waitlist follows the seven-day verified-request target in section 5. It is retained until request and is not deleted automatically after invitations are sent.
• Product analytics events sent to PostHog are kept under the one-year event-retention window of Sotta’s PostHog plan. Events older than that window are no longer available to Sotta; PostHog controls whether and when it erases them from its storage.
• Publisher-page rollups are retained for 180 days. The Sotta-controlled page-rollup database deletes rows daily once they are older than that period.
• Finalized 24-hour-pass records are retained for 12 calendar months after settlement or failed finalization. A pending pass claim remains only until it is finalized, after which the 12-month period starts.
• Durable settlement ledger rows are retained as financial/audit and replay evidence and are not part of the 12-month Chrome retention cleanup. A verified deletion request may require delinking rather than deleting that evidence, subject to the limitations below.
• Finalized promotional-credit records are retained for 12 calendar months after payout finalization. Pending, signed, or broadcast rows remain until finalization when needed for replay protection and byte-identical settlement recovery; the 12-month period then starts.
• A verified deletion request may result in earlier deletion or de-identification, subject to fraud, security, legal, dispute, active settlement, and public-ledger limitations.
• Public Base Sepolia transaction records are outside Sotta’s control and are not erasable by Sotta.

To delete the data Sotta holds for an email address, enter it at sotta.app/delete-my-data. Sotta emails that address a link that works once and expires after 30 minutes; opening it and confirming is the verification. Sotta then deletes the address from the waitlist, publisher console sign-in records and invitations, and any extension feedback sent with that address as its contact, and emails a note listing what was deleted, what was delinked, and what stays on-chain. A similar single-use link, valid for 30 days, may appear at the foot of email Sotta already sends you (such as a publisher console sign-in code). A publisher account is closed by a person rather than automatically, and a legal hold can pause a request; either way Sotta targets a response within 30 days.

For a wallet or other identifier, or to request access or correction, email m@sotta.app. Sotta may ask for information needed to verify control of the wallet, install, or other identifier in scope, such as a message signed with the wallet. Sotta does not promise that one identifier can be automatically matched across every processor.

9. Security and human access

Sotta transmits user data over HTTPS. Payment signatures are exact, single-use, and short-lived. Registry signatures, origin checks, schema filters, and replay protections limit the release paths that can handle the information described here.

Humans do not read user data except with the user’s specific consent for support, when necessary for security or abuse investigation, when required by law, or when using aggregated and anonymized information for internal operations.

10. Chrome Web Store Limited Use

Sotta’s use of information received from Google APIs adheres to the Chrome Web Store User Data Policy, including the Limited Use requirements. Sotta uses and transfers that information only as necessary to provide or improve the extension’s disclosed single purpose, for security, to comply with law, or in the other limited circumstances allowed by that policy.

11. Contact and changes

Questions, privacy requests, or security concerns: m@sotta.app.

If the extension’s data practices change, Sotta will update this policy and the in-product or store disclosures before the new practice begins, obtain any required consent, and update the effective date.

Appendix A — Chrome Web Store data-use mapping candidate

This is a preparation map, not a submitted certification. The authorized publisher must confirm it against the exact uploaded artifact.

Candidate certifications: no sale, no personalized advertising, no unrelated use, no creditworthiness/lending use, and Limited Use compliance.