Skip to main content

Privacy Policy

This policy explains what personal data Stellar Index collects when you use the explorer at stellarindex.io or the API at api.stellarindex.io, why, for how long, who processes it, and what rights you have. The short version: we run no advertising or analytics trackers, we never sell data, and the only personal data we hold is what an account and abuse-prevention use — an email address, IP addresses and browser user agents. Section 6 lists how long each is kept; some records have no automatic deletion.

Last updated: 2026-09-30

1. Who we are

The data controller

The data controller for the Service is Loop Finance Ltd (company no. 16862033), a company registered in England and Wales, trading as Stellar Index (the “Operator”, “we”, “us”). Registered office: Unit 9 Vinnetrow Business Centre, Vinnetrow Road, Runcton, Chichester, England, PO20 1QH. Contact for anything in this policy: security@stellarindex.io. We acknowledge every message within 72 hours.

We have not appointed an EU representative under Article 27 GDPR; we rely on the Article 27(2) exemption for occasional, low-risk processing. We will appoint one if that changes.

Our servers and database are hosted by Hetzner in Germany (mainnet) and Finland (test networks). Personal data leaves the EU only for the processors listed in section 5. The UK GDPR and the EU GDPR both apply to this processing.

2. Browsing and anonymous API use

No account, no tracking

You can use the whole explorer and read every public API endpoint without an account. When you do, we process:

IP address
Used to enforce the anonymous per-IP rate limit: a counter keyed by your IP address (for IPv6, its /64 block) is held in our cache (Redis) for the current one-minute window and expires within minutes. It is not written to the account database.
Invalid API keys
Requests that present an invalid API key are counted per IP address (IPv6 per /64 block) and per key prefix in our cache (Redis), so that guessing keys can be throttled. These counters expire within minutes.
Request logs
Standard server logs (request path, status, timing, user agent, IP) for operating and securing the Service. Query strings, API keys and the Referer are not logged; for a slow request we also log the query shape: the names of the parameters it used, and the values of a fixed list of enumerated or numeric ones (for example limit and order_by); any other parameter is reduced to its name, so free-text and identifying values are never logged.

Our server logs, including web-server access logs with client IP addresses, are kept for up to 30 days in our log store (Loki) and up to 14 days in the host system journal. Application and database log files on the host are rotated weekly and kept for about ten weeks; the database logs slow queries in full, which can include the values a query carried. All are used only for operations, security, and abuse investigation.

The explorer web site is served by Cloudflare, a processor acting under its data-processing agreement with us (section 5). Its edge sees your IP address and requests to the site in transit and keeps request logs under Cloudflare’s own retention, which we do not set. If a page fails to render, the explorer sends an error report (the error message, a digest, the page section and the page path — no account data) to Cloudflare, where it lands in our function logs.

Asset icons are published by their issuers. Your browser loads them from our own /icon endpoint, which fetches the issuer image from our edge, so the issuer’s host does not see your IP address or user agent. The icon is cached for up to a day.

We load no third-party analytics, advertising, or social-media scripts. The explorer writes nothing to your browser’s local storage. It sets one sessionStorage flag when it has to recover a failed page load, so the page does not reload itself over and over; the flag is cleared when you close the tab and never leaves your device.

3. Accounts, sign-in and API keys

What an account actually stores

Sign-in is passwordless: you enter an email address, we send a single-use magic link (or a short code), and clicking it creates a session. Passkeys (WebAuthn) can be added as a second sign-in method. We hold no passwords. An account can also be created from the terminal with POST /v1/register, which asks for nothing: a name and an email address are both optional, and an address given there is stored as a contact address without being verified. For an account we process:

Email address
Your sign-in identity and the address we send magic links and account notices to. Required to sign in to the dashboard; optional for an account created with POST /v1/register.
Sign-in requests
Each magic link we issue is recorded with the email address and the IP address that requested it. To limit abuse we also count requests per IP address and per email address over a rolling hour in our cache (Redis).
Account name
Derived from your email address when the account is created at sign-in, or the name you gave to POST /v1/register.
Passkey public keys
If you register a passkey, its public key and credential ID. The private key never leaves your device.
API keys
We store a hash of each key, its name, tier and limits, and — each time it is used — the last-used time, IP address and user agent. Your dashboard shows the last-used time; the IP address and user agent are included in your data export.
Usage counts
Per-account request counts by day and by endpoint (successful, client-error, server-error and rate-limited) for your quota and the usage chart in your dashboard, plus short-lived per-minute rate-limit counters. All keys on an account share one set of counters. These are counts, not request bodies.
Sessions
For each dashboard session: creation time, last-seen time, the first and most recent IP address, the user agent, and a country code where the request carries one (empty in production).
Audit log
Security-relevant account actions (sign-in, key minted, key revoked, and similar) with the acting IP address and user agent.
Webhooks
If you register a webhook: its name, HTTPS URL, event types and signing secret, and a log of each delivery attempt including the payload sent and the response status.
Price alerts
If you create a price alert: the asset pair, condition, threshold and when it last fired.

