ERC-8004 explained: the draft standard for trustless agents

The hard part of putting AI agents to work is not that they can act on their own. It is that agents built by different organizations, running on different software, have to deal with counterparties they have never met, and each side needs enough verifiable information to decide whether to proceed. Inside one platform, the platform answers that question. A platform’s directory, however, only reaches the participants who already trust the same operator. When an agent crosses an organizational boundary, that assurance stops at the border.

ERC-8004, titled “Trustless Agents”, is a draft Ethereum standard that proposes three onchain registries (identity, reputation and validation) to give an agent a record that others can read without asking a platform to vouch for it. It is a draft, and it may change. After reading this article, you will be able to describe what each of the three registries is for, say what the draft does and does not settle, and explain where naming fits. You will also know what an organization can reasonably do while the text is still a draft.

One caution before starting. “Trustless” is a term of art. It means that you do not have to rely on one intermediary’s word, because the records are public and anyone can read them. It does not mean that risk disappears, and it does not mean that an agent with a record is an agent that behaves well. That distinction matters for any legal or risk function reading the proposal.

The problem the draft addresses

Agents can exchange messages, act and transact, yet they struggle to show who they are and why anyone should rely on them. That gap is tolerable while an agent works inside a single platform, where the platform itself is the reference point. It becomes a real obstacle when one organization’s procurement agent negotiates with another organization’s fulfillment agent, and neither operator has an account with the other’s provider.

Without a shared way to identify and assess agents, each vendor ends up trusting only its own, and every interaction across organizations needs a prior arrangement between people before the first machine message is sent. The cost is more than technical friction. It caps what agent systems can do, because the number of counterparties an agent can deal with is limited to those somebody has already vetted by hand.

A useful agent identity is more than a label or a wallet address. A counterparty wants to know who operates the agent, where it can be reached, what it claims to do, and what others have observed about its past work. ERC-8004 is an attempt to standardize where those answers are recorded, so that any counterparty can look them up on a public ledger instead of in a private directory.

The draft does this with three separate records. The first says that the agent exists and points to its description. The second collects what those who worked with it reported. The third collects what independent parties found when they checked its work. Each is covered below, with the same reservation every time: this is the shape of a proposal, not a settled rule.

Draft status and what it implies

ERC-8004 is a draft. On Ethereum, a standard starts life as a public proposal document that is discussed, criticized and revised in the open before it is treated as settled. A draft sits at the early end of that process. Its authors can revise it, reviewers can ask for changes, and parts of the specification may be rewritten, renamed or removed before it settles, if it settles at all.

Three practical consequences follow.

First, a description of the draft, including this one, is a description of a text at one point in its life. The broad design of three registries is the stable part of what you can say. The details of how each registry behaves are the part most likely to move, which is why this article stays at the level of what each registry is for.

Second, software written against a draft may need to be rewritten. Smart contracts, the programs that run on a blockchain, can be deployed by anyone at any stage of a proposal. The existence of working code that follows a draft says nothing about whether the draft is final. An organization that builds on a draft is building on a moving reference and should budget for that.

Third, adoption is a separate question from the text. A standard matters when wallets, platforms and counterparties actually read the records it defines. A well-drafted proposal that few systems consult gives you a record that few counterparties will look at. Neither the pace of revision nor the breadth of adoption can be assumed.

The identity registry

The identity registry is the starting point of the design. In the draft, each agent is an ERC-721 token that points to its agent card. Both halves of that sentence deserve a plain explanation.

ERC-721 is the Ethereum standard for unique tokens. Each token is distinct from every other, is held in a wallet, and can be transferred from one wallet to another. Using that standard for agents is a pragmatic choice: a great deal of existing software already knows how to read, display and index unique tokens, so an agent identity does not need a new kind of tooling to be visible.

The agent card is the description the token points to. Think of it as the agent’s public data sheet: what the agent is called, what it says it can do, and where it can be reached. The token is the durable handle. The card is the content behind the handle.

What the identity record tells you, and what it does not

An identity record tells you that an agent has been registered, which wallet holds its token, and what its card says. The registry record is public, and anyone can check it on a block explorer, the public search tool for a blockchain.

It does not tell you that the card is true. An agent card is a statement made by whoever controls the identity. If the card says the agent is operated by a particular organization, the registry records that the statement was made. It does not audit it. Treat the card the way you would treat a counterparty’s own description of itself in a first meeting: useful, necessary and not sufficient.

Why a transferable identity deserves attention

Because the identity is a token, it can change hands. That is convenient when an agent moves from one operating entity to another inside a group, or when a business unit is sold. It also means that the party you assessed last quarter may not be the party that controls the agent now. How the draft treats the history attached to an identity when the token moves is the kind of detail to read in the current text, not to assume.

The identity record is the anchor for everything else. Feedback and checks are only meaningful if they are attached to a specific agent, and the identity token is what they attach to. For an organization that runs agents under its own TLD, the identity record is also the place where that affiliation can become readable by machines, a point developed on the page about identities for AI agents under a TLD.

The reputation registry

