1 What we collect

Registration requires no personal identifier. The form asks for a name you choose, the network you produce on, and a signature made by the key your node already publishes on-chain. It does not ask who you are, and there is no field in which you could tell it.

The registry stores exactly this about you, and nothing else — plus four internal bookkeeping timestamps that say nothing about you, listed in full under the table:

The network you pick is not signed, and it does not scope your name. The message your node signs is DOLI claim: <username> <timestamp> and nothing else, so network is recorded exactly as your browser sent it and no signature attests to it. Usernames are unique across every network — one namespace covers all networks, so a name registered on testnet is blocked on mainnet: the registry will not issue it twice. It is not held for you there — the row keeps the network you declared, and the mainnet dashboard shows nothing for it.

The four bookkeeping timestamps complete the row. They are the registry's own operating record, not anything you supply: verified_at (the second your claim was accepted), created_at (the second the row was written), last_renamed_at (the second of your last rename — this is how the 30-day rename cool-off is enforced, and it is 0 until you first rename), and unsubscribed_at, a disused column left behind by the mail system that was removed: it is empty for every row and nothing in the service can write to it. Those four plus the five stored fields above are the complete contents of the producers table — nine columns, all of them. The IP address in the table above is an nginx log line, not a database column.

We do not collect: an address of any kind, real name, phone number, billing data, location, browser fingerprint, or any third-party tracking identifier. There is no account, no password, and no session cookie.

2 How we use it

1. Prove the claim. Your pubkey must be in the active producer set and the signature must match the claim. The request must also clear field validation, a 5-minute freshness window on the signed command, two rate limits, a replay guard, the reserved-name list, the 30-day post-deletion lockout and a uniqueness check before a row is written. None of those involve anything about you, because nothing about you was submitted.
2. Show your name on the network dashboard. username, pubkey and network are returned by GET /api/producers/names, which is what the dashboard at explorer.doli.network/network.html reads. They are meant to be public — that is the entire purpose of the registry. The signature, the claim timestamp and the four bookkeeping timestamps are kept as the audit and operating record of the claim and are not returned by any API.
3. Rate limit. Your IP and your pubkey are checked against two separate in-memory limits. Per IP they are token buckets, not a fixed quota per period: registration allows a burst of 5 and refills one token per second, the public GET /api/producers/names read allows a burst of 60 on the same one-token-per-second refill, and rename and delete have their own, much slower buckets (a burst of 5 refilled once every 12 minutes, and a burst of 3 refilled once every 20 minutes). Per pubkey a rolling 60-minute ceiling applies on top — 5 registration attempts, 1 rename, 3 deletions. Nothing here is written to disk: both limits live in the service's memory and are lost when it restarts.

3 Legal basis (GDPR Art. 6)

A public key and a self-chosen handle are, in most readings, not personal data at all — but we do not want the policy to rest on that argument, so we state a basis for each item as if it were:

• Legitimate interest (Art. 6(1)(f)) — publishing the username against the pubkey. Running a producer is a public act on a public ledger; a readable label for a node you already operate publicly is the interest, and you create the record yourself by signing for it. It is assessed as a minimal intrusion because you supply the label and can change or remove it yourself at any time (Section 5).
• Legitimate interest (Art. 6(1)(f)) — retaining the signature, the claim timestamp and the operational logs. These exist to stop someone claiming a name they cannot sign for, and to protect the service from abuse.

Consent is no longer a basis for anything here, and no consent is asked for. Earlier versions of this policy relied on Art. 6(1)(a) for a contact address and on Art. 7(2) for a separate, optional mailing preference. Neither is collected any more, so neither consent exists, and there is nothing left to withdraw. The registration form no longer carries a consent tickbox.

4 Third parties (sub-processors)

None. The registry uses no sub-processor. Nothing it stores is shared with, transmitted to, or processed by any third party on our behalf. There is no delivery provider, because there is nothing to deliver. We use no analytics, no tag manager, no user-tracking CDN, and no advertising network.

That is a statement about transfers, not about confidentiality. The username, pubkey and network triple is served to anyone who asks for it and Section 5 says so too — that is a publication by design (Section 2), not a disclosure to a third party.