Before POST /v1/signup was retired, an API key could be requested without a dashboard account. For those keys we hold a SHA-256 hash of the email address given, with no expiry. New keys are issued through POST /v1/register, which keys nothing on an email. An unsalted hash of an email is still personal data — it can be reversed by guessing the address — and we treat it as such. Such a key is not part of an account, so the export and erasure in section 8 do not cover it; ask us by email.

The lawful basis for each purpose (UK GDPR and EU GDPR Art. 6(1)):

Contract
Your account, its email address, API keys and dashboard sessions, and the messages we send to the address: necessary to provide the account you asked for (Art. 6(1)(b)).
Legitimate interests
Our legitimate interest in keeping the Service secure and available, and enforcing fair use (Art. 6(1)(f)): the audit log, anonymous request logs, per-IP rate-limit counters (IPv6 per /64), invalid-API-key counters, the sign-in device cookie, the sign-in request records, the CDN edge logs, client error reports, the POST /v1/signup email hash, and the proxied asset-icon requests.
Legal obligation
None today: we keep no record because a law requires it (Art. 6(1)(c)). If that changes we will say so here.

An email address is needed to sign in to the dashboard; without one you can still use anonymous reads and POST /v1/register keys.

4. Why we keep IP addresses at full resolution

A deliberate, documented decision

Several of the records above hold a full IP address rather than a truncated or hashed one. That is deliberate. The sign-in endpoint is unauthenticated by design — anyone can ask for a magic link to any address — so the IP behind each request is the only signal that lets us throttle inbox-bombing and detect an attacker minting links for someone else’s mailbox. Likewise, the IP on a session and on an API key’s last use is what lets us recognise a hijacked session or a leaked key; both are included in your data export. A masked prefix would defeat all three controls.

Some IP-bearing records are deleted automatically and some are not: the last-used IP of an API key and the IP addresses on audit-log entries are kept until the account is erased (section 6). We do not use IP addresses for anything other than security, abuse prevention, and operating the Service. We do not geolocate you for advertising, profile you, or link your IP to third-party data.

5. Who processes data for us

Only the providers the Service actually runs on

We do not sell personal data, and we do not share it with anyone except the providers below, each acting on our instructions, and where the law requires us to.

Cloudflare
Serves this explorer web site from its edge network (CDN), keeps edge request logs, and receives the client error reports described in section 2. United States; data-processing agreement with standard contractual clauses.
Resend
Transactional email delivery, via Amazon SES in the us-east-1 (United States) region. Receives your email address and the sign-in and account-security messages we send to it. Data-processing agreement with standard contractual clauses.
Google Workspace
Hosts the security@stellarindex.io mailbox, so it receives anything you email us, including rights requests. United States; data-processing agreement with standard contractual clauses.
GitHub
Issue tracker for public reports. If you open an issue or discussion, GitHub processes it under its data-processing agreement and its own privacy policy; we do not run a support inbox for general questions.
Hetzner
Hosts the API servers and the database in which account data lives, in Germany (mainnet) and Finland (test networks).
Backblaze
Holds the off-site copies of the database, in its eu-central-003 region (Amsterdam, Netherlands). The copies are encrypted (AES-256) before they leave our servers, so Backblaze cannot read them.

The account database is hosted in the EU. Where a provider above processes data in the United States, the transfer relies on the standard contractual clauses in that provider’s data-processing terms (or a UK or EU adequacy decision where one applies). You can ask us for a copy of the clauses that apply to your data by email.

There is no payment processor. The Service has no paid tier and no billing surface (ADR-0049), so we never collect card or bank details.

6. How long we keep it

The retention each record is actually held to

Magic-link tokens
Valid for 15 minutes. Expired tokens (email + requesting IP) are deleted automatically 48 hours after expiry; the delay preserves a short forensic window on sign-in floods.
Sign-in lockouts
Records of repeated failed sign-in codes (email address only) are deleted automatically 48 hours after the lockout ends.
Sign-in counters
The per-IP and per-email counters that limit magic-link requests live in our cache (Redis) for a rolling hour; the invalid-API-key counters in section 2 expire within minutes. Both expire automatically.
Sessions
A dashboard session lasts up to 30 days, or until you sign out or we revoke it. The session record (including its IP addresses and user agent) is deleted automatically 90 days after it expires or is revoked.
API keys
The last-used IP and user agent are overwritten on each use. Keys, including revoked keys and their last-use details, are kept until the account is erased; nothing deletes them sooner.
Usage counts
Daily per-endpoint counts are deleted automatically after 12 months (in practice up to about 15, as they are dropped in 90-day blocks).
Webhook deliveries
The delivery log, including payloads, is deleted automatically 30 days after it was queued, once no retry is pending.
Webhooks and alerts
A webhook or price alert you configure is kept until you delete it or the account is erased.
Signup email hash
The email hash kept from the retired POST /v1/signup has no expiry; email us to have it deleted.
Audit log
Nothing deletes or archives audit-log entries: they are kept indefinitely. An account erasure pseudonymises them by stripping the identifying fields (section 8).
Account and email
Kept indefinitely while the account exists; nothing deletes an inactive account. An erasure deletes the account record and pseudonymises the records that are kept (section 8).
Server logs
Log store (Loki) 30 days; host system journal 14 days; application and database log files on the host about ten weeks (section 2).
CDN logs
Cloudflare's edge request logs and the function logs that receive client error reports are held by Cloudflare under its own retention, which we do not set.
Backups
The local backup repository (a weekly full backup, kept for up to about three weeks) sits on the database host and is not separately encrypted. Local snapshots are kept for 7 days, except one an operator pins by hand, which is deleted by hand. The off-site copy is AES-256 encrypted and expires on a rolling schedule of a few weeks (one full plus seven differential sets).
Correspondence
Email you send to security@stellarindex.io is kept in that mailbox while your request is open and afterwards as a record of how we handled it; ask us and we will delete it once the request is closed.

