Privacy policy

Last updated · October 10, 2026

1. Overview

MintMetric is a precious metals portfolio tracker. This policy explains what the app and the website collect, what we store on our servers, which third parties process data on our behalf, how long we keep each category, and what rights you have. It covers the MintMetric mobile app and mintmetric.app.

We have written it to be specific rather than reassuring. Where something does leave your device, this policy says so and says exactly what it is.

2. Information We Collect

Free tier — no account. No account is required to use MintMetric. Your portfolio — holdings, purchase prices, notes and storage locations — is created and kept on your device in an encrypted local database; your item photos are stored alongside it as separately encrypted files on your device, not inside that database (§4, §6). Local-only use does not upload that portfolio content to us. Earlier encrypted copies from cloud use can remain after a return to Free, subject to §12 and §14. The app does request spot prices from our API; those requests carry no account identifier and no portfolio data (§7). This local-first statement is about your portfolio content, not the limited identifiers and diagnostics processed by the production support SDKs described in §8 and §9.

Account-backed features — optional account. If you create an account you provide an email address and a password, both handled by our authentication provider, Supabase. An account is required for encrypted cloud sync and backup, subscription management and PCGS lookup if that conditional integration is enabled; individual features can also require Pro. NGC's official-site handoff is Free and does not require a MintMetric account. Data that leaves your device when you use account-backed features includes:

• Your portfolio, as ciphertext. Holdings are encrypted on your device with a key derived from your sync passphrase before anything is uploaded. If you use Secure Sync, your item photos are uploaded too, each encrypted on your device with its own key that travels only inside that encrypted data (§4). We store the ciphertext. We do not have your passphrase and cannot decrypt it.
• Certificate details, if you use conditional PCGS lookup. PCGS certificate numbers are sent through our server only when PCGS lookup is enabled. The Free NGC handoff opens NGC's official checker; you enter certificate details on NGC's site, not through MintMetric — see §7.
• RevenueCat identifiers. In a production release, RevenueCat creates a random anonymous app user ID before you sign in or buy anything. If you sign in, MintMetric then supplies your account identifier — a random UUID — so a subscription can be matched to your account. RevenueCat receives no email address or portfolio content. See §8 and §10.

The website. If you join the waitlist we store the email address you submit, along with the referrer and any campaign parameters in the link you arrived from. Aggregate, cookieless page analytics are described in §8.

3. How We Use Your Information

• To operate the features you turn on: sync, encrypted backup, subscriptions, certificate lookups and spot price alerts.
• To email you before an encrypted backup is deleted after a subscription lapses, so you have time to resubscribe or export it.
• To email you when you request account deletion, and again when the deletion is complete.
• To keep the service available and resistant to abuse — rate limiting, error handling and capacity planning.
• To answer support requests and requests you make under this policy.
• Only if you opt in, to measure — in aggregate and pseudonymously — how people move through first-run setup and where they drop off, so we can improve it (§8). This is off by default and does not happen unless you turn it on.

We do not use your information for advertising, profiling or automated decision-making, and we do not sell or rent it.

4. How We Store and Protect Your Information

The claims below describe what MintMetric's own code does. We do not restate our hosting providers' internal security measures as though they were ours; those are governed by the agreements listed in §10.

• Your portfolio database is encrypted on your device using SQLCipher. If the SQLCipher library is not present the app raises an error rather than silently writing a plaintext database.
• Your item photos are encrypted on your device as well. Each photo file in the app's private storage is encrypted with AES-256-GCM under a key derived from your database key, so the photo files on your device are not ordinary, readable image files.
• The database key is generated on your device — a 256-bit random value created on first launch and held in the platform secure store: the iOS Keychain, or Android's encrypted preferences. We never receive it in readable form. It leaves the device in one situation only: when you create a cloud backup it is wrapped with your passphrase-derived key and travels inside the encrypted archive, so that the backup can be restored on another device.
• You can lock the app with a PIN, and unlock it with your device biometrics if you enable that.
• Sync and backup are end-to-end encrypted. Your sync passphrase is stretched with Argon2id (64 MB of memory, 3 iterations) into a 256-bit key, and your data is encrypted with AES-256-GCM before it leaves the device. The passphrase itself is never sent to us.
• Photos that Secure Sync uploads are end-to-end encrypted too. Each item photo is encrypted on your device with AES-256-GCM under its own random 256-bit key before it is uploaded. That photo key, the photo's in-app identifier and a fingerprint used to check the photo on download are stored only inside your encrypted sync data, so our servers never receive the photo key, the identifier or the photo itself in readable form.
• A cloud backup is encrypted before upload. Your encrypted database and your item photos are bundled into a single archive, and that archive is then encrypted with the same passphrase-derived key. What we receive is one opaque blob.
• Release builds refuse a non-HTTPS connection to our API.
• Our servers do not log IP addresses — see §7.
• Every authenticated request is scoped to your account. The account identifier is taken from a verified authentication token and database queries are restricted to it.

No security measure is absolute, and we do not claim otherwise. If you lose your sync passphrase we cannot recover your encrypted sync data or your backups for you — that is a direct consequence of not holding your key.

5. Data We Store on Our Servers

This is the full inventory of what MintMetric holds server-side. Where an entry says ciphertext, we hold the data but not a key that would let us read it — it is listed here because we do hold it.

