Privacy Policy

Version 2026-09-09. Effective 2026-09-09. Supersedes the version of 2026-08-19.

This policy explains what personal data we process about you when you use merkleset, why, on what legal basis, how long we keep it, and what you can ask us to do about it.

It is short because the service collects little. We run no advertising, no profiling and no session recording, and we do not sell or share personal data.

What changed in this version. Where our data is stored changed. What we collect did not. Until 2026-09-09 the object storage holding dataset release artifacts and our internal raw evidence ran on our own application host. It now runs in DigitalOcean Spaces, the managed object storage of the same provider that already hosts the platform — so no new company sees your data — but it is a third-party managed service rather than software on a machine of ours, and it sits in a different United States region from the application host: storage in sfo3 (San Francisco), the host in nyc1 (New York). Three passages moved with it. Section 10 no longer says object storage has no public port, because that described the old arrangement and is not true of a managed service. Section 11 now says where the internal raw evidence lives, since that is the one tier that is unscreened. And your downloads are now fetched straight from the storage provider rather than through merkleset.com. The opt-in analytics introduced on 2026-08-19 is unchanged and still requires your consent.

There are two separate subjects that this policy keeps apart:

1. Personal data about you, our customer or visitor — an email address, a login history, consent records, billing details, and now site-usage measurement if you agreed to it. That is what this policy is about.
2. Personal data inside the datasets we sell. Datasets are built to contain no personal data, screening runs in the pipeline before any published hash is computed, and the scope and known gaps of that screening are documented in clause 7 of the Data License Agreement. Section 11 below covers it.

1. Who is responsible

The controller is Andrii Sukhanov, a natural person trading as an independent professional (autónomo) registered in Spain, NIE Z2338955K, using merkleset as a trading name.

Postal address: Av. Marítima 2, puerta 05c, 38479 Los Silos, Santa Cruz de Tenerife, Spain.

Data protection contact: privacy@merkleset.com (Andrii Sukhanov handles these requests personally).

We have not designated a Data Protection Officer. At this scale of processing — no large-scale monitoring, no special category data, no public-authority role — the GDPR does not require one. If that changes we will designate one and say so here.

Because the controller is established in Spain, the GDPR applies directly and no Article 27 representative is required.

2. What we process, why, and on what basis

Data	Where it comes from	Purpose	Legal basis
Email address	You, at sign-up and login	Identify your account; send the one-time login code	Performance of a contract (Art. 6(1)(b))
Account timestamps: created, last login	Generated by the service	Operate and secure the account	Performance of a contract (Art. 6(1)(b))
One-time login code, stored only as a SHA-256 hash, and a per-email rate-limit counter	Generated by the service	Authenticate you; prevent brute-force and abuse of the login endpoint	Performance of a contract; legitimate interests in security (Art. 6(1)(b), (f))
Refresh tokens, stored only as SHA-256 hashes, with rotation and revocation timestamps	Generated by the service	Keep you signed in; detect stolen tokens	Performance of a contract; legitimate interests in security (Art. 6(1)(b), (f))
Consent records: document id, version, SHA-256 hash of the exact text, acceptance timestamp	Generated when you accept a document	Prove which version of which document you accepted	Legal obligation (Art. 6(1)(c)); performance of a contract (Art. 6(1)(b))
Entitlements: your user id, dataset, plan, expiry, and the release cutoff of a one-time purchase	Generated when a subscription or one-time purchase starts	Decide whether you may download a release	Performance of a contract (Art. 6(1)(b))
Wallet ledger, append-only: signed amounts in cents, a reason (top-up, download debit, or adjustment), the release a debit paid for, the Stripe event identifier of a top-up, timestamps	Generated when you top up the prepaid wallet or a download is debited from it	Compute your balance, deliver what you paid for, keep billing records, defend against fraud and abuse	Performance of a contract; legal obligation; legitimate interests in fraud and abuse defence (Art. 6(1)(b), (c), (f))
Analytics measurement data: a randomly generated Google Analytics identifier stored in a first-party cookie on your device; the pages you view, when, in what order and for how long; the site or search that referred you; approximate location derived from your IP address (typically country, region and city); and device and browser characteristics — device type, operating system, browser, screen size and language	Generated in your browser by Google Analytics 4 and sent to Google, only if you have accepted analytics in the cookie banner	Understand which pages and datasets people actually use, and where visitors come from, so we can improve the site	Consent (Art. 6(1)(a)), given through the cookie banner and withdrawable at any time
Application request logs: method, path, status code, duration	Generated by the service	Diagnose faults, detect abuse	Legitimate interests (Art. 6(1)(f))
Web server access logs: client IP address, timestamp, request line, status, user agent	Generated by our reverse proxy	Security, abuse investigation, fault diagnosis	Legitimate interests (Art. 6(1)(f))
Contact form: your name, email, company (optional), message, plan of interest (optional)	You, when you submit the form	Answer your enquiry	Legitimate interests, and steps before a contract (Art. 6(1)(f), (b))
Billing data: name, email, billing address, tax identification number, transaction and payment metadata	You, through Stripe's checkout	Take payment, issue your invoice, determine and remit taxes, handle disputes	Performance of a contract; legal obligation (Art. 6(1)(b), (c)). See section 6 on Stripe's own role

