For the complete documentation index, see llms.txt. The full corpus is available at llms-full.txt. This page is also available as Markdown by appending
.mdto the URL.
Verifying an account
An account is Verified when a first party confirmed you control it: the platform itself, a post only the account holder could have made, a DNS record, or a signature from the key behind the account. Everything else is Claimed, which is your word and nothing more.
The distinction is not decoration. If the two were mixed together the word verified would stop meaning anything, which would make the whole directory worthless.
The two lists are drawn apart on purpose, and the claimed one says plainly that RealHandles has not confirmed anything about it.
Verify before you claim a handle
Section titled “Verify before you claim a handle”Proofs attach to your login, not to an identity. That is deliberate: a handle of 8 characters or fewer needs a matching proof, and you would otherwise have to claim the handle before you could prove you deserved it. Verify first, then claim.
The methods
Section titled “The methods”| Method | What it proves | Status | Can hold a short handle |
|---|---|---|---|
| Sign in with the platform (OAuth) | The platform says this account is yours | Verified | Yes, on a key platform |
| Post a one-time token (X, TikTok) | Only the account holder could publish it, and the platform tells us the author | Verified | Yes |
| Token in your channel description (YouTube) | Same, read back through the platform’s own API | Verified | Yes |
| Bluesky handle lookup (atproto) | The public atproto record resolves to you | Verified | Yes |
| Domain control (file or DNS TXT) | You control the domain | Verified | Yes, and it is the strongest |
| Wallet signature | The address signed our challenge | Verified | No |
| Nostr signature | The key behind the account signed our challenge | Verified | No |
Mutual rel="me" link | You listed the page and the page links back to this exact profile | Verified | No, see below |
| Token somewhere on a page | Somebody edited that page | Claimed | No |
| Self-attested | Nothing | Claimed | No |
Live OAuth platforms today: GitHub, Discord, Twitch, GitLab, Dribbble. Instagram and LinkedIn have no reliable read path yet, so an account there lands as Claimed until an OAuth app exists.
Three proofs, three different methods. A domain verified by DNS sits in the same list as an OAuth sign-in and a posted token, because all three are first-party checks.
Why some verified proofs still cannot hold a short handle
Section titled “Why some verified proofs still cannot hold a short handle”Three separate questions get asked about every proof, and a proof can pass one and fail the next.
- Is it verified? Did a first party confirm control.
- Does it add to the trust score? Every verified proof does. Claims do not.
- Can it reserve a scarce handle? Only a domain, or a matching handle on a curated key platform, proved by a method other than
rel="me".
The third bar is the strict one, and the reason is scarcity, not strength of evidence. @ben on X is globally unique and hard to get, so holding it really is a claim to the name “ben”. A rel="me" link on a page you built, or an account on a platform where anyone can register any name, proves you control that thing but proves nothing about the name. A namesake could mint one just as easily as you can, so it never takes a scarce name from somebody who can prove it.
Same logic for domains. A matching .com scores highest, established TLDs score below it, and anything else scores under the protected threshold. Otherwise ben.xyz for a dollar would beat a person who actually holds @ben.
Signing in with the platform (OAuth)
Section titled “Signing in with the platform (OAuth)”
The strongest and fastest proof, because the platform itself answers. Pick one and it sends you there and back.
The platform asks before it tells us anything. RealHandles requests your username and which servers you are in, and the screen states outright that it cannot read or send your messages.
Verified the moment you land back, and not yet public. That second half is the part people miss.
If you administer servers or organizations on that platform, you are offered them next:
Being an admin proves control regardless of who signed in, so these can be verified as first-party accounts too. Discord has no public server URL, so a permanent invite link stands in for one.
One thing to expect: if the desktop app is installed, the platform may try to hand the login to it and the browser tab will look stuck. Use the link to continue in the browser, or quit the app.
Domain proofs
Section titled “Domain proofs”
The token can go in a DNS TXT record on the domain, or in a file at /.well-known/realhandles-challenge.txt. It stays valid while DNS propagates, so there is no race to win.
Publish a one-time token at /.well-known/realhandles-challenge.txt, or add it as a DNS TXT record. Either one on its own is enough. The token is yours and does not expire, so setting it up on a computer later is fine.
A check that fails right after you set it up is normal. DNS changes and caches take minutes to hours to reach us. Nothing is lost, so wait and check again.
A verified domain is separate from an anchor, which is where a copy of your signed identity is hosted. Proving ben.com and anchoring at ben.com are two different actions.
Wallets and Nostr keys
Section titled “Wallets and Nostr keys”Both accounts are keypairs already, so a signature over our challenge settles it outright. No platform is asked and no page is read.
- The challenge is tied to your login and your key, so a signature made for it cannot be replayed somewhere else.
- The server recovers which address or public key signed. That address, not one you typed, is what gets recorded.
- A signature is public. Producing one proves the wallet without opening it, and no transaction is made.
If the address has a primary ENS name, or the Nostr key has a confirmed NIP-05, your profile publishes the readable name instead of the raw string. The key underneath is still what the identity rests on.
After you verify, publish
Section titled “After you verify, publish”A new proof lands on realhandles.com immediately and reaches your signed manifest only when you publish and re-sign. Until then, anyone verifying you independently sees the previous version. See The signed manifest.
Hiding an account
Section titled “Hiding an account”Hiding keeps the account and everything it has already proved. It stays attached to your identity and it still counts toward the handles you are allowed to hold. What changes is that the next version you publish leaves it out of the public manifest. So hiding on its own changes nothing for anyone checking you: it comes off your public proof when you publish, and showing it again later is a publish of its own, not an undo.
In the Android app
Section titled “In the Android app”Verifying lives under Identity > Verify. The methods are the same ones in the table above, reached differently: one way in, and three exceptions.
Add an account is the one way in. Paste the link to the account and the server answers with everything that link supports, strongest first. Paste github.com/yourname and you are offered the GitHub sign-in. Paste a page nothing can confirm and you are offered a claim instead. Before anything happens the screen says which one you are about to get, and whether that proof is strong enough to reserve a short handle.
The three rows under it are the cases a link cannot reach:
- Verify a domain. Name the domain, take the token, publish it in a file or a DNS TXT record, then press Check now. The token does not expire, so finishing on a computer later is fine.
- Verify a Nostr key. Signing is handed to a NIP-55 signer app such as Amber. The secret key stays inside the signer and is never seen by RealHandles or by the app.
- Verify a wallet. The app shows the exact message, you sign it in the wallet app and paste the signature back. No transaction, no gas.
Posting a token works the way it does on the website: the app issues the token, you publish it, then paste the link to the post and run the check.
OAuth on the phone
Section titled “OAuth on the phone”Signing in with the platform works in the app. The app asks realhandles.com for a start URL, opens it in the phone’s browser, and the finished handshake comes back to the app on a deep link.
Two things about that return are worth knowing, because they explain what you see:
- Nothing the return link says is displayed. The wording names the platform the app started, not whatever the link carried.
- What happened is read back from realhandles.com afterwards, because the server is the only party that knows whether a proof was actually created.
If you administer organizations or servers on that platform, the app offers them next, the same as the website does. A Discord server needs a permanent invite link, because Discord has no public server URL.
If the copy of realhandles.com being talked to cannot hand the result back to the app, the app refuses to start rather than strand you in a browser tab, and says to use the website for that one.
Hiding, on the phone
Section titled “Hiding, on the phone”The app can hide an account and cannot show it again. A hidden account is left out of the list the app reads, so once you leave the screen there is no row left to tap. Showing it again is done on realhandles.com.