• Account identity. Your email address, a randomly generated account identifier (UUID), and authentication sessions. Held by Supabase.
• Account email, in our own database. When the app uses our cloud backup service while you are signed in — including checking your backup allowance, which the subscription screen also does — we copy your email address into our database. We use it to warn you before a backup is deleted after a subscription lapses and to confirm that an account deletion is complete.
• Encrypted sync data. Versioned ciphertext blobs containing your portfolio, keyed to your account identifier.
• Encrypted sync photos. If you use Secure Sync, each item photo is stored as a separate encrypted object in DigitalOcean Spaces under a random storage key within your account's area. A database record holds that storage key, your account identifier, the encrypted size in bytes, whether the upload is pending, confirmed or being deleted, and the related timestamps. We hold no key to the photo, its in-app identifier, or which holding it belongs to (§4, §6).
• Secure Sync deletion records. If you turn Secure Sync off, a record of that deletion: your account identifier, when it was requested and completed, its status, retry attempts and timing, the text of the last storage or database error (which can include your account identifier), a marker for the deleted sync setup, and the random, non-secret salt that was combined with your passphrase to make your sync key. It lets the deletion be retried until it is confirmed and stops a device that still holds the old sync setup from uploading it again. The salt is kept so that cloud backups made earlier can still be restored with the same passphrase. It holds no portfolio data, no encrypted sync data, no photos and no value derived from your passphrase.
• Encrypted backup archives and their metadata. The archive objects (ciphertext, containing your database and your item photos) are stored in DigitalOcean Spaces. A metadata row — identifier, your account identifier, storage key, size in bytes, status, whether you pinned the backup, and timestamps — is stored in our database.
• Subscription and entitlement records. Tier, status, the RevenueCat identifier, and purchase and expiry timestamps.
• Subscription-transfer replay records. RevenueCat event identifier, source and destination account identifiers, and event/creation timestamps. These links prevent delayed billing events from assigning paid access to the wrong account.
• Pending subscription webhook deliveries. After our server authenticates a subscription event from RevenueCat, we temporarily keep the provider API version; the event identifier, type and store environment; the app account, product, entitlement and original transaction identifiers; purchase, expiry, grace-period and event timestamps; the period type and trial-conversion flag; transfer source and destination identifiers; and retry count, next-attempt time and last processing error. Before writing that queue entry, we discard subscriber attributes (including email address, name, phone number and custom attributes), aliases, attribution and experiment data, country, currency, price, and fields our entitlement processor does not use. This durable queue prevents a temporary RevenueCat or server outage from losing a purchase, refund, expiry or account transfer after RevenueCat stops its own delivery retries.
• Legal acceptance records. The accepted Terms/Privacy document versions and digests, required action, time, platform, app build and release channel. Current state is keyed by account identifier. The append-only evidence log uses an HMAC-SHA256 keyed hash of that identifier rather than the plaintext identifier.
• Spot price alerts. Metal, threshold, direction, whether the alert is enabled, and when it last fired. When a threshold crossing is detected, a durable delivery row also temporarily records your account and alert identifiers, the metal and direction, fixed account-neutral notification text, observation and expiry times, delivery attempts and errors, and the random device-registration identifiers already resolved or still awaiting delivery. It does not store the current price or repeat your threshold.
• Push notification device tokens. A device token is an online identifier under GDPR Art. 4(1). The table records the token, platform, app build and release channel, your account identifier, a random installation-registration identifier, a one-way hash of its revocation secret, and when the token was created and last seen. Short-lived revocation rows keep the account identifier, random registration identifier, hashed secret where available, and revocation and expiry times so a delayed registration cannot recreate a token after sign-out. Retention is in §12.
• PCGS certificate lookup cache. If conditional PCGS lookup is enabled, PCGS responses and short-lived not-found results are cached by certificate number. These rows hold no account identifier. The Free NGC official-site handoff creates no MintMetric lookup or result record.
• Certificate lookup quota counters. A per-account shared minute-window count, plus a daily PCGS count, used to enforce fair-use and upstream limits. These counters do not record which certificate numbers you entered.
• Email suppression records. If mail to your address bounces or is marked as spam, we record the address and the reason so we stop sending to it.
• Backup retention warning records. That a warning was sent for a given backup, when, to which address, and whether it bounced.
• Backup warning send-attempt timestamps. A per-account row recording when we last attempted to send you a backup-deletion warning, so repeat warnings are spaced out. It holds your account identifier and that timestamp only — no backup identifier and no email address.
• Waitlist emails. If you joined the waitlist on the website: the email address, the referrer, and any campaign parameters.
• Pseudonymous product-analytics events. Only if you opt in to the optional product analytics described in §8, first-party funnel events tied to a random per-install identifier — never your account identifier, email address or an advertising identifier. Each event carries only the reviewed allowlist of non-identifying fields set out in §8 and no portfolio content. They are held in our own database (§10), not with a third-party analytics processor, and are retained for a bounded window (§12). This choice is off by default; if you never turn it on, we hold nothing here.

6. Your Holdings and Photos

An inventory of the precious metals someone owns — quantities, purchase prices, storage locations and photographs — is sensitive in a particular way. It is both a financial profile and, in the wrong hands, a theft risk. We treat it as the most sensitive category of data in the product.

• Local-only use, including Free use without cloud features, does not upload holdings or photos to us. Earlier encrypted cloud copies can remain after Pro ends under §12, and you can choose to export or share files yourself (§13).
• If you turn on sync or backup, they leave only as ciphertext, encrypted with a key derived from a passphrase we do not hold. What reaches our servers is an opaque blob. It is listed in §5 as data we hold, because we do — we simply cannot read it.
• There is no readable copy on our side. Our servers hold no plaintext holdings or photos: your portfolio reaches us only as the encrypted sync blob, the encrypted sync photos and the encrypted backup archive, and we cannot read any of them.
• Certificate details can reach us in the clear only through conditional PCGS lookup (§7). That flow sends the certificate number in an authenticated request, and its cached response is keyed by certificate number alone with no account identifier. The Free NGC handoff is a direct browser visit; MintMetric receives neither the certificate details nor the result.
• Item photos are stored as encrypted files in the app's private storage on your device (§4), not inside the encrypted database. They reach our servers only in encrypted form: inside an encrypted backup archive, and, if you use Secure Sync, as individually encrypted photo files so that your other devices can show them. A PDF report you create shows your photos, and a CSV or JSON export includes them only if you choose Include photos (§13); those files are made on your device and are not sent to us.
• What Secure Sync lets us see about your photos, and what it does not. Each synced photo is stored as ciphertext under a random storage key that is not derived from the photo, its filename or the holding. The operational metadata we can observe is limited to each encrypted photo's size, its storage key, how many encrypted photos your account holds, whether each upload has been confirmed, and when an upload, download or deletion was requested. We cannot see your photo contents, their filenames or EXIF/image metadata, their in-app identifiers, which holding a photo belongs to, or the keys that decrypt them. Encrypted photos count toward your Secure Sync storage allowance; if it is full, new photos stay on your device and are not uploaded until there is room, while the rest of your sync data keeps syncing. A photo too large to sync stays only on the device it was added on, and your other devices show that it is not synced.
• What a cloud backup lets us see, and what it does not. A backup is your encrypted database together with the item photo files it references, bundled and encrypted on your device before upload. Because we hold only that ciphertext, the operational metadata we can observe is limited to the encrypted archive size, the number of backups you hold and their status and timestamps, whether you pinned each one, when an upload or download URL was issued, and each backup's retention state. We cannot see your photo contents, their filenames or EXIF/image metadata, or your holdings' names, quantities or values. We retain up to five completed backups per account; when a new backup would exceed five, the oldest backup that you have not pinned is replaced. You can pin up to two backups. Pinning does not change the retention period that applies after a subscription ends. Each archive must fit the 99 MB backup size limit before encryption. Creating a new cloud backup requires a Secure Sync setup. Backup archives are stored separately from active sync data: turning Secure Sync off does not delete those archives. You can delete backups individually or request account deletion (§14).
• We do not sell or share your holdings, and we do not use them for advertising, profiling or automated decision-making.
• Crash reports (§9) never carry holdings, portfolio values, your email address or your sync passphrase.