The registry does not sell, rent, share or otherwise disclose anything it holds.

5 Your rights (GDPR / CCPA)

Several of these rights are exercised differently here than on a normal service, because the registry holds no identifier it could match you to. It cannot look you up; only your signing key can. That is deliberate, and it cuts both ways — each right below says how it actually works.

• Access — everything the registry publishes about a key is already readable by anyone at GET /api/producers/names, with no authentication. The fields it does not publish are the signature and the claim timestamp, both values your own machine produced, and the four bookkeeping timestamps listed in Section 1 — verified_at, created_at, last_renamed_at and the disused, always-empty unsubscribed_at. That is the whole of it; there is no hidden profile to request.
• Rectification — change your display name yourself at doli.network/rename.html. It is signature-gated and allowed once every 30 days; the change applies immediately. Advanced users can call POST /api/producers/rename directly.
• Erasure — delete your registration yourself at doli.network/delete.html. It is signature-gated, immediate and permanent; it removes the whole record, releases the name for anyone else to claim, and locks that public key out of registering again for 30 days. Advanced users can call DELETE /api/producers/:pubkey directly. The 30-day marker holds the pubkey and two timestamps (when it was written and when it expires), nothing else, and it expires by itself.
• Data portability — the record is a name, a public key and a network. It is already public and already yours; you can re-create it on any other service by signing there instead. There is no retention lock-in.
• Object / restrict processing — delete your registration. Because the only lawful basis in play is legitimate interest, deletion is also how you object to it.
• Withdraw consent — not applicable. Nothing here runs on consent (Section 3).
• Complain to a supervisory authority — if you're in the EU / EEA / UK, you can lodge a complaint with your national data protection authority.

If you have lost your signing key, none of the self-service routes above will work, because every one of them is proved by a signature and there is no other way to establish that a record is yours. There is no fallback identity check, and never has been: we hold nothing that could serve as one. Write to privacy@doli.network and we will do what we can, but be clear that we cannot verify the claim cryptographically and will not hand a name to whoever asks first.

CCPA-specific (California residents). We do not "sell" or "share" personal information as defined by the CCPA / CPRA, and we hold no personal identifier to sell. You have the right to know what we collect (Section 1), the right to delete (above), and the right to correct inaccurate data.

6 Retention

There is no pending-registration table any more — a claim either succeeds outright or is rejected outright, so nothing is held in an intermediate state.

7 Security

• Communication with the registry is HTTPS only (TLS 1.2+).
• The backend runs as an unprivileged systemd service with ProtectSystem=strict, PrivateTmp=yes, and NoNewPrivileges=yes.
• Database file is owned by the service user only and is not world-readable.
• The service calls no external provider — no analytics, no third-party API. It makes exactly one kind of outbound request: a getProducers JSON-RPC call to the DOLI node at the RPC_URL it is configured with, which is how a claiming key is checked against the active producer set. That request carries the method name and an empty parameter list, so nothing the registry stores travels in it.
• Every rejection from the registration, rename and delete endpoints is answered with the same {"error":"rejected"} body, whichever check failed, so the API cannot be used to enumerate which keys or names exist. (A request the registry does not serve — an unknown path, or a method it does not accept on a path it does — comes back as a bare 404 or 405 with no body at all. Which of the two you get is fixed by the route table, not by whether any key or name exists.) Signatures are checked with verify_strict, which works only on public values — the key, the message and the signature. We publish no timing figure, because nothing in the service enforces or measures one.

8 Children

The DOLI producer registry is not directed at children under 16. It collects no personal data from anyone, of any age, so there is nothing about a child for it to hold. If you believe a record should not be there, write to privacy@doli.network and we will look at it.

9 International transfers

The backend is hosted in the European Union and nothing leaves it. There are no international transfers, because there is no third party to transfer anything to (Section 4).

10 Changes to this policy

We will post the updated policy at this URL and update the "last updated" date at the top. We cannot notify you individually and will not pretend otherwise: the registry holds no way to reach you, by design. Check this page, or follow the community channels linked from doli.network.

11 Contact

Data controller: DOLI Network. Contact: privacy@doli.network. We aim to respond to all privacy requests within 72 hours and in all cases within 30 days as required by GDPR Art. 12.