The reputation registry is where the draft places feedback from those an agent has worked with. Its purpose is simple to state: after an interaction, a client, or another agent acting as one, can leave a record of how it went, and later counterparties can read that history before deciding whether to engage.

The value of placing this in a shared public registry, and not in each platform’s database, is portability. A track record earned in one context can be read in another. An agent does not start from zero every time it meets a new counterparty, and a counterparty does not have to rely on the agent’s own account of its past.

The limits of feedback

Feedback is opinion with a timestamp. It records what a counterparty reported, not what actually happened. Any public feedback system faces the same well-known weaknesses, and nothing in the idea of an onchain registry removes them.

• Coordinated praise. A group of related agents can deal with one another and exchange favorable feedback. The record looks rich and says little.
• Thin history. A new agent has no record. Absence of feedback is not evidence of anything, good or bad.
• Context. A record earned on small, simple tasks does not show fitness for large or sensitive ones.
• Hostile feedback. A competitor or an unhappy counterparty can leave a negative record that is unfair and still visible.

How far the draft itself guards against these, and how far it leaves the matter to those who build on it, is one of the areas to verify in the current text. The sensible working assumption is that a reader of reputation data has to weigh it, and that the weight depends on how much is at stake.

Why it matters to a brand

An organization that runs agents under a name carrying its brand has a specific interest here. What is written about those agents in a public registry can be read by anyone, and a public ledger does not forget. That is a reason to decide, before any agent is registered, who inside the organization monitors what is said about it and how a disputed record is answered. It is a matter of governance more than of technology.

The validation registry

The validation registry holds independent checks of an agent’s work. Where the reputation registry records what counterparties thought, the validation registry is meant to record whether someone who was not a party to the interaction verified the result.

The difference is the one between a client reference and an audit. A reference tells you that a customer was satisfied. An audit tells you that a third party looked at the work against some standard and reached a finding. Both are useful. They answer different questions, and the second usually costs more to produce.

For low-value interactions, feedback may be all a counterparty needs. For interactions where an error is expensive (a payment instruction, a regulatory filing, a decision that binds the organization), an independent check carries more weight than any number of favorable opinions. The draft gives that kind of evidence its own registry so that it does not get mixed with opinion.

What to ask about a validation record

A validation record is only as strong as the validator behind it. Before relying on one, a reader should be able to answer four questions.

• Who performed the check, and are they independent of the agent’s operator?
• What exactly was checked: one output, a sample, or a whole process?
• By what method, and can the method be examined?
• What does the validator stand to lose if the check is wrong?

The draft does not answer these on your behalf, and no registry could. It provides a place to record that a check was requested and what came of it. Judging validators remains the reader’s work.

Independent verification of machine work is the hardest of the three problems, and it is reasonable to expect this part of the proposal to be the one that changes most. Treat the validation registry as something to follow closely, not as a foundation for commitments.

How the three registries fit together

The three registries are distinct records that share one reference: the agent’s identity. Read together, they follow the order in which a careful counterparty would ask its questions.

In practice, an operator registers an agent and obtains its identity. Counterparties who deal with the agent leave feedback that refers to that identity. Where the stakes justify it, an independent party checks a piece of work and the outcome is recorded against the same identity. Anyone assessing the agent then reads across the three records using a single reference.

The separation is deliberate, and it is useful to a reader. Each record has a different author with a different interest. The operator writes the identity and wants the agent to look capable. Counterparties write the feedback and have their own view of the relationship. Validators write the checks and are supposed to be neutral. Keeping the three apart lets you see who said what, which a single blended score would hide.

The registries are also meant to stay light. They record references and outcomes and leave the judgment to those who read them. Scoring models, thresholds and rules about which agents to accept belong to the applications that consult the registries, not to the registries themselves.

What the draft leaves to others

Knowing the edges of ERC-8004 is as important as knowing its content. Product and legal teams sometimes assume that a standard about trust between agents covers everything around that trust. It does not.

Payment. The three registries deal with identity, feedback and checks. None of them moves money. An agent with a clean record still needs a separate arrangement to pay or be paid, and that arrangement carries its own terms and risks.

Governance. A registry is software, and software has administrators, upgrades and failures. Who can change a given deployment, how a disputed record is handled and what happens if a deployment has to be replaced are questions about that deployment. Ask them of whoever operates it.

Law. The draft does not say which country’s law governs an interaction between two agents whose operators sit in different jurisdictions. It does not create a forum for disputes. It does not define when the organization or person behind an agent is liable for what the agent does, or whether a commitment made by an agent is enforceable. Those rules vary by country and are for your own counsel to decide. What the registries can contribute is evidence: a public record of what was declared, reported and checked.

The agent itself. The proposal is about how an agent is identified and assessed. It says nothing about how the agent is built, which model it uses or how good its outputs are.

Withdrawal. Agents are retired, replaced and sometimes compromised. Do not assume that any registry marks an agent as no longer trustworthy on its own. An organization needs its own procedure for taking an agent out of service and for telling counterparties, whatever the final text provides.

