Onchain Identity for AI Agents: What the Chain Proves
An onchain identity record can show which address controls a registered identifier. It may also point to metadata, record an attestation, or commit to a particular version of a document.
Those are useful facts. None automatically proves that an AI agent belongs to the company named in its profile, delivers the service it advertises, or has permission to act for a customer.
Onchain digital identity uses blockchain records as evidence about an identifier, its control, or claims associated with it. For an AI agent, the useful question is specific: what does this record let another party verify?
People and Agents Can Use the Same Identity Primitives
A wallet address, registry entry, or signed statement can participate in an identity system for a person, organization, or software agent. The underlying mechanism does not become a different kind of proof because an agent uses it.
Nor does every decentralized identity system require a blockchain. The W3C DID specification allows different registry technologies and distinguishes the subject being identified from the controller who can update its identifier document.
An organization might control an agent's record while the agent runs under separate service credentials. A key associated with the record does not, by itself, explain that operating relationship.
For the broader definition and components, see What Is Agent Identity? Here, the focus is the evidence an onchain record actually supplies.
Match Each Proof to the Claim It Supports
“Verified onchain” leaves too much unsaid. A reviewer needs to know what was checked, against which source, and at what state of the chain.
| Evidence checked | Supported conclusion | Still unproven |
|---|---|---|
| Registry state at a specified block | The registry assigns control to this address | The controller's real-world identity |
| Valid signature over a fresh challenge | The relevant signing authority approved that message | Authority over unrelated services or actions |
| Document matches a recorded content hash | These bytes match that commitment | The document's claims are accurate |
| Valid issuer attestation | The issuer made the specified statement | The issuer is reliable or the statement sufficient |
| URI stored in the registry | The record points to that location | Everything currently served there is verified |
A signed challenge also needs a clear purpose and freshness checks. Otherwise, evidence collected for one interaction can be mistaken for approval of another.
Attestations need the same care. The W3C Verifiable Credentials Data Model distinguishes verifying a credential from deciding whether its claims are true. A verifier still evaluates the issuer, applicable status information, and whether the claim meets its requirements.
Ask Where the Identity Data Actually Lives
An identity can have an onchain anchor and mostly offchain content. Read the storage arrangement before describing the whole record as “onchain.”
A stored URL is a pointer. If it leads to an ordinary HTTPS document, the server may change the document without changing that URL. The registry entry alone does not bind every future response to the bytes a reviewer saw today.
A content hash binds particular bytes. When a document matches a securely obtained commitment, the reviewer can detect a different version. The match does not establish that the document is honest, that its endpoint works, or that the content will remain available.
Content stored directly onchain has a different retrieval path. Its claims still require interpretation. Moving a service description onto a blockchain does not test the service.
Keep the evidence chain visible: the registry record, the referenced content, and any separate evidence supporting that content's claims.
A Company Name in a Record Is Still a Claim
Consider, for example, an agent profile that says “Operated by Northstar Services.” A reviewer confirms that a wallet controls its registry entry and that the profile matches the hash recorded there.
The reviewer has established control of the entry and a match to a particular document. The company attribution remains unresolved. Anyone able to publish a profile can type a company name into it.
Evidence from an independently established company channel could support the relationship. For example, the company's authenticated website could identify the same agent record. An appropriate attestation could provide another route, depending on who issued it and what was checked.
Even after confirming the operator, the reviewer has a separate service question: does the advertised endpoint perform the claimed work? And a customer has a separate authorization decision: may this agent access this account or spend this amount?
Keep those findings separate in the review. A precise statement such as “registry control checked; company affiliation unresolved” is more useful than a blanket verified badge.
ERC-8004 Shows Why the Pointer Distinction Matters
ERC-8004, currently a Draft proposal, describes an identity registry with an agent registration URI. That URI can reference HTTPS content, IPFS content, or an embedded data URI, and it can be updated.
The registration and the information it references therefore need separate inspection. An identity identifier needs its registry context, including chain and contract, rather than a bare numeric agent ID.
For the dedicated discussion of connecting these records, read ERC-8004 and Headless Domains.
Check Current Control, Not Just Historical Registration
A transaction proves something about the state in which it was accepted. It does not establish that the same controller remains in place today.
Records can change under their system's rules. Control may transfer, a pointer may be replaced, or an attestation may cease to be valid. A screenshot of an old registration cannot answer all of those questions.
Record which chain and registry you checked, the relevant block or observation time, and the specific conclusion. When a decision depends on current control, consult current state using an appropriate confirmation policy rather than relying on an old event alone.
The migration process belongs in Canonical AI Agent Identity. This article's narrower point is that durable history and current authority are different findings.
Where Headless Domains Fits
Headless Domains uses Handshake naming infrastructure. Handshake uses a blockchain for its naming root; it does not replace the whole DNS system or put every service response onchain.
Headless Domains also supports DNS pointers and hosted or self-hosted identity content, described in its profile documentation. A blockchain-backed naming foundation should not be presented as proof that every profile field, manifest, or API response is stored onchain.
The available namespaces include .agent, .chatbot, .boss, .factory, .protocol, .bpo, and .manifest. A name gives callers a reference from which to discover published information. They still need to assess that information and enforce their own access rules.
A marketplace or Headless Profiles listing can provide another discovery route to the same published identity. That listing does not add cryptographic proof merely by displaying it, and cross-platform verification depends on what each platform actually implements.
Write Down the Fact You Verified
Before relying on an onchain identity, finish this sentence: “Using this source, at this state, we verified this specific fact.”
Then name what remains unresolved: operator affiliation, document accuracy, endpoint behavior, or authority for the requested action. That gives the next person or agent enough information to decide what still needs checking.
To publish a discoverable identity with Headless Domains, start with the current machine-readable setup instructions.