ownership-pseudonym verifier, and your app gets a reusable proof ID it can badge, link, and gate.
When to use this
- Creator platforms, media networks, or launchpads that need handle ownership proof.
- Pseudonymous identity without legal identity exposure.
- Gating drops, founders tables, or premium calls behind a verified handle.
What you need
- A published Proofable gate with
ownership-pseudonymenabled (or use direct verification with in-app signing). - The user’s wallet address.
- A
namespaceto isolate your handles from the defaultneusnamespace.
Flow
- User claims a handle in your app.
- Your app asks Proofable to bind
handle+namespace+walletAddress. - Proofable returns a proof ID in
qHashand a proof URL. - Your app stores the proof ID with the user record.
- Surface a verified badge that links to the public proof page.
- Before any privileged action, check the proof on your server.
Direct verification (in-app signing)
UseProofableClient.verify() when your app already handles wallet signatures.
pseudonymId must match ^[a-z0-9._-]{3,64}$ (3–64 lowercase chars).
Hosted Verify (no in-app signing)
Send the user to Proofable and get the proof ID back on return.qHash field in the callback URL or popup message and store it.
Show the badge
Drop the SDK widget next to the handle.https://proofable.me/proof/{qHash} and shows live proof status.
Gate creator actions on the server
Always check the proof server-side before allowing privileged actions.Namespace policy
Namespaces other thanneus require the namespace owner to confirm DNS control with ownership-dns-txt, or Proofable admin approval. Contact Proofable to reserve a production namespace for your platform.
Optional: link social accounts
Layerownership-social to also confirm a linked X, Discord, Telegram, GitHub, or other social account. Social checks are interactive and hosted-only, so they usually run through VerifyGate or Hosted Verify rather than direct signing.