That table is the complete list. We do not build profiles, we do not score you, and no decision about you is made by automated means.

Analytics runs only with your consent, and only after it. On your first visit every storage category is denied under Google Consent Mode v2, the Google Analytics script is not loaded at all, and no measurement request is made. It loads only when you accept. Refusing loads nothing and is remembered. Withdrawing is described in section 8 and in the Cookie and Local Storage Policy, which lists the exact cookies involved and their lifetimes.

We do not tie analytics to your account. We do not send Google your email address, your user id or any other identifier we hold, and we do not use the Google Analytics User-ID feature. The identifier in the analytics cookie is generated in your browser and means nothing to us outside Google's reporting interface.

The advertising signals stay off. ad_storage, ad_user_data and ad_personalization are denied permanently and are never granted, whatever you answer. We run no advertising, no remarketing and no conversion tracking, and Google Analytics data is not linked to any Google Ads account.

Your IP address and analytics. Google uses your IP address to derive the approximate location described above. Google states that IP addresses are not logged or stored in Google Analytics 4; we cannot verify that independently, we do not receive your IP address in the reporting we see, and we are repeating Google's statement rather than making it ourselves.

Application logs are deliberately thin. The request logging interceptor records the method, path, status and duration only — never request bodies, query strings or headers. Our reverse proxy writes ordinary web server access logs, which do include the client IP address; that is the one place we record an IP address, it is server-side, and it is unrelated to analytics.

Card data never reaches us. The purchase transaction — a subscription, a one-time purchase or a wallet top-up — is processed by Stripe as merchant of record, on a Stripe-hosted checkout page. We receive confirmation and billing metadata, never full card numbers and never payment credentials; of a wallet top-up we keep only the Stripe event identifier, the amount, and the resulting ledger entry described above.

3. What we do not do

• We do not sell personal data, and we do not share it for cross-context behavioural advertising.
• We run no advertising pixels, no remarketing, no conversion tracking and no session recording, and the advertising consent signals are permanently denied.
• We run no analytics unless you have accepted it, and no other third-party script at all: the Google Analytics tag is the only third-party code the site can load, and it loads only on your consent.
• We do not use your data to train models. Our datasets are built from government sources, not from customer activity.
• We do not track you across other websites, and we serve no advertising.

4. Cookies and local storage

The site uses four client-side storage items that are strictly necessary — the two login tokens in localStorage, the NEXT_LOCALE cookie that remembers your language choice, and merkleset.consent, which records the analytics decision you made in the banner so that we do not ask again and so that a refusal is respected. Two further cookies, _ga and _ga_HZFYWX9XE4, are set by Google Analytics — and only if you accepted analytics.