7. Spot Prices and Certificate Lookups

Spot prices. The app fetches spot prices from our API, which sources them from metals.dev. A spot price request is a market quote: it carries no account identifier and no portfolio data. metals.dev receives nothing about you at all — our server asks for the price, your device does not.

IP addresses. We do not log IP addresses. Our request log records a request identifier, the HTTP method, the path, the response status, the response size and the duration — and no client address. A client address is derived from the forwarded-header chain for exactly one purpose: an in-memory, per-client rate-limit counter that keeps the API available. It is never written to a log line, and no database table has a column for it.

Certificate checks. When PCGS lookup is enabled, the authenticated request sends the PCGS certificate number to our server, which calls PCGS. PCGS sees our server's IP address and receives no account identifier, email address or holdings data. Successful PCGS responses stop affecting lookups after 30 days, and short-lived not-found results stop affecting them after one hour; periodic cleanup removes both kinds of expired rows. Both caches use only the certificate number and hold no account identifier. The Free NGC official-site handoff simply opens NGC's checker in your browser, where NGC receives your device's IP address and any certificate number and grade you enter. MintMetric does not transmit those details, receive the authenticity result, or require an account for the handoff.

8. Analytics

Website. mintmetric.app uses Plausible Analytics when it is enabled for a deployment. Plausible sets no cookies, collects no personal data and no cross-site identifiers, and is hosted in the European Union. We use it for aggregate page views, traffic sources, and a small number of anonymous events such as a waitlist submission. Plausible is not used in the mobile app.

Mobile app. MintMetric contains no Google Analytics, Facebook SDK, attribution or advertising SDK, and performs no cross-app tracking. Its authentication client, Supabase, transmits your email address and password when you sign in or sign up and is described in §2, §5 and §10. The production app also includes the following SDK paths; their submitted privacy-manifest categories are listed explicitly rather than hidden behind a general “no analytics SDK” claim:

• RevenueCat handles in-app purchases and is active in release builds. It first creates a random anonymous app user ID before sign-in. When you sign in it receives your MintMetric account UUID so a purchase can be matched to your account, together with purchase and entitlement data. It does not receive your email address, holdings or other portfolio data. Its privacy manifest declares Purchase History for App Functionality and no tracking; our store label conservatively treats authenticated purchase history as linked.
• Sentry is the production crash reporter. Its privacy manifest declares Crash Data, Performance Data and Other Diagnostic Data for App Functionality, unlinked and not used for tracking. Runtime performance tracing is disabled, default personal data is disabled and every Dart error event is scrubbed through a strict allowlist. Native crash envelopes can carry a random installation-scoped Sentry identifier and technical app/OS/device contexts; our store answers conservatively treat those diagnostics as linked. Release builds require Sentry configuration; development builds may leave it disabled. See §9.
• Firebase Cloud Messaging is bundled for notification transport, which depends on the build, platform and enabled features. Launch builds have price alerts disabled, so the App's notification bootstrap does not activate that transport. On Android, bundled native Firebase configuration can still initialize a local FirebaseApp; messaging auto-initialization is disabled. On iOS, Firebase configuration is conditional on the notification feature. These distinctions do not change our conservative SDK disclosures: its privacy manifest declares Device ID for App Functionality, Other Data Types for Analytics, and Other Diagnostic Data for App Functionality, all unlinked by the SDK and not used for tracking. MintMetric includes the Analytics-purpose declaration even though it does not include Google Analytics. In a build that supports push alerts, if you enable them, MintMetric stores the messaging token against your account to deliver and revoke those alerts.
• Firebase Installations and GoogleDataTransport are bundled transitive dependencies of Firebase messaging. Their submitted privacy manifests each declare Other Diagnostic Data for Analytics, unlinked and not used for tracking. MintMetric includes that Analytics-purpose diagnostic declaration even though it does not include Google Analytics or use these SDKs for advertising or behavioral profiling.

Optional product analytics — off by default. MintMetric offers a single, optional choice to share pseudonymous product-usage analytics that helps us see how people get through first-run setup and where they get stuck. It is a first-party measurement path: the events go only to our own servers (the DigitalOcean database in §5 and §10), never to a third-party analytics, attribution, advertising or session-replay SDK, and they are not used to track you across other apps, websites or devices. This choice is off by default and stays off until you turn it on. It is its own separate control — it is not part of, and is never enabled by, accepting the Terms of Service or acknowledging this Privacy Policy; acknowledging this policy is not consent to this optional processing. You can turn it off again at any time in the app's Settings, which stops collection going forward, and you can delete what was collected (below). If you never turn it on, MintMetric collects no product analytics at all. It does not require an account and is available whether or not you have one.

When it is on, each event draws only from a fixed, reviewed allowlist of non-identifying fields and nothing else. Some fields are set on every event: the onboarding or purchase step name and its step index; the app version and build number; the platform (iOS or Android); the app's release channel (production, TestFlight or internal); and a coarse signed-in-versus-signed-out class — never your account identifier or email. Others are set only where they apply: locale and region at country granularity when your device reports them; a coarse returning-versus-new-install band; a preset-versus-custom class for the add-a-holding step; and a bounded save-error category, never a raw error message. A few more fields belong to the same reviewed allowlist but are not meaningfully populated in this release — a coarse OS major version, a coarse time-to-first-value band, a privacy-safe entry-point class, and a coarse session-count band are reserved, and until a later release wires them they are either omitted or sent only as a coarse constant such as “unknown”. It never carries your holdings or their names, quantities, values, metals, cost basis, storage locations, notes or photos; your email address or any credential; your account identifier or RevenueCat identifier; any free-form text; or any precise timestamp, precise location or advertising identifier. Unknown or unlisted fields are rejected rather than sent.

