Privacy Policy

Last updated: 27 October 2026

1. Who we are

handles.link is operated by GROUNDED SYSTEMS - FZCO, a free zone company registered in the IFZA free zone under the Dubai Integrated Economic Zones Authority (DIEZ), licence number 57418, at Building A1, Dubai Digital Park, Dubai Silicon Oasis, Dubai, United Arab Emirates.

In this policy, "we", "us" and "our" mean GROUNDED SYSTEMS - FZCO. "You" means the person using the service.

For anything about this policy, including a request about your data, write to contact@handles.link.

2. What this policy covers

It covers the handles.link website, the linking flow on it, the page for sending value to a handle, and the contact form.

It does not cover, because we do not control them: the blockchains a handle is written to, the platforms you sign in with, the wallet you use, and any other bridge or gateway built on libID that somebody else runs. Each has its own terms and its own privacy policy, and this one cannot speak for them.

3. The short version

There are no accounts here, so there is nothing to sign up for and no password to keep.

When you link a handle, the work happens in your browser. What the platform hands back is used there and goes from your browser to the blockchain. The only piece that reaches a server of ours is a one-time sign-in code, which that server neither uses nor keeps.

Two fingerprints go onto a public blockchain: one of your account, one of your handle. Neither is the readable value. Your handle itself is not written to the chain. Nothing is published automatically, and at launch there is no option to publish it.

A fingerprint is not a secret. Anyone can compute it from a handle they already have or can guess, so an unlisted link is not hidden — it is only not written out.

We hold a copy of what is already on the chain, so the site can show it to you. We hold nothing we learned about you ourselves.

Analytics set no cookies, which is why there is no cookie banner. The site does keep a few things in your browser so that it works between visits, and none of them reach us.

4. What we receive when you link a handle

Almost nothing, and that follows from how it is built rather than from a promise.

When you sign in with a supported platform — at launch, X, Google or GitHub — the proof is assembled in your browser. What the platform returns arrives there and goes from your browser to the blockchain directly. For X and GitHub, the platform sends you back to a page on our sign-in server, bridge.handles.link, with a one-time code in the page address. That server only delivers the page: it does not use the code, does not pass it on and keeps it out of its logs. The code is exchanged from your browser, over an encrypted connection relayed by the notary described in section 11, which cannot read it. For Google, the response stays in the part of the address that browsers never send to a server.

Everything the sign-in produces beyond what goes on chain — access tokens above all — stays in your browser and never leaves it.

What each platform asks for at sign-in. You see this on the platform's own consent screen before you approve anything, and it is written out here as well.

X asks for read access and nothing more: the posts and accounts you can already see yourself. It cannot post for you, it cannot read your direct messages, and it does not hand over your email address. GitHub asks for your profile information, read-only. Google hands over your email address, and nothing else.

When we add a platform, what it asks for at sign-in is written here before it goes live.

What we hold. One database, and everything in it is already public. It is the indexer: it reads the events our contracts write to the public blockchain and keeps a copy so the site can answer quickly. The copy holds, for each link, the two fingerprints, the wallet address, the platform, the time the platform stated, and — only where a handle has been written to the chain in readable form, which our interface does not do at launch — the handle itself; and it keeps a journal of every event it has read, with the transaction it came from. Every record in it is on the chain, and anyone following the chain can build the same copy without us. We keep it for as long as the chain exists, because deleting our copy would remove nothing.

The same service answers lookups from that copy: a handle to its wallet, an account to its wallet, a wallet to every handle it has proved on every chain, and a search that matches handles by partial text. All of these answer from the public record.

What we do not hold. No accounts. No passwords. No IP addresses — none is written down at any point. No cookies are used for any of this. No backups, because there is nothing to take a backup of. We do not record who looks up which handle. The one exception is failure: when a request errors, the request and the error are written to a log so the failure can be investigated, and that log can contain the handle that was looked up. It contains no IP address and no cookie, so it records what was asked and not who asked.

5. What goes onto a public blockchain

This is the part that cannot be undone, and the reason to read before linking rather than after.

