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, and when a passage was added or changed. The controller is Elevated Spaces Pte. Ltd. (UEN 202641668K), trading as OpenApps, 60 Paya Lebar Road, #06-28, Paya Lebar Square, Singapore 409051. Privacy contact: privacy@onwallet.si. 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 an email address, and for two links that show you did the reservation's three steps: your quote of our launch post, and your Telegram username. We take your X profile from the link to your quote post. 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. There is no limit per mail domain. For an address at a mail domain that is not a large public provider, a fingerprint of the domain is kept beside it and erased with it, so that a flood of reservations from one domain can be found and removed, and counted if a limit is ever turned on against one.
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 set 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
The links of the reservation's steps: the link to your quote post on X, your X profile as that link names it (x.com/…), and your Telegram username (t.me/…)	Encrypted under the same key as your email address. We collect them only to check that your reservation is eligible for an invite key (terms, section 2). Only OpenApps operators see them, when they check the steps by hand. The registrar never opens the links and sends nothing to X. If you press “Verify with Telegram”, we also keep your Telegram user id and username, encrypted in the same way, and for a drawn reservation we ask Telegram whether that account is in our group [Added 30 Oct 2026. Changed 31 Oct 2026.]	Deleted with your email address: when you use your code in OnWallet, when you cancel, or 30 days after the hold lapses. Encrypted backups keep them for up to 30 days more; the key is not in them
The result of the check: waiting, eligible or not eligible; the step that was missing; when it was decided	As they are	With the rest of the reservation's record, as the last rows of this table say
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
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 a flood of reservations from one domain is found and removed, and how a limit per mail domain would be counted. There is no such limit by default [off by default since 26 Oct 2026]	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, of the second code inside an invite key we emailed you (if we did), and of the links we emailed; when an invite key was handed to our email provider for you, or refused by it; 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
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 seven 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;
only if a check finds your reservation not eligible for an invite key: one notice that says which step was missing;
only if your reservation is drawn, is eligible and is still held: an invite key that already includes your reservation, so that it is the only code you enter in OnWallet.

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. An invite key for a drawn reservation is sent the same way, so the provider sees the address and the key, as it sees your code. The registrar passes the key on and does not keep it in any form; what it keeps is a keyed hash of the second reservation code inside it, deleted with your code's when the reservation is used or lapses. [Added 26 Oct 2026; since 30 Oct 2026 the keys are drawn from reservations.]

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 three steps. Your X profile, your quote post and your Telegram username are public on X and Telegram. Kept beside your reservation, they link your email address and the name to those accounts, for as long as they are kept. Our operators open the links by hand to check the steps, and the links are not shown to anyone else. Nothing is sent to X. If you press “Verify with Telegram”, we keep your Telegram user id and username with the links, and for a drawn reservation we ask Telegram whether that account is in our group. [Added 30 Oct 2026. Changed 31 Oct 2026.]

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, and to count the level of the member who gave the key (terms, section 7)	12 months after the key was used; 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 Genesis member invited you: whether your Genesis pass was held at the last check, and nothing more about it	To count your pass toward your inviter's level (terms, section 7)	Checked while your claim record is kept, at most 90 days [how long the last answer is kept after that: not set]
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. To issue the NFT we do look the account up on public XRP Ledger servers run by others, and the mint itself is public.
For levels. If a Genesis member invited you, OnWallet ID asks the registrar about once a day, while your claim record is kept (at most 90 days), whether your Genesis pass is held, to count it toward your inviter's level. It asks about many people's claims together and never says who invited whom. When three people a member invited hold their passes, OnWallet ID asks the registrar to raise that member's pass to level 2: the registrar learns only that a pass earned level 2, and keeps a record of that, with its time, beside the pass's token and with no OnWallet ID. The new level is then written in the pass, on the public ledger. [Added 26 Oct 2026.]

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.

If you claim a .on name without an invite key

Any OnWallet ID can claim one .on name with no invite key, once this is open. You are not a Genesis member by doing so, and no OpenApps product is told anything new about you: no Genesis claim is added to your sign-in. What OnWallet ID keeps is the same kind of record it keeps for members:

The account you claim with. OnWallet ID learns that ledger address, because the voucher it signs is for that address. The address is kept sealed and is deleted within 90 days of the voucher's first issue, with the voucher's number and the times around it.
That your OnWallet ID has used its one name, for good: as the day it did, and as a keyed hash of your mailbox (and of your Google account, if you sign in with Google). That hash is what stops the same mailbox claiming a second name after deleting its OnWallet ID. It is kept after your OnWallet ID is deleted, with no name, email or address beside it.
Counts that limit abuse: how many name vouchers were issued each day, kept for 30 days with nothing about any person; and, only while a limit per mail domain is turned on (there is none by default), a keyed hash of a mail domain that is not a large public provider, with a count, kept for good.
Nothing about the name itself. OnWallet ID never learns which name you chose, whether it was issued, or whether you accepted it. You choose the name at the registrar.

The registrar keeps what it keeps for any claim (section 9): your address, the name, and the voucher number. What can still be worked out after the 90 days is the list above, word for word; and your name and your account are public for good (section 6).

In your browser

While a claim is under way, OnWallet keeps the account you are claiming with, the voucher, the name and what the claim is for 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. After a claim that included a Genesis pass, OnWallet keeps the claim's number at the registrar, so that it can ask what became of the pass later. After a claim of a name on its own, it keeps nothing.

OnWallet notices

The wallet fetches one public file, notices.json, from onwallet.si (from testnet.onwallet.si in the Testnet test build) every few hours, and when you open it if it has not checked for 30 minutes, to show announcements signed by OnWallet. That request carries nothing beyond what any HTTPS request carries: our server sees your IP address and your browser's ordinary headers, as for any page. The wallet sends no cookie, no account, no ledger address and no identifier of the wallet or the browser. On the Testnet server the log line of the request keeps the hour, the method, the kind of request and its status, and not the IP address [Mainnet: the same, once the file is served there]. The notices received are kept in your browser. To turn this off, open Settings, then Notices, and switch off "Show OnWallet notices": the wallet then does not fetch the file at all. [Added 28 Oct 2026. The store build has no notices until a Mainnet notices key exists.]

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. The level is written on the pass, which is public. A level says something about its holder: a pass at level 2 tells anyone that its holder invited three people who hold their pass, or that OpenApps set that level. [Added 26 Oct 2026.]

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;
when your pass's level changed. The ledger does not say who invited whom, but a rise to level 2 comes at a daily check after the third person you invited holds their pass, so its time can hint at whose passes those were.

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@onwallet.si. 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:
- 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

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.