LiqGuard has no accounts, no emails, no passwords, no names. It knows your device by a push token — an identifier that isn't tied to your name, email, or payment details — it knows the public wallet addresses you choose to add, it keeps the latest figures it computed for those addresses, it knows whether your device has an active subscription, and our servers keep standard web-server logs, which include IP addresses. We rate-limit by IP as requests arrive, for abuse prevention. Section 2 lists the data we collect and why. The rest is the server logs just mentioned, the hashed API credential in section 5, the alert record in section 4, and routine bookkeeping about your own records — such as when you added an address, when we last tried to alert you, and whether your device is still reachable. As of the effective date above, we don't sell your data, we share it only with the providers listed in section 3 — its only third-party SDK is RevenueCat — the app shows no ads, and it contains no advertising or tracking SDKs. If any of that ever changes, this page and our App Store privacy labels will say so before it does. That promise is being kept right now: we have decided to show ads in the free tier, and section 7 is the advance notice. Nothing described there has started — when it does, this page will be rewritten in the present tense with a new effective date.
| Data | Why |
|---|---|
| Apple push-notification token, and the date your device first registered and last contacted us | Delivering liquidation alerts to your device. This is also your "identity" — there is no account. We also record when the device registered and when it last contacted us as part of that record. |
| A name you give a wallet, if you choose to set one | Showing it in the app instead of the address, so several watched wallets can be told apart. It is optional, we never require it, and it is used for nothing else — the monitor does not read it, RevenueCat never receives it, and it is not included in any alert we send. Like every other column it is present in the backups described in section 4. Because it is text you write, it can contain whatever you put in it: if you would rather it held no personal detail, leave it blank or use something neutral. It is deleted with the wallet, subject to the backup note in section 4. |
| Public wallet addresses you add, and the supported perpetual DEX each one is watched on | Reading their publicly available position data from that DEX to compute liquidation distance. Hyperliquid is currently the only supported one. |
| The alert threshold you set for each address, the repeat-alert schedule you choose for it if you turn repeat alerts on, and the latest figures we computed for it — distance to liquidation, whether it had crossed your threshold, when we last checked, and — if your device tells us alerts can reach you normally again — the time it said so | The threshold and the last distance are how we detect that a position has crossed it, and the last distance is shown in the app when live data isn't available. Each cycle overwrites the previous one; apart from the alert record and backups described in section 4, we keep no history of these figures. If you turn repeat alerts on, we also record the interval you chose and — while a repeat is running — when it ends and when we last re-sent, so the same warning can be re-sent at your chosen pace until you act, the position recovers, or a fixed span runs out. Re-sends are not added to your alert history: the original alert is the record. That last time is recorded only so we can re-send a warning you may have missed while alerts were not reaching you normally — for example if they were switched off, silenced, or not marked as time sensitive — and is cleared as soon as we do. |
| Which alert sound you chose, if you changed it from the standard one | Naming that sound in the alert we send, so your device plays the tone you picked. It is one of a small fixed set of choices, not text you write, and it is used for nothing else. If a Pro subscription ends we keep the choice rather than discarding it, so it comes back if you subscribe again; until then your alerts use the standard tone. |
| Alert history (which alerts we sent, when, delivered or not) | Preventing duplicate alerts and auditing that the safety function worked. |
| Not yet collected — from the launch of advertising (section 7): an advertising identifier, your IP address, device and connection information, approximate location derived from that address, which screen an ad appeared on, whether you interacted with it, and diagnostic data about the ad itself | Selling the ad slot by auction, measuring whether an ad was shown, limiting how often you see the same one, and detecting click fraud. Free tier only — LiqGuard Pro will send none of it. It will be collected on your device by Google's SDK rather than sent to us — though our web-server logs record IP addresses for every request, as section 1 says, so that one item reaches us by a different route. It will never be combined with your wallet addresses or positions; section 7 states that promise in full, and says plainly what it rests on. |
| Subscription status and purchase history (from RevenueCat/Apple), including when your Pro period ends and whether auto-renew is off | Applying free vs Pro limits, and sending you notifications about your own subscription — when you turn auto-renew off (confirming when Pro ends), a few days before it ends if auto-renew is still off, and when it has ended and wallets beyond the free limit are paused. We never see your payment details — Apple handles payment entirely. |
| Whether you asked to be told when Pro subscriptions reopen, and when you asked | If Pro is full and you tap the waitlist button, we record the request so we can send you that one notification. The record is cleared when the notification is sent, or when you subscribe. It is used for nothing else. |
Wallet addresses are already public information on a public blockchain; adding one to LiqGuard tells us you're interested in it, which is why we treat the association between your device and your addresses as private and never share it.
As of the effective date above, we don't share your data beyond the parties listed here, we don't sell it, and nothing we collect is used for advertising; the notice in section 1 applies if that changes.
Removing a wallet in the app stops monitoring it immediately and removes the address from your account. We keep a record that an alert was sent — the time, which alert it was, the risk band, the alert threshold that was set, an approximate distance-to-liquidation, the market and leverage of the position that triggered it, and whether it was delivered. Your address is not kept; in its place is a fingerprint computed with a private key we hold, so we can check an address you give us against our records. Without that key the record cannot be turned back into your address. The record no longer references your account or device. It is deleted from our database after two years.
Removal takes effect in our live database immediately. We also keep private, access-controlled backups of that database, so a copy made before your removal can remain in the backup set afterwards.
That alert record is deliberately kept even when you remove a wallet, because it is how we can answer "did the alert fire?" — including when you are the one asking. We keep no more of it than that question needs.
If you delete the app, your push token stops working — but we only discover that the next time we try to send you an alert, so monitoring can continue until then, and if nothing crosses your threshold it can continue indefinitely. If you want it stopped now, remove your wallets in the app before deleting it, or email us. To have your account and wallets deleted, email support@liqguard.app — since we hold no account details, include the wallet address(es) you had added so we can locate them. We keep that email only as long as it takes to action the request, then delete it.
A deletion request removes your account and your watched addresses. The alert records described above are retained for the rest of their two years: they no longer link to your account or device, and on their own they cannot be turned back into an address. We are being precise rather than absolute here — because we hold the fingerprint key, an address is something we can still check a record against, which is exactly the capability that lets us answer "did my alert fire?" for you later.
Some things outlast a deletion request, and we would rather name them than let you discover them. Our log of subscription events from RevenueCat — event type, timing, and the numeric app-user id, never your addresses — is kept so that a re-delivered event cannot re-apply an old subscription change. It is deleted after 90 days. Our web-server logs, which include IP addresses, are rotated on the server's own schedule and are not searched or purged in response to a request. And a backup taken before your request, as described above, remains in the backup set. If any of these matter to you, say so in your deletion email and we will tell you what we can do.
Transport is TLS end to end. API credentials are stored hashed; secrets live only on the server. The service is read-only by design — it holds nothing that could move funds.
LiqGuard is a financial monitoring tool and is not directed at children under 18, is rated for adults, and is not offered in the App Store's Kids category. We do not ask your age, so we cannot know it; if you believe someone under 18 is using LiqGuard, write to us and we will delete their records. When advertising launches (section 7) it will be configured as a general-audience adult app under Google's policies — deliberately NOT tagged as directed to children, because that tag is a declaration about this app that would not be true.
This section describes something that has not started. It is here because section 1 promises to tell you before it does, and because the law we are subject to expects notice at or before collection rather than after. As of the effective date above, no ad has been shown, no advertising SDK is in the app, and none of the advertising described below is happening yet. When it starts, this page will be rewritten in the present tense with a new effective date.
LiqGuard is free today, and advertising is how we intend to keep it free. The ads will be sold by auction: when an ad slot appears, Google AdMob will send a request describing your device and the moment to ad networks that bid to fill it. Those networks will receive the advertising row in section 2 — an advertising identifier, your IP address, device and connection information, approximate location derived from that address, and which screen you are on.
Under California law that will count as selling and sharing personal information. We say so plainly rather than relying on a narrower reading of either word: bidding is what those terms were written about.
Ad networks will never receive your wallet addresses, your positions, your liquidation distances, the names you give your wallets, or your alerts. What holds that up is simply that we will never hand them over, and we would rather say so than dress it up as something stronger: an advertising SDK would be compiled into the app and would run with the app's own permissions, so the guarantee is about what we pass to it, not about what it is prevented from reaching. Keeping that true is a discipline, and it is written into our release checklist as one. Section 2's promise about the association between your device and the addresses you watch is unchanged by any of this.
One thing an auction reveals that no such list can cover: every bid request carries the app it came from. A network bidding to show you an ad will know it is bidding inside LiqGuard, and so that you are someone who watches leveraged positions. Running an auction at all means revealing that, so we would rather you read it here than work it out later. Pro will remove the auction entirely.
Before the first ad is shown, you will be able to: turn off personalised ads, so an ad is chosen from the screen you are on rather than from an advertising profile; opt out of the selling and sharing described above, a control we will offer to everyone and not only to California residents; and say no to the iOS prompt that asks whether apps may track you, which stops that identifier being available to the ad networks at all — our own servers never receive it under any of these settings. LiqGuard Pro will show no ads. Pro will also send nothing to an advertising partner, which is the stronger of the two: it means that code is never asked to run at all, rather than asked to run and told to stay quiet.
As of the effective date above, the first two of those controls now exist in the app's Settings, no advertising does, and the iOS tracking prompt is not shown because there is nothing yet to track. When advertising starts, this section will be rewritten in the present tense with a new effective date. Controls first, advertising after: that ordering is the point of this section.
Material changes to this policy will appear on this page with a new effective date. Questions or deletion requests: support@liqguard.app.