Two fingerprints, not two names. Linking writes two values to the chain: a fingerprint of your account on the platform, and a fingerprint of your handle. A fingerprint is a one-way hash — a fixed string computed from the original value, from which the original cannot be read back. The account identifier itself, the number or address the platform knows you by, is never written to the chain in readable form under any setting.

Every link is unlisted. At launch that is the only way to link: you do not choose a state, and nothing is published — not automatically, and not on request, because there is no option for it.

Unlisted means: the chain holds the two fingerprints, the wallet address they are bound to, which platform the account is on, the time the platform stated when it confirmed the account, and which application made the link. It does not hold the handle or the account identifier in readable form. The handle still works: it resolves to your wallet, and anyone who has it can send to it.

On Google the handle is your email address. At launch only its fingerprint goes on the chain, like any other handle.

A fingerprint is not anonymity. It is computed by a published formula with no secret ingredient. Anyone who has your handle, or guesses it, can compute the same fingerprint and match it to your wallet. Handles are not hard to come by — the platforms publish them. So an unlisted link is not hidden from somebody who is looking for you; it is only not written out. The protocol's own specification says this plainly: private here means not disclosed, not unguessable. The same holds for the account fingerprint: account identifiers are short enough that trying values is practical.

What this means in ordinary terms: unlisted is worth having, and it is not protection against anyone determined. Treat the link itself as permanent and findable, because it is both.

What follows from the pairing. Once a handle and an address are on the chain together, activity associated with that address can be connected to that platform account, by anyone, permanently, without any further involvement from you. How much that reveals depends on the blockchain rather than on us. Every network we launch on is a public one.

We cannot erase any of it. Section 14 says what that means for your rights.

6. When you send value to a handle

Sending is its own page, and it puts data on a public blockchain — including data about the person you are sending to, who has agreed to nothing.

What becomes visible: the wallet address you sent from, the amount, the network and the time. Who sent it follows from the transaction itself.

The recipient appears as a fingerprint of their handle. At launch the sending page writes only the fingerprint; the recipient's handle itself does not go on the chain, and there is no option to send it in readable form. Nothing about the recipient is published. The contract can also record a recipient by their readable handle, which would put that person's handle on a public blockchain before they know the transfer exists, without any act of theirs, and permanently. Our interface does not use that at launch.

If somebody has already linked the handle, the value goes straight to their wallet in the same transaction. There is no waiting and no taking it back.

If nobody has linked the handle, the value waits in a smart contract assigned to it, and anyone can see that it is waiting. It is released to whoever proves the handle, whenever that happens. If nobody does, you can take it back: thirty days after you send, a Return button appears beside that transfer in your history. The wait stops a payment being shown to someone as made and then quietly taken back. You pay the network fee for a return transaction. Nothing happens on its own: the value stays in the contract until either the recipient claims it or you take it back, whichever comes first, and we can do neither.

A handle typed wrongly cannot be corrected. If the handle you typed is already linked by somebody, the value goes to them at once and cannot be recovered. Otherwise it waits in the contract, and you can take it back once the Return button appears — unless somebody proves that handle and claims it first. So check the handle before you send.

The sending page helps with that check. For GitHub it checks automatically whether the account exists. For X it cannot, because X offers no way to ask, so the page gives you a link to open the profile on X and confirm it yourself.

Your deposit history — the list of transfers you have sent — is read from the same chain events and shown back to you. The event each transfer writes carries the handle's fingerprint, the amount, the token, and your address, both as the sender and as the address a refund goes to. Nothing in it is private to us; anyone following the chain can assemble the same list, and our copy of it is kept on the basis described in section 4.

7. What we receive when you use the site

Site analytics are provided by Plausible. Plausible is cookieless and does not build a profile of individual visitors, which is why this site sets no analytics cookies and asks for no cookie consent.

For each page view Plausible records the page address, where the visitor came from, the browser, operating system and device type, an approximate location down to country, region and city, and how long and how far the visitor engaged with the page. Location and device details are worked out from the IP address and user agent as the request arrives, and neither is stored. To count a visitor once without a cookie, Plausible turns the IP address and user agent, together with this site's domain and a secret that is discarded every 24 hours, into a one-way identifier. It uses no cookies, no local storage and no persistent identifier, processes the data on our behalf on servers in the European Union, and does not sell it.

