Privacy Policy
Last updated: June 2026
Policy Summary
Pharos does not ask for accounts or wallet connections. Portfolio data is stored locally by default, share links encode holdings in the URL, analytics are anonymized when enabled, and support or API-access requests route through the feedback/contact channels listed below. The homepage discovery module and Stablecoin Picker use functional browser storage, and Picker share snapshots are described below.
What We Collect
When a Google Analytics 4 (GA4) measurement ID is configured for the current deployment, Pharos collects anonymized usage analytics such as page views, session duration, approximate geographic region, device or browser type, and a small set of product-interaction events. If you choose to share a Telegram or X handle in the feedback form, that handle is included in the GitHub issue created for the submission. Telegram alert subscriptions store chat ID, optional username, followed coins, alert settings, quiet hours, snooze state, and short-lived pending-command or pending-alert metadata; subscriber rows with no follows or pending state and no Telegram activity for 180 days are automatically purged by a weekly cleanup job. If you request API access, Pharos stores the email address you verify plus any name, organization, project URL, use-case, intended-endpoint, cadence, and volume details you submit; request throttling stores salted hashes of IP address and user-agent data. The homepage page discovery module stores a local rotation cursor for the suggested internal pages. The Stablecoin Picker stores local browser state for callout dismissal and tab-scoped result recovery, and share links can store a content-addressed snapshot of the generated selector output in Cloudflare KV.
Functional Browser Storage
The homepage page discovery module uses localStorage to store a small rotation cursor under pharos.homepageDiscovery.v1. It is only used to show a different five-route suggestion set between homepage visits. It does not contain route history, account identifiers, wallet addresses, IP addresses, or a browser fingerprint.
Stablecoin Picker Storage
The Picker at /screener/picker/ uses functional browser storage. The long-lived local key in the current build is the callout dismissal key, pharos.selector.callout.v1. It is scoped to this site, does not contain an IP address or user identifier, and remains until you clear browser site data. A tab-scoped sessionStorage key, pharos.selector.sessionResult.v1, can hold the last successful live result for accidental navigation recovery and clears when the browser session ends.
Picker share links use a sid that points to a Cloudflare Pages KV snapshot of the form answers and resulting output. Snapshot IDs are content-addressed, so identical answers against an identical dataset produce the same ID. Anyone with the link can view the frozen artifact. Snapshots do not include IP addresses, browser fingerprints, or account identifiers, and are retained for five years.
Telegram Data and Retention
PharosWatchBot stores only what is required to deliver alerts and keep the bot reliable. The full list of Telegram-owned tables and how long each one is retained:
- Subscribers (chat ID, optional username, default alert flags, quiet hours, snooze state, last-active timestamp): auto-purged after 180 days of inactivity once no follows or pending state remain.
- Per-coin and preset subscriptions: kept while the subscriber exists, cleared by
/unsubscribe allor the inactivity prune. - Pending disambiguation (ambiguous ticker prompts, setup wizard state, bulk-action confirmations): 5-minute TTL.
- Pending alerts (overflow and retry queue for delivery): 1-hour TTL for depeg, DEWS, and safety; 30-minute TTL for launch and admin broadcasts.
- Alert job manifests and per-target audit: 90-day retention.
- Dead-letter audit trail for expired or permanently failed deliveries: 90-day retention.
- Processed-update idempotency claims: 7-day prune.
- Daily usage aggregates: privacy-preserving counters only; no chat ID is stored. 400-day retention.
- Daily watcher lifecycle snapshots: aggregate-only public pulse history.
- Per-chat delivery diagnostics used by
/health: kept while the subscriber exists, with a 90-day stale prune.
For the PharosWatchBot Mini App, the signed Telegram initDatabody is never persisted. It is validated request-locally through Telegram's HMAC signature and freshness window. Mutations use a 5-minute auth window plus a per-user cooldown, while read-only session launches accept a Telegram-signed launch up to 24 hours old so an open panel stays usable across the day.
No Accounts or Wallet Connections
Pharos does not require user accounts, logins, or wallet connections for the website. Optional feedback contact details and self-serve API request emails are self-declared and are not used as site accounts.
Cookies
When analytics is enabled, the only cookies set by Pharos are those required by Google Analytics 4 (e.g., _ga, _ga_*) for distinguishing unique visitors. No advertising or tracking cookies are used.
Data Retention
When GA4 is enabled, analytics data is retained for 14 months per Google's default settings. We do not maintain user-account databases. Feedback submissions are sent to GitHub Issues for product support and issue tracking; optional follow-up contact details are included there when you provide them. The worker stores rate-limit metadata for feedback abuse prevention. A legacy `feedback_submissions` table exists in the D1 schema, but the current submission path does not write to it. Self-serve API key requests are stored for operator review and duplicate-claim enforcement; verification tokens are stored only as hashes and expire after 30 minutes. Issued self-serve API keys expire after 60 days by default. Picker localStorage remains until browser site data is cleared. Picker KV snapshots are retained for five years because they are content-addressed analytical records rather than user-account records.
Third-Party Services
Pharos is hosted on Cloudflare Pages with API endpoints served by Cloudflare Workers. Analytics data is processed by Google (GA4) only when analytics is enabled for the current deployment. Feedback submissions are also forwarded to GitHub Issues for product triage; optional Telegram/X handles are echoed publicly in those GitHub issues. API request verification emails are sent through Resend. API key issuance notifications can create private operator GitHub issues, but those notifications include request ID, key prefix, quota, expiry, and an ops link only, not requester details or plaintext tokens.
Contact
Questions about this policy? Reach out on @PharosWatch or via the About page.