smirk-backend-core/PRIVACY.md

Privacy Policy

Status: stable · Updated 2026-09-27 · Applies to: backend data handling

The canonical Smirk privacy policy lives at https://smirk.cash/privacy and describes the data practices of the instance operated by Such Software LLC (api.smirk.cash).

For operators who self-host

This backend is open source and self-hostable. If you run your own instance, you are an independent data controller for it and the Such Software policy does not speak for you. What your instance receives from wallets that connect to it:

• Monero/Wownero view keys (to scan for users' incoming funds; a view key cannot spend) and their scan/registration state.
• Public addresses for BTC/LTC balance lookups and signed transactions to broadcast. A signed Bitcoin or Litecoin transaction contains its output addresses and amounts; sending it through the backend exposes those public transaction fields to the backend.
• A client-derived seed fingerprint used to locate a returning wallet. The backend stores an HMAC of it under an instance-specific pepper, rather than the client value. A fingerprint is not a seed or proof of ownership.
• If enabled: the username to npub mapping published in your NIP-05 directory, and, for the relay, encrypted message envelopes (ciphertext only).
• Client IP addresses for rate limiting. The application keeps its rate-limit counters in memory; its persisted restore-attempt identifier is a salted one-way hash on restore_attempts, which the seed-restore abuse limiter reads back. Login events record no IP at all, and the raw-IP columns that older schemas carried on sessions and audit_logs were dropped in migration 20260722000001_privacy_drop_pii. One exception, and it is about you rather than your users: the tamper-evident operator audit chain (admin_audit_logs) records the IP of privileged admin actions.

Private spend keys and seed phrases are never transmitted to the backend. Monero and Wownero private incoming view keys are transmitted for scanning, and the configured light wallet servers retain them. They reveal incoming payments but cannot spend funds. Reverse proxies and chain services have their own logging and retention settings, which operators must disclose separately.

Retention

Retention is enforced by the backend, not merely advertised. A background sweep deletes login_events older than RETENTION_LOGIN_EVENTS_DAYS and audit_logs older than RETENTION_AUDIT_DAYS, in bounded batches so a long-running instance drains its backlog without stalling writers. Setting either knob to 0 means keep indefinitely, so an unset value never destroys data by surprise.

The admin_audit_logs chain is deliberately exempt: it is hash-chained and MAC'd, so a deleted row reads as tampering to the verifier. Prune it on purpose if your policy calls for it.

Self-service erasure (ERASURE_ENABLED) is separate and user-initiated: a confirmed request deletes the account and its owned rows after a grace window, purging or anonymizing that user's login events per ERASURE_PURGE_LOGIN_EVENTS.

If you offer your instance to others, publish your own privacy policy describing how you handle this data, your retention, and your jurisdiction. The knobs that affect retention and data exposure (login-event and audit retention, erasure, relay retention, landing-page exposure) are documented in docs/operations/CONSOLE.md and the root .env.example.

Operator checklist

• Document the light wallet servers that receive and retain view credentials.
• Match proxy and chain-service logging to the published privacy policy.
• Configure retention and test account export and erasure.
• Keep spend keys and recovery phrases on clients.