When you link a handle. The linking page also sends a technical record of each attempt to our own server, which keeps it in Cloudflare's analytics storage. It holds which platform and network were used, how long each step took, whether the attempt succeeded, failed or was abandoned, the version of the site, and the browser and operating system family, such as Chrome on Windows. Each attempt gets a random number that is not linked to you. It does not hold your wallet address, your IP address or the full description of your browser. When an attempt fails, it also keeps the text of the error, with web addresses, email addresses, long numbers, wallet addresses and other identifiers removed first; what remains could still include the handle you were linking. We use this record to see where linking breaks and how long it takes, and it is kept for three months.

8. What we receive when you contact us

If you use the contact form, you give us a name, an email address and a message. This is the one place in the product where we hold ordinary personal data about you.

The form passes through Cloudflare, which runs this website. Cloudflare holds the submission until it has been written into a spreadsheet on Google Workspace and both emails have gone out: one to the team, and a confirmation to you with a copy of what you sent, so you have a record that it arrived. Both emails are sent by Cloudflare. That confirmation is the only email you will get from us. An address given here is not added to a mailing list and is not used to tell you about the product.

Inside the company the spreadsheet is open to a small number of people: the company's leadership, and whoever is handling marketing.

In the spreadsheet we keep a submission for twelve months from the day it arrives, and then delete it. Cloudflare deletes its copy as soon as both emails have gone out. If delivery fails, that copy is kept for up to thirty days so the failure can be investigated, and then deleted. For the same thirty days Cloudflare keeps a one-way fingerprint of the submission, used only to recognise the same form sent twice.

9. What we store in your browser

Analytics store nothing. Plausible uses no cookies, no local storage and no persistent identifier, which is why this site shows no cookie banner and asks you for nothing.

The site keeps a few things in your browser's local storage so that it works between visits: whether you have a wallet connected, which network you chose, the transfers you have sent, linking and sending transactions that have not finished yet, and tokens you added yourself. All of it stays in your browser, none of it reaches us, and clearing your browser data removes it.

The platforms you sign in with and the wallet you connect run on their own pages and may set their own cookies there. Those are theirs, under their own policies.

If anything else is added that sets a cookie or stores something in your browser, this section changes before it ships.

10. Whether this is personal data, and on what basis we process it

A wallet address on its own is a string. A handle attaches a name to it, and from then on the pair identifies a person in the ordinary sense of the word. It is personal data. That is what the law makes of it; it is not a view we hold and not one we could change by taking a different view.

Hashing does not change that. A fingerprint is pseudonymised data, not anonymous data, because the original can be recovered by anyone able to guess it and check. So the pair is personal data whether your handle is on the chain in readable form or not.

The basis is consent, and it differs by operation only in how it is given.

For the on-chain record, consent is your own act of linking. At launch that is the only act there is: no state is chosen and nothing is published. For a transfer, consent is your act of sending. For the contact form, consent is given by writing to us. For the technical record of a linking attempt, consent is the same act of linking. For site analytics, there is no name, email or stored address, and we do not treat it as personal data.

Under UAE law there is no fallback: the Personal Data Protection Law permits processing only on the listed grounds, and legitimate interests is not one of them. Consent carries the whole product, which is why every step that publishes something is a step you take yourself.

One case would have no basis available, and we say so rather than hide it. If a sender could name a recipient by their readable handle, that recipient would have consented to nothing, would not know, and could not be reached by us. At launch the sending page does not offer that. If it ever does, this is the paragraph that has to be answered first.

11. Who else is involved

Cloudflare serves this website and handles visitors' network addresses in order to deliver the pages, under its own terms; we do not store them. It also passes contact-form submissions on and sends the emails around them, as section 8 describes, and it keeps the technical record of linking attempts described in section 7. Amazon Web Services runs the backend and holds the deployment keys. Grafana is used for monitoring. Google Workspace holds the contact-form spreadsheet and the team's email. Plausible provides site analytics, acting as our processor and keeping that data on servers in the European Union.