Events are tied to a pseudonymous per-install identifier — a random value created on your device only after you opt in, stored so it is excluded from operating-system backups (§16), and it is not your account, your email or an advertising ID. It is pseudonymous, not anonymous: it lets us count one installation's progress through the funnel without identifying you. Turning the choice off retires that identifier, and a new opt-in is not silently relinked to the old one. Raw analytics events are retained for a bounded window of about 90 days and then deleted; only aggregate, non-identifying counts are kept beyond that (§12). Because the choice is opt-in and carries no account key, deletion is possession-based: your device holds a secret, generated with the identifier and never included in any event or log, that lets it ask our servers to delete that installation's events; knowing the identifier alone does not let anyone delete or read the data. Deleting the app, erasing the local vault, or deleting your account also clears the on-device analytics choice, the identifier and any events still queued on the device.

9. Crash Reporting

Production release builds initialise Sentry using a build-time DSN so faults can be diagnosed. Local development builds without a DSN do not initialise the SDK and send no crash reports.

For Dart errors, MintMetric sends only a bounded exception type, sanitized stack locations needed for symbolication, build release and environment, and tightly allowlisted operational codes. The final scrubber removes free-form exception and message text, throwable objects, breadcrumbs, extra data, users, requests, transactions, arbitrary tags and contexts, plus stack-frame variables, registers, source context and absolute paths. If scrubbing fails, the event is dropped rather than sent in its original form. Native fatal-crash handling remains enabled for release verification and can send native crash stacks, threads/registers, technical app/OS/device contexts, a random installation-scoped Sentry `user.id`, and on iOS a `device_app_hash`. Those pseudonymous SDK values correlate events from one installation; they are not a MintMetric account UUID, RevenueCat identifier, email address or advertising identifier. Default personal-information collection, automatic breadcrumbs, screenshots, view hierarchy and failed-request capture are disabled, and MintMetric does not add portfolio breadcrumbs or user scope. Holdings, portfolio values, your email address, account identifier and sync passphrase are never intentionally attached.

Sentry's submitted privacy manifest inventories Crash Data, Performance Data and Other Diagnostic Data for App Functionality. Runtime performance tracing is zero. The store privacy inventory therefore keeps all three SDK-declared diagnostic categories even though Dart event content is minimized and tracing is disabled.

Release automation rejects a production build without Sentry configuration. Builds with the forced-crash diagnostic control enabled are kept out of both stores and are used only to verify capture and symbolication before the final store artifact is cut. Before Sentry or other product SDKs may start, a startup fault persists only a fixed failure code and phase on the device. A later launch submits one sanitized event only after runtime and legal policy admit normal product networking, and removes the local envelope after the Sentry SDK accepts it. If the app remains blocked, it does not contact Sentry and the fixed envelope remains local.

10. Sub-Processors and Third-Party Services

We share data with the parties below only as needed to operate the service. Where no data processing agreement is in place, the table says so rather than implying one.

Each provider processes data under its own privacy policy. Apple and Google appear here as distribution and purchase-processing platforms; the app itself is also subject to their respective policies when you download it.

11. International Data Transfers

Where we transfer personal data to a sub-processor that handles it on our behalf — the parties in §10 we have a data processing agreement with — we rely on appropriate safeguards: for EU and EEA transfers, the EU Standard Contractual Clauses; for UK transfers, the UK International Data Transfer Agreement or Addendum; for Australian users, the cross-border accountability requirements of APP 8; and for users in Singapore, we take reasonable steps to ensure that overseas recipients provide a standard of protection comparable to the Singapore PDPA.

That does not cover every recipient in §10, and we will not imply otherwise. Apple and Google process App Store and Google Play transactions as independent controllers under their own terms, not as processors for us — we are not the exporter for those transactions, so there is no safeguard of ours to rely on. PCGS can receive a certificate number through our server; NGC receives the certificate number and grade you enter during a direct browser visit; and metals.dev receives nothing about you at all. For those recipients we have executed neither a data processing agreement nor Standard Contractual Clauses, and §10 says so in each row rather than naming a mechanism we do not hold. §10 is the authoritative per-recipient position; where it and this section could be read differently, §10 governs.

We do not rely on your consent as a transfer mechanism. We also do not rely on the EU–US Data Privacy Framework.

Your personal information may be stored or processed in the United States and, for website analytics only, in the European Union.

12. Data Retention

