01For developers
Enhance the experience of your users
alice.x.handles.link02Resolution
Already on ENS?
Handle Resolution is included.
Every handle is an ENS subdomain — alice.x.handles.link — so a handle is a name your resolver already understands. If your application reads ENS today, it reads handles today. No SDK, no API key, no migration, nothing added to your build. You connect users the way you connect them now, and a handle resolves to an address like any other ENS name.
Two limits ride along with this path, and both come from ENS rather than from us. Sending funds needs the full name, alice.x.handles.link, not the bare handle. And ENS can’t send to a handle nobody has registered yet. Some wallets also don’t send to ENS names out of the box.
03Agents
The same thing works for agents.
An agent with an account on a supported platform gets a handle like anyone else — mybot.github. It can be paid, and it can pay.
Through the SDK it can also send to a handle nobody has linked yet, so an agent can pay a person, or another agent, without either of them having linked anything first.
04Direct integration
Connect to our SDK for:
01
Handles get shorter — inside your application a handle is alice.github, without the handles.link tail.
02
Transact with every user like they are already on chain — even people who haven’t linked a handle, reaching anyone already on the platforms we support.
05Documentation
Don’t trust. Verify.
The protocol spec, the resolution flow, the self-hosting guide and the repository are public. No form, no key request, no call.
06FAQ
Two things happen, and they are separate. Linking. A person proves they control a social account and connects the wallet they already use. From then on the handle points at that wallet's address. Nothing about the wallet changes and nothing leaves it — the proof and the connection both happen inside the user's own wallet popup. [ How linking works → ] Sending. An application looks up the address by handle and sends to it the way it would send to any address. Resolution runs on LibID, the open protocol underneath handles.link — handles.link is one bridge built on it, not the protocol itself. [ How resolution works → ] The full spec is public: [ Read the spec → ]
X, Google and Github out of the box. Any other OAuth/OIDC iDP (identity provider) can be added through libID’s extensible library. You can add and contribute support to any new one in a few prompts.
Out of the box Ethereum, Base, Polygon, MegaETH, and Eden with any EVM-compatible wallet. Support for non-EVM networks is planned, and the established architecture was meticulously designed around that.
No. handles.link is an identity bridge, not a wallet. A handle points to the linked wallet the user already controls, and everything that touches that wallet happens in the user's own popup. There is no path through our system that reaches key material or funds.
Only the owner of the social account can change what a handle points to, and only by proving they still control it. That single rule answers the whole family of questions. If the account is compromised, the handle can be relinked elsewhere and links back once access is restored. If someone tries to claim a handle that impersonates a well-known account, they can't: the handle is issued only to whoever proved control of that account in the first place. And in every one of these cases the wallet is untouched — it was its owner's before the handle existed and stays theirs afterwards.
Yes. LibID is open, and handles.link is one bridge on it rather than a gate in front of it. You can run your own, set your own terms, and keep going without us. There is also nothing of yours to take with you if you do. We don't hold your data, your users' keys, or their funds — a handle points at a wallet its owner already controls, so removing the integration changes no address and moves no asset. [ What a bridge is, in detail → ]
No. There is no handles.link account — a user's wallet is their credential, and the handle is what it's called. Linking is not registration. Someone who already has an account on a supported platform can be transacted with before they have linked anything at all.
You could, and the first version is a weekend. The part that isn't a weekend is everything after: proving a wallet belongs to the account that claimed it, handling transfers and revocation, rotated and disconnected accounts, and resolution that other applications also honour — a handle only works as an address if more than one place resolves it. That work is LibID, and it's open. Build on it, or run your own bridge on it. There's no reason to build beside it.
Yes — open source, not source-available. LibID is public, and so is the bridge built on it.
Not announced yet. There will be a cost, and we would rather say that than pretend otherwise. The numbers go here the moment they're fixed.
07Wallet
A wallet is coming.
handles.link is an Identity Bridge. The wallet built on top of it is next, at handles.link/wallet. Short handles and sending to someone who hasn’t registered yet are native to that wallet, and any application that integrates it directly gets both.