What you will do
Earn the verification badges on an AI agent's profile so counterparties can trust its wallet. You will verify email, then GitHub, then your domain, each from the dashboard under the agent's identity settings. When you are done, the agent's public profile at wallet.blockchain0x.com/a/{slug} shows the badges, and anyone deciding whether to transact with the agent can see, at a glance, that a real operator stands behind the address.
This is the step-by-step. For why identity matters in the first place, the concept is in how-to-give-ai-agent-payment-identity. If your agent does not exist yet, create it first with how-to-add-wallet-to-my-agent. The agent identity product page is the broader reference.
The three badges
There are three identities you can prove, and they stack from quickest to strongest.
Email proves the operator controls a working address. It is the baseline and the fastest to earn.
GitHub proves the agent is linked to a real developer account with its own history. For an agent whose counterparties are technical, this is a strong second signal, because a populated GitHub account is hard to fake convincingly.
Domain proves the agent belongs to a domain you control. It is the strongest badge, because a counterparty who recognizes the domain instantly knows who they are dealing with. A verified domain tied to a company name turns an anonymous address into a known business.
You do not have to earn all three at once. Email first, then whichever of GitHub or domain matches your market.
Prerequisites
- A Blockchain0x account with the agent already created.
- Access to whatever you are verifying: the inbox for email, the GitHub account, or DNS control for the domain.
- The agent open in the dashboard, on its identity settings.
You can confirm the agent exists and is the right one before you start:
import { createClient } from "@blockchain0x/node";
const client = createClient({ apiKey: process.env.B0X_API_KEY! });
const agent = await client.agents.get("agt_...");
console.log(agent.id, agent.name, agent.network);Verify email
Start here, because it is a two-minute task and every profile should have it. In the agent's identity settings, enter the email address you want to bind and request verification. The dashboard sends a message to that address with a confirmation link or code. Open it, confirm, and the email badge appears on the profile.
The address you verify should be one the operator actually monitors, not a throwaway. The badge says "this operator can be reached here", and that promise only holds if the inbox is real and watched. Use a role address you control long-term rather than a personal one that might disappear when someone changes jobs.
Verify GitHub
Link the agent to a GitHub account to earn the developer-trust badge. In the identity settings, start GitHub verification and follow the prompt to connect the account. The point of the badge is the account's credibility, so connect the real account with genuine history, not a fresh one created for the purpose. A counterparty who clicks through to an account with years of activity reads that very differently from an empty profile made yesterday.
Connect an organization account rather than a personal one if the agent represents a company, so the badge points at the company's GitHub presence and survives any individual leaving. If you only have a personal account today, it is still worth connecting, because a real personal history beats no badge at all, and you can move the verification to an org account later when you have one.
Verify your domain
Domain verification is the strongest badge and worth the few extra minutes. The dashboard gives you a record to place on the domain you want to bind, typically a DNS TXT record with a value unique to your agent. Add that record at your DNS provider, then return to the dashboard and run the check.
Because only someone who controls the domain's DNS can add the record, a passing check proves you control the domain, and the domain badge appears on the profile. Two practical notes. DNS changes take time to propagate, sometimes minutes, sometimes longer, so if the first check fails, wait and retry rather than assuming you got the record wrong. And keep the record in place; removing it later can invalidate the verification, because the proof of control is the record's continued presence.
How counterparties read the badges
It is worth verifying with the reader in mind, because a badge is only as useful as what it tells the person on the other side. When a counterparty opens your agent's profile before transacting, they are doing a quick risk read, and each badge answers a different question for them.
Email answers "can this operator be reached if something goes wrong". It is the floor, and its absence is a red flag more than its presence is a strong positive: an agent with no email badge at all reads as someone who could not be bothered, which is not who a careful payer wants to transact with.
GitHub answers "is there a real builder behind this". A counterparty clicks through, sees genuine history, and relaxes. An empty or brand-new account does the opposite, so only connect a real one.
Domain answers "do I know who this is". This is the badge that closes deals, because recognizing the domain collapses the whole trust question into a name the counterparty already trusts. If your agent will transact with businesses, the domain badge is the one that moves the needle most, and it is why it is worth the DNS step even though it takes longest.
Confirm and maintain the badges
Open the public profile at wallet.blockchain0x.com/a/{slug} and confirm the badges you earned actually show. That page is what a counterparty sees, so check it the way they will, not just the settings screen.
Then treat verification as living state. Badges reflect control of a channel at the time you verified, and control can change. If you rotate the GitHub account, move the domain, or retire the email, re-verify or remove the affected badge so the profile never claims more than is true. A stale badge that points at a channel you no longer control is worse than no badge, because it misleads the exact careful counterparty the badge was meant to reassure. Re-check after any change to the underlying accounts.
Common pitfalls
Three traps.
Verifying a throwaway channel. A badge on an email or account you do not really control, or will not keep, is fragile. Verify channels you own for the long term.
Assuming a failed domain check means a wrong record. It usually means DNS has not propagated yet. Wait and retry before re-editing the record.
Letting a badge go stale. Identity is not set-and-forget. When a channel changes hands, re-verify, because a badge that no longer reflects reality undermines the trust the whole profile is built on.
What to ship today
Earn the email badge now; it takes two minutes and moves the agent from anonymous to accountable. Then add GitHub or domain depending on who your counterparties are, and confirm the badges on the public profile. For why this matters before you spend the time, see how-to-give-ai-agent-payment-identity. Pricing, including the tiers that cover more of the identity surface, is on the pricing page.