What you will build

A public payment identity for an AI agent: a profile that ties the agent's wallet to a real operator and proves it, so anyone deciding whether to pay the agent or accept its payment can check first. The wallet is the account; the identity is the reputation attached to it. By the end your agent has a page at wallet.blockchain0x.com/a/{slug} that a counterparty can open and trust.

If your agent does not have a wallet yet, start with how-to-add-wallet-to-my-agent. The agent identity product page is the broader reference.

Why an agent needs a payment identity

A wallet address is anonymous by design. It is a string of hex that says nothing about who controls it. For a human paying a human that is often fine, because trust came from somewhere else, a contract, a relationship, a brand. For an agent transacting with strangers, there is no prior relationship to lean on, and the address is all the counterparty has.

That is the gap a payment identity fills. When another agent or a person is about to pay yours, or about to accept a payment from it, they want to know who stands behind the address. An identity answers that: this agent is operated by this party, who has proven control of this email, this GitHub account, this domain. The payer can check the claim before they act, the same way they would confirm a payee before a bank transfer.

Without it, your agent is a bare address competing against other bare addresses, and the careful counterparties, the ones worth transacting with, route around anonymity. With it, your agent is a known entity, and that is what gets the first payment through.

Prerequisites

• A Blockchain0x account with the agent created, so it has a wallet and a profile.
• Access to the channels you will verify: the email, the GitHub account, or the domain you want to bind to the agent.
• A few minutes in the dashboard. The identity is profile-managed, not set from code.

The public profile

Every agent has a public profile at wallet.blockchain0x.com/a/{slug}. This page is the identity. It shows the agent's name, its wallet address, and the verification badges the operator has earned. It is meant to be shared and checked: you put the URL where counterparties will see it, and they open it before they transact.

You can read the agent's record programmatically to confirm what is set, using the same client you use for everything else:

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);

The profile content itself, the display name and the verification badges, is managed in the dashboard rather than through the SDK, because identity is a human-curated trust surface, not something an agent should be able to rewrite about itself.

What a payment identity is made of

Three parts, in increasing order of trust.

The name and wallet address are the baseline. They say "this is the agent, and this is where its money moves". On their own they are an assertion, not proof.

The verification badges are the proof. Email verification shows the operator controls a working address. GitHub verification links the agent to a real developer account with its own history. Domain verification is the strongest, because it ties the agent to a domain you control, and a counterparty who recognizes that domain recognizes who they are dealing with.

The binding between them is what makes it an identity rather than a bio. The address on the profile is the agent's actual wallet, so the thing a counterparty verifies is the same thing that sends and receives the money. There is no gap between the reputation and the account.

Why identity decides whether you get paid

For an agent that transacts with the open market, identity is not decoration; it is conversion. Put yourself on the other side. You are an agent, or a person running one, about to pay an agent you found for a service. One candidate has a bare address and no profile. Another has a profile with a verified domain you recognize. You pay the second, every time, because the first is indistinguishable from a scam and the second is accountable.

The same asymmetry runs on the receive side. A counterparty deciding whether to accept a payment from your agent, before delivering something in return, checks who is paying. A verified identity turns "an unknown address sent funds" into "a known, accountable party paid", and that is the difference between the transaction completing and the counterparty backing out. Identity is the cheapest trust you can buy, and it compounds: every verified badge raises the floor on every future transaction the agent makes.

Which badge to earn first

You do not have to earn all three at once, so spend the effort where it buys the most trust for your situation.

Earn email first, always. It is the fastest, it is the baseline every other badge builds on, and a profile with at least one verification reads very differently from one with none. It is the cheapest move from "anonymous" to "accountable".

Then choose based on who your counterparties are. If your agent transacts with developers and other technical builders, GitHub is the high-value second badge, because that audience reads a real GitHub history as a strong signal. If your agent represents a company and pays or bills businesses, domain is the one that matters most, because a counterparty who recognizes your domain instantly knows who they are dealing with. Most agents end up wanting all three, but the order is email to establish the floor, then GitHub or domain depending on whether your market trusts a developer or a brand. Earning the wrong one first is not harmful, just slower to pay off.

Set it up today

Create the agent so it has a profile, set its display name in the dashboard, and start the verification you can finish fastest, usually email, then add GitHub and domain. Share the profile URL wherever counterparties will encounter the agent. The mechanics of earning each badge live in the dashboard under the agent's identity settings; this page is about understanding what the identity is and why it matters before you do the steps. The agent identity product page covers the badge set in full.

Common pitfalls

Three traps.

Treating identity as optional for a market-facing agent. If strangers decide whether to transact with your agent, identity is load-bearing, not nice-to-have. Skipping it caps how much your agent can earn or spend with anyone careful.

Sharing the address without the profile. Handing out a raw wallet address throws away the trust you could have conveyed. Share the profile URL, which carries the address and the proof together.

Letting the profile and wallet drift. The strength of the identity is that the verified profile shows the real wallet. Do not promote one address while the profile shows another; the mismatch reads as exactly the kind of thing a careful payer avoids.

What to ship today

Create the agent, set its name, and earn the email badge as a first step, then share the profile URL. Add GitHub and domain verification as you go from the agent's identity settings in the dashboard. Pricing, including the tiers that cover more of the identity surface, is on the pricing page.