• Account identity: kept for as long as your account exists.
• Account email in our database: once written, this row is kept indefinitely — nothing removes it on a schedule today, and it is not deleted when your backups are deleted. You can have it removed at any time by emailing privacy@mintmetric.app, and it is purged by account deletion (§14).
• Encrypted sync data: kept while Secure Sync is on. Superseded intermediate versions are compacted away automatically; the most recent snapshot is retained so a new device can restore from it. Turning Secure Sync off deletes it from our servers (§14).
• Encrypted sync photos: kept while your synced holdings still use them. While Secure Sync is active on your plan, deleting a photo or its holding deletes its encrypted copy; otherwise the copy is kept until you turn Secure Sync off or delete your account. Turning Secure Sync off deletes all of them (§14). After a deletion, a minimal record of the storage key is kept only until any upload link issued for it has expired, so a final check can remove a late upload; the record is then removed. An upload that is started but never confirmed is removed, together with its record and any uploaded copy, about an hour after its upload link expires.
• Secure Sync deletion records: kept while your account exists, so the deletion can finish, an old sync setup cannot be uploaded again, and cloud backups made earlier can still be restored with the same passphrase; removed when your account is purged (§14).
• Encrypted backup archives and metadata: kept while a subscription that grants sync is active. If it lapses, backups are held for a 60-day grace period, after which we email a warning and open a further 14-day notice window before deletion — around 74 days in total. Resubscribing during that window restores them. If we cannot deliver the warning email, the backup is not deleted. Pinned backups follow the same schedule.
• Backup retention warning records: removed together with the backup they relate to, when a resubscription rescues that backup, when your account email changes, or when you cancel an account deletion request.
• Backup warning send-attempt timestamps: kept for 30 days from the last attempt, then purged, or removed when your account is erased — whichever comes first. Unlike the warning records above, this row carries no backup identifier; it is a per-account timestamp used only to throttle repeat warnings.
• Deletion-status recovery capabilities: a one-way SHA-256 digest of a random recovery secret, your account UUID, and creation and expiry timestamps are kept in PostgreSQL for up to 400 days. The plaintext secret stays only on your device. These minimal rows let a device determine whether an account-deletion request succeeded even after ordinary account access is closed; expiry cleanup removes them after 400 days.
• Independent deletion lifecycle evidence: reserved, scheduled and cancelled lifecycle events, plus a pre-destruction irreversible-erasure marker, are retained in a versioned deletion journal outside PostgreSQL. Lifecycle events can contain the account UUID, lifecycle generation, request, deadline and record timestamps and, for a scheduled event, the recovery-capability digest and expiry. The erasure marker contains the account UUID and irreversible timestamp; successful purge completion is recorded in PostgreSQL. These records contain no email or portfolio contents. Journal retention is configured to outlast the maximum configured database and backup restore horizon so a restore cannot revive an accepted deletion or discard an accepted cancellation.
• Subscription and entitlement records: kept while your account exists, so entitlements can be restored across devices and reinstalls.
• Subscription-transfer replay records: kept indefinitely so delayed or replayed RevenueCat events cannot restore access to the wrong account. They contain the source and destination account identifiers and event timestamps, not holdings, email, payment-card details or plaintext purchase receipts.
• Pending subscription webhook deliveries: deleted as soon as processing succeeds. A delivery that still cannot be processed remains in the queue and is retried without a fixed attempt limit so a paid-access or ownership change is not silently lost. Operational staff use the stored error and retry metadata to investigate a delivery that remains unresolved. The queue contains no subscriber attributes, holdings, email, payment-card details or plaintext purchase receipts.
• Legal acceptance records: current per-account state is deleted with the account. The pseudonymous append-only evidence record is kept indefinitely to establish which published legal documents were accepted, when, and through which app build. You may request a copy under §13; retention and erasure questions can be sent to privacy@mintmetric.app.
• Spot price alerts: kept until you delete the alert, or until the account is purged. A pending crossing is normally removed after delivery or expiry. A crossing stopped by a permanent system-level delivery error is retained for operator diagnosis until a later crossing replaces it, you delete the alert, or the account is purged.
• Push notification device tokens: a device that re-registers replaces its own row rather than adding one. MintMetric removes a token after 90 days without a successful check-in, when Firebase reports it permanently invalid, on successful device deregistration, or when deletion is requested. Revocation rows expire after 24 hours and are then removed, or are purged with the account first. Firebase retains its installation identifier until we request deletion; after that request, Google says removal from live and backup systems can take up to 180 days. Notification messages sent by MintMetric have a maximum one-hour delivery lifetime.
• PCGS certificate lookup cache: successful responses expire after 30 days and not-found results expire after one hour, after which they no longer affect lookups. Periodic cleanup then removes those expired rows. Both are keyed by certificate number only, with no account identifier. MintMetric stores no NGC verification response.
• Certificate lookup quota counters: 90 days, then purged.
• Email suppression records: 12 months from the date recorded, then purged. These are kept on the basis of our legitimate interest in not repeatedly mailing an address that has bounced or complained, and they are not removed by account deletion — see §14.
• Waitlist emails: kept until you ask us to remove them (privacy@mintmetric.app). There is no automatic expiry for these today.
• Pseudonymous product-analytics events (only if you opt in): raw events are kept for a bounded window of about 90 days and then deleted; only aggregate, non-identifying counts are kept beyond that. Turning the choice off in Settings retires the on-device identifier and stops collection, and you can delete an installation's events at any time (§8). If you never opt in, nothing is collected or retained.
• Server logs: two kinds, and they differ. Our HTTP request logs contain no IP address and no account identifier — only a request identifier, method, path, status, response size and duration. Our application logs are separate, and they do record significant account events against your account identifier, including when a deletion is requested, when one is reversed, and when a Secure Sync server deletion completes or has to be retried. Where an email address appears in them at all it is redacted before it is written: the part before the @ is replaced with asterisks and only the domain remains, so the full address is never logged. Both kinds are retained by our hosting platform under its own log retention settings rather than by us.
• Deletion records: retained indefinitely. Two survive a purged account: a marker row holding your account identifier — a UUID — and the timestamps for when deletion was requested, scheduled and completed; and a tombstone, written for every completed purge, being an HMAC-SHA256 keyed hash of the email address on the account — or, where no email address was ever stored, of the account identifier — held in an append-only log that holds no account data and no plaintext identifier. Neither stores your email address, your name or any other account data — see §14.
• RevenueCat subscriber records after account deletion: retained by RevenueCat rather than purged, deliberately — see §14 for what remains, why, and how to have it removed.

13. Your Rights

You have the right to access your data, to have it corrected, to have it erased, to restrict or object to processing, and to receive it in a portable form. For users in the EU and EEA these are the rights in Articles 15–22 of the GDPR; equivalent rights apply in the UK. Send any request to privacy@mintmetric.app and we will respond to a verified request within 30 days. An access request returns everything §5 records about you — §5 is the authoritative inventory, and the scope of an access request is defined by it rather than by any shorter list here. That includes the categories people are most often surprised we hold: your backup metadata rows, your push device tokens, your certificate lookup quota counters, any email suppression record and backup retention warning record against your address, and, if you joined the website waitlist, that entry with the referrer and campaign parameters captured with it (§14). We return it decrypted where we hold it in the clear, and as ciphertext where we do not. Your holdings and photos are the second case: your sync blobs, encrypted sync photos and backup archives are end-to-end encrypted (§4), so an access request returns those objects as ciphertext and cannot include your holdings or photos in decrypted form. We do not hold the key that would decrypt them, and we hold no other copy of your portfolio.

