Privacy Policy.

Overview & Posture

This Privacy Policy describes how Synthetics Inc (“Azal”, “we”, “us”) collects, uses, retains, discloses, and protects information when you interact with azal.ai, the trading terminal at /intelligence, the Discord bot, the Telegram bot, the public API, or any other surface operated by us.

We operate the platform with a high-collection posture by design. The trading surface routes real money to upstream venues, attracts coordinated abuse (wash-trade rings, scraper farms, sanction-evasion attempts), and is subject to financial-services regulatory scrutiny. To operate it safely and to investigate incidents, we record a detailed log of every request, including from unauthenticated visitors. This document tells you exactly what is recorded, why, where it goes, and how long it lives.

By accessing the service you accept the collection described in this policy. The consent modal you saw on first visit (azal:consent:v1 localStorage key) is your acknowledgement that you have read — or had the opportunity to read — the disclosures below.

What We Collect On Arrival (No Authentication Required)

The moment your browser opens a connection to any Azal surface — the public landing, a legal page, /intelligence, an API endpoint — we record the following without requiring any login:

• Network identifiers. Your IP address (IPv4 or IPv6), the X-Forwarded-For and X-Real-IP headers if present, and the IP’s reverse DNS (when resolvable).
• Approximate geolocation. Derived from your IP via Vercel’s edge geo header (request.geo): country, region / state, city, and approximate latitude / longitude (city-centroid precision).
• Network metadata. ASN, hosting provider, and whether the IP is on known datacenter, VPN, Tor exit, or scraping infrastructure ranges (used for bot detection per lib/admin/botDetection.ts).
• Request metadata. Every HTTP request method, path, status code, response time, Referer, and a UTC timestamp.
• User-Agent string (truncated to 512 characters), including browser family, version, rendering engine, operating system, and any client hints exposed by the browser.
• Device fingerprint hash. A SHA-256-derived 8-byte hash computed from the combination of User-Agent, screen dimensions and pixel ratio, timezone, language, platform string, CPU hardware concurrency, reported device memory, and touch-capability flag (see lib/admin/userSurveillance.ts fingerprintHash()). The fingerprint is stable across sessions on the same device and is used to recognise returning visitors and detect multi-account abuse.
• Cookies set immediately. An anonymous identity cookie (azal_v6_pid), a CSRF token, and (post-authentication) the Privy session cookies and the azal_gate JWT.
• localStorage / sessionStorage keys we read or write on the client: azal:consent:v1, azal_v6_onboarded, azal_v6_my_handle, azal_v6_chat_me_user, azal_v6_watchlist, azal_v6_recent_markets, azal_v6_pref_audio_haptic, and the Privy privy:* / privy-* keys.
• CSP violation reports sent by your browser to /api/v6/csp-report.
• Client error reports (uncaught exceptions, render errors caught by an ErrorBoundary, fetch failures) sent to /api/v6/error-report.
• Telemetry events for UX instrumentation: gateway:* events (sign-in flow, denied-banner clicks, request-access CTA), onboarding:* events (each step of the username-claim flow), market:open (which markets you click), search:query (what you type into the search bar — payload {q, length}).

Every captured field becomes part of your surveillance dossier, accessible to authorised Azal operators via the admin portal at /admin-v2/user/<did>/dossier.

What We Collect After Authentication

When you authenticate with Privy and claim a username, we begin attributing your collected data to a persistent identity. Additional fields include:

• Privy DID — the persistent identifier Privy assigns to your account (did:privy:cm...).
• Authentication factor used — email, SMS, Apple, Google, Discord, X, wallet, or passkey. The factor identifier (e.g. the email address you signed in with) is stored by Privy and visible to us via Privy’s server SDK.
• Wallet address(es) — both the Privy-embedded wallet address and any external wallet you connect. Stored alongside the Privy DID in azal:admin:user:<did>:profile.
• Claimed v6 username and avatar image (base64-encoded JPEG, capped at ~48 KB after client-side downscale).
• Tier & permission flags — Basic / Pro / FnF / Admin and any feature flags granted on a per-account basis.
• Linked identities — if you link Discord, Telegram, or X via the link-code flow, the platform binds those identities to your Privy DID and stores the bind in a reverse-lookup index for cross-surface delivery.
• Activity timeline — the last 1,000 page hits attributed to your DID, each row containing {ts, path, method, ip, fingerprintHash}. Stored in the Redis list azal:admin:user:<did>:activity with capped LTRIM.
• Every unique IP you have visited from with first-seen, last-seen, hit count, and geo. Stored in azal:admin:user:<did>:ips.
• Every unique device fingerprint you have visited from, including the underlying reported screen dimensions, timezone, language, platform, hardware concurrency, device memory, and touch flag. Stored in azal:admin:user:<did>:devices.
• User preferences — theme, notification opt-ins, quiet hours, whale-tier thresholds, stop-loss / take-profit defaults, custom rule definitions, auto-copy targets, follow-set, mirror percent, max concentration, trader watchlist, blocked-user list, category subscriptions, withdrawal address.
• Azal Copilot conversations — the messages you send, the assistant responses, Copilot tool calls/results, market context, portfolio/P&L snippets returned by read-only tools, and long-term Copilot memory are stored under your verified owner DID. The runtime also writes bounded ai_feedback_events and ai_feedback_rollups rows under the ai_training purpose so we can measure and improve answer quality.