The banner is opt-in and script-blocking: nothing non-essential is stored or loaded until you say yes, refusing is as easy as accepting, and the choice can be changed at any time from the footer. The full inventory, with purposes and lifetimes, is in the Cookie and Local Storage Policy.

5. How long we keep it

Data	Retention
Account record (email, timestamps)	While your account exists; deleted on request, subject to the rows below
One-time login code	10 minutes, then it expires automatically
Login rate-limit counter	15 minutes
Refresh tokens	Up to 30 days from issue; revoked tokens are kept until expiry to detect reuse
Consent records	For the life of the account and then {{CONSENT_RETENTION_YEARS}} years, because they are the evidence of what you agreed to
Entitlements	For the life of the subscription or purchase, then retained as billing records for the period stated below
Analytics measurement data, held by Google	User-level and event-level data is deleted after the retention period configured in our Google Analytics property, which is {{GA_DATA_RETENTION_MONTHS}} months. Google's retention control offers 2 or 14 months for this data and it governs the exploration reports; Google separately keeps aggregated report data, which does not identify you, independently of that setting
Analytics cookies in your browser	2 years from your last visit by Google's default, capped shorter by some browsers — see the Cookie and Local Storage Policy. Clearing site data removes them at once
Your analytics decision (merkleset.consent)	On your device until you clear site data or change the choice
Application request logs	Container logs rotate at a fixed size (10 MB × 3 files per service), so retention is bounded by volume rather than by a date
Web server access logs	14 days
Contact form emails	In the destination mailbox, {{CONTACT_MAIL_RETENTION_MONTHS}} months
Billing and invoice records, including the wallet ledger	{{BILLING_RECORD_RETENTION_YEARS}} years, as required by Spanish tax and commercial law

Where a retention period above is a placeholder, the period has not been fixed yet and will be stated here before this policy is published as final.

6. Who else processes it

We use four external providers, listed with their role, data categories, location and transfer mechanism in the Subprocessor annex: DigitalOcean (hosting and object storage), Stripe (payments), Mailgun (transactional email) and Google (analytics). We use no content delivery network.

Where the data sits. The application, its databases and its logs run on a DigitalOcean virtual host in the nyc1 (New York, United States) region. Dataset release artifacts and the internal raw evidence described in section 11 are held in DigitalOcean Spaces, the same company's managed object storage, in the sfo3 (San Francisco, United States) region. That is two regions of one provider under one contract, not two providers; the annex records the split.

Google receives analytics data only with your consent. If you accept analytics, the data described in section 2 is sent to and processed by Google in connection with Google Analytics 4. We have configured the property for our own measurement purposes and do not link it to any advertising product. If you refuse, or have not answered the banner, no request reaches Google at all — including no request for the script itself.

Stripe is not simply our processor. Stripe acts as merchant of record for the purchase: it invoices you, collects and remits applicable taxes, and handles payment disputes. For that billing relationship Stripe determines its own purposes and acts as an independent controller, and its own privacy notice applies to it. We remain the controller for your account and your use of the service. This matters when you exercise your rights: a request about your account comes to us, and a request about the billing relationship may need to go to Stripe as well — tell us and we will point you to the right place.

We do not otherwise disclose personal data, except where we must to comply with a legal obligation or a valid order from a competent authority, or to establish or defend a legal claim.

7. International transfers

Mailgun is used in its EU region, so login-code and contact-form email stays within the EU.

Our hosting and object storage provider, DigitalOcean, LLC, is a United States company, and both of the regions we use are United States datacentres — the application host in nyc1 (New York) and object storage in sfo3 (San Francisco), as recorded in the Subprocessor annex. Data at rest therefore sits in the United States, so hosting is a transfer to a third country as a fact rather than a possibility. Moving object storage into a second region of the same provider on 2026-09-09 added no new company, no new contract and no new country to that analysis. Stripe likewise operates in both the EU and the US, in its own right as merchant of record.

