FAQ

Your unique user name on a platform you already use, turned into something that can receive money.

You will mostly see it as alice.x — the name with the platform inside it. That form matters, because the same person can hold alice.x, alice.github and alice.google, and each one is a separate handle.

A handle becomes a linked handle once you connect it to a wallet of your own.

Yes. ENS is the naming system EVM apps already use — the thing behind names ending in .eth. A lot of wallets and apps can read it without anyone telling them to.

While having a completely different architecture, handles.link integrates with ENS, and that is the whole reason a handle.link works out of the box in major wallets. Nobody has to integrate anything for it to resolve.

The borrowing has one cost. In an app that reads ENS but does not know handles.link, you type the long form — alice.x.handles.link — instead of alice.x. In an app that has integrated handles.link, the short form is enough.

And not every wallet reads ENS names yet. That is an ENS-side gap rather than ours, and it is the reason the long form exists at all.

It links the handles you already have on X, GitHub and Google to a wallet you already own, so people can transact with you by the handle instead of the address.

No. Any EVM-compatible wallet, and WalletConnect. You link the one you already use, and it stays exactly what it was — same address, same keys, same app.

No. You sign in with the platform account, approve the authorisation in the platform's own popup, and approve the linking transaction in your wallet. That is the whole flow — no extension, no download, no seed phrase.

No. There is no handles.link account and no handles.link password. Your wallet is your credential, and the handle is one you already own on the platform you picked. handles.link is the bridge between the two.

Linking costs money. There are three parts to it.

The network charges a fee for the transaction. That one moves with the network, it is not ours, and it is not fixed. We charge a fee for the link itself. And there is a verification fee, which covers checking that the account is really yours.

There is no single number to quote, because the total depends on the network you pick and on the platform the handle comes from. The exact estimate for your choice is on screen before you confirm anything.

You and the platform, together. A handle is yours in the context of the platform it came from: you own the account, but the platform can take the account away at their discretion. That is the reality today, and not one we can override, and bringing handles onchain is the first step towards changing it.

Not if you have already linked it. The link stays where it is, money sent to the handle still arrives in your wallet, and you can go and recover the account without hurrying.

Two things follow. If you have not linked yet, you cannot — linking needs you to sign in to the account. And if you linked more than one account to the same wallet, the others carry on working, which is the cheapest reason there is to link a second one.

The long tail belongs to the platform rather than to us: an account you never get back is an account someone else controls, and eventually a handle they can relink. What they cannot do is reach your wallet.

Nothing changes the same day. The link stays where it is, and transactions sent to the handle still arrive in your wallet.

What can change later is the pointer. Whoever takes the username can prove control of it and relink the handle to their own wallet, signing that in their own wallet the way you signed in yours — it is a transaction somebody makes.

They get the name. They do not get the wallet it used to point at, nothing in it moves, and nothing you have already received is affected.

Eventually, onchain handle ownership may become authoritative over what platforms say, but it is too early for that at the moment.

You and only you. We or any platform can never touch your funds or keys. A handle is a pointer: it holds nothing, and it signs nothing. Every transaction is still signed in your own wallet, exactly as it was before you had a handle.

Yes. A linked handle is a pointer and relinking it is a normal thing to do — you connect a different address and the handle follows.

You can relink, but cannot unlink. The unlink functionality is possible, but hasn’t been prioritized.

They cannot. A handle is issued to whoever proves control of the matching account, inside that platform's own login flow. There is no queue to jump and nothing to claim early — if you hold the account, the handle is yours whenever you want it. No squatting is possible.

The one way a handle may change hands is when the account does.

A lookalike handle needs a lookalike account first. We do not hand out names, we bind the ones the platform already issued — so a near-miss handle is the same problem as a near-miss account on X, and it lives in the same place.

What it cannot do is reach anything. A handle points; it opens nothing. Nothing can be taken out of your wallet by someone holding a name that resembles yours, and nothing in it is frozen or blocked.

Yes. Each handle points to exactly one address, and one address can carry as many handles as you have accounts. An X handle and a GitHub handle can both point at the same wallet, or at different ones.

Three ways, and which one a person gets depends on the app they are in.

Using handles.link/send

In an app that has integrated handles.link, they type alice.github and send.