There is a second group, easy to miss because nothing of ours is involved. When you link a handle, your browser talks directly to the platform you are signing in with, to a public blockchain node, and to WalletConnect's wallet directory if you connect that way. Those are not our services and we send them nothing — but your browser reaches them, which means they see your network address at that moment, the way any site you open does. Your browser also loads the sign-in window from ccdp.lib.id, which delivers the code that builds the proof in your browser. For X and GitHub it connects to the notary at notary.lib.id, which relays the encrypted connection to the platform and signs a confirmation that the session was genuine, so the platform sees the notary's address rather than yours. Both are part of libID, the protocol this service is built on.

On the sending page there is one more. For a GitHub recipient, your browser asks GitHub directly whether the account exists, so GitHub sees your network address and the name you typed. X has no public interface we can use to check whether an account exists, so the form asks you to open the profile yourself and look.

12. Where your data is handled

For most of what this policy covers the question barely arises, because so little is held. What we hold is a copy of public chain records — the indexer — on our own infrastructure. No IP address is stored, nothing is logged about an ordinary request apart from the technical record of linking attempts in section 7, and there are no backups.

The exception is the contact form. If you write to us, your name, your email address and your message sit in a spreadsheet on Google Workspace, under Google's terms. On the way there they pass through Cloudflare, which keeps them only as long as section 8 describes. That is the whole of the ordinary personal data this company holds about anyone.

Site analytics are held by Plausible on servers in the European Union.

13. How long we keep things

The record on a public blockchain is permanent. Its retention period is the lifetime of the chain, and it is beyond anyone's reach, ours included.

The indexer's copy of chain events, including the sender addresses in transfer events, is kept on the same basis: it copies a permanent public record, and deleting our copy would remove nothing.

Contact-form submissions: twelve months in the spreadsheet, then deleted. Cloudflare's copy is deleted once both emails have gone out, and after thirty days at most if delivery fails.

Technical record of linking attempts: three months, then removed.

Site analytics: Plausible keeps page-view and visit records with an approximate location and device type, and no name, email address or IP address, so there is no profile of you to delete. It publishes no fixed retention period for these records.

14. Your rights, and the one we cannot give you

Most requests we can handle by hand, precisely because there is so little to handle. Write to contact@handles.link and we will tell you what we hold about you and remove what we can.

You can withdraw consent at any time. Withdrawing it stops anything further; it does not make what already happened unlawful, and it does not reach the chain.

What is written to a blockchain cannot be erased. We cannot delete it and neither can anyone else. That is a property of the technology, not a policy we chose, and we are not going to dress it up as one.

What we will actually do, in order, when you ask us to erase a record: stop resolving the handle in our own interface; stop serving it from our own gateway; delete what little exists on our side; tell you exactly what remains on the chain and who can see it; explain that relinking moves the pointer without removing what came before; and tell you where to complain if that is not enough. This does not satisfy a right to erasure and we do not claim it does. It is what lies within our power.

Relinking a handle to a different wallet takes the name off the old wallet from that moment on. The earlier record stays in the chain's history.

15. Children

You must be at least 18 to use this service, and old enough to enter into a binding agreement where you live if that age is higher. There are no accounts here and we collect nothing at linking, so this is not something we can check — by using the service you are telling us it is true.

It matters more here than in most places, because linking writes to a public blockchain permanently and nobody can remove it afterwards. If we are told a handle belongs to someone under 18, we will stop showing it in our own interface and stop serving it from our own gateway. What is on the chain stays there.

16. Security

Deployment keys are held in a key-management system rather than in a file somewhere. The sensitive material in this product — your keys and your funds — is never ours to protect, because we never hold it.

There has been no completed independent security audit of the contracts. One with an outside firm has started and is not finished, and nothing here will say audited until it completes.

17. Changes to this policy

When this policy changes, the new version is published here with the date it took effect, and the previous date stays visible so you can see that something moved.

There are no accounts and no mailing list, so there is no way for us to write to you about it. For a change that materially affects what we receive or what we keep, a notice appears in the interface where you link, which is the one place everyone who uses the service passes through.

18. Complaints

Write to contact@handles.link first.

If you are in the United Arab Emirates, you can complain to the competent federal data protection authority. If you are in the European Union or the United Kingdom, you can complain to the data protection authority of the country you are in.