Google is a United States company, and analytics data is processed on infrastructure that Google operates globally, including in the United States. Accepting analytics therefore involves a transfer to a third country. This is the same question as the two legs above and it is answered the same way: the specific instrument in force is recorded in the Subprocessor annex as {{TRANSFER_MECHANISM}} until we have confirmed and published it. If that matters to you, refusing analytics avoids this leg entirely — the rest of the site works identically.

For those transfers we rely on the provider's own data processing agreement together with the European Commission's Standard Contractual Clauses. The specific instrument in force for each provider is recorded in the Subprocessor annex. You can ask us for a copy of the relevant terms at privacy@merkleset.com.

8. Your rights

Under the GDPR you can ask us to:

1. confirm whether we process personal data about you, and give you a copy (access);
2. correct data that is inaccurate or incomplete (rectification);
3. delete your data (erasure), subject to records we must keep for tax or evidence purposes;
4. restrict processing while a dispute about it is resolved;
5. port the data you gave us, in a machine-readable form;
6. object to processing we base on legitimate interests;
7. withdraw consent where we relied on it.

Withdrawing analytics consent. Analytics is the one thing here we do on the basis of your consent, and you can withdraw it at any time from the cookie-settings control in the site footer. Withdrawal takes effect immediately: the analytics signal returns to denied and nothing further is sent. It does not make the earlier collection unlawful, and it does not by itself delete what has already been sent to Google — for that, ask us at privacy@merkleset.com and we will do what Google's controls allow, and clear the _ga cookies from your own browser. Refusing or withdrawing changes nothing about your account, your entitlements or your access to the service.

How to exercise them. Email privacy@merkleset.com from the address on your account, or tell us which account you mean. We answer within one month and will tell you if we need longer, which the GDPR permits for complex requests. We do not charge for this. We may ask you to confirm control of the account's email address, because that address is the only identifier we hold.

One honest limit on access and erasure for analytics data: it is keyed to a cookie identifier generated in your browser, not to your account, so we usually cannot tell which analytics records are yours. If you can supply the identifier from your own _ga cookie we will use it; otherwise the effective remedy is withdrawal plus clearing the cookie, and we will say so rather than pretend to a lookup we cannot perform.

Deleting your account removes the account record and, by database cascade, its refresh tokens and consent records. We will tell you what we must keep and why — typically invoices and the fact that a particular document version was accepted.

Complaints. If you think we have handled your data badly, tell us first at privacy@merkleset.com. You can also complain to the Spanish supervisory authority, the Agencia Española de Protección de Datos (AEPD, www.aepd.es), or to the supervisory authority where you live or work.

9. Information for California residents

We do not sell personal information and we do not share personal information for cross-context behavioural advertising, as those terms are used in the CCPA as amended by the CPRA. We have not disclosed personal information to a third party for money or other valuable consideration in the preceding 12 months. Our analytics is first-party measurement of our own site, it is used for no advertising purpose, and the advertising consent signals are permanently denied.

The categories we collect are identifiers (email address, and — with consent — the analytics cookie identifier), commercial information (subscription and billing records) and internet activity, which covers the log entries described in section 2 and, if you accepted analytics, the site-usage measurement described there. Purposes are in section 2 and retention is in section 5. You may request access, deletion, correction, and a statement of what we collect, using the route in section 8; we will not discriminate against you for asking. We do not process sensitive personal information for the purpose of inferring characteristics. Browser signals that opt out of sale or sharing are honoured; there is nothing to opt out of, because we do neither.

10. Security

What we actually do, rather than a list of adjectives:

