Draft

Privacy notice for reservations, claims and .on names.

Draft of 10 October 2026, revised after a clause-by-clause check against what the software does. Square brackets mark something that is not decided yet, not built yet, or that depends on a server that does not exist yet. The controller is OpenApps [legal entity, address and privacy contact: to be added]. OpenApps runs every service named here.

This notice covers what the Genesis launch adds. OnWallet ID and the OpenApps account each have a notice of their own for everything else they do [neither has been updated for Genesis yet].

1. The short version

To reserve a name we ask you for one thing, an email address. We also record your language, the versions of the terms and this notice you agreed to and when, and the times the reservation was made and confirmed. Your IP address is used for rate limits.
The email address is deleted when it has done its job. A scrambled fingerprint of it stays for a while, so that the same address cannot reserve twice, and is erased 90 days after the hold on the reservation ends [the 90 days is a default the founder has not confirmed]. If your address is at a small mail domain, a fingerprint of the domain is kept and erased with it.
A claimed name is public. It is on the XRP Ledger, whose history nobody can edit, us included. We can end a name or a pass under the policy, and we update a pass's number and level; the history of both stays.
For up to 90 days after you start a claim, OnWallet ID holds a record that links your ID to the ledger account you claimed with. We then delete it and keep no address. Some traces of timing remain, and section 4 lists them.
This website loads no third-party scripts, sets no cookies and has no advertising or cross-site tracking.

2. When you reserve a name

What	How it is kept	Until
Your email address	Encrypted under a key that is not in the database or its backups [where that key is kept is decided at the key ceremony, which has not been held]	You use your code in OnWallet (deleted in that step), you cancel (the whole reservation is deleted at once), or 30 days after the hold lapses. Encrypted backups keep a deleted address for up to 30 days more; the key is not in them
A keyed hash of the address	A one-way fingerprint made with a second secret key	It is what stops one address reserving twice after the address itself is gone. You cancel: deleted at once. The reservation lapses unused: the whole record, this fingerprint included, is deleted 90 days after the lapse. You use your code in OnWallet: the fingerprint is replaced by random bytes 90 days after the latest of the confirmation, your wave's opening and the end of the hold; the rest of the record stays, because it counts against your wave's places. After that the same mailbox could reserve again. The software does this by itself [the 90 days is a default the founder has not confirmed]
A keyed hash of your address's mail domain, only if the domain is not on our list of large public mail providers	A one-way fingerprint made with the same secret key. It is how the limit on reservations per mail domain is counted	As long as the keyed hash of the address, and erased with it
A shortened keyed hash of the address, inside a counter	A one-way fingerprint. It is how "at most three messages an hour to one address" is counted, and it is counted whoever typed the address	Two hours at most
The name; hashes of your code and of the links we emailed; your wave; the versions of the terms and privacy notice you agreed to and when; your language; when the reservation was made and when it was confirmed, to the second	As they are	A cancelled reservation: deleted at once. A request never confirmed: 24 hours. A lapsed one: deleted 90 days after the lapse [default, not confirmed]. A used one: kept without a set end, with no email address and, after the 90 days, no fingerprint: it is the count of your wave's places [whether a used record needs an end date: for counsel]
Your IP address	Inside rate-limit counters at the registrar; and as a keyed hash beside your reservation while it waits for you to confirm, which is how "three unconfirmed reservations from one network at a time" is counted. It is not written to the registrar's own logs	The counters: until their window ends, from 30 minutes to 24 hours. The keyed hash beside a reservation: until it is confirmed, cancelled or lapses, at most 30 minutes and the next clean-up after that. [The web server in front of the registrar keeps its own logs; they are to be set to hold no client address, on a host that does not exist yet.]

To decide whether two addresses are the same mailbox we ignore capital letters and anything after a + sign, and for Gmail the dots as well. Mail always goes to the address exactly as it was typed.

A reservation can send you five emails, and no others:

the verification link, which asks you to open it and press Confirm, and which also lets you cancel the request;
a reminder, in place of a new link, if the address already has a reservation;
the confirmation with your code, the date your hold ends if your wave has one, and a link to cancel;
one notice when your wave has a date;
one notice three days before the hold lapses. These two carry no cancel link; they point you to the one in your confirmation email.

Anyone can type your address into the form. It then receives a verification message, and nothing is reserved unless the person who opens that message presses Confirm on the page. One address is sent at most three messages an hour this way.