Correcting your data. Your holdings, purchase prices, notes, storage locations and photos can be edited directly in the app at any time. If cloud sync is enabled, the corrected version replaces the encrypted version we hold on the next sync. To correct the email address on your account, email privacy@mintmetric.app.

Portability. The app exports your portfolio in machine-readable form — CSV and JSON — from its export controls; a PDF export, which shows your item photos, is also available if you want something to read rather than to re-import. Those exports are produced on your device from your own data and are not sent to us, so they are the fastest route to a portable copy. A CSV or JSON export leaves your item photos out unless you turn on Include photos for that export; the choice starts off each time. With it on, the export is a ZIP file containing the CSV or JSON file together with the photos stored on that device as decrypted, viewable image files, so anyone you share that export with can see your photos. A holdings archive (Save holdings archive) includes photos only if the app offers Include photos for it and you turn it on. For anything an export does not cover, email privacy@mintmetric.app and we will provide it in a structured, commonly used, machine-readable format.

Erasure. The primary route is in the app: Settings → Delete Account requests deletion of your account and the server-side data that the deletion job purges. §14 lists exactly which categories that covers and what remains afterwards — it is not everything inventoried in §5, and we would rather point you at the real list than imply a wider sweep than the job performs. The request stays reversible for 30 days — sign in again during that window and it is cancelled. You can also email privacy@mintmetric.app from the address on the account.

Restriction and objection. To ask us to restrict processing (Art. 18), or to object to processing we carry out on the basis of legitimate interest (Art. 21) — those cases are listed below — email privacy@mintmetric.app. Email is the mechanism for both; there is no in-app control for either.

California residents (CCPA/CPRA). If you live in California you have the right to know what personal information we collect and how we use and disclose it — §2, §5 and §10 set that out in full, and you can request the same information for your own account by email. You have the right to delete personal information we hold about you, the right to correct inaccurate personal information, and the right not to be discriminated against for exercising any of these rights: we will not deny you the service, charge you a different price, or give you a lesser level of quality because you made a request. The mechanisms are the ones already described here — Settings → Delete Account in the app, or privacy@mintmetric.app — and the exceptions in §14 apply to a California deletion request in the same way.

We do not sell or share your personal information as those terms are defined by the CCPA and CPRA — we do not sell it, and we do not share it for cross-context behavioural advertising. There is accordingly no “Do Not Sell or Share My Personal Information” mechanism for us to offer you, because there is nothing to opt out of. The sub-processors in §10 receive data only to run the features you turn on, under the agreements listed there.

Withdrawing consent. Where we rely on your consent — the website waitlist, and the optional product analytics described in §8 — you can withdraw it at any time: for the waitlist, by emailing privacy@mintmetric.app; for product analytics, by turning the choice off in the app's Settings, which also retires the on-device identifier and stops collection going forward. Withdrawal does not affect processing that took place before it (Art. 13(2)(c)).

Complaints. You have the right to lodge a complaint with your supervisory authority, or with the European Data Protection Board (Art. 13(2)(d)).

Legitimate interest. Where we rely on legitimate interest (Art. 6(1)(f)) we have weighed that interest against your rights and freedoms (Art. 13(1)(d)). Those cases are narrow: rate limiting, which processes a client address in memory and never stores it; suppression records, which hold an address and a reason so we stop mailing someone who has bounced or complained; cookieless aggregate website analytics; and production crash diagnosis through Sentry. We also retain pseudonymous legal-acceptance evidence so we can document which published terms governed an account, respond to disputes, and establish or defend legal claims without retaining the deleted account identifier.

Whether providing data is required. Providing an email address and a sync passphrase is a contractual requirement when you enable cloud sync or backup — without them we cannot provide those services or account-based subscription management. It is not a statutory requirement, and nothing obliges you to provide it: the free tier works with no account at all (Art. 13(2)(e)).

Legal basis for each processing activity:

14. Data Deletion

What is true today. Account deletion is available from inside the app. This section says plainly what it does, what it does not do, and what survives it.

• Deleting the app from your device removes the local database and the photo files stored with it. On iOS, key material held in the system Keychain can survive an app deletion; the app detects and reconciles that on the next install. Deleting the app does not remove anything from our servers: if you have used an account, the data listed in §5 remains.
• Inside the app you can delete individual holdings and photos. If Secure Sync uploaded a photo and Secure Sync is active on your plan, deleting that photo, or the holding it belongs to, also deletes its encrypted copy from our servers, including stored object versions; the app keeps retrying that deletion until our server confirms it. If Secure Sync is not active on your plan, for example because your subscription has lapsed, that deletion is not sent; the encrypted copy is deleted when you turn Secure Sync off, which is available on any plan, or when you delete your account. The backup controls in Settings let you create, list, download, restore, pin and permanently delete individual cloud backups.
• Turning Secure Sync off deletes all of your Secure Sync data from our servers, for your whole account and not only for the device you use: your encrypted sync records and their history, and your encrypted sync photos, including stored object versions. It also clears the sync key material from that device. The holdings and photos already on each of your devices are kept; another device that still had Secure Sync on stops syncing and keeps its data. We do not report the deletion as complete until our server confirms it — if it cannot finish straight away, for example because you are offline, the app shows it as pending and keeps retrying until it is confirmed. Once our server has accepted the request, it finishes the deletion even if that device goes offline. If the app's data on that device is erased before the request reaches our server, the request is lost with it; you can then email privacy@mintmetric.app to have your Secure Sync data deleted. Turning Secure Sync off does not delete your encrypted cloud backups, which are managed separately in the backup controls, and does not delete your account; account deletion follows its own grace period, described below. After Secure Sync is turned off we keep only a minimal record (§5): a marker that stops old devices from uploading the deleted sync data again, and the random, non-secret salt that was used with your passphrase, so that cloud backups made earlier can still be restored with the same passphrase. We keep no encrypted sync data, no photos and no value derived from your passphrase. This record is deleted when your account is deleted. Turning Secure Sync on again later starts a new sync setup from the data on that device; it does not bring back the deleted server data. To restore a cloud backup made earlier, open your cloud backups in Settings and enter the passphrase you used when that backup was made; you do not need to turn Secure Sync on again, and a different passphrase cannot open it.
• To have your account and its server-side data removed, open Settings → Delete Account in the app. You can also email privacy@mintmetric.appfrom the address on the account, and we will action the request and confirm when it is done. Either route is subject to the exceptions set out below: if mail to your address has bounced or been marked as spam we keep a suppression record (§12), and your RevenueCat subscriber record is retained unless you ask us to remove that as well. Separately, deleting your account does not cancel a paid subscription — a subscription bought through the App Store or Google Play is cancelled in your App Store or Google Play subscription settings, which account deletion does not perform automatically. A separate support request can ask us to cancel or refund a Google Play purchase where Google's developer tools permit it; Apple handles App Store requests. See §8 of our Terms of Service.