Personal data. Records on a public ledger are hard to remove. Anything placed in an agent card or in feedback should be reviewed against data protection law before it is published, not after.

In short, the draft offers building blocks. Deciding how much weight to give them, and what to require on top of them for a given level of risk, remains the job of the organization that relies on them.

Where naming enters

ERC-8004 identifies an agent by a token. A token identifier is precise and unreadable. People, and the systems people configure, work better with names. That is the gap naming fills: a readable handle that says whose agent this is before anyone looks at feedback or checks.

How naming registries plug into the draft is still evolving. It would be wrong to present any naming system as part of the standard, or to say that the standard favors one namespace over another. What can be said is narrower, and more useful.

An onchain TLD gives an organization a namespace it controls. On Freename, for example, a TLD is recorded onchain as a token held in a wallet, and only the holder of the TLD can issue names under it. An organization that holds .yourbrand could therefore give each agent or agent role a name under it, such as pay.yourbrand for a payments agent or procurement.yourbrand for a purchasing agent. Because nobody else can issue names under that TLD, a name ending in .yourbrand carries an organizational signal that a free-form label in an agent card does not.

The two layers do different jobs. The name gives human-readable context and ties an agent to a namespace with a single controller. The identity token is what feedback and checks attach to. Neither replaces the other, and a name by itself proves nothing about how an agent behaves.

The same reasoning applies to a sector namespace. An operator who runs .yoursector could issue name.yoursector to the agents of its members under a published policy, so that the name signals membership of a defined group. Whether counterparties give that signal any weight depends on the quality of the policy and on who enforces it.

There are honest limits. Onchain names resolve outside the ICANN DNS root, and software support for them is partial and changes. Whether a given agent platform reads an onchain name at all is a question to check, not to assume. The page on what is live records which capabilities of onchain TLDs work now, with sources, and the glossary defines the terms used here.

What an organization can reasonably do while it is a draft

Uncertainty about a standard is not a reason to do nothing. It is a reason to choose work that stays useful whatever the final text says. Most of what agent identity requires is organizational, and none of it depends on the draft being settled.

1. Inventory your agentsList every agent your organization operates or relies on that acts across an organizational boundary. Note who is accountable for each one. The inventory is useful under any standard.
2. Draft the description of each agentWrite down, for each agent, what it is called, what it does, where it is reached and who operates it. Gaps in this exercise are gaps in governance, and they are cheaper to find now.
3. Decide a naming policyIf your organization holds or is considering an onchain TLD, settle how names under it would be assigned to agents, who approves them and how a name is withdrawn when an agent is retired.
4. Assign someone to follow the draftName one person who reads each revision of the proposal and reports what changed. Pay particular attention to validation, the part most likely to move.
5. Brief counsel on the open legal questionsLiability for an agent's acts, governing law, disputed feedback and personal data in public records are not answered by the draft. Give your counsel enough technical context to address them. This is information, not legal advice.
6. Check your exposure in onchain namespacesAn agent that presents itself under a name resembling your brand, but is run by someone else, creates the confusion between counterparties that the draft is meant to reduce. Know where your name stands before agents carry it.

Two free tools on this site support the third and sixth steps. The Launch Roadmap helps structure how a newly acquired TLD is put to use, and the Namespace Exposure Score gives a first measure of how exposed a brand is onchain.

It is equally useful to know what to hold back. Do not make a commercial promise that depends on a specific behavior of the draft. Do not describe a product as compliant with a standard that is not final. Do not treat a registry entry as a substitute for the checks you would run on any new counterparty.

Where the namespace itself is the missing piece, that is the work of a desk such as Hush Partners: an organization can mandate the desk to find and approach the holder of a TLD, and a TLD acquired through the desk can then be put to work through post-transfer activation. Teams that expect to administer names in conversation can read how a TLD is managed from an AI assistant, and the page for brands and legal teams sets out the wider context.

Questions people ask

Does a standard like ERC-8004 create legal obligations?

Not by itself. A technical standard defines how software behaves so that different systems can work together. It has the force of neither regulation nor contract. Obligations can arise from how an organization uses it, for example if a statement in an agent card turns out to be false and a counterparty relied on it. Whether and how that happens depends on the law of the relevant country and on the transaction, and it is a question for your own counsel.

What happens to an agent’s record if its identity token changes hands?

Because the identity is a transferable token, the question is a real one, and it is a point to verify in the current text of the draft. From a due diligence standpoint, treat the acquisition of an agent identity with a history the way you would treat the acquisition of anything with a track record attached: establish who controlled it, during which period, and whether the record reflects the operator you are dealing with now.

Do we need an onchain TLD to register an agent?

Nothing stated here suggests that the draft requires one, and how naming registries connect to it is still evolving. A TLD is an organizational choice. It becomes relevant when you want the names of your agents to sit in a namespace you alone control, so that the name itself says something about who operates them.

Does a good record replace due diligence on a counterparty?

No. The registries are designed to make evidence available, not to reach a conclusion. A record of feedback and checks can shorten an assessment and make it more consistent. The decision to rely on an agent, and the level of evidence that decision requires, stay with the organization that bears the consequences.