They are sent through an email provider [provider, its country and how long it keeps delivery records: to be named], which sees your address in order to deliver them. [Whether people who reserved are also emailed an invite key when their wave opens is not decided. If they are, this notice and the form will say so first.]

What this links. When you use your code in OnWallet, the registrar briefly has your email address, the name and your ledger address together; it then deletes the email address. The keyed hash stays beside the name and the address until it is erased as the table above says. It cannot be read back into an address, but someone with the secret key and a guess at your address could test the guess.

The page also asks your browser to solve a small puzzle before a reservation is accepted, and has a hidden form field that people leave empty. Both are there to slow down scripts. Neither identifies you, and neither is stored.

3. When you look up a name

A name you type is checked against the naming rules in your browser. If the rules allow it, the page asks the registrar whether it is available. The availability check does not say who holds or reserved a name. Once a name is claimed, the lookup service and the ledger tell anyone which address holds it.

The registrar does not store the names people look up. [The web server in front of it is to be set up not to log them either; that is confirmed here once the host exists and has been checked.]

4. When you enter an invite key and claim

What OnWallet ID keeps

What	Why	Until
That your OnWallet ID is a Genesis member, of which wave, and when you entered the key, to the second; a fingerprint of the key (never the key)	To give you one claim and to keep each wave to its size	As long as your OnWallet ID exists
Who gave the invite key you used, and who used the keys you gave	To investigate abuse of invite keys	12 months after the key was used [a default the founder has not confirmed]; after that only how many of your keys were used. Kept even if either OnWallet ID is deleted, with no name, email or address attached. You are shown whether a key was used, never by whom
The ledger account you chose to claim with, a random voucher number, and the network. The address is encrypted under a key kept apart from the database and never in our backups	To hand the same voucher back to your own browsers, so that a claim can be resumed	At most 90 days from the voucher's first issue, then deleted with its key; at once if you delete your OnWallet ID
In our security records: when a voucher was issued or its account changed, from which browser and IP address	To investigate a claim made with a stolen sign-in	Deleted together with the address: at most 90 days
That your claim was used, and the day it was first issued	So that one membership gives one claim	As long as your OnWallet ID exists. No address and no voucher number
If a membership is removed: a scrambled form of the sign-in mailbox, and of the Google account if one was used	So that a new OnWallet ID made with the same mailbox cannot become a member again	Without limit. It cannot be turned back into an address

OnWallet ID also emails you when you become a member, when a voucher is first issued, and when its account is changed. None of those messages names a key or an address.

What the registrar receives