How account deletion works. Settings → Delete Account requests deletion of your account. Here is the sequence it sets in motion.

• Requesting deletion does not delete immediately. The request is accepted — the API answers with HTTP 202 — and returns the date on which deletion is scheduled.
• After that acceptance is confirmed, the submitting device immediately starts an irreversible local erase covering its holdings database, photos, PIN, encryption and sync keys, temporary exports, and account binding. The 30-day grace period applies to surviving server and cloud data, not to that device-local copy. Local-only data cannot be recovered by cancelling the server-side deletion.
• Access is cut off at once: session tokens are revoked, push device tokens are deactivated, and authenticated endpoints are closed to the account.
• Server-side deletion remains reversible for 30 days. Signing in again during that window cancels the scheduled deletion and restores access to server or cloud data that still exists; encrypted cloud recovery may require your sync passphrase. If the app cannot tell whether the deletion request was accepted, it locks product access until an authoritative server check resolves or cancels the request.
• The returned deletion deadline is the exact point of no return: cancellation is accepted only before that instant. At or after the deadline a background job serializes an irreversible transition, locks the account against sign-in and new sync writes, and confirms that deletion is still due. Cleanup is asynchronous and is retried until every required target succeeds; reaching the deadline does not mean every byte has already been removed. The job first appends the account UUID and irreversible timestamp to an independent, erasure journal outside the PostgreSQL backup/PITR domain. It then deletes each encrypted backup archive from DigitalOcean Spaces, deletes your encrypted sync photos there, and deletes the authentication user from Supabase. If an external deletion fails, the server-side database rows remain so the job can retry; an archive or photo deleted before a later external failure cannot be restored. Only after the external steps succeed does one short database transaction erase your encrypted sync blobs, encrypted sync photo records and Secure Sync deletion records; backup metadata and retention-warning records; subscription and entitlement records; spot price alerts and pending alert-delivery rows; push device tokens and revocation rows; certificate lookup quota counters; the timestamp of the last backup-warning attempt; audit rows recording any reactivation; current legal-acceptance state; and account email row, while recording completion of the purge. That is the whole of what §5 records against your account, apart from the items listed below as remaining. The PCGS certificate lookup caches appear in neither list because they are keyed by certificate number alone and hold no account identifier (§5) — there is nothing in them tied to you to delete. The quota counters that are deleted record only how many lookups you made in each rate-limit window, never which certificates you looked up.
• A PostgreSQL snapshot or point-in-time restore is never allowed to restore a deleted account. Before HTTP traffic or workers start, the backend reads the independent erasure journal and reapplies every recorded purge to the restored database, object storage, and authentication provider. Startup fails closed if the journal cannot be read or replayed.

After the authentication user has been purged, the same email address can be used to create a new MintMetric account. That creates a new account identifier; it does not restore the purged account, its erased device-local vault, or any deleted cloud data.

Some things will remain after that purge. Account deletion is therefore not the same as erasure from every system that has ever touched your data, and we would rather say so here than let you discover it later. These are the exceptions we know of, in our own systems and at the sub-processors listed in §10:

