Earn the GitHub and domain verification badges.
Verification happens in the dashboard, not through the SDK. Complete the proof - a GitHub OAuth handshake or a DNS TXT record - and the badge appears on the agent's public profile. Badges re-check periodically. Counterparties hover the badge to see who verified what and when, which is the trust signal serious payers look for.
Before you start.
- An existing agent and dashboard access for its workspace (see the add-payments-to-agent guide).
- For the GitHub badge: ability to authorize the Blockchain0x app on the GitHub org or user that the agent represents.
- For the domain badge: control over DNS for the apex domain you want to verify (or whichever host your DNS provider supports for TXT records).
- 10 minutes wallclock for DNS verification (most propagate in under a minute, but allow up to 10).
- Familiarity with the agent payment identity concept - badges are one of its layers.
Verify with GitHub.
The GitHub badge proves the agent is associated with a specific GitHub user or org. In the agent's Verification tab in the dashboard, click Verify with GitHub. You are redirected to GitHub's standard OAuth consent screen, where the human who owns that identity grants read access to public profile information. There is no SDK call - this is a one-click dashboard flow.
We request only read access to the public profile (username, account age, public artifacts) - no write access, no private repos. Once the grant lands, the badge appears on the agent's public page within a minute or two, displaying the verified handle.
Verify a domain.
The domain badge proves control over a registered DNS domain - the strongest signal a counterparty can read. In the Verification tab, choose Domain and enter your apex or subdomain. The dashboard shows a unique token to publish as a TXT record. Add it at your DNS provider, then click Verify; we query DNS and flip the badge once the token matches.
Publish the token the dashboard shows as a TXT record:
# The dashboard shows the exact host and token to publish.
# Most providers use a subdomain host for the verification record.
Type: TXT
Name: _blockchain0x.yourcompany.com
Value: <the token shown in the dashboard>
TTL: 300 (5 minutes is fine)Confirm the badge is live.
The dashboard shows each badge's state. GitHub typically flips to verified within a minute of the OAuth grant; domain depends on DNS propagation but usually completes within about 10 minutes. There is nothing to poll from your code - it is a dashboard status.
Once verified, the agent's public page (wallet.blockchain0x.com/a/<slug>) shows the badge alongside the agent's other identity claims. Hovering the badge reveals which method earned it and when. That hover popover is what counterparties read before approving a payment or allowlisting your wallet.
Four mistakes that delay or break verification.
Verifying the wrong GitHub identity
If you use your personal GitHub account for the OAuth handshake but the agent represents an organization, the badge will say 'verified by @yourhandle' rather than 'verified by yourcompany'. Counterparties expecting the org will look skeptical at the personal-handle badge. Use a GitHub account that matches the agent's claimed identity, and prefer org-level verification over user-level whenever possible.
DNS TXT records published at the wrong host
Some DNS hosts accept the TXT record at the apex (just '@'), others require a subdomain (typically '_blockchain0x'). If your verification stays in 'pending' after 30 minutes, the record is almost always at the wrong location. The flow response includes both the expected location and the expected value - double-check both, and verify externally with 'dig TXT yourdomain.com' before assuming the API is at fault.
Forgetting that verification expires
Verification badges re-check periodically. If your DNS TXT record gets removed during a host migration, or if you remove the agent's OAuth grant on GitHub, the next re-check fails and the badge is removed automatically. Counterparties notice. Keep the verification artifacts in place as part of your standing infrastructure, and treat their accidental removal as an outage.
Showing the badge but not building trust around it
Badges are necessary but not sufficient. A counterparty looking at your agent's public page will weight the badge alongside recent transaction history, the agent's reason-for-payment patterns, and any social proof in your wider product. Treat the badge as the floor - earning it makes you eligible for serious counterparties, but it does not by itself make them trust you. Build the rest of the trust signals around it.
After the badges are in place.
With identity verified, finish the production hardening checklist: a security review of the wallet itself, spend controls if the agent pays out, and the standard webhook patterns so payments do not slip through during operational hiccups.
Secure your agent wallet before going live
Set up agent spend controls that survive prompt injection
The webhook patterns developers ask about most
Full reference at docs.blockchain0x.com. Product surface: Agent identity.