Your ledger address, the name, and a voucher from OnWallet ID showing that an invite key was redeemed. It does not receive your OnWallet ID or your email address. Because we run both services, we could join the two records while both exist.
It keeps the address, the name and the records of each mint and offer, with their times to the second, for as long as the claim exists. The same facts are on the public ledger.
Our application logs carry no address, name, email, voucher or code in readable form. Each appears only as a keyed tag, so an incident can be traced without the logs revealing who was involved. [The logs of the web server and the host are separate and are not set up yet.]
Before an NFT is issued, the address is checked against a list of our own, which may be empty. We do not send it to a screening company [subject to counsel's advice on screening]. To issue the NFT we do look the account up on public XRP Ledger servers run by others, and the mint itself is public.

After the 90 days: what we can and cannot still work out

We delete the record that says "this OnWallet ID claimed with this address", and we keep no address at OnWallet ID. That does not make the claim untraceable to us. Someone holding all our systems, or one of them and the public ledger, could still work out, with good odds, which OnWallet ID claimed with which account. These are the traces that remain:

The day and the wave. A voucher carries its wave and a day, and we keep the day your claim was used. In a small wave, a quiet day can point to one member.
The sign-in log. You sign in just before a voucher is issued. As for every sign-in, OnWallet ID keeps when and from which device and IP address, to the second, and that log is never deleted. The registrar's records and the ledger's own times are usually within a minute of it.
The public ledger by itself, during the 90 days: the security records above and the time of the mint link a member to an address with nothing else needed.
The emails about your voucher, at our email provider and in your own mailbox, each with a time.
Server and host logs, whose retention is not set yet.
The time you entered your invite key, kept with the membership.
A reservation, if you made one: the keyed hash of your email address sits beside the name and the address.
If a membership is removed, a record of that for up to 30 days.

And your name and your account are public for good.

In your browser

While a claim is under way, OnWallet keeps the account you are claiming with, the voucher and the name in the browser profile. It is not encrypted there, so anyone who can open that profile can read it. It is removed when the claim completes or is abandoned, after 90 days, and when the wallet is removed.

5. Perks, and your OpenApps account

When you sign in to an OpenApps product with OnWallet, the product can ask whether you are a Genesis member. You choose each time, and it is told only "yes": not your number, your name or your address.
The account keeps that its OnWallet ID is a member, each month's grant of credits and its size, and your level if one is assigned. A record of each month's grant is kept after an account is deleted, as a hash of the ID, so that one ID earns one grant a month [retention not set; 13 months is proposed].
Activity. To decide whether a month's credits are due, the account records, once per month, that it was active: the first and last time in that month that credits were spent or a member feature was used. Nothing about what was done. It is deleted with the account [off until credits begin].
Levels. A level written on a public pass says something about its holder's use of OpenApps products. [Whether levels are shown on the pass is not decided; until it is, every pass shows the first level.]

6. What is public, for good

The XRP Ledger is a public record. Once you claim, anyone can see, permanently:

that your name belongs to your address, and since when;
that your address holds a Genesis pass, its number and its level;
your address's balance and every payment it sends or receives;
which account first funded your address. If a friend or an exchange sent the XRP, that link is visible;
the mint, the offer and your acceptance, each with its time.

Nobody can delete or change the ledger's history, us included. We can end a name or a pass under the policy, and we update a pass's number and level. The history of each stays.

The picture and description of a Genesis pass are files on our server. If you look at a pass in another app, that app fetches them from us. [That server is to be set up not to log those requests; confirmed here once it exists.] OnWallet itself never fetches them.

7. The name lookup service

A lookup tells the service's operator an IP address and the name or address asked about. The service itself stores neither, sets no cookies and has no analytics. [Its web server's logs: as section 3.] Anyone can run their own copy, or read names straight from the ledger.

8. About this website

No cookies. Your language choice is kept in your browser's local storage and is not sent to us. Your reservation code is kept in the page's memory only, never in storage.
No third-party scripts, fonts or trackers. Everything the page needs is served from this site.
[If page views are counted, it is with a self-hosted counter that sets no cookie and stores no IP address. This line is confirmed or removed before launch.]

9. Your choices, and what we keep anyway

Cancel a reservation with the cancel link in your verification or confirmation email. It is deleted from our live systems at once, and from encrypted backups within 30 days.
Ask what we hold, or ask us to delete it, at [privacy contact: to be added]. Both exist at the registrar: an export of everything it holds about a reservation, a claim or a ledger address, and a deletion. One of our operators runs an export; a deletion takes two. To make sure the request is yours, we answer a request about a reservation to the reserved mailbox, and a request about a claim or an address needs a signature from that account [the steps for asking and for collecting that signature are not written yet; the same requests at OnWallet ID are described in its own notice].
What a deletion at the registrar removes: a reservation that was not used, whole. For a reservation already used, nothing more than the email address, which went when the code was used; its fingerprint goes on the 90-day schedule above. For a claim: the voucher number that leads back to your OnWallet ID, and the working counters around it.
Some records we keep even then, and why [whether each can be justified: for counsel]:
- the ledger's history, which nobody can delete;
- OnWallet ID's sign-in log, which is built so that no entry can be removed without breaking it;
- the record of each action our operators take, which may name a voucher, an address or a name;
- that a claim was used, and the fingerprint kept when a membership is removed;
- at the registrar, after a deletion: the claim's account and name and the record of each mint, offer and acceptance, which are its copy of the public ledger; and a keyed hash of the account, which stops a second claim by the same account;
- backups, until they age out (30 days);
- the record of each month's grant.
The ledger lets you burn your own name or pass. OnWallet will have a button for it in a later release; until then, write to us.

10. Still to be written with counsel

This list is part of the draft and is removed before the notice is published.

The controller's identity and contact, and the legal basis for each use, including whether consent is the right basis for reservation emails and whether one tick can cover both the terms and this notice.
Where each server is hosted, and any transfer between countries.
The email provider and any other processor, named.
Rights under the laws that apply (for example Singapore's PDPA and the GDPR), how to complain, age, and how a breach is handled.
Retention for every item above marked as not set.