• Email suppression records. If mail to your address has bounced or been marked as spam, that record stays for its 12-month retention (§12). It is kept on the basis of our legitimate interest in not mailing an address that has told us to stop.
• Database records evidencing the erasure. Two of these are kept indefinitely, and they are complementary by design — neither on its own links a purged account back to an email address. The first is a marker row keyed by your account identifier: the UUID, and the timestamps for when deletion was requested, when it was scheduled and when the purge completed. If you reactivate instead, those two timestamps are cleared rather than kept. A separate audit row does record each reversal while your account exists, but the purge deletes that too — so in our database a purged account's marker row carries no history of how many times deletion was requested and reversed along the way. That is a statement about our database and not about our logs: as the next item sets out, the application log lines recording those same events are not ours to purge. We retain it as the record that the erasure ran, and it is what stops a late subscription webhook from recreating data for an account that no longer exists. The second is a tombstone — an HMAC-SHA256 keyed hash appended to a log that holds no account data and no plaintext identifier, and that cannot be reversed without the key. One is written for every completed purge, without exception. What it hashes is the email address on the account — or, where no email address was ever stored, the account identifier. That second case applies when the app never used our cloud backup service while you were signed in, because that is the only time we copy an email address into our own database (§5). Where the subject is the account identifier, the tombstone is a hash of a value the marker row already holds, so it widens nothing: it adds no way to re-identify you beyond the record we were keeping anyway. Neither record stores your email address, your name, your holdings or any other account data, and once your account and your authentication user are deleted, the identifier in the marker row no longer maps to you on our systems.
• Independent restore-safety journal. Versioned records with configured retention and deletion protections are retained outside our PostgreSQL and backup restore domains for longer than the maximum configured restore horizon. Before purge they can record reserved, scheduled and cancelled transitions with account UUID, lifecycle generation, request, deadline and record timestamps, plus the scheduled recovery-capability digest and expiry. Before destructive work starts, an irreversible-erasure marker records the account UUID and irreversible timestamp. Successful purge completion is recorded in PostgreSQL rather than as a second journal event. The journal contains no email, holdings, photos, payment details, or profile contents. It preserves accepted cancellations as well as preventing a database or backup rollback from resurrecting data already erased at your request. Provider controls depend on the deployment: supported controls include S3 COMPLIANCE Object Lock retention, or DigitalOcean Spaces versioning with a deletion-denying bucket policy and lifecycle restrictions. The DigitalOcean mode is not COMPLIANCE Object Lock; its protections depend on administrators preserving those policies and credentials.
• Deletion-status capability rows. PostgreSQL retains the account UUID, one-way recovery-secret digest, and creation and expiry timestamps for no more than 400 days, including after purge if that expiry has not yet arrived. They contain no plaintext secret, email or portfolio data and are removed by expiry cleanup.
• Subscription-transfer replay records. The source/destination account identifier link and RevenueCat event timestamps described in §5 remain so late billing events cannot move access back to a former account. This can link a purged identifier to a live destination identifier. We use it only for entitlement ordering and include it in access requests; contact privacy@mintmetric.app about a specific retention or erasure request.
• An unresolved subscription webhook delivery. A delivery accepted before the purge may remain temporarily while processing is retried. Ordinary events for the purged account are then discarded; a transfer involving another live account may still be applied so subscription ownership is not left on the erased account. The queue row is deleted immediately when that processing finishes.
• Pseudonymous legal acceptance evidence. The append-only HMAC-keyed subject hash and document/action/build/timestamp fields described in §5 remain after the current account row is deleted. We retain them to evidence the legal terms presented and accepted; they contain no holdings, photos, email address or payment details and are included in access requests where we can match the requesting account.
• Your RevenueCat subscriber record. RevenueCat will keep the subscriber record — an app_user_id, which is your account identifier, and the associated purchase history. We leave it in place deliberately: deleting a MintMetric account does not cancel a subscription bought through the App Store or Google Play, and if you return with the same store account, destroying that history would leave you paying for an entitlement you could no longer restore. There is no self-serve control that deletes it. If you want it removed anyway, email privacy@mintmetric.app and we will arrange it with RevenueCat.
• Your waitlist email address. If you joined the website waitlist, that row — the email address, the referrer and any campaign parameters (§2, §12) — is stored separately from your account and is keyed by the email address rather than by your account identifier. The account purge does not reach it, and it is kept until you ask us to remove it (§12). To have it removed, email privacy@mintmetric.app from the address you signed up with, or use the same address in a request under §13, and we will delete it and confirm when it is done.
• Application log lines. Our application logs record significant account events against your account identifier — when a deletion was requested, when one was reversed, when a request was refused, and when a Secure Sync server deletion completed or had to be retried — each with the time it happened (§12). The purge empties our database, but it does not reach the logs: they are held by our hosting platform under its own retention settings, and they age out on that schedule rather than on ours. So for as long as those entries live, they carry the reversal history the marker row above does not. Alongside the identifier and the event they hold limited technical detail about it — the date a deletion was scheduled for, the sign-in method a refused request presented, or the error that caused a step to fail. They never contain your email address, your name, your holdings or your IP address.
• Transactional email we already sent you. Any email we sent you — in practice the backup retention warnings (§3, §12) and the account-deletion emails (§3) — stays in the sending history held by our email provider, Postmark (§10), along with the address it went to and the message content. The purge does not reach into that history; nothing in our systems can delete it. If you want it cleared, email privacy@mintmetric.app and we will arrange it with Postmark.

Beyond that list, records held by parties who are not processing on our behalf sit outside this purge altogether. Apple and Google keep their own record of App Store and Google Play transactions as sellers of record (§10), under their own policies and retention periods. We cannot delete those for you, and asking us will not reach them — they are requested from Apple or Google directly.

15. Children's Privacy

MintMetric is not directed at children under 13. We do not knowingly collect information from children. If you believe a child has provided us with personal information, contact privacy@mintmetric.app and we will remove it.

16. Cookies and Local Storage

The website sets no advertising or analytics cookies — Plausible is cookieless by design (§8). One short-lived cookie is used only if you access a password-protected preview build of the site, to remember that you entered the password.

The app uses your device's local storage for the encrypted portfolio database, your item photos, your preferences, and the key material described in §4. MintMetric itself transmits none of it to our servers except as set out in §2 and §4 — and what does leave the device for our servers is the ciphertext described there.

Operating-system device backups. Separately from anything MintMetric does, your phone's operating system can include app data in a device backup or a new-device transfer that you ask Apple or Google to perform. That backup is operated by Apple or Google under their own terms and policies, not by us, and it never reaches our servers. What the operating system is allowed to include is deliberately constrained, and it differs by platform:

• iOS. Your vault — the encrypted database and your item photos — and the app's runtime-authority journal are marked excluded from iOS device and iCloud backups, so they are not copied into one. The device-bound values in §4 — the database key, and your saved sign-in session, its PKCE verifier and a pending vault-reveal marker — are held in the iOS Keychain with “this device only” accessibility: they can be carried in an encrypted backup, but they remain bound to that one device and are not restored onto a different device. Ordinary, non-sensitive app preferences that are not specifically excluded can be included in an Apple device or iCloud backup.
• Android. MintMetric disables Android auto-backup and sets data-extraction rules that exclude the entire app data directory (the encrypted database and your photos), all app and secure preferences, and the no-backup journal from both Google Drive cloud backup and Android device-to-device transfer. In practice no MintMetric app data is carried into an Android backup or a new-phone transfer.

In every case an operating-system backup is one you direct Apple or Google to make; the encrypted, account-backed uploads to our own servers are only ever the ciphertext described in §4 and §5.

17. Changes to This Policy

We may update this privacy policy from time to time. Changes will be posted on this page with an updated revision date. Where a change alters what data leaves your device — for example adding a new analytics or diagnostic data category — we will update this page as part of that change rather than after it. That is how the account deletion copy in §14 was updated when the feature landed.

18. Contact

Data controller. The controller of the personal information described in this policy is Nimbus Foundry, LLC (a Wyoming limited liability company); its registered agent is in Sheridan, Wyoming, United States. MintMetric is a product of Nimbus Foundry, LLC.

Registered Agent:

Mailing Address:

Data protection requests — access, correction, erasure, portability, restriction, objection and withdrawal of consent — go to privacy@mintmetric.app. The same company details, and a form if you prefer one, are on our contact page.

• privacy@mintmetric.app — all data protection matters: access, erasure, portability, objection, withdrawing consent, and any question about this policy. This is the correct address for every request described above.
• support@mintmetric.app — general product support, including App Store and Google Play matters.
• legal@mintmetric.app — terms of service and legal notices.

There is no named data protection officer. privacy@mintmetric.app is a monitored role address and is the route for every request under this policy.