Why an AI agent needs more than a wallet address
A wallet address can prove it controls funds and can sign a transaction. That's genuinely useful, it's why permissionless systems work at all. But it cannot prove who's behind it, whether that operator has been checked by anyone, or what the agent is actually authorized to do. As agents increasingly trade, hire other agents, and pay for API calls on their own, that gap stops being academic. A relying party, another agent, a merchant, a platform enforcing a spending policy, needs an answer to "who's accountable if this misbehaves," and a bare address has no way to give one.
This isn't a story about one vendor's approach being right. It's three distinct patterns for grounding an agent's identity, each answering a different slice of that question, and each with real limits worth naming plainly.
Pattern 1: wallet-address-only
The simplest option is also the most common one today: an Externally Owned Account (EOA), a keypair, nothing else. It's permissionless (anyone can generate one, no registration, no gatekeeper) and it's genuinely sufficient for what it's built for: proving control of a key and authorizing a transaction with a signature.
What it can't do is carry any provenance. The address itself is just a public key hash; nothing about it says who generated the key, what entity operates the agent behind it, or whether that operator has ever been checked by anyone. Two addresses that behaved identically yesterday could belong to a careful, accountable operator and to nobody in particular: the address alone gives no way to tell them apart. For a relying party trying to decide whether to extend trust, an address-only identity answers "can this key sign" and nothing else.
Pattern 2: soulbound-token-bound
A step up: bind a non-transferable token, a soulbound token, in the term the field converged on, to that same address. This adds a marker that can't be sold or handed off, which rules out a specific failure mode of pattern 1: an operator building a reputation on one address and then quietly selling that address (and its history) to someone else.
But a soulbound token by itself usually doesn't carry a portable, third-party-verifiable credential underneath it: it's a marker attached to a chain, checkable by whoever indexes that chain, not a signed claim a relying party can validate independently against an issuer. And it's still bound to the address, not to a person or organization. It answers "has this address always belonged to the same continuous history" a little better than pattern 1, but it still can't answer "who operates this, and were they ever checked."
Pattern 3: DID+VC-bound
The third pattern separates the agent's identity from any single address by anchoring it to a Decentralized Identifier (DID) and pairing that DID with a Verifiable Credential (VC), a data model defined by the W3C, not something Solidus originated (see the Verifiable Credential entry for the standard itself). A credential here is issued by some third party, is portable across platforms rather than tied to one chain's indexer, and, depending on the credential format, can support selective disclosure: proving a specific claim ("this operator passed a KYC check") without exposing the underlying document that backs it. Crucially, it's checkable independent of any single platform's say-so, because the check runs against the issuer's signature, not against a platform's internal database.
did:solidus's listing in the W3C DID Method Registry is one concrete, checkable example of what this "paperwork" actually looks like in practice, not the only way to build the pattern, and not a claim that this is the best or only implementation of it. What it demonstrates is the shape: a real agent gets a real DID, that DID is registered under the method's own extension mechanism (verifiable by anyone: curl the ERC-8004 registry, resolve the DID, compare), and the resulting identity is checkable by a stranger without asking Solidus to vouch for it. The agent passport page walks through that worked example end to end, the same eth_call-and-resolve sequence a skeptic would run themselves.
The honest tradeoff
DID+VC-bound identity answers real questions the other two patterns can't. It's also the heaviest to integrate: it requires an issuer relationship, a resolver, and a verification step a relying party actually has to run, where checking a bare address is a single eth_call. And its trust doesn't come from the cryptography alone: a signed credential is only as good as whoever signed it. That pushes the hard question one level up, from "does this agent have a credential" to "who issued it, and why should anyone trust that issuer." That's a real, separate question, and it deserves its own careful answer rather than a hand-wave here, see how operator KYC works for AI agents for what that issuer relationship actually looks like, and where its limits are.
None of these three patterns is free. A bare address costs nothing and proves the least. A DID+VC pairing costs the most to integrate and proves the most, but only as far as its issuer's credibility reaches. Knowing which question you're actually trying to answer is what decides which pattern is worth the integration cost.