Trading & On-Chain Data

When you place an order through Azal, we capture additional data tied to the trade lifecycle:

• EIP-712 signing payload — the order parameters (market id, side, size, price, time-in-force, builder code) and the signature your wallet produced. Submitted to the venue (Polymarket CLOB V2 or Kalshi); also retained in our audit chain so a future support request can reconstruct exactly what you signed and when.
• Builder code attribution. Every Polymarket order routed through Azal carries Synthetics Inc’s builder code; the rebate is aggregated daily and visible in the admin portal under /sage builder_volume.
• Custodial-wallet keys (opt-in only). If you opt into the custodial trading wallet, we generate a secp256k1 keypair on your behalf and store the private key encrypted with MASTER_KEY at rest in Upstash. The key is decrypted in-process only at the moment a signature is required. It is never logged.
• Position state — submitted, live, matched, filled, cancelled, expired, settled. Tracked in the order store, surfaced via the dashboard and the /positions Telegram command.
• Settlement events observed from the Polymarket ConditionalTokens contract on Polygon, attributed to your positions. Final P&L is computed and stored.
• Auto-copy attribution — if you mirror a caller, each mirrored fill is linked back to the originating signal in the copy-trade trace so the source of every trade is auditable.
• Deposit / withdrawal addresses and events — including the on-chain transaction hashes and observed transfer events.

All on-chain transactions you sign are public on Polygon. Anyone can read them; the wallet you trade from is effectively pseudonymous, not private. Linking that wallet to your real identity is your decision.

Cookies, Sessions & Local Storage

• privy-token, privy-refresh-token, and related Privy session cookies (HTTP-only, secure, set by Privy on the response after successful authentication).
• azal_gate — a server-signed JWT granting admin or beta-gate access where applicable. HTTP-only, secure, scoped to .azal.ai.
• azal_v6_pid — an anonymous device identifier used to attribute pre-auth activity to a stable bucket so that, once you authenticate, your prior anonymous activity can be folded into your DID’s timeline.
• localStorage keys listed in § 02. These persist client-side until cleared by you via the consent panel, the Settings panel, the cmd+k “Clear recent markets” action, or by clearing site data in your browser.

How We Use Information

• Operate the service. Route orders, display positions, mirror trades, send notifications, render the dashboard.
• Secure the service. Bot detection, abuse mitigation, rate limiting, sanction screening, fraud investigation, sybil / multi-account detection (the fingerprint and IP history are the primary inputs here), incident response.
• Comply with law. Respond to subpoenas, court orders, sanction lists, and regulator inquiries.
• Improve the service. Aggregate telemetry (search queries, market clicks, onboarding drop-off, gateway funnel) is used to prioritise product work and surface dead-end paths.
• Communicate with you. Trade fills, settlements, alerts you opted into, caller-of-the-week notifications, security notices, and policy updates.
• Aggregate analytics. Builder-fee totals, monthly active wallets, hub mix — reported internally and to investors in de-identified, aggregated form.

Legal Bases (UK / EU users)

If you are in the United Kingdom, the European Economic Area, or another jurisdiction with an analogous regime, we rely on the following legal bases under the UK GDPR and EU GDPR:

• Contract — processing necessary to deliver the trading service you asked for (Art. 6(1)(b)).
• Legal obligation — sanction screening, AML obligations, retention of trading records (Art. 6(1)(c)).
• Legitimate interests — preventing abuse, securing the platform, improving product (Art. 6(1)(f)). Balancing test performed; the surveillance posture is justified by the financial-risk attack surface of the trading rail.
• Consent — for non-essential cookies, marketing communications, and any new collection category we add after the effective date of this policy (Art. 6(1)(a)).

Sharing & Third-Party Recipients

We do not sell personal data. We share data with the following categories of recipient, only as necessary:

• Infrastructure providers. Vercel (hosting, edge compute, build logs), Upstash (Redis for the dossier, Copilot state, and order store), Google Cloud (Cloud Run for the Discord / Telegram bot worker and Google Vertex AI / Gemini for Azal Copilot model inference), Cloudflare (where used for protection layers).
• Identity providers. Privy (authentication, embedded wallets, factor identifiers).
• Trading venues. Polymarket (CLOB V2 API, gamma-api, data-api), Kalshi (REST API, trade-stream WebSocket), Polygon RPC providers (drpc, tenderly, publicnode, Alchemy).
• Communication surfaces. Discord (per-channel posts, DMs, slash command responses), Telegram (per-chat messages, mini-app authentication via initData).
• AI model processors. Google Vertex AI / Gemini receives Copilot conversation messages, the selected system prompt, recent thread history, and tool outputs needed to answer your Copilot request. This can include market questions, public Polymarket position/P&L data surfaced by Copilot tools, and your own typed prompt. We do not send wallet private keys or server-side custody secrets to the model.
• Analytics & observability. Sentry (errors, when DSN is configured), Google Analytics / Tag Manager (when configured), Google AdSense (when configured for the marketing surfaces).
• Data oracles & news. GDELT (geopolitical events), BBC / Al Jazeera / NPR / Hacker News (news headlines), OpenSky / ADS-B (aircraft), AIS / vessel feeds, USGS (earthquakes), GDACS (disasters). Outbound requests carry our service User-Agent; we don’t expose your IP to these endpoints.
• Law enforcement & regulators. In response to a legally compelling request, or where we believe disclosure is necessary to protect rights, property, or safety.
• Successors. In the context of a merger, acquisition, asset sale, financing, or similar transaction, subject to commercially reasonable confidentiality protections.

Retention

• Surveillance dossier (profile, IPs, devices). Retained indefinitely as long as the account exists. Required for ongoing abuse prevention and incident response.
• Activity timeline. Capped at the 1,000 most recent hits per DID via Redis LTRIM. Older hits are dropped.
• Trade records. Retained indefinitely for accounting, regulatory, and dispute-resolution purposes.
• Azal Copilot state. Thread metadata, messages, and Copilot memory are retained in Redis while the Copilot feature is active for your account and are included in the account export when linked to your verified owner DID. Closing your account revokes ai_training consent and clears volatile Copilot Redis state; durable ai_feedback_events and ai_feedback_rollups remain subject to the retention schedule and DSAR export.
• Chat messages. Retained as long as the relevant channel is active; subject to deletion via the moderation flow.
• Server logs. Vercel and Cloud Run request logs retained per the provider’s defaults (typically 1–30 days).
• Telemetry events. Aggregated and retained indefinitely; individual rows truncated per the activity-log retention.
• Backups. Cycled out on the provider’s rolling window (typically 7–30 days). Deletion requests are honoured in primary storage immediately and propagate to backups as they cycle.

Your Rights

Depending on your jurisdiction (UK GDPR, EU GDPR, California CCPA / CPRA, Virginia VCDPA, and similar) you may have the right to:

• Access — request a copy of your dossier (profile, IP history, device fingerprints, activity timeline, trade records, platform-v6 preferences, alert state, Copilot threads/messages/memory, cross-site events, and ai_feedback_events / ai_feedback_rollups where linked to you).
• Rectify — correct inaccurate data, primarily the username and preferences you submitted.
• Delete — ask us to close your account. The self-serve account deletion flow is a soft-delete: it disables account access, revokes user-controllable purposes such as analytics, personalization, marketing attribution, and ai_training, and clears volatile Copilot Redis state. Data that must be retained for security, compliance, trade/accounting, abuse investigation, or stated retention-policy reasons remains retained and exportable; a legal erasure request is reviewed separately and may still preserve exempt records.
• Restrict processing in certain circumstances.
• Object to processing based on legitimate interests; we will weigh the request and respond.
• Portability — receive your data in a structured, commonly used, machine-readable format.
• Withdraw consent for any processing based on consent. Withdrawal does not affect the lawfulness of prior processing.
• Opt out of sale or sharing (CCPA / CPRA). We do not sell personal data; the “Do Not Sell” link is a no-op for Azal but available on request.
• Lodge a complaint with your local supervisory authority (e.g. the ICO in the UK).

To exercise any of these rights, email privacy@azal.ai from the email associated with your Privy account. We aim to respond within 30 days.

International Transfers

Synthetics Inc is incorporated in Delaware, USA, and our infrastructure runs principally in US-based regions (Vercel iad1, Google Cloud us-central1, Upstash regional databases). If you access the service from outside the United States, you understand that your data will be transferred to, stored in, and processed in jurisdictions whose data-protection laws may differ from those of your home country. Where required, we rely on Standard Contractual Clauses or equivalent transfer mechanisms.

Security

We implement controls proportionate to the financial surface we operate:

• TLS-only enforced at the edge; HSTS preload.
• Per-route Content-Security-Policy, X-Frame-Options DENY, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy locked-down.
• Privy session cookies HTTP-only + secure; CSRF tokens on mutating endpoints.
• Custodial private keys encrypted at rest with MASTER_KEY; decrypted only in-process at signing time; never logged.
• Admin endpoints gated by JWT with role=admin; admin actions audited.
• Rate limiting + bot detection on the gateway and every public API.
• Append-only audit chain for every sensitive event (signing, key rotation, admin action, signal-fire, copy-trade attribution); verifiable via the /sage-audit-chain operator command.

No system is perfectly secure. If you believe you have discovered a vulnerability, please email security@azal.ai rather than disclosing publicly.

Children

The service is not directed to children under 18, and we do not knowingly collect personal data from them. If you believe a child has provided personal data to us, email privacy@azal.ai and we will delete it.

Changes & Contact

We may update this Privacy Policy. Material changes — especially additions to the data categories we collect or new third-party recipients — will be announced with at least 14 days’ notice via the Discord announcement channel and / or an email to the address on file, and the effective date at the top of this page will be updated.

Synthetics Inc · Delaware, USA.

Privacy requests: privacy@azal.ai.
Security disclosures: security@azal.ai.
General legal: legal@azal.ai.

Additions effective 2026.05.25

The surveillance stack was expanded in two material directions. This section is an addendum to § 2 / § 3 / § 6.

• Anonymous visitor identity cookie azal_avi (64 hex chars, HttpOnly, Secure, SameSite=Lax, 2-year expiry) is now set on first contact and links every subsequent request from the same browser into one durable visitor record. This is in addition to the existing azal_v6_pid cookie.
• Rich device fingerprint (30+ signals) — canvas hash, AudioContext FFT hash, font enumeration hash, WebGL vendor + renderer + extension list, client-rects hash, WebRTC private-IP leak, permissions snapshot, sensor presence, Client Hints, Battery API, Connection API, color gamut. Captured asynchronously after page hydration via /api/v6/fingerprint/v2.
• Behavioral telemetry — mouse coordinates sampled at 4 Hz, click x/y/target, scroll-depth milestones (25/50/75/100%), mouse-leave / mouse-jitter (bot detection signal), form-focus + blur events (NO input values), copy / cut / paste events (selection LENGTH only), page-visibility (tab hide/show), active-time-on-page. Posted to /api/v6/telemetry.
• rrweb session replay — the entire DOM mutation stream + mouse + scroll, gzip-chunked every 10 seconds to /api/v6/replay, capped 5 MB per session. Password / email / tel / url inputs and elements with data-mask or data-private are masked at source. Reviewable by authorised operators via the admin replay player.
• Traffic source attribution — UTM source / medium / campaign + click IDs for fbclid, gclid, gbraid, wbraid, dclid, ttclid, twclid, li_fat_id, msclkid, epik, igsh, snapchat_click_id, scid, yclid, rdt_cid (19 schemes). First-touch and last-touch are stored per person; the full click_ids set persists in a JSONB column.
• Third-party processors added.
  • IPinfo.io — we send each unique IP we observe (deduped 24 h via Redis cache) to IPinfo’s REST API to retrieve ASN, ISP / org name, reverse DNS, and finer city-centroid geo. IPinfo’s privacy policy: https://ipinfo.io/privacy-policy.
  • ip-api.com — a free supplementary enrichment for the VPN / proxy / hosting / mobile flags. Each unique IP forwarded once per 24 h.
  • Tor Project — we fetch the public Tor exit-node list at https://check.torproject.org/torbulkexitlist hourly to flag Tor visitors locally; no per-visitor data leaves our infrastructure for this check.
  • ntfy.sh — when an admin-configured watchlist rule matches an incoming visit, we POST a short summary (the matched value, the visit’s path / IP / city / country / UA family / linked DID if any) to the ntfy.sh topic configured by the operator, which forwards to subscribed devices as a push notification. ntfy.sh’s privacy policy: https://docs.ntfy.sh/privacy/.
  • Neon (Postgres) — the durable surveillance store. Schema covers people, visitors, events, devices, ip_intelligence, behaviors, sessions_replay, watches. Operated under our Neon project (provisioned through the Vercel marketplace).
  • CartoDB / OpenStreetMap — the geo map in the admin console loads tile images from CartoDB; only the operator’s browser issues those tile requests, never the visitor’s browser.
  • Etherscan / Polygonscan — the admin Wallets directory links out to these explorers; clicks happen from the operator’s browser only.
• Cross-device stitching. When the same Privy DID, email hash, or fingerprint hash appears on multiple browsers, we link them into a single “person” record. This means a sign-in on your laptop will be linked to a prior anonymous visit on your phone if device fingerprints or shared IP subnet matches.
• Admin dossier URL update. The dossier was previously at /admin-v2/user/<did>/dossier; it now lives at /admin-v2/people/<person_id>.

To request a copy, account closure, or legal erasure review, email privacy@azal.ai with the email address, DID, or wallet address you used.