7. Cookies

Five, all for signing in

The Service sets cookies only for signing in. Because they are strictly necessary for a feature you asked for, no consent banner is shown.

__Host-stellarindex_session
Set when you sign in to the dashboard; identifies your session and expires with it (up to 30 days). HttpOnly, Secure, SameSite=Lax.
stellarindex_session_present
Set alongside the session cookie with the value "1" and the same lifetime, so this web site can tell that you are signed in without reading the session itself. Readable by scripts on the site; SameSite=Lax.
__Host-stellarindex_login_intent
Set when you request a magic link and cleared when you use it; lasts at most 15 minutes. Binds the link to the browser that asked for it so a link cannot be used to sign someone else in. HttpOnly, Secure, SameSite=Lax.
stellarindex_login_device
Set each time you sign in and kept for 400 days. Holds an expiry time and a keyed hash of your email address (not the address itself), so this browser can still request a sign-in link for that address when the per-address sending limit has been used up by someone else. Sent only to the sign-in endpoint; it signs nothing in. HttpOnly.
__Host-stellarindex_passkey_ceremony
Set while you register or use a passkey; lasts at most 5 minutes. HttpOnly, Secure, SameSite=Lax.

Anonymous browsing sets none of ours, and embedded widgets set none either. Our CDN may set a strictly-necessary security cookie (for example __cf_bm) during a challenge.

8. Your rights

GDPR and UK GDPR

If you are in the UK or the EEA you have the right to access the personal data we hold about you, to have it corrected or erased, to restrict its processing, to receive it in a portable form, and to withdraw any consent you have given. You also have the right to object, on grounds relating to your particular situation, to any processing we base on legitimate interests (section 3); if you do, we stop unless we can show compelling legitimate grounds that override your interests. Equivalent rights may apply under other laws where you live.

To exercise any of them, email security@stellarindex.io from the address on your account, so we can verify it is you. We acknowledge within 72 hours and respond within one month. Your dashboard shows your API keys, usage, passkeys, price alerts and webhooks, and you can revoke keys there yourself; it has no view of your sessions other than signing out.

An account owner can also act directly through the API, signed in to the dashboard (an API key cannot do either) and within 10 minutes of signing in: GET /v1/dashboard/account/export returns the account’s records — the account, its members, sessions, passkeys, API keys, webhooks, price alerts, invitations, usage counts and audit log — as a JSON download, and DELETE /v1/dashboard/account erases it; you type the account slug back to confirm. The export does not include cache counters, expired sign-in tokens, or the email hash kept from the retired POST /v1/signup; ask us by email for those. The explorer has no button for either yet.

An erasure takes effect immediately; there is no grace period and it cannot be undone. It deletes the account, its members’ sign-in records, sessions and passkeys, API keys, webhooks and their delivery log, price alerts, pending invitations and sign-in tokens, and the account’s cached counters. Erasing through the API emails each owner a confirmation; an erasure we carry out on an emailed request does not.

Some records are kept after an erasure, pseudonymised so they are no longer linked to you. Audit-log entries are kept indefinitely with their IP address and user agent removed (entries recording an action by our staff keep the staff member’s), and with the account name, email address, account identifiers, key labels, passkey names and suspension reasons stripped from their details; daily usage counts are re-labelled with a random identifier and age out after 12 months; and a hash of the account name is kept so the name cannot be reused. An erasure does not reach database backups and snapshots, which are kept for the periods in section 6; server logs, which age out after about ten weeks; or copies of sent email held by our email provider under its own retention. Erased accounts are not re-created from a backup restore: our restore runbook is required to re-apply erasures before the API serves; if a restore predates your erasure request, tell us and we will erase again.

You also have the right to complain to a supervisory authority. The UK regulator is the Information Commissioner’s Office (ICO). If you are in the EEA you may also complain to your national supervisory authority.

9. Changes to this policy

How you will find out

Material changes will be posted on this page with a new “last updated” date and a row in the policy history below, and, where we hold a verified email address for the account, sent to it. The changelog is not the notice. This policy is part of the terms of service.

Policy history

  • 2026-09-30 — first published