1. No passwords exist. Login is a one-time code emailed to you, so there is no password to leak, reuse or crack.
2. Login codes and refresh tokens are stored only as SHA-256 hashes, compared in constant time. A dump of our database yields no usable credential.
3. Short-lived access tokens (15 minutes) with rotating refresh tokens. Presenting an already-rotated token is treated as theft and revokes that whole session family.
4. Rate limits on the login and contact endpoints, and a general request limit on the public API.
5. Only two services of ours are exposed to the internet — the website and the public API. Authentication, the catalogue, the databases and the message broker are reachable only on an internal network, with no public port. Object storage is not ours: since 2026-09-09 it is a third-party managed service, so it necessarily has a public endpoint. The bucket itself is private — our services reach it with a credential that is not in any browser, nothing can be listed or browsed without one, and you reach one object at a time through a signed URL that expires.
6. TLS on every public connection, with certificates renewed automatically.
7. Minimal logging — the application never logs request bodies, query strings or headers.
8. Download links are signed and time-limited, and are issued only after an entitlement check. Your browser fetches them directly from the storage provider; the read-only path that used to proxy them through merkleset.com has been removed.

Honest limitations, because you should be able to weigh them: there is no automated backup of our databases or release artifacts today, and no automated monitoring or alerting. The application runs on a single host. Object storage is now a managed service with the provider's own durability behind it, which is not the same as a backup: versioning is not enabled, so an erroneous overwrite or deletion there is not recoverable from the provider either. We are telling you this rather than implying a resilience we do not have; it is also why the Terms of Service make no availability or recovery commitment.

11. Personal data inside the datasets

Our datasets are built from official public US federal government sources and are built to contain no personal data.

Screening runs inside the pipeline before any published hash is computed. Email addresses and telephone numbers are redacted; a value shaped like a US Social Security number with an explicit nearby cue causes the whole record to be dropped; person names are redacted where a source field declares them or where an explicit contact label introduces them. For the procurement corpus we never read the source's contact columns at all, so those values reach neither the product nor our internal storage.

The scope of that screening is deliberately narrow and we publish its gaps. It does not catch a person named in running prose without a contact label, labels separated by whitespace only, postal addresses, obfuscated contact details, or number shapes with no nearby cue. So the accurate claim is that datasets are systematically screened to a documented scope — not that they are guaranteed free of personal data.

Internal raw evidence. To make the provenance hashes checkable we keep one snapshot of each source record, exactly as fetched, in a separate internal store. Those snapshots are unscreened by design — a hash must describe the original bytes. They are never delivered to customers, never included in a release manifest, and never given a public URL. A retention period of 90 days is configured; nothing enforces it automatically yet, so expiry is currently manual. We are not going to describe that as automated deletion when it is not.

Where that store is, since 2026-09-09. It is held in our object storage provider's sfo3 (San Francisco, United States) region — the same region as the release artifacts, under a reserved key prefix of its own, so the unscreened tier and the buyer-facing tier stay separate and the unscreened one stays deletable. Until 2026-09-09 it sat on our own application host in nyc1 (New York, United States). Both are United States regions of the provider already named in the Subprocessor annex, so this moved the unscreened tier to a different datacentre of the same company, not to a different company or a different country. Two things we would rather state than let you assume: this tier is the one place unscreened source data is retained at all, and the separation between it and the published releases is now a key prefix enforced by our own software rather than a separate bucket enforced by the provider.

If you believe personal data about you is in a release, write to privacy@merkleset.com or follow the route in the Copyright, Takedown and Complaints Policy. We will remove it from future releases and delete it from the internal evidence store. We cannot recall a release a customer already downloaded; our licence obliges customers to remove identified records from their own copies on our reasonable request, and we will make that request.

12. Children

The service is sold to businesses and is not directed at children. We do not knowingly process data about anyone under 18. If you believe we have, write to privacy@merkleset.com and we will delete it.

13. Changes to this policy

This policy is versioned by effective date. When we publish a new version we ask you to accept it the next time you sign in, and we record the version, the acceptance time and a SHA-256 hash of the exact text you were shown. A new version applies from the date you accept it.

English is the authoritative language of this policy. Translations are for convenience only.

14. Contact

Privacy and data protection: privacy@merkleset.com Everything else: contact@merkleset.com