Anywhere that reads ENS names, they type the full alice.github.handles.link.

If the app reads ENS names, yes — a handle is an ENS name, so it resolves the way a .eth name does, with no integration on their side. If the app does not read ENS names, no, for the same reason a .eth name would not work there either.

On the integrated path, yes. The amount waits on a contract, on-chain, marked for the handle. It is not held by us and no person at the company decides when it moves — it moves when you connect an address and prove the handle is yours.

Worth knowing: because it waits on a public chain, a transfer addressed to you is visible before you know about it.

The plain ENS path cannot do this, so whether it works depends on the app.

Yes. An agent with an account on a supported platform gets a handle on the same terms a person does, and can be paid at it. There is no separate agent product and no special case in the protocol — which is the point.

Two separate things, and they are worth keeping apart.

Your wallet's transaction history is as public as the blockchain you link on. That is a property of the chain rather than of us, and every chain we launch on is a public one.

A link is unlisted by default: the chain stores a fingerprint of your handle, not the handle itself. Unlisted is not secret. Anyone who has or guesses your handle can look up the linked address, and if you set it as your primary handle, anyone can read it on an explorer.

Which is why the address you link is a choice. If you do not want your main one carrying a public name, link a different one.

Yes, and it is the default. Setting a handle as your primary one is a choice you make when you link. Either way the handle keeps working: people can send to it, and it resolves to your address.

Unlisted, your wallet does not carry the handle as its name, and the chain keeps only a fingerprint. That is not secrecy. Anyone who has or guesses the handle can check which wallet it points to, and a fingerprint of an account number can be matched by trying numbers.

Partly. Once a handle is your primary one it stays in the chain's history. Linking the account unlisted to another wallet takes the name off the old one, but the earlier record stays in the history, and anyone looking for it can still find it.

A handle is the account name you already use, so it is exactly as anonymous as that account is. An anonymous X account makes an anonymous handle. Nothing here asks for a legal name, a document or a phone number.

Almost nothing, and that is a matter of how it is built rather than a policy we promise to keep.

When you link, the zero-knowledge proof is assembled in your browser. What the platform hands back arrives in your browser and goes from there to the blockchain directly — we are not standing in the middle of it. What ends up on-chain is a fingerprint of your username and user ID on that platform, plus the username itself if you set it as your primary handle. From that point, they are public blockchain information, which is the same thing D1 describes.

Everything else the sign-in produces, the access tokens above all, stays in your browser and never leaves it.

There is no user database on our side, and we do not log who looks up which handle. The code that would have to do the logging is public, so that is checkable rather than promised.

If you bought a .eth name and it works for you, keep it — a handle does not replace it and both can point at the same wallet.

The difference is what it takes to have one. There is no name to buy here, nothing to renew and nothing to lose by forgetting to. The handle exists because the account does.

You can, and people do. The reason this exists is that nobody reads a hex string, so nobody checks one properly either — and an address is the one thing in crypto where being almost right is the same as being wrong.

No. The wallet is the one you already have — the handle is the name that points the way to it. A wallet of our own is coming later and separately, at handles.link/wallet.

Yes, in the sense that matters — dual MIT and Apache-2.0, public from the first day, and published to the standard package registries so anyone can pull it in rather than copy it out. Not "you can look but not use".

The open protocol underneath. handles.link is one bridge built on it; libID does the identity bridging. Anyone can build another bridge, and nothing about the protocol has to come through us.

Handles.link relies on an innovative open protocol (libID) that is brand new and implies a certain risk. An independent security audit has been started and is not finished. In the meantime, the contracts are re-audited internally and continuously with the frontier LLMs.

What you can check without waiting for any of that is the code. libID is public under MIT and Apache-2.0 and has been public from day zero.

You are not giving it any. Nothing transfers, nothing is deposited, and there is nothing to withdraw later. The wallet is yours throughout, and the most that is ever at stake is that a name points at an address.

Links are stored on blockchain smart contracts developed as part of permissionless libID protocol, not on a server of ours. Looking it up is done by software that is public and that anyone can run, so the answer does not depend on us being here.

Grounded Systems - a small and mighty team of passionate protocol and product engineers/visioners focused on making cryptocurrencies accessible. The protocol underneath is libID — open, public, and permissionless.