ERC-8004 team (community effort, 8004.org); coordinated by Marco De Rossi (MetaMask) and Davide Crapis (Ethereum Foundation), Co-authors: Jordan Ellis (Google), Erik Reppel (Coinbase)
Status
Draft The ERC is Draft, not Final. The Identity and Reputation registries are listed on 25 mainnets in the contracts README (as of 2026-08-15). The Validation Registry is specified, not officially deployed.
Latest version
Draft text last changed 2026-01-25 (Updates from community feedback); registry contracts report version 2.0.0,
State as of
Verified (verified under 30 days ago)
Crypto-native
Rail-agnostic
Identity and trust (primary layer)
Reputation and feedback
Discovery
A. TL;DR and key facts
ERC-8004 is a Draft Ethereum standard that gives AI agents an ERC-721 identity pointing to a registration file, plus a public feedback registry. It moves no money. A validation registry is specified but not officially deployed.
Why it exists
An agent that wants to be hired by strangers needs a name others can look up, a list of where to reach it, and some record of how it behaved. Platform directories hold that data in one company's database. ERC-8004 puts the minimum on public chains instead: a transferable identity token, a pointer to a file that lists the agent's services, and a log where any client can leave a score with tags. Anyone can read it and build their own ranking on top, and payment stays with other protocols such as x402.
What it is not
Not Final. ERC-8004 is a Draft: it moved to Review on 2025-10-08 and an EIP editor returned it to Draft on 2026-01-13, where it still is, even though registries are listed on 25 mainnets in the contracts README. Source [1, 2, 4, 11, 16, 17]
Not a payment protocol. The specification calls payments orthogonal and the registries have no payable function; x402 or any other rail moves the money. Source [1, 5, 8]
Not three deployed registries. The Validation Registry is specified, but the contracts README lists no address for it on any chain. Source [2]
Not a quality signal by itself. Agent counts are token ids, free to mint and full of placeholders; one study found only 3% to 15% of agents with a valid file and a live endpoint. Source [18, 19]
Not gated feedback any more. The agent-signed feedbackAuth was removed (contracts 2025-11-12, specification 2026-01-07); any address except the owner and operators can rate an agent. Source [1, 20, 21]
Not know-your-agent or KYC. Registration is permissionless and nothing checks who runs an agent. Source [1]
Not ERC-8183 or ERC-8126. ERC-8183 is job escrow with an evaluator and ERC-8126 is a separate verification standard; both build around ERC-8004. Source [22, 23, 24]
Not the ERC-3643 Identity Registry. The T-REX registry maps wallets to issuer-attested identities for token transfers; the ERC-8004 one is an open ERC-721 agent directory. Source [1, 25]
Key facts as of 2026-10-11
Steward
Community effort (8004.org), coordinated by Marco De Rossi (MetaMask) and Davide Crapis (Ethereum Foundation); co-authors Jordan Ellis (Google) and Erik Reppel (Coinbase); no foundation found Source [1, 2, 3]
Governance
ethereum/ERCs editorial process; returned from Review to Draft by an EIP editor on 2026-01-13 Source [2, 3, 4]
License
Spec CC0; contracts MIT per file headers (the README says CC0) Source [1, 2, 5]
First announced
Created 2025-08-13; first merged into ethereum/ERCs on 2025-08-18 Source [1, 6]
Latest version
Draft text last changed 2026-01-25; all three registry implementations report 2.0.0 Source [3, 5, 7, 8, 9, 10]
Status
Draft, not Final. Identity and Reputation registries on 25 mainnets (README, 2026-08-15); Validation Registry specified, not officially deployed Source [1, 2, 11, 12]
Transports
EVM transactions and reads; registration file over ipfs, https or a data URI; optional /.well-known domain proof Source [1]
Rails
None. It moves no money; payments on any rail can only enrich feedback Source [1, 5, 8]
x402 (x402Support, agentWallet, proofOfPayment); MPP discovery draft cites it; A2A and MCP as services Source [1, 13]
Upgrade key
One externally owned account owns all three proxies on Ethereum and Base (2026-10-11); the holder is not published Source [5, 10, 14, 15]
How to read this explanation
ELI5 is a short plain-language version. Practitioner is the full text. Spec-deep adds field tables and wire examples. STE shows the Simplified Technical English version instead.
B. Detailed explanation
ELI5 mode: plain-language version only.
Practitioner mode: the full explanation.
Spec-deep mode: the full explanation plus 3 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
Picture a notice board in a town square that no single shop owns. Any helper robot can pin a card on it. The card has a number, and it points to a longer profile: the robot’s name, what it can do, how to reach it, and whether it takes payment. Whoever holds the card can hand it to someone else, the way you might sell a shop sign.
Next to the board hangs a guestbook. Anyone who used a robot can write a short score in it, with a word or two that says what the score is about, such as “fast” or “reachable”. The robot’s own owner may not write about their own robot. You can cross out your own entry later, and anyone can pin a reply under an entry, for example “I gave this person a refund”.
The guestbook has a weak spot. Writing in it costs almost nothing, so one person can pretend to be a hundred happy customers. That is why the board only adds up scores from writers you say you trust. Everything else you have to judge for yourself.
A third book, where independent checkers would confirm that a robot did its work correctly, is described in the rules, but nobody has officially hung it up yet.
The board never handles money. If you pay a robot, you pay somewhere else, and you can mention that payment in your guestbook note so others can check it.
The board already holds a huge number of cards, but most of them lead to empty profiles or to doors that never open. A big board is not the same thing as a board full of good robots.
ERC-8004 answers one question: how does an agent find another agent it has never met, and decide how far to trust it, without a platform in the middle?Source [1] It puts three small registries on Ethereum and other EVM (Ethereum Virtual Machine) chains.Source [1] The Identity Registry mints each agent an token, the token type behind NFTs (non-fungible tokens). The token points to a that lists the agent’s services, such as an MCP (Model Context Protocol) server or an A2A (Agent2Agent) .Source [1] The lets any address except the owner and its operators post a score with tags.Source [1, 8] The , where an independent validator would record a check of the agent’s work, is specified but not officially deployed.Source [1, 2] ERC-8004 moves no money: payments are out of scope, and an x402 payment can only add evidence to a piece of feedback.Source [1, 5, 8] What ERC-8004 does not give you: proof that an agent works, protection against , or any check on who runs it. The text says as much and leaves ranking to whoever reads the data.Source [1] It is a Draft ERC (Ethereum Request for Comments), not a Final one, even though its registries are listed on 25 mainnets.Source [1, 2, 11, 12]
Problem and design goals
The authors start from a gap. MCP lets a server list its tools and A2A handles messaging and task lifecycles. Neither tells you which agent to pick from an organization you have never dealt with, or whether it behaved well before.Source [1] ERC-8004 fills that gap with three lightweight registries meant to run as one singleton per chain, on Ethereum mainnet or a Layer 2 network.Source [1] Trust is meant to scale with the value at risk: client feedback for cheap tasks, and stake-secured re-execution, (zero-knowledge machine learning) proofs or TEE () oracles for expensive ones.Source [1]
Three design choices follow. First, identity reuses ERC-721, so any wallet or NFT app can display and transfer an agent without new code.Source [1] Second, almost everything descriptive lives off-chain in a registration file that the token points to, served over IPFS (the InterPlanetary File System), HTTPS or an inline data URI.Source [1] Third, feedback keeps a few numbers and tags on-chain so smart contracts can read them, and pushes detail into events and off-chain files.Source [1, 8] The registries filter by reviewer and tag; anything smarter, such as weighting or graph analysis, is expected to happen off-chain.Source [1]
The scope is narrow on purpose. Payments are orthogonal and not covered.Source [1, 5, 8] Validator incentives and slashing belong to whatever validation protocol plugs in.Source [1] And the text admits that it can tie a file to an on-chain agent but cannot guarantee that the advertised capabilities work or are safe.Source [1] If an agent lists no trust models in its file, the registration is for discovery only.Source [1]
Actors and roles
The owner holds the ERC-721 token for an agent. In ERC-8004 the token id is called and the token URI is called .Source [1] Operators are addresses the owner approves through the normal ERC-721 approval functions; they can update the URI, metadata and wallet and request validation, just like the owner.Source [1, 5]
The is the address where the agent receives payments. It starts as the owner’s address, and changing it needs a signature from the new wallet.Source [1] Clients are any addresses that give feedback; neither the owner nor an operator may rate its own agent.Source [1, 8] When the client is itself an agent, it should give feedback from its agent wallet so that reputation can be aggregated per agent.Source [1] Responders are anyone at all: the agent showing that it refunded someone, or an aggregator tagging feedback as spam.Source [1]
Validators are addresses or contracts named in a , and only the named validator may answer it.Source [1] Two roles sit outside the text but matter in practice. The owner of the registry contracts can upgrade them, and on Ethereum and Base that owner is a single EOA (externally owned account) whose holder is not published.Source [5, 10, 14, 15] Indexers and explorers, such as 8004scan (powered by AltLayer) and the Agent0 subgraphs on The Graph, turn events into searchable data.Source [27, 28]
Core objects
An agent is named globally by two values. The first, agentRegistry, has the form namespace, chain id and registry address joined by colons, with eip155 as the namespace for EVM chains; the second is the agentId.Source [1] The text says ids are assigned incrementally, and the deployed code starts at 0: the first agent on Ethereum mainnet has id 0.Source [5, 10]
The registration file is what agentURI resolves to. Its type is a fixed URI ending in #registration-v1, followed by a name, description and image for NFT apps, a services list, two booleans (x402Support and active), a registrations list and an optional list.Source [1] Each service has a name and an endpoint, with a recommended version; the example names web, A2A, MCP, (Open Agentic Schema Framework), ENS (Ethereum Name Service), (decentralized identifier) and email.Source [1] Each registrations entry carries an agentId and an agentRegistry, which binds the file back to one or more on-chain identities.Source [1] The text gives the structure as an example, not as a JSON Schema, so “required” is partly a reading of that example.Source [1] An agent may also prove that it controls an HTTPS service domain by serving a matching registrations entry at /.well-known/agent-registration.json on that domain.Source [1]
On-chain metadata is a key and bytes value store per agent.Source [1] One key, agentWallet, is reserved: you cannot set it through the generic setter or at registration.Source [1, 5]
Feedback is a signed fixed-point number: an int128 value plus a count from 0 to 18.Source [1] Two free-text tags say what the number means; the text’s examples include starred, reachable, uptime, successRate, responseTime and revenues, and an uptime of 99.77% is written as 9977 with two decimals.Source [1] Only value, decimals, both tags and a revoked flag are stored; the endpoint, the URI of a detail file and that file’s keccak256 hash are emitted in the event and then forgotten by the contract.Source [1, 8] Each entry gets a that counts from 1 per client and agent.Source [1]
The repeats the registry, agent, client, timestamp, value and decimals, and can add tags, the rated endpoint, MCP, A2A or OASF context and a proofOfPayment object.Source [1] That object has four fields (from and to addresses, a chain id and a transaction hash), and it lives only in the file: the registry stores no payment data and never checks the proof.Source [1, 8]
Field tables. Spec version: ERC-8004 Draft, text last changed 2026-01-25, read at ethereum/ERCs commit b1f2bd8. Function details come from the reference contracts at erc-8004-contracts commit b9e466c (implementation version 2.0.0). Descriptions are paraphrased.
Agent registration file (resolved from agentURI)Spec version Draft 2026-01-25
Field
Type
Required
Description
type
string (URI)
Yes
Fixed value https://eips.ethereum.org/EIPS/eip-8004#registration-v1. Spec reference for type
name
string
Yes
Agent name; with description and image it SHOULD keep ERC-721 apps working. Spec reference for name
The only place endpoint, feedbackURI and feedbackHash appear on-chain
Validation Registry (specified, not officially deployed): validationRequest(address validatorAddress, uint256 agentId, string requestURI, bytes32 requestHash) by the owner or an operator; validationResponse(bytes32 requestHash, uint8 response, string responseURI, bytes32 responseHash, string tag) by the named validator, response from 0 to 100; reads getValidationStatus, getSummary returning (count, averageResponse), getAgentValidations, getValidatorRequests.
Tag examples from the text.starred 87 with 0 decimals; reachable 1; ownerVerified 1; uptime 9977 with 2 decimals for 99.77%; successRate 89; responseTime 560 (ms); blocktimeFreshness 4 (blocks); revenues 560 (for example USD); tradingYield with tag2 of day, week, month or year, -32 with 1 decimal for -3.2%. The best-practices copy of this table shows 32 without the minus sign; the specification is primary.
Illustrative example, spec version Draft 2026-01-25: a registration file for an agent on Ethereum mainnet. Endpoints and ids are invented.
Illustrative example, spec version Draft 2026-01-25: a feedback file that records an x402 payment. The file is uploaded first; giveFeedback then carries its URI and hash.
The main sequence in section C covers registration and wallet binding, the two calls every agent owner makes.Source [1, 5]
The owner writes the registration file and hosts it on IPFS or HTTPS, or encodes it as a base64 data URI to keep it fully on-chain.Source [1]
The owner calls one of the three register functions on the Identity Registry. The registry mints the token to the caller and sets the agent wallet to the caller.Source [1, 5]
The transaction emits a Transfer event, a Registered event with the new agentId, a MetadataSet event for the agent wallet and one MetadataSet per extra metadata entry. The deployed code also emits an ERC-4906 MetadataUpdate event when a URI is set; the text does not fix the order of these events.Source [1, 5, 17]
If the file was written before the id was known, the owner adds the agentId to its registrations list and calls setAgentURI, which emits URIUpdated.Source [1]
Optionally, the owner serves /.well-known/agent-registration.json on each service domain that differs from the file’s own domain.Source [1]
To receive payments at a different address, the new wallet signs an typed message that names the agent, the wallet, the owner and a deadline; a contract wallet answers an check instead.Source [1, 5]
The owner or an operator submits that signature with setAgentWallet. The reference code accepts a deadline at most 5 minutes ahead.Source [5]
Feedback after a payment has a fixed order. The client pays through x402 or any other rail, with no ERC-8004 call involved.Source [1, 5, 8] It writes and uploads the feedback file with the proofOfPayment object, computes the file’s hash, and only then calls giveFeedback with the file’s URI and hash.Source [1] The registry stores the value, decimals and tags under the next feedbackIndex and emits NewFeedback with the rest.Source [1, 8] Nobody on-chain checks the proof, the hash or the file; a reader who cares must fetch the file, compare the hash and look the transaction up on the named chain.Source [1, 8]
Reading reputation starts with a choice the registry forces on you: which reviewers do you trust? getSummary needs a non-empty list of client addresses and reverts without one.Source [1, 8] It returns a count and a plain mean of the matching, non-revoked values, normalized to 18 decimals and reported at the most common decimals.Source [1, 8] For anything better, read every entry with readAllFeedback and the events, and score them off-chain.Source [1]
Every write has a failure path, and section C plays three of them. A wallet signature fails with “expired”, “deadline too far” or “invalid wallet sig”.Source [5] An owner who rates its own agent hits “Self-feedback not allowed”.Source [8] A token transfer clears the agent wallet, so payments addressed to the old wallet no longer match until the new owner binds one again.Source [1, 5] A broken registration file fails nowhere on-chain: the registries never read it, so explorers and clients must handle a dead link themselves.Source [1, 5]
Wallet binding signature. Domain name ERC8004IdentityRegistry, version 1, the chain id and the registry address. Typed struct AgentWalletSet(uint256 agentId,address newWallet,address owner,uint256 deadline). The reference code tries ECDSA recovery first (this also covers EIP-7702 delegated accounts), then ERC-1271 isValidSignature with magic value 0x1626ba7e.
Illustrative example, spec version Draft 2026-01-25 with contracts 2.0.0: the typed data the new wallet signs. Addresses are invented.
bad wallet, expired, deadline too far, invalid wallet sig
giveFeedback
Self-feedback not allowed, too many decimals, value too large, ERC721NonexistentToken
revokeFeedback
index must be > 0, index out of bounds, Already revoked
appendResponse
index must be > 0, Empty URI, index out of bounds
getSummary
clientAddresses required
validationRequest, validationResponse
bad validator, exists, Not authorized, unknown, not validator, resp>100
Lifecycle and states
An agent identity has few states, and most of them are about the wallet. Registration leaves the agent with or without a URI, and with its wallet set to the owner.Source [1, 5] setAgentWallet moves it to a verified wallet, and unsetAgentWallet clears it.Source [1] Any ERC-721 transfer clears the wallet too, and the new owner has to bind one again.Source [1, 5]
There is no on-chain end state. The reference registry has no burn or deregistration function, so an owner who wants to retire an agent can only point the URI elsewhere, set active to false in the file, or transfer the token.Source [1, 5] An “inactive” agent is therefore visible only to someone who fetches and reads its file.Source [1, 5]
Feedback entries have two states: given and revoked. Only the original client can revoke, and nothing un-revokes.Source [1, 8] Responses can pile up under an entry in either state without changing its value or the summary.Source [8] Validation requests, in the specified registry, go from requested to responded, and the validator may answer again, for example a soft result first and a final one later.Source [1] In the reference code a later answer can also lower a pass, which an open issue reports as a rogue-validator risk.Source [29, 30]
Security and trust model (summary)
ERC-8004 makes data public and comparable; it does not make it true. The text says Sybil attacks can inflate fake agents’ reputation, and its only built-in defense is to filter by reviewers you already trust, which is why getSummary refuses an empty reviewer list.Source [1, 8] Since the agent-signed was removed, any address other than the owner and operators can rate any agent without proving an interaction.Source [1, 21] The self-rating check stops the owner’s own address, not a fresh address the owner controls.Source [1, 8]
Files are the second soft spot. An HTTPS registration file can change with no on-chain event, and only content-addressed URIs pin what an agent claimed.Source [1, 5] Wallet binding is tighter: the signature names the agent, the wallet, the owner and a short deadline under a chain-bound domain. It has no nonce, though, so it can be replayed for the same tuple inside its window.Source [5]
The third is the contracts themselves. All three registries are (Universal Upgradeable Proxy Standard) proxies that only the contract owner can upgrade.Source [5, 14] On 2026-10-11 that owner, on Ethereum and on Base, was the address 0x547289319C3e6aedB179C0b8e8aF0B5ACd062603, which has no contract code: it is a single externally owned account, not a multisig contract.Source [10, 14] Who holds that key is not published, while the project’s own upgrade notes advise a multisig or timelock for production.Source [10, 15] No CVE (Common Vulnerabilities and Exposures) entry, GitHub advisory or named audit firm’s report was found; a community audit in an open pull request reports one high, three medium and three low findings.Source [30, 31, 32] Section H has the full threat table.
Versioning and governance
ERC-8004 carries no semantic version. The text changes by commit, the registration file is versioned by its type URI, and all three registry implementations report version 2.0.0.Source [1, 5, 8, 9, 10] It was created on 2025-08-13, merged into ethereum/ERCs on 2025-08-18 and moved to Review on 2025-10-08, when Erik Reppel joined the author list.Source [1, 6, 16] On 2026-01-13 an EIP (Ethereum Improvement Proposal) editor moved it back to Draft and added a requires line for EIP-155, EIP-712, EIP-721 and ERC-1271.Source [4] The last change to the text before 2026-10-11 came on 2026-01-25.Source [3, 7]
Governance is light. The contracts README calls ERC-8004 a community effort coordinated by Marco De Rossi (MetaMask) and Davide Crapis (Ethereum Foundation), co-authored by Jordan Ellis (Google) and Erik Reppel (Coinbase).Source [2] No foundation or association was found, so changes to the text go through the ethereum/ERCs editors, while the contracts and their deployments are in the hands of whoever owns the proxies.Source [2, 3, 33, 34] The text is CC0; the Solidity files carry an MIT license header, while the README’s license section says CC0.Source [1, 2, 5]
Deployments use the same two proxy addresses on every listed mainnet, created with CREATE2 through the Safe Singleton Factory: Identity at 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 and Reputation at 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63.Source [2, 34] Testnets use a second pair.Source [2] The table shows when each mainnet first appeared in the contracts README. These are listing dates, not deployment dates, and a listing can lag the chain.Source [2, 12]
The list was unchanged on 2026-10-11: 25 mainnets including Ethereum, 24 besides it.Source [2, 12] A listing is not proof of a working registry. On 2026-10-11 the Soneium proxies still ran the 1.0.0 placeholder, where register reverts, and Billions could not be reached on public RPCs; the other 23 returned version 2.0.0.Source [2, 17] Upgrade control also differs by chain: on BSC a Safe multisig owns the Identity and Reputation proxies.Source [17] Explorers count more networks than that, which suggests community deployments outside the official list.Source [2, 28]
Renamed and removed identifiers. Use this table to spot outdated tutorials.
Earlier name
Current name
Changed
endpoints[]
services[]
spec 2026-01-25
score (uint8, 0 to 100)
value (int128) plus valueDecimals (uint8, 0 to 18)
spec 2026-01-25; contracts January 2026
averageScore in getSummary
summaryValue, summaryValueDecimals
spec 2026-01-25
bytes32 tags
string tags
contracts 2025-11-12; spec 2026-01-07
feedbackAuth (agent-signed permission to rate)
removed; any address except owner and operators may rate
contracts 2025-11-12; spec 2026-01-07
agentWallet as an endpoints entry
reserved metadata key set by setAgentWallet
spec 2026-01-07
tokenURI
called agentURI
spec 2026-01-07
requestUri
requestURI
spec 2026-01-07
The 2026-01-25 update also barred the owner and operators from feedback, made the reviewer list in getSummary mandatory, added getAgentWallet and unsetAgentWallet, and typed metadata values as bytes. Contract versions: repository created 2025-10-08, upgradeable proxies from 2025-10-14, 1.1.0 on 2025-11-12, 2.0.0 in January 2026.
Extensibility
Most extension happens in files, not contracts. The services list takes any number and kind of endpoints, and the feedback file accepts extra fields beyond the defined ones.Source [1] Tags are free text, so any community can define its own dimensions; the text only offers examples.Source [1] On-chain metadata accepts any key except the reserved wallet key.Source [1, 5] supportedTrust is the hook for trust models beyond reputation, such as crypto-economic validation or TEE attestation.Source [1]
The other extension path is a new ERC that builds on this one. ERC-8122 (Minimal Agent Registry, Draft) targets custom deployments instead of one singleton per chain.Source [35] ERC-8217 (Agent NFT Identity Bindings, Draft) binds an ERC-8004 agent to an outside NFT through a metadata key.Source [36] ERC-8183 (Agentic Commerce, Draft, created 2026-02-25) is job escrow with an evaluator and recommends plugging in ERC-8004 reputation and validation through hooks.Source [22] ERC-8126 (AI Agent Verification) lists ERC-8004 in its requires line and reached Final on 2026-06-02, while ERC-8004 itself stays Draft; the sources do not explain the gap.Source [23, 24] ERC-8226 (Regulated Agent Mandate, Draft, created 2026-04-12) adds what ERC-8004 lacks for regulated assets: a mandate that gives an agent scoped, time-bounded and capped authority.Source [26]
How it composes with the other seven
x402 is the closest partner, but neither depends on the other. ERC-8004 gives x402 three hooks: the x402Support flag in the registration file, the agent wallet as the payee address, and proofOfPayment in feedback files.Source [1] Its best-practices guide asks facilitators to publish revenues feedback, because indexers cannot easily tell x402 payments from ordinary transfers.Source [37] The link is also personal: Erik Reppel co-authors ERC-8004 and represents Coinbase on the x402 Technical Steering Committee.Source [1, 38]
Stripe’s MPP (Machine Payments Protocol) discovery draft cites ERC-8004 and calls its own off-chain discovery compatible with future on-chain anchoring, without specifying an integration.Source [13] AP2 (Agent Payments Protocol) does not mention ERC-8004; the link runs through A2A, which ERC-8004 lists as a service and which AP2 can extend.Source [1, 39] No documented relation was found to Visa’s Trusted Agent Protocol, the OpenAI and Stripe Agentic Commerce Protocol, Google’s Universal Commerce Protocol or Mastercard Agent Pay.Source [40, 41, 42, 43]
Limitations and open issues
Count is not quality. 8004scan reported 561,576 or more registered agents, 682,170 feedback entries and 496,805 unique wallets on 2026-10-11.Source [28] Those are token ids, free to mint and full of placeholders.Source [18, 19] The CSOAI census of 2026-09-26 read 505,635 ids on three chains and found at least 13,210 whose file declares an http(s) MCP, A2A or web endpoint; 231,014 files were not fetched.Source [18] An empirical study (arXiv:2606.26028, data to 2026-05-13) found only 3% (Ethereum), 4% (BSC) and 15% (Base) of agents with a valid file and a live endpoint.Source [19]
Reviewers are mostly Sybils in measured data. The same study saw coordinated Sybil behavior among 73.5%, 59.2% and 90.6% of reviewers on those chains.Source [19] After removing it, most rated agents on BSC and Base had no valid feedback left.Source [19]
Values do not compare. A value means whatever its tags say, getSummary averages whatever matches, and the study concludes that the registry cannot work as a trust signal as deployed.Source [8, 19]
Validation is unfinished. The README calls that part of the text still under discussion with the TEE community and lists no address.Source [2] A contract answers at the scripted Validation address on Ethereum and Base, but it is not listed or announced, so treat the registry as not officially deployed.Source [10, 44]
One upgrade key. A single unidentified account can change the code of every registry on Ethereum and Base.Source [10, 14, 15]
Draft in production. The standard is Draft while 25 mainnets list it and a companion ERC that requires it is Final.Source [2, 11, 23, 24]
Loose edges. There is no JSON Schema for the registration file. The editors’ notes question the URIStorage dependency, the x402 example and the missing test cases, and the best-practices copy of the tag table drops a minus sign.Source [1, 37]
Gas-heavy reads. getSummary and readAllFeedback loop over every entry, and the community audit flags unbounded returns.Source [8, 30]
What changed in 2025 and 2026
2025-08-13 and 2025-08-18: created, then merged into ethereum/ERCs.Source [1, 6]
2025-10-08: moved to Review; the contracts repository was created the same day.Source [16, 20, 31]
2025-10-22 to 2025-11-03: first testnet registries listed, including Validation Registry addresses.Source [12]
2025-11-12: feedbackAuth removed from the contracts, tags changed to strings.Source [20, 21]
2025-11-21: Trustless Agent Day at La Rural in Buenos Aires during Devconnect.Source [45]
2026-01-06 and 2026-01-07: testnet Validation addresses dropped from the README; the text reserved agentWallet and added x402Support and active.Source [12, 21]
2026-01-13: returned from Review to Draft.Source [4]
2026-01-25: endpoints became services and score became value plus valueDecimals.Source [7]
2026-01-29: Ethereum mainnet addresses listed for the Identity and Reputation registries.Source [12]
2026-03-06: twenty more mainnets listed at once.Source [12]
2026-04-12 and 2026-04-14: ERC-8226 created; Agent0 subgraphs live on five chains.Source [26, 27]
2026-08-15: Robinhood Chain listed as the 25th mainnet.Source [12]
2026-09-26: the CSOAI census measured 505,635 ids.Source [18]
2026-10-11: on-chain reads show one externally owned account owning the proxies on Ethereum and Base.Source [10, 14]
C. Diagrams
Main flow: ERC-8004 registration and wallet binding
An owner publishes a registration file, mints an agent identity, writes the new agentId back into the file, proves control of a service domain, and binds a separate payment wallet with an EIP-712 signature. No money moves at any step.
Agent owner
File host (IPFS or HTTPS)
Identity Registry
Service domain
New agent wallet
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 10Agent owner toto File host (IPFS or HTTPS)
Publish registration file
The owner writes the registration file (type, name, description, image, services, x402Support, active, registrations, supportedTrust) and hosts it on IPFS or HTTPS, or encodes it as a base64 data URI to keep it on-chain. The registries never fetch this file.
JSON payload. Illustrative example, spec version Draft (text of 2026-01-25).
// Illustrative example, spec version Draft 2026-01-25.
{
"type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
"name": "weather-oracle",
"description": "Returns current weather for a city. Pay per call with x402.",
"image": "https://agent.example/logo.png",
"services": [
{ "name": "MCP", "endpoint": "https://mcp.agent.example/", "version": "2025-06-18" }
],
"x402Support": true,
"active": true,
"registrations": [],
"supportedTrust": ["reputation"]
}
Spec version Draft (text of 2026-01-25) (2026-01-25). Sources: [1], [5], [10], [17]
Step 1 of 10: Agent owner to File host (IPFS or HTTPS). Publish registration file. Crosses a trust boundary.
Sequence diagram: ERC-8004 registration and wallet binding
Scroll to see the whole diagram
Generated from the flow definition (spec version Draft (text of 2026-01-25), 2026-01-25). The player above uses the same data.
Text alternative
Sequence diagram: ERC-8004 registration and wallet binding. 5 participants: Agent owner, File host (IPFS or HTTPS), Identity Registry, Service domain, and New agent wallet. 10 steps, 8 crossing a trust boundary, 8 failure branches. Based on erc-8004 Draft (text of 2026-01-25) (2026-01-25). Step 1: Agent owner to File host (IPFS or HTTPS): Publish registration file. This step crosses a trust boundary. If The file is unreachable or not valid JSON: Nothing fails on-chain; explorers and clients mark the agent as unreachable or invalid. Step 2: Agent owner to Identity Registry: register(agentURI). This step crosses a trust boundary. If The metadata array uses the key agentWallet: Reverts with "reserved key". Step 3: Identity Registry to Agent owner: Return events Transfer, MetadataUpdate, Registered, MetadataSet. Step 4: Agent owner to File host (IPFS or HTTPS): Write agentId into registrations. This step crosses a trust boundary. Step 5: Agent owner to Identity Registry: setAgentURI(agentId, newURI). This step crosses a trust boundary. If The caller is neither owner nor operator: Reverts with "Not authorized". Step 6: Agent owner to Service domain: Serve /.well-known/agent-registration.json. This step crosses a trust boundary. Step 7: Agent owner to New agent wallet: Ask the new wallet to sign AgentWalletSet. This step crosses a trust boundary. If The wallet is a smart contract wallet: It does not sign with ECDSA; the registry calls its ERC-1271 isValidSignature instead. Step 8: New agent wallet to Agent owner: Return signature. This step crosses a trust boundary. Step 9: Agent owner to Identity Registry: setAgentWallet(agentId, newWallet, deadline, signature). This step crosses a trust boundary. If newWallet is the zero address: Reverts with "bad wallet". If The deadline has passed: Reverts with "expired". If The deadline is more than 5 minutes ahead: Reverts with "deadline too far". If Neither ECDSA nor ERC-1271 validates the signature: Reverts with "invalid wallet sig". Step 10: Identity Registry to Agent owner: Return MetadataSet(agentWallet).
Step 1: Agent owner to File host (IPFS or HTTPS): Publish registration file. This step crosses a trust boundary. If The file is unreachable or not valid JSON: Nothing fails on-chain; explorers and clients mark the agent as unreachable or invalid.
Step 2: Agent owner to Identity Registry: register(agentURI). This step crosses a trust boundary. If The metadata array uses the key agentWallet: Reverts with "reserved key".
Step 4: Agent owner to File host (IPFS or HTTPS): Write agentId into registrations. This step crosses a trust boundary.
Step 5: Agent owner to Identity Registry: setAgentURI(agentId, newURI). This step crosses a trust boundary. If The caller is neither owner nor operator: Reverts with "Not authorized".
Step 6: Agent owner to Service domain: Serve /.well-known/agent-registration.json. This step crosses a trust boundary.
Step 7: Agent owner to New agent wallet: Ask the new wallet to sign AgentWalletSet. This step crosses a trust boundary. If The wallet is a smart contract wallet: It does not sign with ECDSA; the registry calls its ERC-1271 isValidSignature instead.
Step 8: New agent wallet to Agent owner: Return signature. This step crosses a trust boundary.
Step 9: Agent owner to Identity Registry: setAgentWallet(agentId, newWallet, deadline, signature). This step crosses a trust boundary. If newWallet is the zero address: Reverts with "bad wallet". If The deadline has passed: Reverts with "expired". If The deadline is more than 5 minutes ahead: Reverts with "deadline too far". If Neither ECDSA nor ERC-1271 validates the signature: Reverts with "invalid wallet sig".
Step 10: Identity Registry to Agent owner: Return MetadataSet(agentWallet).
A filled dot marks the initial state; terminal states have a double border; dashed lines go back to an earlier state. Numbers on the lines match the transition list.
Transition
Not registered to Registered, no URI
Trigger
Mint without a URI
API call
register()
Spec reference
ERCS/erc-8004.md Registration
About Registered, no URI
register() with no argument; Registered carries an empty agentURI.
State notes
Not registered
No token id yet.
Registered, no URI
register() with no argument; Registered carries an empty agentURI.
Registered with URI, wallet = owner
agentWallet defaults to the owner address at mint. Wallet state and URI state change independently.
Wallet verified
agentWallet set to another address by setAgentWallet with a signature from that address.
Wallet cleared
agentWallet is the zero address after unsetAgentWallet or a transfer.
Declared inactive (off-chain only)
active is false in the registration file. The registry has no such state and no burn function, so the token persists. The wallet keeps whatever value it had.
Spec version Draft (text of 2026-01-25); contracts 2.0.0.
State diagram: ERC-8004 agent identity lifecycle (Identity Registry)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Generated from the state machine definition (spec version Draft (text of 2026-01-25); contracts 2.0.0).
Text alternative
State diagram: ERC-8004 agent identity lifecycle (Identity Registry). 6 states: Not registered, Registered, no URI, Registered with URI, wallet = owner, Wallet verified, Wallet cleared, and Declared inactive (off-chain only). Starts in Not registered. 17 transitions. From Not registered to Registered, no URI when Mint without a URI (register()). From Not registered to Registered with URI, wallet = owner when Mint with a URI (register(agentURI) or register(agentURI, metadata)). From Registered, no URI to Registered with URI, wallet = owner when Owner or operator sets the URI (setAgentURI(agentId, newURI)). From Registered with URI, wallet = owner to Registered with URI, wallet = owner when File moved or edited (setAgentURI(agentId, newURI)). From Registered with URI, wallet = owner to Wallet verified when New wallet signs AgentWalletSet within 5 minutes (setAgentWallet(agentId, newWallet, deadline, signature)). From Wallet verified to Wallet cleared when Owner or operator clears the wallet (unsetAgentWallet(agentId)). From Registered with URI, wallet = owner to Wallet cleared when Token transferred to a new owner (ERC-721 transferFrom or safeTransferFrom). From Wallet verified to Wallet cleared when Token transferred to a new owner (ERC-721 transferFrom or safeTransferFrom). From Wallet cleared to Wallet verified when Current owner binds a wallet again (setAgentWallet(agentId, newWallet, deadline, signature)). From Registered with URI, wallet = owner to Declared inactive (off-chain only) when Owner publishes a file with active false (setAgentURI(agentId, newURI) or an HTTPS file edit). From Wallet verified to Declared inactive (off-chain only) when Owner publishes a file with active false (setAgentURI(agentId, newURI) or an HTTPS file edit). From Declared inactive (off-chain only) to Registered with URI, wallet = owner when Owner publishes a file with active true (wallet state unchanged) (setAgentURI(agentId, newURI)). From Registered with URI, wallet = owner to Wallet cleared when Owner or operator clears the wallet (unsetAgentWallet(agentId)). From Registered, no URI to Wallet verified when New wallet signs AgentWalletSet (no URI needed) (setAgentWallet(agentId, newWallet, deadline, signature)). From Registered, no URI to Wallet cleared when Transfer or unset before a URI is set (ERC-721 transfer or unsetAgentWallet(agentId)). From Wallet verified to Wallet verified when Bind a different wallet (setAgentWallet(agentId, newWallet, deadline, signature)). From Wallet cleared to Declared inactive (off-chain only) when Owner publishes a file with active false (setAgentURI(agentId, newURI) or an HTTPS file edit).
From Not registered to Registered, no URI when Mint without a URI (register()).
From Not registered to Registered with URI, wallet = owner when Mint with a URI (register(agentURI) or register(agentURI, metadata)).
From Registered, no URI to Registered with URI, wallet = owner when Owner or operator sets the URI (setAgentURI(agentId, newURI)).
From Registered with URI, wallet = owner to Registered with URI, wallet = owner when File moved or edited (setAgentURI(agentId, newURI)).
From Registered with URI, wallet = owner to Wallet verified when New wallet signs AgentWalletSet within 5 minutes (setAgentWallet(agentId, newWallet, deadline, signature)).
From Wallet verified to Wallet cleared when Owner or operator clears the wallet (unsetAgentWallet(agentId)).
From Registered with URI, wallet = owner to Wallet cleared when Token transferred to a new owner (ERC-721 transferFrom or safeTransferFrom).
From Wallet verified to Wallet cleared when Token transferred to a new owner (ERC-721 transferFrom or safeTransferFrom).
From Wallet cleared to Wallet verified when Current owner binds a wallet again (setAgentWallet(agentId, newWallet, deadline, signature)).
From Registered with URI, wallet = owner to Declared inactive (off-chain only) when Owner publishes a file with active false (setAgentURI(agentId, newURI) or an HTTPS file edit).
From Wallet verified to Declared inactive (off-chain only) when Owner publishes a file with active false (setAgentURI(agentId, newURI) or an HTTPS file edit).
From Declared inactive (off-chain only) to Registered with URI, wallet = owner when Owner publishes a file with active true (wallet state unchanged) (setAgentURI(agentId, newURI)).
From Registered with URI, wallet = owner to Wallet cleared when Owner or operator clears the wallet (unsetAgentWallet(agentId)).
From Registered, no URI to Wallet verified when New wallet signs AgentWalletSet (no URI needed) (setAgentWallet(agentId, newWallet, deadline, signature)).
From Registered, no URI to Wallet cleared when Transfer or unset before a URI is set (ERC-721 transfer or unsetAgentWallet(agentId)).
From Wallet verified to Wallet verified when Bind a different wallet (setAgentWallet(agentId, newWallet, deadline, signature)).
From Wallet cleared to Declared inactive (off-chain only) when Owner publishes a file with active false (setAgentURI(agentId, newURI) or an HTTPS file edit).
Five trust zones. The owner controls the token, the file and the wallet binding; clients write feedback; the chain holds three registries, one of them only specified; off-chain hosts serve files the chain never reads; indexers turn events into rankings. Payment happens elsewhere.
Text alternative
Flowchart. The owner zone holds the agent owner, operators and the agent wallet. The owner registers and updates the agent in the Identity Registry and binds the wallet with a signature. The off-chain zone holds the registration file host, the .well-known domain proof and feedback files. The client zone holds clients and responders, which call giveFeedback and appendResponse on the Reputation Registry. The Validation Registry is drawn dashed as specified, not officially deployed, with a validator. The registry owner can upgrade all registries: one externally owned account on Ethereum and Base, a Safe multisig on BSC. Indexers and explorers read events and files. A payment rail such as x402 sits outside ERC-8004.
The chain stores very little: a token, its URI, metadata bytes, and per feedback only value, decimals, two tags and a revoked flag. Endpoint, feedbackURI and feedbackHash exist on-chain only in events. The registration file, feedback files with proofOfPayment, and validation evidence live off-chain.
Text alternative
Flowchart with two columns. On-chain storage: Identity Registry with tokenId as agentId, owner, agentURI and metadata including agentWallet; Reputation Registry with value, valueDecimals, tag1, tag2 and isRevoked per client and feedbackIndex; Validation Registry, specified, with requestHash, validator, response, responseHash, tag and lastUpdate. Events only: NewFeedback carries endpoint, feedbackURI and feedbackHash. Off-chain: registration file with services and registrations; feedback file with proofOfPayment; response files; validation request and evidence files. Arrows show the agentURI pointing to the registration file, feedbackURI in the event pointing to the feedback file, and the registrations list pointing back to the agentId.
The objects of the Draft text and how they refer to each other. The registration file and the feedback file are off-chain JSON; the other classes are contract storage or events. Field names follow the text of 2026-01-25.
Text alternative
Class diagram. AgentIdentity has agentId, owner, agentURI and metadata. RegistrationFile has type, name, description, image, services, x402Support, active, registrations and supportedTrust. Service has name, endpoint, version, skills, domains. Registration has agentId and agentRegistry. MetadataEntry has metadataKey and metadataValue. FeedbackRecord has value, valueDecimals, tag1, tag2 and isRevoked, keyed by client and feedbackIndex. FeedbackFile has agentRegistry, agentId, clientAddress, createdAt, value, valueDecimals and optional proofOfPayment. ProofOfPayment has fromAddress, toAddress, chainId and txHash. ValidationRecord has requestHash, validatorAddress, agentId, response, responseHash, tag and lastUpdate.
ERC-8004 feedback with proof of payment after an x402 payment
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
A client agent pays a seller agent through x402, writes an off-chain feedback file that carries proofOfPayment, uploads it, and only then calls giveFeedback with the file URI and hash. The registry stores value, decimals and tags; the proof stays off-chain and nobody on-chain checks it.
Text alternative
Sequence diagram: ERC-8004 feedback with proof of payment after an x402 payment. 6 participants: Client agent, Seller agent (x402 server), x402 facilitator, IPFS or HTTPS host, Reputation Registry, and Indexer or reader. 8 steps, 5 crossing a trust boundary, 5 failure branches. Based on erc-8004 Draft (text of 2026-01-25) (2026-01-25). Step 1: Client agent to Seller agent (x402 server): Pay for a call with x402. This step crosses a trust boundary. Step 2: Seller agent (x402 server) to x402 facilitator: Verify and settle. This step crosses a trust boundary. Step 3: Seller agent (x402 server) to Client agent: Return 200 with PAYMENT-RESPONSE. Step 4: Client agent to IPFS or HTTPS host: Upload feedback file with proofOfPayment. This step crosses a trust boundary. Step 5: Client agent to Client agent: Compute feedbackHash. Step 6: Client agent to Reputation Registry: giveFeedback(agentId, value, valueDecimals, tag1, tag2, endpoint, feedbackURI, feedbackHash). This step crosses a trust boundary. If The caller is the owner or an operator of the agent: Reverts with "Self-feedback not allowed". If valueDecimals is above 18: Reverts with "too many decimals". If The agentId does not exist: Reverts with ERC721NonexistentToken. Step 7: Reputation Registry to Indexer or reader: Return NewFeedback event. Step 8: Indexer or reader to IPFS or HTTPS host: Fetch the file and check the proof. This step crosses a trust boundary. If The file is gone or its hash does not match: The on-chain value still counts in getSummary; only off-chain scoring can discount it. If The txHash does not exist or pays someone else: Nothing on-chain flags it; the reader must reject it.
Step 1: Client agent to Seller agent (x402 server): Pay for a call with x402. This step crosses a trust boundary.
Step 2: Seller agent (x402 server) to x402 facilitator: Verify and settle. This step crosses a trust boundary.
Step 3: Seller agent (x402 server) to Client agent: Return 200 with PAYMENT-RESPONSE.
Step 4: Client agent to IPFS or HTTPS host: Upload feedback file with proofOfPayment. This step crosses a trust boundary.
Step 5: Client agent to Client agent: Compute feedbackHash.
Step 6: Client agent to Reputation Registry: giveFeedback(agentId, value, valueDecimals, tag1, tag2, endpoint, feedbackURI, feedbackHash). This step crosses a trust boundary. If The caller is the owner or an operator of the agent: Reverts with "Self-feedback not allowed". If valueDecimals is above 18: Reverts with "too many decimals". If The agentId does not exist: Reverts with ERC721NonexistentToken.
Step 7: Reputation Registry to Indexer or reader: Return NewFeedback event.
Step 8: Indexer or reader to IPFS or HTTPS host: Fetch the file and check the proof. This step crosses a trust boundary. If The file is gone or its hash does not match: The on-chain value still counts in getSummary; only off-chain scoring can discount it. If The txHash does not exist or pays someone else: Nothing on-chain flags it; the reader must reject it.
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 8Client agent toto Seller agent (x402 server)
Pay for a call with x402
The client finds the seller through its registration file (x402Support true, MCP service) and pays with x402. ERC-8004 is not involved: the payment is orthogonal to the registries.
HTTP payload. Illustrative example, spec version Draft (text of 2026-01-25).
# Illustrative example, spec version x402 v2.0.
GET /weather?city=Lisbon HTTP/1.1
Host: mcp.agent.example
PAYMENT-SIGNATURE: eyJ4NDAyVmVyc2lvbiI6Mi...
Spec version Draft (text of 2026-01-25) (2026-01-25). Sources: [1], [8], [37], [56]
Step 1 of 8: Client agent to Seller agent (x402 server). Pay for a call with x402. Crosses a trust boundary.
ERC-8004 reading reputation with a trusted reviewer list
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
A reader asks for an agent summary. Without a list of trusted client addresses getSummary reverts; with one it returns a count and a plain mean. Serious scoring reads every entry and the off-chain files.
Text alternative
Sequence diagram: ERC-8004 reading reputation with a trusted reviewer list. 3 participants: Reader (client agent or app), Reputation Registry, and Feedback file hosts. 6 steps, 1 crossing a trust boundary, 2 failure branches. Based on erc-8004 Draft (text of 2026-01-25) (2026-01-25). Step 1: Reader (client agent or app) to Reputation Registry: getSummary(agentId, [], "", ""). If clientAddresses is empty: Reverts with "clientAddresses required". Step 2: Reader (client agent or app) to Reputation Registry: getClients(agentId). Step 3: Reader (client agent or app) to Reputation Registry: getSummary(agentId, trustedClients, "starred", ""). Step 4: Reputation Registry to Reader (client agent or app): Return count, summaryValue, summaryValueDecimals. Step 5: Reader (client agent or app) to Reputation Registry: readAllFeedback(agentId, trustedClients, tag1, tag2, false). If The agent has very many entries: The loop grows with every entry; large reads can hit RPC gas limits, so indexers read events instead. Step 6: Reader (client agent or app) to Feedback file hosts: Fetch feedback files. This step crosses a trust boundary.
Step 1: Reader (client agent or app) to Reputation Registry: getSummary(agentId, [], "", ""). If clientAddresses is empty: Reverts with "clientAddresses required".
Step 2: Reader (client agent or app) to Reputation Registry: getClients(agentId).
Step 3: Reader (client agent or app) to Reputation Registry: getSummary(agentId, trustedClients, "starred", "").
Step 4: Reputation Registry to Reader (client agent or app): Return count, summaryValue, summaryValueDecimals.
Step 5: Reader (client agent or app) to Reputation Registry: readAllFeedback(agentId, trustedClients, tag1, tag2, false). If The agent has very many entries: The loop grows with every entry; large reads can hit RPC gas limits, so indexers read events instead.
Step 6: Reader (client agent or app) to Feedback file hosts: Fetch feedback files. This step crosses a trust boundary.
Solidity payload. Illustrative example, spec version Draft (text of 2026-01-25).
// Illustrative example, spec version Draft 2026-01-25.
ReputationRegistry(0x8004BAa17C55a88189AE136b182e5fdA19dE9b63).getSummary(4242, new address[](0), "", "")
Spec version Draft (text of 2026-01-25) (2026-01-25). Sources: [1], [8], [19]
Step 1 of 6: Reader (client agent or app) to Reputation Registry. getSummary(agentId, [], "", "").
Sybil reviewers and filtering by trusted clients
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
One operator funds many fresh addresses and rates its own agent. getSummary refuses an empty reviewer list, so the reader must pick reviewers; with a trusted list the Sybil cluster drops out. The study arXiv:2606.26028 measured coordinated Sybil behavior among 59.2% to 90.6% of reviewers on three chains (data to 2026-05-13).
Text alternative
Flowchart. On the left, two honest clients who paid the agent and wrote feedback with proof of payment. In the middle, one operator controlling five fresh addresses, all giving high scores to agent A, plus the owner address, which is refused. All entries reach the Reputation Registry. A reader calling getSummary with an empty list gets a revert. A reader calling getSummary with only the trusted clients gets a summary from the two honest entries. An off-chain scorer can also weight entries that carry a verifiable proofOfPayment.
ERC-8004 validation flow (specified, not officially deployed)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The Validation Registry as the Draft text specifies it. The contracts README lists no Validation Registry address on any chain, so this flow describes the specification, not a supported deployment.
Text alternative
Sequence diagram: ERC-8004 validation flow (specified, not officially deployed). 4 participants: Agent owner or operator, Request data host, Validation Registry (specified, not officially deployed), and Validator contract or service. 5 steps, 4 crossing a trust boundary, 4 failure branches. Based on erc-8004 Draft (text of 2026-01-25) (2026-01-25). Step 1: Agent owner or operator to Request data host: Store request data. This step crosses a trust boundary. Step 2: Agent owner or operator to Validation Registry (specified, not officially deployed): validationRequest(validatorAddress, agentId, requestURI, requestHash). This step crosses a trust boundary. If The requestHash was used before: Reverts with "exists" in the reference code; the first owner to submit a hash occupies it. If validatorAddress is zero: Reverts with "bad validator". Step 3: Validator contract or service to Request data host: Fetch and check the work. This step crosses a trust boundary. Step 4: Validator contract or service to Validation Registry (specified, not officially deployed): validationResponse(requestHash, response, responseURI, responseHash, "soft"). This step crosses a trust boundary. If The caller is not the named validator: Reverts with "not validator". If response is above 100: Reverts with "resp>100". Step 5: Validator contract or service to Validation Registry (specified, not officially deployed): validationResponse(requestHash, response, ..., "hard").
Step 1: Agent owner or operator to Request data host: Store request data. This step crosses a trust boundary.
Step 2: Agent owner or operator to Validation Registry (specified, not officially deployed): validationRequest(validatorAddress, agentId, requestURI, requestHash). This step crosses a trust boundary. If The requestHash was used before: Reverts with "exists" in the reference code; the first owner to submit a hash occupies it. If validatorAddress is zero: Reverts with "bad validator".
Step 3: Validator contract or service to Request data host: Fetch and check the work. This step crosses a trust boundary.
Step 4: Validator contract or service to Validation Registry (specified, not officially deployed): validationResponse(requestHash, response, responseURI, responseHash, "soft"). This step crosses a trust boundary. If The caller is not the named validator: Reverts with "not validator". If response is above 100: Reverts with "resp>100".
Step 5: Validator contract or service to Validation Registry (specified, not officially deployed): validationResponse(requestHash, response, ..., "hard").
Validation Registry (specified, not officially deployed)
Validator contract or service
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 5Agent owner or operator toto Request data host
Store request data
The owner stores everything the validator needs, including the inputs and outputs to check, at requestURI. requestHash is keccak256 of that payload and identifies the request.
Spec version Draft (text of 2026-01-25) (2026-01-25). Sources: [1], [2], [9], [29]
Step 1 of 5: Agent owner or operator to Request data host. Store request data. Crosses a trust boundary.
ERC-8004 failure: wallet binding with a bad deadline
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The owner asks for a wallet signature with a deadline too far ahead, then submits a correct signature too late. Both reverts come from the 5-minute window in the reference Identity Registry.
Text alternative
Sequence diagram: ERC-8004 failure: wallet binding with a bad deadline. 3 participants: Agent owner, New agent wallet, and Identity Registry. 5 steps, 4 crossing a trust boundary, 2 failure branches. Based on erc-8004 Draft (text of 2026-01-25) (2026-01-25). Step 1: Agent owner to New agent wallet: Request AgentWalletSet with a 30-minute deadline. This step crosses a trust boundary. Step 2: Agent owner to Identity Registry: setAgentWallet(...). This step crosses a trust boundary. If deadline is more than 5 minutes after the block time: Reverts with "deadline too far". No state changes. Step 3: Agent owner to New agent wallet: Request a new signature with a 4-minute deadline. This step crosses a trust boundary. Step 4: Agent owner to Identity Registry: Submit after 6 minutes. This step crosses a trust boundary. If block time is after the deadline: Reverts with "expired". The wallet keeps its previous value. Step 5: Agent owner to Identity Registry: Retry with a fresh signature.
Step 1: Agent owner to New agent wallet: Request AgentWalletSet with a 30-minute deadline. This step crosses a trust boundary.
Step 2: Agent owner to Identity Registry: setAgentWallet(...). This step crosses a trust boundary. If deadline is more than 5 minutes after the block time: Reverts with "deadline too far". No state changes.
Step 3: Agent owner to New agent wallet: Request a new signature with a 4-minute deadline. This step crosses a trust boundary.
Step 4: Agent owner to Identity Registry: Submit after 6 minutes. This step crosses a trust boundary. If block time is after the deadline: Reverts with "expired". The wallet keeps its previous value.
Step 5: Agent owner to Identity Registry: Retry with a fresh signature.
Spec version Draft (text of 2026-01-25) (2026-01-25). Sources: [1], [5]
Step 1 of 5: Agent owner to New agent wallet. Request AgentWalletSet with a 30-minute deadline. Crosses a trust boundary.
ERC-8004 failure: self-feedback and the fresh-address loophole
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The owner tries to rate its own agent and is refused. It then rates from a fresh address it controls, which the registry cannot tell apart from a real client. Only a reader that filters by trusted reviewers ignores it.
Text alternative
Sequence diagram: ERC-8004 failure: self-feedback and the fresh-address loophole. 4 participants: Agent owner, Fresh address controlled by the owner, Reputation Registry, and Reader with a trusted list. 4 steps, 2 crossing a trust boundary, 1 failure branch. Based on erc-8004 Draft (text of 2026-01-25) (2026-01-25). Step 1: Agent owner to Reputation Registry: giveFeedback(4242, 100, 0, "starred", ...). This step crosses a trust boundary. If The caller owns or operates agent 4242: Reverts with "Self-feedback not allowed". Step 2: Fresh address controlled by the owner to Reputation Registry: giveFeedback from a fresh address. This step crosses a trust boundary. Step 3: Reputation Registry to Reader with a trusted list: Return NewFeedback. Step 4: Reader with a trusted list to Reputation Registry: getSummary(4242, trustedClients, "starred", "").
Step 1: Agent owner to Reputation Registry: giveFeedback(4242, 100, 0, "starred", ...). This step crosses a trust boundary. If The caller owns or operates agent 4242: Reverts with "Self-feedback not allowed".
Step 2: Fresh address controlled by the owner to Reputation Registry: giveFeedback from a fresh address. This step crosses a trust boundary.
Step 3: Reputation Registry to Reader with a trusted list: Return NewFeedback.
Step 4: Reader with a trusted list to Reputation Registry: getSummary(4242, trustedClients, "starred", "").
Solidity payload. Illustrative example, spec version Draft (text of 2026-01-25).
// Illustrative example, spec version Draft 2026-01-25.
ReputationRegistry(0x8004BAa17C55a88189AE136b182e5fdA19dE9b63).giveFeedback(4242, 100, 0, "starred", "", "", "", bytes32(0))
Spec version Draft (text of 2026-01-25) (2026-01-25). Sources: [1], [8], [21]
Step 1 of 4: Agent owner to Reputation Registry. giveFeedback(4242, 100, 0, "starred", ..). Crosses a trust boundary.
ERC-8004 alternative path: a transfer clears the agent wallet
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
An agent identity is sold. The transfer clears agentWallet, so a payer that reads the wallet gets the zero address until the new owner binds a wallet with a fresh signature.
Text alternative
Sequence diagram: ERC-8004 alternative path: a transfer clears the agent wallet. 5 participants: Previous owner, New owner, Identity Registry, Paying client, and New owner wallet. 4 steps, 2 crossing a trust boundary, 1 failure branch. Based on erc-8004 Draft (text of 2026-01-25) (2026-01-25). Step 1: Previous owner to Identity Registry: transferFrom(old, new, agentId). This step crosses a trust boundary. Step 2: Paying client to Identity Registry: getAgentWallet(agentId). If The payer cached the old wallet: It may pay the previous owner; ERC-8004 cannot stop a payment it does not carry. Step 3: New owner to New owner wallet: Sign AgentWalletSet. This step crosses a trust boundary. Step 4: New owner to Identity Registry: setAgentWallet(...).
Step 1: Previous owner to Identity Registry: transferFrom(old, new, agentId). This step crosses a trust boundary.
Step 2: Paying client to Identity Registry: getAgentWallet(agentId). If The payer cached the old wallet: It may pay the previous owner; ERC-8004 cannot stop a payment it does not carry.
Step 3: New owner to New owner wallet: Sign AgentWalletSet. This step crosses a trust boundary.
Step 4: New owner to Identity Registry: setAgentWallet(...).
Solidity payload. Illustrative example, spec version Draft (text of 2026-01-25).
// Illustrative example, spec version Draft 2026-01-25.
IdentityRegistry(0x8004A169FB4a3325136EB29fA0ceB6D2e539a432).transferFrom(0x0E0E...0E0E, 0x9E99...9E99, 4242)
// emits Transfer and MetadataSet(agentWallet, empty)
Spec version Draft (text of 2026-01-25) (2026-01-25). Sources: [1], [5]
Step 1 of 4: Previous owner to Identity Registry. transferFrom(old, new, agentId). Crosses a trust boundary.
ERC-8004 revoking feedback and appending responses
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
A client leaves low feedback, the agent appends a response pointing to a refund, an aggregator appends a spam tag, and the client finally revokes. Responses never change the value; revocation removes it from summaries.
Text alternative
Sequence diagram: ERC-8004 revoking feedback and appending responses. 4 participants: Client, Agent owner, Data aggregator, and Reputation Registry. 5 steps, 3 crossing a trust boundary, 3 failure branches. Based on erc-8004 Draft (text of 2026-01-25) (2026-01-25). Step 1: Client to Reputation Registry: giveFeedback(4242, 20, 0, "successRate", ...). This step crosses a trust boundary. Step 2: Agent owner to Reputation Registry: appendResponse(4242, client, 1, responseURI, responseHash). This step crosses a trust boundary. If responseURI is empty: Reverts with "Empty URI". If feedbackIndex is 0 or past the last index: Reverts with "index must be > 0" or "index out of bounds". Step 3: Data aggregator to Reputation Registry: appendResponse(..., spam tag). This step crosses a trust boundary. Step 4: Client to Reputation Registry: revokeFeedback(4242, 1). If The entry is already revoked: Reverts with "Already revoked". Step 5: Reputation Registry to Client: Return FeedbackRevoked.
Step 1: Client to Reputation Registry: giveFeedback(4242, 20, 0, "successRate", ...). This step crosses a trust boundary.
Step 2: Agent owner to Reputation Registry: appendResponse(4242, client, 1, responseURI, responseHash). This step crosses a trust boundary. If responseURI is empty: Reverts with "Empty URI". If feedbackIndex is 0 or past the last index: Reverts with "index must be > 0" or "index out of bounds".
Step 3: Data aggregator to Reputation Registry: appendResponse(..., spam tag). This step crosses a trust boundary.
Step 4: Client to Reputation Registry: revokeFeedback(4242, 1). If The entry is already revoked: Reverts with "Already revoked".
Step 5: Reputation Registry to Client: Return FeedbackRevoked.
Spec version Draft (text of 2026-01-25) (2026-01-25). Sources: [1], [8]
Step 1 of 5: Client to Reputation Registry. giveFeedback(4242, 20, 0, "successRate", ..). Crosses a trust boundary.
How ERC-8004 composes with the other seven
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
ERC-8004 is an identity and reputation layer with one strong documented link (x402), one citation (the MPP discovery draft), one indirect path (A2A to AP2) and no documented link to TAP, ACP, UCP or Agent Pay as of 2026-10-11. Companion ERCs build around it.
Text alternative
Flowchart. ERC-8004 in the center. x402 is linked by x402Support, agentWallet as payee and proofOfPayment in feedback files. Stripe MPP discovery draft cites ERC-8004 for possible future on-chain anchoring. AP2 connects indirectly through A2A agent cards listed as services. Visa TAP, OpenAI ACP, Google UCP and Mastercard Agent Pay have no documented relation. Companion standards ERC-8122, ERC-8217, ERC-8126, ERC-8183 and ERC-8226 build on or around ERC-8004; ERC-8226 bridges to ERC-3643 regulated tokens.
Where the threats in section H enter. Mutable HTTPS files, free feedback from fresh addresses, the single upgrade key, unchecked proofOfPayment, a reusable wallet signature inside its window, and validator answers that can be lowered. Status of the upgrade key as read on 2026-10-11.
Text alternative
Flowchart of boundaries. Boundary 1, owner to Identity Registry: wallet-binding signature has no nonce and is reusable for 5 minutes; operators share owner powers. Boundary 2, chain to off-chain file: HTTPS registration files can change without an event; capabilities are not guaranteed. Boundary 3, clients to Reputation Registry: any address can rate; Sybil clusters; proofOfPayment is never checked on-chain. Boundary 4, registry owner to all proxies: one externally owned account can upgrade on Ethereum and Base. Boundary 5, validator to Validation Registry (specified): later responses can lower a pass; requestHash is first come first served. Readers sit outside and must filter.
Two identity models on Ethereum. ERC-3643 gates token transfers with issuer-signed claims on an ONCHAINID; ERC-8004 lets anyone mint an agent identity and collects open feedback. ERC-8226 (Draft) is the bridge standard that names both.
Text alternative
Flowchart in two columns. Left, ERC-3643 plus ONCHAINID: a trusted issuer signs a claim on a holder ONCHAINID; the T-REX Identity Registry maps a wallet to that identity and a country; the Compliance contract checks canTransfer on each transfer; the Trusted Issuers Registry and Claim Topics Registry are set by the token owner. Right, ERC-8004: any address registers an agent in the Identity Registry; clients write feedback to the Reputation Registry; a reader filters by trusted clients. Mapping lines: trusted ClaimIssuer to trusted reviewer list; claim topics to feedback tags; Identity Registry to Identity Registry, same name, different thing. ERC-8226 connects a verified principal, a mandate and an ERC-8004 agent with ERC-3643 token compliance.
Spec-deep mode: the full explanation plus 0 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
This section uses Simplified Technical English (ASD-STE100): short sentences, one instruction per step, and one word for one meaning.
ERC-8004 is a draft standard for Ethereum and other EVM chains. It gives an AI agent an identity on a public chain. It also keeps a public record of feedback about the agent. It is not a final standard. It does not move money.
ERC-8004 has three registries. The Identity Registry gives each agent a token with an agentId. The token points to a registration file. This file lists the name of the agent, its services and its trust models. The Reputation Registry keeps a score and two tags for each item of feedback.
The Validation Registry is in the specification. It is not officially deployed on a chain.
The owner of the token controls the agent. The owner can change the address of the registration file. The owner can also set the agentWallet address. The agent gets payments at this address. To change the address, the new wallet must sign a message.
Any address can give feedback, but the owner and the operators cannot. The registry does not prevent fake reviewers. Thus, a reader must select the reviewers that it trusts.
The registry keeps only the value, the decimals, the tags and the revoked flag on the chain. The details and the proofOfPayment object stay in an off-chain file.
Procedure Register an agent (agent developer)
Write the registration file. Use the fields of the specification.
Put the file on IPFS or on an HTTPS server.
Call register on the Identity Registry with the address of the file.
Read the agentId from the Registered event.
Add the agentId and the agentRegistry value to the registrations list in the file.
If the address of the file changes, call setAgentURI.
If the agent must get payments at a different address, do the wallet procedure.
Procedure Set the payment wallet of an agent (agent owner)
Get the agentId, the address of the new wallet and your owner address.
Set a deadline that is less than 5 minutes after the current time.
Sign the AgentWalletSet message with the key of the new wallet.
Call setAgentWallet with the agentId, the wallet, the deadline and the signature.
Make sure that the MetadataSet event shows the new wallet.
After a transfer of the token, do this procedure again.
Procedure Give feedback after a payment (client agent)
Pay the agent with x402 or with a different payment method.
Keep the transaction hash of the payment.
Write the feedback file. Put the value, the decimals and the proofOfPayment object in the file.
Put the file on IPFS.
Call giveFeedback with the value, the decimals, the tags, the file address and the file hash.
Procedure Read the reputation of an agent (controls builder)
Get the list of reviewers with getClients.
Select only the reviewers that you trust.
Call getSummary with the agentId and this list.
If you need a better score, read all feedback and the off-chain files.
Make sure that each proofOfPayment agrees with a real transaction on the chain.
Technical nouns and technical verbs
agentId: The number of the token that identifies an agent in one registry.
agentRegistry: A text value with the chain family, the chain number and the registry address.
agentURI: The address of the registration file of an agent.
registration file: A JSON file that gives the name, the services and the trust models of an agent.
agentWallet: The address where the agent gets payments.
feedback: A value and tags that a client writes about an agent.
proofOfPayment: An object in the feedback file that identifies a payment transaction.
operator: An address that the owner approves to manage the agent.
Sybil attack: An attack where one person uses many addresses to look like many reviewers.
register (TV): To make a new agent token in the Identity Registry.
revoke (TV): To mark your own feedback as not valid.
STE check report
Sentences
68
Longest procedural sentence
18 words (limit 20)
Longest descriptive sentence
17 words (limit 25)
Flags
0 errors, 1 warnings, 0 for review
Warningpassive-voice(description)
"is not officially deployed" is passive. Use the active voice and name the agent.
It is not officially deployed on a chain.
Written to the public ASD-STE100 Issue 9 writing rules. Vocabulary not checked against the official dictionary.
Compare with the practitioner text side by side
Practitioner text (section B)
ERC-8004 answers one question: how does an agent find another agent it has never met, and decide how far to trust it, without a platform in the middle? It puts three small registries on Ethereum and other EVM (Ethereum Virtual Machine) chains. The Identity Registry mints each agent an ERC-721 token, the token type behind NFTs (non-fungible tokens). The token points to a registration file that lists the agent's services, such as an MCP (Model Context Protocol) server or an A2A (Agent2Agent) agent card. The Reputation Registry lets any address except the owner and its operators post a score with tags. The Validation Registry, where an independent validator would record a check of the agent's work, is specified but not officially deployed. ERC-8004 moves no money: payments are out of scope, and an x402 payment can only add evidence to a piece of feedback. What ERC-8004 does not give you: proof that an agent works, protection against fake reviewers, or any check on who runs it. The text says as much and leaves ranking to whoever reads the data. It is a Draft ERC (Ethereum Request for Comments), not a Final one, even though its registries are listed on 25 mainnets.
The authors start from a gap. MCP lets a server list its tools and A2A handles messaging and task lifecycles. Neither tells you which agent to pick from an organization you have never dealt with, or whether it behaved well before. ERC-8004 fills that gap with three lightweight registries meant to run as one singleton per chain, on Ethereum mainnet or a Layer 2 network. Trust is meant to scale with the value at risk: client feedback for cheap tasks, and stake-secured re-execution, zkML (zero-knowledge machine learning) proofs or TEE (trusted execution environment) oracles for expensive ones.
Simplified Technical English
ERC-8004 is a draft standard for Ethereum and other EVM chains. It gives an AI agent an identity on a public chain. It also keeps a public record of feedback about the agent. It is not a final standard. It does not move money.
ERC-8004 has three registries. The Identity Registry gives each agent a token with an agentId. The token points to a registration file. This file lists the name of the agent, its services and its trust models. The Reputation Registry keeps a score and two tags for each item of feedback.
The Validation Registry is in the specification. It is not officially deployed on a chain.
E. Main personas
Agent developer
Builds the agent, writes its registration file and registers it in the Identity Registry. Source [1, 5, 7, 55]
Goals
Make the agent discoverable by other agents and explorers
Advertise MCP, A2A and web endpoints in one place
Keep the payee address correct after key changes
Pains
No JSON Schema for the registration file, so required fields are a reading of an example
Tutorials written before 2026-01-25 still use endpoints and score
The agentId is known only after minting, so the file must be published twice
Implements
A registration file with type, services, x402Support, active, registrations and supportedTrust
register and setAgentURI calls, or an SDK such as agent0-sdk
The /.well-known/agent-registration.json domain proof
Must trust
The file host to serve the file (or IPFS content addressing)
The registry owner not to upgrade the contracts against them
Explorers to read the file the same way they do
Questions, first steps, metrics and a day in the life
Questions they ask
Which fields do explorers actually require?
Should the file be on IPFS or in a data URI?
How do I keep agentWallet set after a transfer?
First three steps
Read the Identity Registry section of the Draft text
Register a test agent on Ethereum Sepolia or Base Sepolia
Check how 8004scan renders the file
Metrics they care about
Whether the agent shows as reachable in explorers
Feedback count from trusted clients
Time to rebind the wallet after a change
A day in the life
Ana ships a weather agent with an MCP server. She writes a registration file, pins it to IPFS and calls register on Base Sepolia. The Registered event gives her agent id 812, so she adds it to the registrations list, pins the new file and calls setAgentURI. Her MCP server lives on another domain, so she serves the well-known file there too. An old tutorial told her to add an agentWallet endpoint; she deletes it and asks her payment wallet to sign the AgentWalletSet message instead, within the five-minute window. Before mainnet she checks that explorers show her services and the x402Support flag.
Finds other agents in the registry, pays them through another protocol and writes feedback afterward. Source [1, 8, 18, 19]
Goals
Pick a counterparty it has never met
Pay the right address
Leave feedback that others can verify
Pains
Most registered agents have no live endpoint
Raw summaries are polluted by Sybil reviewers
Feedback costs gas
Implements
Lookups of agentURI and getAgentWallet
A trusted reviewer list for getSummary
Feedback files with proofOfPayment, then giveFeedback
Must trust
Its own reviewer list
The registration file as served at lookup time
The payment rail it uses, such as x402
Questions, first steps, metrics and a day in the life
Questions they ask
Which reviewers should count?
Is the advertised endpoint the one I am talking to?
Is this agentWallet still current?
First three steps
Resolve the agent file and check its registrations entry
Call getSummary with reviewers it trusts
Probe the endpoint before paying
Metrics they care about
Share of hires that delivered
Feedback written per paid task
Spend on agents without trusted feedback
A day in the life
A research agent needs a translation service. It queries an indexer for agents tagged with translation skills, reads each registration file and drops those whose MCP endpoint does not answer. For the rest it calls getSummary with the twenty client addresses its operator trusts. It pays the best one through x402 at the address returned by getAgentWallet, keeps the transaction hash, uploads a feedback file with proofOfPayment and then calls giveFeedback with the file URI. The gas comes from a sponsor, as the text allows for clients that need not be registered.
Would check an agent's work and post a 0 to 100 response in the Validation Registry, which is specified but not officially deployed. Source [1, 2, 9, 10, 29]
Goals
Offer re-execution, zkML or TEE checks as a service
Publish results others can query
Get paid for the work
Pains
No officially deployed Validation Registry
Incentives and slashing are out of scope
LLM outputs vary between runs, which weakens re-execution
Implements
A validator contract or service that reads requestURI
validationResponse calls with tags such as soft and hard
Evidence files at responseURI
Must trust
The request data at requestURI
Its own attestation or proof system
The registry code, which one key can upgrade
Questions, first steps, metrics and a day in the life
Questions they ask
Will the Validation Registry be redesigned before a listed deployment?
Can I lower a response after a pass, and should I?
Who pays for validation?
First three steps
Read the Validation Registry section and issue 28
Deploy the reference contract on a local chain
Prototype one validation method
Metrics they care about
Requests answered
Time to final response
Disputed responses
A day in the life
Kai runs a TEE attestation service and wants to post results through ERC-8004. He finds the Validation Registry in the text, but the contracts README lists no address and calls that part still under discussion. A contract answers at the scripted address on Base, yet nobody announced it, so he does not build on it. He deploys the reference code on a local chain instead, posts a soft response and then a hard one, and notices that a later answer can also lower a pass. He follows the open issue on that and waits for an official deployment.
Sells an API or agent service, registers it so buyers can find it, and receives payments at agentWallet. Source [1, 8, 37, 56]
Goals
Be found by agent buyers
Show a payment-backed track record
Keep the payee address safe
Pains
Competitors and spammers can rate it from fresh addresses
Responses do not change a low score
x402 payments look like ordinary transfers to indexers
Implements
x402Support true and an agentWallet bound by signature
appendResponse to answer complaints, for example with refund evidence
revenues feedback through its facilitator, as best practices suggest
Must trust
Readers to filter reviewers sensibly
The facilitator that publishes revenues feedback
The registry owner
Questions, first steps, metrics and a day in the life
Questions they ask
How do I get feedback from real customers counted?
What happens to my reputation if I sell the agent token?
Is my wallet binding replayable?
First three steps
Register the service with x402Support true
Bind a dedicated payment wallet
Ask paying clients to include proofOfPayment
Metrics they care about
Feedback from paying clients
Revenue tracked by revenues feedback
Responses posted to complaints
A day in the life
Omar sells a pricing API to agents and already takes x402 payments. He registers it with x402Support true and binds a cold wallet as agentWallet. A week later a burst of zero scores arrives from addresses that never paid him. He cannot delete them, so he appends responses that link to his payment logs and asks his facilitator to publish revenues feedback, as the best-practices guide suggests. His larger buyers already pass a trusted reviewer list to getSummary, and the burst never shows up in their numbers.
Builds policy around agents: which agents a fleet may hire or pay, based on registry data plus its own checks. Source [1, 5, 10, 37]
Goals
Turn public signals into an allowlist
Block payments to stale wallets
Explain decisions to auditors
Pains
No native spending caps, consent or kill switch
Values are not comparable across tags
One upgrade key can change registry behavior
Implements
Trusted reviewer lists and weighting by proofOfPayment
Checks that agentWallet was set after the last transfer
Monitoring of URIUpdated, MetadataSet and Transfer events
Must trust
Its own indexer
The off-chain files it caches
The payment layer that enforces caps
Questions, first steps, metrics and a day in the life
Questions they ask
Which signals are strong enough to allow a payment?
How do I detect a sold agent?
What if the registry is upgraded?
First three steps
Index the identity and reputation events for the chains you use
Define a trusted reviewer set
Alert on transfers and wallet changes
Metrics they care about
Payments blocked by policy
Agents with stale wallets
Time from upgrade to alert
A day in the life
Lena runs controls for a company whose agents buy data from other agents. She indexes Transfer, URIUpdated and MetadataSet events and refuses payment to any agent whose token moved since its wallet was last bound. She scores reputation only from reviewers that paid with a verifiable proofOfPayment. Spending caps live in her payment layer, because ERC-8004 has none. When she learns that one externally owned account can upgrade the registries, she adds an alert on the proxy implementation slot and writes the risk into her vendor review.
Studies the registries, the deployed proxies and the feedback data for attacks and failure modes. Source [9, 10, 19, 29, 30]
Goals
Measure Sybil feedback and placeholder registrations
Find contract and governance weaknesses
Publish reproducible findings
Pains
No named audit report
No public log query over large block ranges on free RPCs
Values with no common unit
Implements
Event crawls and census-style probes
eth_call reads of owner and implementation slots
Graph analysis of reviewers
Must trust
RPC providers and indexers
The census and study methods it reuses
Its own detection heuristics
Questions, first steps, metrics and a day in the life
Questions they ask
Who holds the upgrade key?
How much feedback is grounded in payment?
Can requestHash squatting block validation?
First three steps
Read the Security Considerations and PR 51
Read owner() on the three proxies
Reproduce the arXiv:2606.26028 liveness measure on one chain
Metrics they care about
Share of live agents
Share of Sybil reviewers
Open issues without a fix
A day in the life
Priya reads the proxies on Ethereum and Base and finds one externally owned account owning all three, with no published holder. She checks the community audit in PR 51, still unmerged, and confirms from the code that a validator can lower a pass and that a requestHash can be claimed first by anyone. Then she samples feedback: most reviewers rate many agents with identical values within minutes, the same pattern arXiv:2606.26028 reported. She writes it up with dates and block numbers, because every one of these facts can change with an upgrade.
Describes a structured dataset of 10,000 ERC-8004 agents registered on Ethereum mainnet within a defined block range, combining on-chain identity records, minting and transfer events, reputation summaries and feedback records with resolved off-chain metadata, collected through Web3 RPC queries. The companion data are deposited on Harvard Dataverse under DOI 10.7910/DVN/HJZW8Q (a dataset DOI, which the arXiv record lists in place of a paper DOI).
Why it matters here: A reusable baseline for erc-8004 measurement work; the Mafrur and Khusumanegara readiness study builds on data of this kind. ERC-8004: Trustless Agents: A dataset of early Ethereum registrations for your own analysis.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{liu2026dataset,
title = {{A dataset of early blockchain-registered AI agents on Ethereum}},
author = {Yulin Liu},
year = {2026},
eprint = {2604.22652},
archivePrefix = {arXiv},
primaryClass = {cs.DB},
url = {https://arxiv.org/abs/2604.22652}
}
Builds Tamarin models of x402, MPP, ACP and AP2 from their specifications, schemas and reference code using one shared abstraction of the agent payment lifecycle, then asks source-backed verification questions to expose missing bindings and cross-stage correspondences, which it consolidates into 18 security principles. Across 86 verification cases it reproduces 46 known or calibration cases, reports 40 new formal-consistency findings, and validates ten of them against x402 implementations with proofs of concept.
Why it matters here: The only side-by-side formal model of x402, stripe-mpp, openai-acp and ap2 so far; it shows where each specification leaves delegated authority, settlement and fulfillment unbound. AP2: Tamarin models that include AP2. ERC-8004: Trustless Agents: Formal models of agent payment protocols around ERC-8004. Agentic Commerce Protocol (ACP): Models ACP in Tamarin with x402, MPP and AP2; the only formal analysis that names it. Stripe MPP (Machine Payments Protocol): Models MPP in Tamarin alongside x402, ACP and AP2; the only formal analysis that names MPP. UCP: Formal analysis of agent payment protocols; the abstract does not name UCP but analyzes AP2, which UCP embeds as an extension. x402: Formal Tamarin models of x402 alongside MPP, ACP and AP2.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{jiang2026formal,
title = {{A Formal Analysis of Agent Payment Protocols}},
author = {Ke Jiang and Mohan Yu and Yuan Chang and Mohit Kumar Jangid and Jianyu Niu and Cong Wang and Yinqian Zhang},
year = {2026},
eprint = {2609.00060},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.00060}
}
A chapter-length treatment of agent-to-agent finance as a layer of machine-mediated financial interaction in which agents discover counterparties, express intent, pay and generate auditable evidence, drawing on blockchain agent-to-agent payment work, ERC-8004 registries, provenance-based wallets and official evidence on AI adoption in finance. Its central design question is bounded autonomy.
Why it matters here: Positions erc-8004 and blockchain agent payments such as x402 as candidate financial market infrastructure and sets out the accountability questions regulators will ask.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{gong2026a2afinance,
title = {{Agent-to-Agent Finance: Blockchain Payments and Trust Infrastructure for Autonomous AI Agents}},
author = {Hui Gong},
year = {2026},
eprint = {2607.00245},
archivePrefix = {arXiv},
primaryClass = {q-fin.GN},
url = {https://arxiv.org/abs/2607.00245}
}
First empirical study of ERC-8004 on Ethereum, BNB Smart Chain and Base from deployment through 2026-05-13, crawling Identity and Reputation Registry events, registration files and associated x402 payments. Only 3%, 4% and 15% of registrations on the three chains expose a valid registration file with a live endpoint, reputation values are not commensurable and are cheap to manipulate, and 73.5%, 59.2% and 90.6% of reviewers show coordinated Sybil behavior; removing flagged feedback leaves 15.8%, 77.9% and 86.8% of rated agents with no valid feedback.
Why it matters here: Primary evidence for the disputed status of erc-8004 reputation data and for the gap between registrations and operational agents; it also links x402 settlements to registered identities. ERC-8004: Trustless Agents: The main measurement of ERC-8004 in practice: liveness and Sybil reviewers on three chains.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{xiong2026trustless,
title = {{Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem}},
author = {Xihan Xiong and Zelin Li and Wei Wei and Qin Wang and William Knottenbelt and Zhipeng Wang},
year = {2026},
eprint = {2606.26028},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2606.26028}
}
Extends the A2A protocol with ledger-anchored identities, publishing AgentCards on chain as smart contracts for verifiable discovery, and with x402 micropayments so that agents can discover, authenticate and pay one another across organizational boundaries; includes an implementation and evaluation. Published in Springer CCIS from IJCCI 2025 under the title given here; the arXiv preprint (2507.19550, 2025) carries the longer title 'Towards Multi-Agent Economies: Enhancing the A2A Protocol with Ledger-Anchored Identities and x402 Micropayments for AI Agents'.
Why it matters here: Peer-reviewed design that pairs x402 with on-chain agent identity, the same combination that erc-8004 plus x402 deployments pursue. ERC-8004: Trustless Agents: Ledger-anchored identity with A2A and x402, before ERC-8004. x402: Combines A2A with ledger-anchored identities and x402 micropayments.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{vaziry2026a2ax402,
title = {{Enhancing the A2A Protocol with Blockchain-Based Identities and x402 Micropayments for Agentic AI}},
author = {Awid Vaziry and Sandro Rodriguez Garzon and Axel Küpper},
year = {2026},
booktitle = {Computational Intelligence (IJCCI 2025), Communications in Computer and Information Science, vol. 2827},
publisher = {Springer Nature Switzerland},
series = {Communications in Computer and Information Science},
pages = {454-472},
doi = {10.1007/978-3-032-15632-7_25},
eprint = {2507.19550},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2507.19550}
}
Asks whether ERC-8004 agents on Ethereum are operationally ready beyond registration by building an agent-level feature table (identity status, metadata, service declarations, reputation feedback, transfers, cross-chain registration) and an evidence-layer readiness framework, complemented by network analysis of owner-agent, feedback-client and wallet-transfer graphs. Early adoption is registration-heavy but operationally shallow, and ownership and feedback activity are concentrated in a few wallets and clients.
Why it matters here: Independent, journal-published measurement that supports the atlas distinction between erc-8004 identity registrations and a working agent economy. ERC-8004: Trustless Agents: Measures operational readiness of registered agents.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@article{mafrur2026readiness,
title = {{From Agent Identity to Agent Economy: Measuring the Operational Readiness of ERC-8004 AI Agents}},
author = {Rischan Mafrur and Priagung Khusumanegara},
year = {2026},
journal = {Journal of FinTech and Digital Assets},
volume = {1},
number = {2},
pages = {69-88},
doi = {10.34900/jfda.v1i2.1411},
eprint = {2606.12128},
archivePrefix = {arXiv},
primaryClass = {cs.CE},
url = {https://arxiv.org/abs/2606.12128}
}
Applies a six-dimension governance taxonomy (membership, deliberation, voting, dissent preservation, human escalation, audit and replay) to the specifications of MCP, A2A, ACP, ANP and ERC-8004, finding that voting and dissent preservation are absent in all five and that governed agent communities need a new architectural layer above interoperability standards. The ACP it analyzes is an agent interoperability protocol, not OpenAI's Agentic Commerce Protocol; its exact referent is not confirmed from the abstract.
Why it matters here: One of the few papers to read the erc-8004 specification text against a requirements taxonomy; it also illustrates the ACP name clash.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{kang2026governancegaps,
title = {{Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express}},
author = {Richard Kang and Yudho Diponegoro},
year = {2026},
eprint = {2606.31498},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2606.31498}
}
A vision paper arguing that once buyers are agents paying over agent-native rails such as x402 and AP2, the scarce resource becomes trustworthy product information rather than product matching. It sketches a market in which buyer agents pay fractions of a cent to unlock seller- and reviewer-supplied evidence, with reviewer trust scored reputationally, and lists the NLP problems this creates.
Why it matters here: Names x402 and AP2 directly as the rails that make per-fact micropayments feasible, and ties paid information to the reputation scoring that ERC-8004 registries aim to provide. Stripe MPP (Machine Payments Protocol): Micro-transaction markets for product information, a use case for per-request MPP charges.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{ventirozos2026paying,
title = {Paying to Know: Micro-Transaction Markets for Verified Product Information in Agentic E-Commerce},
author = {Filippos Ventirozos and Matthew Shardlow},
year = {2026},
eprint = {2606.24783},
archivePrefix = {arXiv},
primaryClass = {cs.CL},
url = {https://arxiv.org/abs/2606.24783},
note = {arXiv preprint}
}
Systematizes blockchain-based agent-to-agent payments, with x402 as the lead example, into a four-stage lifecycle of discovery, authorization, execution and accounting, classifies representative designs at each stage, and isolates recurring weaknesses: weak intent binding, misuse under valid authorization, payment-service decoupling and limited accountability.
Why it matters here: Gives a lifecycle vocabulary for x402 and for the discovery role that erc-8004 registries are meant to fill, and names the payment-service decoupling problem that later x402 attack papers exploit. ERC-8004: Trustless Agents: Survey that places ERC-8004 among agent payment components. Stripe MPP (Machine Payments Protocol): Systematizes blockchain agent-to-agent payments; does not name MPP but covers the Tempo-style rails. x402: Systematizes blockchain agent-to-agent payments, with x402 as a central case.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zhang2026sok,
title = {{SoK: Blockchain Agent-to-Agent Payments}},
author = {Yuanzhe Zhang and Yuexin Xiang and Yuchen Lei and Qin Wang and Tian Qiu and Yujing Sun and Spiridon Zarkov and Tsz Hon Yuen and Andreas Deppeler and Jiangshan Yu and Kwok-Yan Lam},
year = {2026},
eprint = {2604.03733},
archivePrefix = {arXiv},
primaryClass = {q-fin.GN},
url = {https://arxiv.org/abs/2604.03733}
}
A systematization of knowledge that frames the security of autonomous LLM agents in commerce along five dimensions (agent integrity, transaction authorization, inter-agent trust, market manipulation, regulatory compliance), derives 12 cross-layer attack vectors from a curated corpus of papers, protocol documents, industry reports and incidents, and proposes a layered defense for the authorization gaps in current agent payment protocols. The ACP it lists is written 'Agent Commerce Protocol', which may not be OpenAI's Agentic Commerce Protocol; that mapping is unconfirmed.
Why it matters here: Places erc-8004, ap2, x402 and stripe-mpp in one threat framework and argues that their authorization gaps compound across the reasoning, tooling, custody and settlement layers. AP2: Places AP2 among agent commerce attack vectors. Stripe MPP (Machine Payments Protocol): Includes MPP in its protocol set for agent commerce security. x402: Security SoK of agentic commerce that covers x402.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{mao2026sok,
title = {{SoK: Security of Autonomous LLM Agents in Agentic Commerce}},
author = {Qian'ang Mao and Jiaxin Wang and Ya Liu and Li Zhu and Cong Ma and Jiaqi Yan},
year = {2026},
eprint = {2604.15367},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2604.15367}
}
A dynamic model in which an agent's reputation is capital that attracts future demand, and the agent chooses each period between honest operation, investing in quality, or a one-shot deviation that cashes out the reputation and restarts under a penalized new identity. The temptation depends on identity-reset cost, reputation persistence, demand sensitivity and enforcement design; ERC-8004, ERC-8183 and x402 are named as the motivating infrastructure.
Why it matters here: Names ERC-8004 and x402 directly and states the economic condition under which an on-chain reputation registry disciplines agents: resetting an identity must cost more than the one-shot gain from burning it. ERC-8004: Trustless Agents: Economics of reputation when identities are cheap.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{gatta2026tempting,
title = {Tempting the Agent: The Economics of Reputation without Persistent Identity in AI Agent Markets},
author = {Federico Gatta and Manuel Naviglio and Francesco Tarantelli},
year = {2026},
eprint = {2609.02992},
archivePrefix = {arXiv},
primaryClass = {q-fin.GN},
url = {https://arxiv.org/abs/2609.02992},
note = {arXiv preprint}
}
Large-scale empirical study of the Web4 agent economy built on MCP, x402 and EIP-8004 (ERC-8004), analyzing 99,448 multi-chain identity registrations, 317,596,323 transaction logs, the source code of 341 MCP projects and 349 GitHub issues. It finds a highly active machine-to-machine payment economy with millions of daily transactions resting on immature identity, authorization and interoperability practice, with payment interoperability the most persistent bottleneck.
Why it matters here: Measurement of erc-8004 registrations and x402 transaction volume from a software-engineering angle; read it together with the authenticity analyses before quoting volume figures.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{jin2026web4,
title = {{The Web4 Agent Economy: A Large-Scale Empirical Study of the Landscape, Challenges, and Opportunities}},
author = {Yuhan Jin and Shuohan Wu and Chong Chen and Lingfeng Bao and Xiaohu Yang and Jiachi Chen},
year = {2026},
eprint = {2606.25876},
archivePrefix = {arXiv},
primaryClass = {cs.SE},
url = {https://arxiv.org/abs/2606.25876}
}
Compares six trust mechanisms for inter-agent protocols (brief, claim, proof, stake, reputation, constraint) and evaluates A2A, AP2 and ERC-8004 against them on security, privacy, cost and resistance to Sybil, collusion and whitewashing, with attention to LLM-specific weaknesses such as prompt injection and sycophancy. It argues that proof and stake should gate high-impact actions, with claims for discovery and reputation as an overlay. The arXiv record says it was submitted to the AAAI 2026 TrustAgent workshop; acceptance is not confirmed.
Why it matters here: Direct comparative treatment of ap2 and erc-8004 trust assumptions; its warning that claim-only and reputation-only designs are brittle anticipates the empirical ERC-8004 Sybil findings. ERC-8004: Trustless Agents: Places ERC-8004 reputation among other inter-agent trust models.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{hu2025trust,
title = {{Inter-Agent Trust Models: A Comparative Study of Brief, Claim, Proof, Stake, Reputation and Constraint in Agentic Web Protocol Design-A2A, AP2, ERC-8004, and Beyond}},
author = {Botao 'Amber' Hu and Helena Rong},
year = {2025},
eprint = {2511.03434},
archivePrefix = {arXiv},
primaryClass = {cs.HC},
url = {https://arxiv.org/abs/2511.03434}
}
Introduces TraceRank, a reputation-weighted ranking for x402-enabled services in which payment transactions act as endorsements, seeded with precomputed reputation and propagated through the payment graph weighted by value and recency, then combined with semantic search. The authors argue that this resists Sybil spam because many low-reputation payers rank below a few high-reputation ones.
Why it matters here: An early proposal for discovery and reputation over the x402 payment graph, the same problem that erc-8004 reputation registries target. x402: Uses the x402 payment graph for Sybil-resistant service discovery.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{shi2025sybil,
title = {{Sybil-Resistant Service Discovery for Agent Economies}},
author = {David Shi and Kevin Joo},
year = {2025},
eprint = {2510.27554},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2510.27554}
}
Designs deployer-side attestations so that, after an incident in a multi-agent workflow, a verifier can tell which deployer released given output bytes and whether each cross-deployer delegation was authorized. It compares a signed linked list, a Merkle chain and a co-signed DAG, and only the co-signed DAG rejects a forged parent link after a child key is compromised.
Why it matters here: Gives the evidence model that ERC-8004 validation records and AP2 mandate chains need when work and authority pass through several agents operated by different parties.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{liu2026ancestry,
title = {{Attesting Outputs and Delegation Ancestry in Multi-Agent AI Systems}},
author = {Lifei Liu and Haoran Yu},
year = {2026},
eprint = {2608.30387},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2608.30387}
}
Argues that Know Your Agent regimes modeled on human identity verification and credit scores are incomplete because language model agents are assemblages of mutable modules (models, prompts, tool policies, memory) with fluid personas that may not internalize sanctions, so identifiability, predictability, credibility and rehabilitability lack grounding. It proposes observability-based, ex ante, protocol-level behavioral harnesses in place of ex post reputation.
Why it matters here: A direct critique of the premise behind ERC-8004's Reputation Registry and of KYA-style identity checks in TAP and Agent Pay: if the sanctioned identity can be swapped out, reputation does not discipline the agent. ERC-8004: Trustless Agents: Questions whether LLM agents have the stable identity reputation needs.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{hu2026dissociative,
title = {Dissociative Identity: Language Model Agents Lack Grounding for Reputation Mechanisms},
author = {Botao Amber Hu and Helena Rong and Max Van Kleek},
year = {2026},
booktitle = {Proceedings of the 2026 ACM Conference on Fairness, Accountability, and Transparency (FAccT '26)},
publisher = {ACM},
pages = {4199-4219},
doi = {10.1145/3805689.3806748},
eprint = {2605.30169},
archivePrefix = {arXiv},
url = {https://arxiv.org/abs/2605.30169}
}
Formalizes an epistemic Sybil problem: extra agent reports that descend from the same evidence add no information, and report-only aggregators cannot tell replication from independent corroboration. Experiments show naive posterior coverage collapsing from 0.940 to 0.263 as report count rises on a single evidence root, and the author argues that aggregation should track evidential ancestry rather than agent or report count.
Why it matters here: Reframes Sybil resistance for ERC-8004 style feedback and validation: many attestations from agents sharing a base model or data source should not be counted as independent evidence.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{bara2026epistemic,
title = {Epistemic Sybil Resistance: Multiplying AI Agents Without Multiplying Evidence},
author = {Marc Bara},
year = {2026},
eprint = {2609.01873},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2609.01873},
note = {arXiv preprint}
}
A positioning paper for InterSAGE, a four-layer trust protocol suite (persistent identity, discovery, trust negotiation and accountability) meant to run alongside MCP, A2A, ANP and AG-UI. It binds agent identity cards to developer, code and operator, and compares the design with more than 50 related efforts.
Why it matters here: Another proposal for the identity and accountability layer that ERC-8004 provides on chain; its survey table is a useful map of competing agent identity designs.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{zou2026intersage,
title = {{InterSAGE: The Secure and Verifiable Interoperability Protocol for An Internet of Agents}},
author = {Zhenhua Zou and Sheng Guo and Qiuyang Zhan and Lepeng Zhao and Shuo Li and Zhuotao Liu},
year = {2026},
eprint = {2608.13030},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2608.13030}
}
A credentialing protocol that binds measured quality and cost per solved task to a signed record of agent configuration, task domain, evaluation budget and evidence, links past outcomes to the same identity as reputation, and lets buyers verify the records. Evaluations show that agents with similar success differ in cost and that comparisons depend on budget; a complementary analysis prices the deposits and fees needed to manipulate reputation under a stated Sybil model.
Why it matters here: A concrete alternative design for the certification and feedback roles that ERC-8004's Validation and Reputation registries describe, with explicit Sybil cost accounting.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{drew2026legit,
title = {LEGIT: Credentialing Protocol for Trustworthy AI Agent Marketplaces},
author = {Steve Drew and Jiayu Zhou},
year = {2026},
eprint = {2609.21325},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2609.21325},
note = {arXiv preprint}
}
Unifies persistent identity, scoped delegation, peer trust, discovery and payment over Nostr relays with three custom event kinds (identity declarations with BIP340 Schnorr signatures and pre-rotation commitments, scoped delegation chains that narrow at each hop, and peer attestations forming a Sybil-deterrent trust graph), with Lightning L402 payments bound to agent identity. A Python prototype shows sub-millisecond offline verification and 157 ms median L402 settlement on regtest. The arXiv comment reports acceptance at AGENTICS 2026 (IJCCI 2026) for Springer CCIS; no publisher record confirms it yet.
Why it matters here: A registry-free alternative to erc-8004 identity and reputation, paired with L402, the Lightning cousin of x402.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{larsen2026nostragent,
title = {{NostrAgent: A Decentralized Identity and Delegation Architecture for Sovereign Agentic Systems}},
author = {Oliver Aleksander Larsen and Mahyar Tourchi Moghaddam},
year = {2026},
eprint = {2609.22944},
archivePrefix = {arXiv},
primaryClass = {cs.SE},
url = {https://arxiv.org/abs/2609.22944}
}
Presents Cairn, a community reputation platform in which agents query the collective opinion of a data source, service or tool before use and submit evidence-backed ratings afterward, aggregated by a time-decayed Beta model with confidence shrinkage and searchable by reviewer rationale. The engine is evaluated under lying, collusion and camouflage, and in a production case study rating heterogeneous agents.
Why it matters here: An off-chain alternative to ERC-8004's registry for the same question (should an agent trust this resource), useful as a design comparison for aggregation and adversarial robustness. ERC-8004: Trustless Agents: A design view of reputation as shared memory for agents.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{chard2026cairn,
title = {Reputation as Community Memory for the Agentic Web},
author = {Ryan Chard and Gus Ellerm and Alexander Brace and Alok Kamatar and Suman Raj and Ian Foster and Kyle Chard},
year = {2026},
eprint = {2609.19502},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2609.19502},
note = {arXiv preprint}
}
Builds a tool that removes redundant checks from zero-knowledge machine learning circuits only when the rest of the circuit still provably enforces them, so the smaller circuit cannot accept forged proofs. On circuits from ezkl and zkml with up to 25.3 million constraints it removes up to 48.7% of constraints and cuts prover time by up to 72.8%.
Why it matters here: zkML proofs are only as good as their circuits; for ERC-8004 validators that accept zkML evidence, under-constrained circuits are a real forgery risk and proving cost is the main adoption barrier, and this work addresses both.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{xue2026zkmldebloat,
title = {{Sound Debloating of Redundant Checks in Zero-Knowledge Machine-Learning Circuits}},
author = {Zhantong Xue and Pingchuan Ma and Zhaoyu Wang and Yuguang Zhou and Huaijin Wang and Shuai Wang},
year = {2026},
eprint = {2609.10149},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.10149}
}
Proposes TessIndex, an agent identity system that records compact identity, ownership and verification commitments on a blockchain while keeping discovery, commerce and reputation metadata on servers, and replaces self-declared capabilities with predicate-based capability proofs. It comes from the same authors as TessPay.
Why it matters here: A close design alternative to the ERC-8004 identity and validation registries, with the same split between on-chain anchors and off-chain metadata.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{goenka2026tessindex,
title = {{TessIndex: Capability Verified Identity System for the Agent Economy}},
author = {Mehul Goenka and Tejas Pathak and Siddharth Asthana},
year = {2026},
eprint = {2608.21942},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2608.21942}
}
Introduces TessPay, a two-plane verify-then-pay infrastructure for agentic commerce: agents are anchored in a canonical registry and user intent is captured as verifiable mandates, funds are escrowed during execution while the agent produces cryptographic evidence (TLS Notary, TEE) for a Proof of Task Execution, settlement releases funds only when the evidence satisfies verification predicates, and a tamper-evident audit trail supports disputes.
Why it matters here: Combines the mandate idea of ap2 with the registry and validation functions of erc-8004 into one escrow design; a useful comparison for how the protocols split those functions.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{goenka2026tesspay,
title = {{TessPay: Verify-then-Pay Infrastructure for Trusted Agentic Commerce}},
author = {Mehul Goenka and Tejas Pathak and Siddharth Asthana},
year = {2026},
eprint = {2602.00213},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2602.00213}
}
Describes the NANDA index architecture in which a lean index resolves to cryptographically verifiable AgentFacts supporting multi-endpoint routing, sub-second revocation and key rotation, schema-validated capability assertions and privacy-preserving discovery, with a CRDT-based update protocol and prototype resolvers.
Why it matters here: Another discovery and identity layer competing with erc-8004 registries; relevant to how agents find x402-priced services.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{raskar2025nanda,
title = {{Beyond DNS: Unlocking the Internet of AI Agents via the NANDA Index and Verified AgentFacts}},
author = {Ramesh Raskar and Pradyumna Chari and John Zinky and Mahesh Lambe and Jared James Grogan and Sichao Wang and Rajesh Ranjan and Rekha Singhal and Shailja Gupta and Robert Lincourt and Raghu Bala and Aditi Joshi and Abhishek Singh and Ayush Chopra and Dimitris Stripelis and Bhuwan B and Sumit Kumar and Maria Gorskikh},
year = {2025},
eprint = {2507.14263},
archivePrefix = {arXiv},
primaryClass = {cs.NI},
url = {https://arxiv.org/abs/2507.14263}
}
Presents the LOKA Protocol, a layered architecture with a Universal Agent Identity Layer for decentralized verifiable identity, intent-centric communication, and a Decentralized Ethical Consensus Protocol, anchored in DIDs, Verifiable Credentials and post-quantum cryptography.
Why it matters here: An identity and governance layer proposal that overlaps with the erc-8004 identity function; mostly conceptual.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{ranjan2025loka,
title = {{LOKA Protocol: A Decentralized Framework for Trustworthy and Ethical AI Agent Ecosystems}},
author = {Rajesh Ranjan and Shailja Gupta and Surya Narayan Singh},
year = {2025},
eprint = {2504.10915},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2504.10915}
}
Proposes a blockchain-based framework for AI-initiated payments that uses DIDs and verifiable credentials for agent identity, on-chain intent proofs recording user authorization, zero-knowledge proofs for private policy compliance and TEE attestations of agent execution, with a hybrid on-chain and off-chain audit trail; the evaluation is qualitative.
Why it matters here: An early sketch of the intent-binding and identity-attestation ideas that ap2 mandates and erc-8004 validation later formalize.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{acharya2025securepayments,
title = {{Secure Autonomous Agent Payments: Verifying Authenticity and Intent in a Trustless Environment}},
author = {Vivek Acharya},
year = {2025},
eprint = {2511.15712},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2511.15712}
}
Proposes opML, which runs machine learning inference for blockchains under an optimistic model: results are accepted unless a challenger wins an interactive fraud-proof game, similar to optimistic rollups. The authors argue this is far cheaper than zero-knowledge proofs and can serve large models on ordinary hardware.
Why it matters here: Shows the crypto-economic alternative to zkML for ERC-8004 validation, where validators stake on a result and disputes, not proofs, keep inference honest. ERC-8004: Trustless Agents: Optimistic re-execution, close to stake-secured validation.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{conway2024opml,
title = {{opML: Optimistic Machine Learning on Blockchain}},
author = {KD Conway and Cathie So and Xiaohang Yu and Kartin Wong},
year = {2024},
eprint = {2401.17555},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2401.17555}
}
Presents zkLLM, a zero-knowledge proof system specialized for large language model inference, with a parallel lookup argument for non-arithmetic tensor operations and a dedicated proof for attention. It lets a model owner prove that an output came from committed parameters without revealing them.
Why it matters here: ERC-8004 leaves room for validators that check agent work with cryptographic proofs; zkLLM shows what a zkML validation response could attest to and how costly that proof is for transformer models. ERC-8004: Trustless Agents: zkML proofs, one of the validation methods the text names.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{sun2024zkllm,
title = {{zkLLM: Zero Knowledge Proofs for Large Language Models}},
author = {Haochen Sun and Jason Li and Hongyang Zhang},
year = {2024},
booktitle = {Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security},
pages = {4405--4419},
publisher = {ACM},
doi = {10.1145/3658644.3670334},
url = {https://doi.org/10.1145/3658644.3670334}
}
Builds the first ZK-SNARK proof of correct inference for a full-resolution ImageNet model, so a client can check after the fact that a machine learning service ran the promised model. It also sketches protocols that use these proofs to verify model accuracy and to pay for verified predictions.
Why it matters here: An early, concrete answer to the question an ERC-8004 validator asks: did the service actually run the model it claimed, and can that be checked without trusting the server. ERC-8004: Trustless Agents: Zero-knowledge inference, another validation path.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{kang2022zkdnn,
title = {{Scaling up Trustless DNN Inference with Zero-Knowledge Proofs}},
author = {Daniel Kang and Tatsunori Hashimoto and Ion Stoica and Yi Sun},
year = {2022},
eprint = {2210.08674},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2210.08674}
}
Surveys systems in which parties rate each other after transactions and aggregated ratings guide future decisions, describing them as collaborative sanctioning systems that also create an incentive for good behavior. It reviews commercial and proposed designs, analyzes trends and proposes a research agenda.
Why it matters here: The reference taxonomy for reputation computation that ERC-8004 reputation clients and off-chain scorers draw on, and a reminder that the field predates agents by two decades. ERC-8004: Trustless Agents: Survey of trust and reputation systems.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@article{josang2007survey,
title = {A Survey of Trust and Reputation Systems for Online Service Provision},
author = {Audun Jøsang and Roslan Ismail and Colin Boyd},
year = {2007},
journal = {Decision Support Systems},
volume = {43},
number = {2},
pages = {618-644},
doi = {10.1016/j.dss.2005.05.019},
url = {https://folk.universitetetioslo.no/josang/papers/JIB2007-DSS.pdf}
}
Sepandar D. Kamvar, Mario T. Schlosser, Hector Garcia-Molina. 2003. WWW 2003 (12th International World Wide Web Conference). Peer reviewedDOI 10.1145/775152.775242 (external link)
Assigns each peer a single global trust value computed by power iteration over local trust ratings, in a distributed and secure way, so peers can avoid downloading inauthentic files. Simulations show the system isolates malicious peers even when they collude.
Why it matters here: The standard reference for turning pairwise feedback, such as the entries ERC-8004's Reputation Registry stores, into a global score, and for the collusion cases any such aggregator must resist.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{kamvar2003eigentrust,
title = {The EigenTrust Algorithm for Reputation Management in P2P Networks},
author = {Sepandar D. Kamvar and Mario T. Schlosser and Hector Garcia-Molina},
year = {2003},
booktitle = {Proceedings of the Twelfth International Conference on World Wide Web (WWW '03)},
publisher = {ACM},
doi = {10.1145/775152.775242},
url = {https://doi.org/10.1145/775152.775242}
}
John R. Douceur. 2002. IPTPS 2002 (1st International Workshop on Peer-to-Peer Systems), Lecture Notes in Computer Science, Springer, pp. 251-260. Peer reviewedDOI 10.1007/3-540-45748-8_24 (external link)
Shows that in a large peer-to-peer system without a logically centralized authority, a single faulty entity can present many identities and defeat the redundancy the system relies on, and that such Sybil attacks remain possible except under unrealistic assumptions of resource parity and coordination among entities.
Why it matters here: Defines the attack every permissionless agent registry inherits: ERC-8004 identities and feedback without a trusted issuer are exposed to it, which is why TAP and the card networks keep a certifying authority in the loop. ERC-8004: Trustless Agents: The original Sybil attack result behind the reviewer-filter design.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{douceur2002sybil,
title = {The Sybil Attack},
author = {John R. Douceur},
year = {2002},
booktitle = {Peer-to-Peer Systems: First International Workshop (IPTPS 2002)},
series = {Lecture Notes in Computer Science},
publisher = {Springer},
pages = {251-260},
doi = {10.1007/3-540-45748-8_24},
url = {https://www.microsoft.com/en-us/research/publication/the-sybil-attack/}
}
Presents a fraud taxonomy for agents with spend authority organized by five observation levels, a benchmark of twenty fraud classes built from production aggregates (1,647 service operations and 1,068 settlements), and gordonguard, an open-source detector stack. Calibrated detectors flag 6.5 percent of clean traffic and leave eight classes at chance, and a median payment of $0.007 makes one human review 143 times costlier than the payment it checks.
Why it matters here: Targets fraud on machine-to-machine rails such as x402 and MPP, where a counterparty can be exactly who it claims to be and still overcharge, and shows why identity checks alone, including ERC-8004 identity, do not stop value loss.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{srivastava2026acb,
title = {Agentic Commerce Bench: Measuring Fraud Detection for Agents That Spend Money},
author = {Ankit Srivastava and Debjyoti Paul},
year = {2026},
eprint = {2609.35886},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.35886},
note = {arXiv preprint}
}
Presents a conceptual framework and prototype in which each agent holds a ledger-anchored W3C Decentralized Identifier and third-party-issued Verifiable Credentials, so agents can authenticate and establish cross-domain trust at the start of a dialogue. Evaluation shows feasibility but also limits when the agent's LLM alone controls the security procedures. The arXiv preprint is dated 2025; the ICAART proceedings appeared in 2026.
Why it matters here: Peer-reviewed DID and VC approach to agent identity that contrasts with the on-chain registry model of erc-8004 and the network-issued credentials of visa-tap. ERC-8004: Trustless Agents: DID and verifiable credential alternative to registry identity.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{garzon2026didvc,
title = {{AI Agents with Decentralized Identifiers and Verifiable Credentials}},
author = {Sandro Rodriguez Garzon and Awid Vaziry and Enis Mert Kuzu and Dennis Enrique Gehrmann and Buse Varkan and Alexander Gaballa and Axel Küpper},
year = {2026},
booktitle = {Proceedings of the 18th International Conference on Agents and Artificial Intelligence (ICAART 2026), Volume 1},
publisher = {SCITEPRESS},
pages = {252-259},
doi = {10.5220/0014234400004052},
eprint = {2511.02841},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2511.02841}
}
Develops Authority-Inference Separation, an architecture in which an agent's proposed financial action gains temporary executable authority only after a deterministic control plane validates registered identity, accountable ownership, mandate lineage, policy version and exact economic semantics, with blockchain enforcing granted authority and recording evidence. A 48-fixture prototype rejected all 36 synthetic authorization attacks, and a test of 1,700 Base transactions tied to public x402 facilitator addresses shows that public ledgers evidence settlement but not mandate, accountability or delivery.
Why it matters here: Uses live x402 facilitator traffic to show what on-chain data cannot prove, and frames mandate lineage in terms that map onto ap2 mandates and erc-8004 identity.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{gong2026ais,
title = {{Authority-Inference Separation in Agentic Finance: First-Line Control, Blockchain Enforcement, and Replayable Assurance}},
author = {Hui Gong and Michail Samawi and Francesca Medda},
year = {2026},
eprint = {2608.30519},
archivePrefix = {arXiv},
primaryClass = {q-fin.GN},
url = {https://arxiv.org/abs/2608.30519}
}
A simulated consumer-to-consumer marketplace with 100 agents, eBay-derived inventories and reputation-based trust, scoring six failure types across five transaction stages over 357,608 model calls. All five tested models promise the same item to multiple buyers, and under adversarial instructions the share of committed sales completed despite unavailable items or overstated condition rises from 15.4 to 33.4 percent, with most extra earnings coming from goods the sellers never held.
Why it matters here: Tests whether reputation can hold a decentralized agent market together, the premise behind ERC-8004's Reputation Registry, and measures delegation failures that ACP and UCP style checkouts would inherit from the agents using them.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{wang2026bazaarbench,
title = {BazaarBench: Delegation Safety in Decentralized C2C Marketplaces Run by LLM Agents},
author = {Ziyan Wang and Shuqing Shi and James Oldfield and Samuele Marro and Jialin Yu and Philip Torr and Yali Du and Adel Bibi},
year = {2026},
eprint = {2610.06748},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2610.06748},
note = {arXiv preprint}
}
Hypothesizes that agent authorization can be expressed as a cryptographically verifiable relation binding an agent principal, a concrete request, an execution context and policy satisfaction while keeping private attributes confidential, defines candidate properties (authorization soundness, principal, request and policy binding, replay resistance), and provides a Groth16 zk-SNARK proof of concept. Full author names are taken from the Frontiers DOI record; arXiv lists initials.
Why it matters here: Peer-reviewed formalization of the identity, request and execution binding that ap2 mandates approximate and that erc-8004 validation could attest.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@article{llambmorillas2026cva,
title = {{Cryptographically verifiable authorization for autonomous AI agents: a falsifiable hypothesis and proof of concept}},
author = {Mar Llambí-Morillas and Daniel Fernández-Fernández},
year = {2026},
journal = {Frontiers in Computer Science},
volume = {8},
pages = {1966725},
doi = {10.3389/fcomp.2026.1966725},
eprint = {2607.21325},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2607.21325}
}
Analyzes 2,583 inter-agent emails from twenty one-year runs of Vending-Bench Arena across 13 frontier models and labels 12.6 percent as misaligned (false factual claims, manipulation, collusion or threats). Misalignment appears in every run and in 74.7 percent of agent-runs, is reciprocal, rises under inventory scarcity, and is not predicted by model capability rank.
Why it matters here: Agent-to-agent commerce protocols assume counterparties negotiate in good faith; this measurement shows deceptive speech acts emerging without adversarial prompting, which bears on reputation layers in ERC-8004 and on merchant-agent trust in ACP and UCP.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{li2026misaligned,
title = {Emergent Misaligned Communication in Long-Horizon Multi-Agent LLM Commerce},
author = {Zeyuan Li and Lukas Petersson and Alessandro Acquisti and Michiel A. Bakker},
year = {2026},
eprint = {2608.14825},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2608.14825},
note = {arXiv preprint}
}
Systematizes security and economic requirements across the lifecycle of an agent task into 17 property families over six stages, examines 12 systems and standards, five mechanism families and four classical baselines, and introduces guarantee closure, a criterion for whether guarantees made at one stage still constrain later decisions. Experiments over 840 matched executions and an 11,648-case check expose recurring gaps between verification and settlement.
Why it matters here: Relevant to stacks that chain ERC-8004 identity and validation with x402 payment: it shows how an escrow can release funds on an approval that carries little evidence the work was done. Which 12 systems are covered was not confirmed from the abstract alone.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{sun2026sokeconomic,
title = {SoK: Decentralized Agent Economic Infrastructure},
author = {Rui Sun and Xihan Xiong and Qin Wang and Fei Gao and Zelin Li and Zehua Cheng and Jiahao Sun and Zhipeng Wang},
year = {2026},
eprint = {2610.01756},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2610.01756},
note = {arXiv preprint}
}
Argues that OAuth, OIDC and SAML style IAM is inadequate for ephemeral, interdependent AI agents and proposes a framework built on verifiable agent identities using DIDs and VCs, an Agent Naming Service for discovery, fine-grained dynamic access control, a global session and policy enforcement layer for revocation, and zero-knowledge proofs for selective disclosure.
Why it matters here: A frequently cited zero-trust identity blueprint that overlaps with the discovery and identity roles of erc-8004 and the agent recognition goals of visa-tap. Visa Trusted Agent Protocol: A decentralized alternative to a network-controlled agent identity.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{huang2025zerotrust,
title = {{A Novel Zero-Trust Identity Framework for Agentic AI: Decentralized Authentication and Fine-Grained Access Control}},
author = {Ken Huang and Vineeth Sai Narajala and John Yeoh and Jason Ross and Ramesh Raskar and Youssef Harkati and Jerry Huang and Idan Habler and Chris Hughes},
year = {2025},
eprint = {2505.19301},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2505.19301}
}
Proposes the Agent Name Service, a DNS-inspired, protocol-agnostic registry that uses PKI certificates for verifiable agent identity, with a registration and renewal lifecycle, capability-aware naming and resolution, and a protocol adapter layer for A2A, MCP and others, accompanied by JSON Schema definitions and a threat analysis.
Why it matters here: A PKI-based alternative to the erc-8004 Identity Registry for agent discovery.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{huang2025ans,
title = {{Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability}},
author = {Ken Huang and Vineeth Sai Narajala and Idan Habler and Akram Sheriff},
year = {2025},
eprint = {2505.10609},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2505.10609}
}
Defines context manipulation (input channels, memory modules and external data feeds) as the attack surface of blockchain agents, shows on ElizaOS that injected prompts or falsified memories trigger unauthorized asset transfers, and introduces CrAIBench with over 150 Web3 tasks and over 500 attack cases. Memory injection proved more effective than prompt injection, and prompt-injection detectors offered little protection.
Why it matters here: The closest existing study of agents that hold crypto spending keys, the deployment model for x402 clients and ERC-8004 registered agents; a poisoned memory can drain a wallet that no protocol-level check would stop.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{patlan2025memories,
title = {Real AI Agents with Fake Memories: Fatal Context Manipulation Attacks on Web3 Agents},
author = {Atharv Singh Patlan and Peiyao Sheng and S. Ashwin Hebbar and Prateek Mittal and Pramod Viswanath},
year = {2025},
eprint = {2503.16248},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2503.16248},
note = {arXiv preprint}
}
Introduces Verifiable Execution Traces, a compositional framework for host-independent authentication of agent outputs built on an Agent Identity Document that specifies configuration and proof systems, supporting trusted hardware, succinct proofs and notarized TLS transcripts; for secret-bearing API calls Web Proofs add under 3x overhead, and a verifiable trading agent is deployed as a case study.
Why it matters here: Provides the kind of attestation evidence that the erc-8004 Validation Registry is designed to record and that TessPay-style escrow would consume.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{grigor2025vet,
title = {{VET Your Agent: Towards Host-Independent Autonomy via Verifiable Execution Traces}},
author = {Artem Grigor and Christian Schroeder de Witt and Simon Birnbach and Ivan Martinovic},
year = {2025},
eprint = {2512.15892},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2512.15892}
}
Victor Costan, Srinivas Devadas. 2016. Not peer reviewed
A long technical analysis of Intel Software Guard Extensions built from Intel papers, manuals, a tutorial and patents. It explains enclave creation, memory protection and remote attestation, and it catalogs the side-channel and design weaknesses that limit the trust these guarantees deserve.
Why it matters here: TEE attestation is one of the validation methods ERC-8004 anticipates; this paper is the standard reference for what an SGX attestation proves and where it does not hold. ERC-8004: Trustless Agents: Background on TEE attestation for validators.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{costan2016sgx,
title = {{Intel SGX Explained}},
author = {Victor Costan and Srinivas Devadas},
year = {2016},
howpublished = {Cryptology ePrint Archive, Paper 2016/086},
url = {https://eprint.iacr.org/2016/086}
}
Replaces centralized orchestration with AgentLance, a repeated labor market in which agents bid on tasks using private costs, an allocator picks winners from bids and public reputation records, a VCG-style rule sets payments, and winners can subcontract through the same mechanism. It outperforms single-model, centralized and market baselines, and the authors show a centralized LLM allocator can be swayed by a single inserted preference.
Why it matters here: Demonstrates reputation records and payments working together to allocate agent labor, which is the combination ERC-8004 (reputation) and x402 (payment) aim to provide on open rails.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{liu2026agentlance,
title = {Markets, Not Planners: Decentralized Orchestration of LLM Agents with Private Information},
author = {Xiao Liu and Haoyang Li and Songwei Li and Hongbo Fang and Fengli Xu and Feng Shi and James Evans},
year = {2026},
eprint = {2608.23867},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2608.23867},
note = {arXiv preprint}
}
LLM merchant agents fabricate product attributes in most listings under competitive pressure even when told to be honest. CARP, a reputation-penalty mechanism with a deadband that forgives complaint noise and a state-dependent severity, suppresses low-rated liars without any product-level ground truth, and SPARC makes the penalty behaviorally binding so merchants restrain themselves once lying costs sales.
Why it matters here: Shows how a platform-level reputation penalty can govern seller agents behind ACP or UCP storefronts using only noisy complaints, a design that could sit on top of ERC-8004 feedback entries.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{yang2026honesty,
title = {Paying for Honesty Without Knowing the Truth: Reputation-Penalty Design for LLM Marketplace Agents},
author = {Mingdai Yang and Shicheng Fan and Kejing Yu and Duohao Wang and Li Sun and Hao Peng and Philip S. Yu and Zhiwei Liu},
year = {2026},
eprint = {2607.28330},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2607.28330},
note = {arXiv preprint}
}
Shows that the usual one-round slashing argument for restaking-based verifiable LLM inference overstates security when a provider serves many queries under the same stake, because proportional slashing shrinks future penalties while cheating savings recur. It proposes history-dependent challenges, reputation-weighted slashing and stake vesting, and finds that surveyed deployed parameters admit profitable repeated deviations.
Why it matters here: ERC-8004 lists stake-secured re-execution as a validation option; this paper shows how to size stakes and audits so such validators stay honest over many jobs, not only one.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{shang2026restaking,
title = {{Repeated-Game Security for Restaking-Based Verifiable Inference}},
author = {Zhenhang Shang and Yingzhe Yu and Kani Chen},
year = {2026},
eprint = {2608.09055},
archivePrefix = {arXiv},
primaryClass = {cs.GT},
url = {https://arxiv.org/abs/2608.09055}
}
A survey chapter for economists on how AI agents that plan and act over long horizons with little oversight might interact with people and with each other, reshape markets and organizations, and what institutions would be needed for such markets to work.
Why it matters here: Frames the institutional questions (identity, liability, enforcement) that ERC-8004 registries and AP2 mandates try to answer with technical artifacts.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{hadfield2025economy,
title = {An Economy of AI Agents},
author = {Gillian K. Hadfield and Andrew Koh},
year = {2025},
eprint = {2509.01063},
archivePrefix = {arXiv},
primaryClass = {econ.GN},
url = {https://arxiv.org/abs/2509.01063},
note = {arXiv preprint}
}
Proposes the sandbox economy as a lens on the emerging layer in which AI agents transact at machine speed, classifying it by origin (emergent or intentional) and by permeability to the human economy. The authors discuss auctions for resource allocation, mission economies, and the identity, trust and oversight infrastructure needed to steer such markets, warning that the current path leads to a large and highly permeable agent economy with systemic risk.
Why it matters here: Names the infrastructure gaps (verifiable identity, reputation, controls on permeability) that ERC-8004 and x402 are being built to fill, and gives the policy vocabulary for discussing them.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{tomasev2025virtual,
title = {Virtual Agent Economies},
author = {Nenad Tomasev and Matija Franklin and Joel Z. Leibo and Julian Jacobs and William A. Cunningham and Iason Gabriel and Simon Osindero},
year = {2025},
eprint = {2509.10147},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2509.10147},
note = {arXiv preprint}
}
Paul Resnick, Ko Kuwabara, Richard Zeckhauser and others. 2000. Communications of the ACM, vol. 43, no. 12, pp. 45-48. Peer reviewedDOI 10.1145/355112.355122 (external link)
The classic statement of the problem: the Internet lets strangers transact at a scale where personal references and community standing no longer work, so reputation systems collect, aggregate and distribute feedback about past behavior. The authors set out what such systems must do and the difficulties of eliciting honest feedback and of cheap identity changes.
Why it matters here: ERC-8004's Reputation Registry is a reputation system in Resnick's sense, and the paper's warning about cheap identity changes is exactly the Sybil feedback dispute recorded against it.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@article{resnick2000reputation,
title = {Reputation Systems},
author = {Paul Resnick and Ko Kuwabara and Richard Zeckhauser and Eric Friedman},
year = {2000},
journal = {Communications of the ACM},
volume = {43},
number = {12},
pages = {45-48},
doi = {10.1145/355112.355122},
url = {https://doi.org/10.1145/355112.355122}
}
Documents a national agent-identity system in China, scheduled for public launch in Q3 2026, in which an agent is bound to a verified legal principal that is not disclosed to business-layer participants and can be re-identified only by compelling two separate government agencies, a mechanism the authors call split-knowledge binding and describe as institutional rather than cryptographic. The paper is a pre-launch v1 and promises post-launch measurements.
Why it matters here: A state-run alternative to erc-8004 style permissionless identity and to network-issued agent identity in visa-tap and mastercard-agent-pay; status is announced, not yet measured.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{he2026accountable,
title = {{Accountable yet Anonymous AI Agents - Split-Knowledge Binding in National Agent-Identity Layer in China}},
author = {Yifan He and Zhiguang Shan and Le Luo and Wei Wang},
year = {2026},
eprint = {2607.23207},
archivePrefix = {arXiv},
primaryClass = {cs.CY},
url = {https://arxiv.org/abs/2607.23207}
}
Defines AI identity as the continuous relationship between what an agent is declared to be and what it is observed to do, compares human and AI identity on substrate, persistence, verifiability and legal standing, evaluates current technical and regulatory documents against agent identity requirements, and identifies five structural gaps including recursive delegation accountability and agent identity integrity.
Why it matters here: A gap analysis that the identity claims in visa-tap, erc-8004 and ap2 can be checked against. Visa Trusted Agent Protocol: Survey of agent identity standards and gaps.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{otsuka2026aiidentity,
title = {{AI Identity: Standards, Gaps, and Research Directions for AI Agents}},
author = {Takumi Otsuka and Kentaroh Toyoda and Alex Leung},
year = {2026},
eprint = {2604.23280},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2604.23280}
}
Designs Recourse, a set of smart contracts that binds each agent action to its scope, recovery plan, evidence, payout and collateral, so residual harm from a permitted action that fails can be settled through an optimistic oracle or arbitration. The authors deploy it on Base Sepolia and report less uncompensated harm than authorization-only baselines; the arXiv comment says it was accepted at IEEE BCCA 2026, not yet confirmed in proceedings.
Why it matters here: Adds the after-the-fact remedy that payment and identity protocols lack; it pairs naturally with ERC-8004 reputation and on-chain settlement used by x402.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{bindschaedler2026recourse,
title = {{Bonded Recourse for Smart-Contract Settlement of Compensable Agent Side Effects}},
author = {Laurent Bindschaedler and Quentin Botha and Christoph Siebenbrunner},
year = {2026},
eprint = {2609.01939},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.01939}
}
Proposes a framework in which IDs are ascribed to instances of AI systems, such as a particular agent session, with associated information accessible to parties that interact with them, and argues that demand for IDs is strongest where systems can make financial transactions or contact real people. The arXiv comment reports acceptance at the RegML workshop at NeurIPS 2024; no publisher record confirms it, so no venue is shown.
Why it matters here: Direct conceptual ancestor of per-agent identity in visa-tap, erc-8004 registrations and the agent credentials in ap2 mandates. Visa Trusted Agent Protocol: Agent identifiers, the general problem TAP solves for one network.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{chan2024ids,
title = {{IDs for AI Systems}},
author = {Alan Chan and Noam Kolt and Peter Wills and Usman Anwar and Christian Schroeder de Witt and Nitarshan Rajkumar and Lewis Hammond and David Krueger and Lennart Heim and Markus Anderljung},
year = {2024},
eprint = {2406.12137},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2406.12137}
}
Assesses three measures for visibility into AI agents, agent identifiers, real-time monitoring and activity logging, outlines implementations that vary in intrusiveness and informativeness, and analyzes how they apply across centralized and decentralized deployments, including implications for privacy and concentration of power.
Why it matters here: Foundation for the agent identifier idea that visa-tap, erc-8004 and ap2 each implement in their own way.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{chan2024visibility,
title = {{Visibility into AI Agents}},
author = {Alan Chan and Carson Ezell and Max Kaufmann and Kevin Wei and Lewis Hammond and Herbie Bradley and Emma Bluemke and Nitarshan Rajkumar and David Krueger and Noam Kolt and Lennart Heim and Markus Anderljung},
year = {2024},
booktitle = {Proceedings of the 2024 ACM Conference on Fairness, Accountability, and Transparency (FAccT '24)},
publisher = {ACM},
pages = {958-973},
doi = {10.1145/3630106.3658948},
eprint = {2401.13138},
archivePrefix = {arXiv},
primaryClass = {cs.CY},
url = {https://arxiv.org/abs/2401.13138}
}
Grey literature: central banks, standards drafts and white papers
Global Legal Entity Identifier Foundation (GLEIF). 2026. GLEIF Working Paper Series. Not peer reviewed
A working paper (cover dated September 2026, written by contributors from GLEIF, Curvy Protocol, zERC20, Terminal 3 and an independent expert) arguing that existing law can allocate liability for agent payments but practical proof of delegated authority is missing. It proposes Agent Mandate Credentials anchored in the verifiable LEI to show which organization stands behind an agent and what it may do.
Why it matters here: Offers an organizational-identity answer to the "who is behind this agent" question that ERC-8004 registries, Visa TAP keys and Agent Pay tokens each answer differently.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@techreport{gleif2026agenticpayments,
title = {{Agentic AI in Payments: Establishing Interoperable Trust and Control}},
author = {{Global Legal Entity Identifier Foundation (GLEIF)}},
year = {2026},
institution = {Global Legal Entity Identifier Foundation},
type = {GLEIF Working Paper Series},
month = {sep},
url = {https://www.gleif.org/organizational-identity/research-publications/2026-08-13_agentic_ai_in_payments_v1.0-1.pdf}
}
ERC-8004 makes agent data public and comparable; it does not make it true. The text admits Sybil feedback is possible and offers one defense, filtering by trusted reviewers. Since feedbackAuth was removed, anyone except the owner and operators can rate any agent, and proofOfPayment is never checked on-chain. Files over HTTPS can change silently. Wallet binding is signed but has no nonce. One externally owned account can upgrade all registries on Ethereum and Base (2026-10-11). The Validation Registry is specified, not officially deployed, and its reference code lets a validator lower a pass. No CVE, advisory or named audit report was found.
STRIDE threats (12)
STRIDE
Threat
Spec mitigation
Implementer notes
S Spoofing
Sybil reviewers inflate reputationOne operator funds many fresh addresses and rates its own or a client's agent. Since feedbackAuth was removed, nothing ties feedback to a real interaction. Source [1, 8, 19, 21]Preconditions: Gas is cheap on the target chain; Readers use unfiltered data or a naive reviewer list.Impact: Fake agents rank above real ones; arXiv:2606.26028 measured coordinated Sybil behavior among 59.2% to 90.6% of reviewers (data to 2026-05-13).
Partly
getSummary refuses an empty reviewer list, but choosing reviewers is your job. Weight feedback that carries a verifiable proofOfPayment and discount clusters that rate many agents at once.
S Spoofing
Owner rates its own agent from a fresh addressThe self-feedback check covers the owner and approved operators only. A new address controlled by the same person passes. Source [1, 8]Preconditions: The owner controls a second funded address.Impact: Self-promotion that looks like independent feedback.
Partly
Treat addresses without history or payment proof as untrusted reviewers.
S Spoofing
Wallet signature replay within its windowThe AgentWalletSet typed data has no nonce. Inside its deadline the same signature can be submitted again for the same agent, wallet and owner, but only by the owner or an approved operator, because setAgentWallet checks the caller. Source [5]Preconditions: The owner or an approved operator resubmits the old signature before the deadline, for example after another operator called unsetAgentWallet.Impact: A wallet the owner just removed can be set again for up to 5 minutes.
Partly
Keep deadlines short; check getAgentWallet after any wallet change; sign with fresh deadlines.
S Spoofing
Stale payee after a transferA transfer clears agentWallet, but payers that cached the old address may keep paying it, while the agentId and its feedback now belong to someone else. Source [1, 5]Preconditions: A client caches agentWallet; The token is sold or moved.Impact: Payments go to the previous owner; reputation carries over to a new operator.
Partly
Read getAgentWallet right before paying; watch Transfer events; discount feedback older than the last transfer.
S Spoofing
Capability claims not guaranteedThe text ties a file to an on-chain agent but says it cannot guarantee that advertised capabilities are functional and non-malicious. Source [1, 18]Preconditions: A client trusts the services list.Impact: Clients call malicious or dead endpoints; the census found at least 13,210 of 505,635 ids declaring an http(s) endpoint, with 231,014 files not fetched (2026-09-26).
Partly
Use the /.well-known domain proof, probe endpoints, and require trust models beyond discovery for valuable tasks.
T Tampering
Registration file changed after reviewAn HTTPS agentURI can serve different content at any time without an on-chain event, for example a new endpoint or a new payee hint. Source [1, 5]Preconditions: The file is served over HTTPS, not IPFS or a data URI.Impact: Clients act on capabilities or endpoints that changed after they vetted the agent.
Partly
Prefer content-addressed URIs; cache and hash the file you vetted; re-check before each high-value call.
T Tampering
Rogue validator lowers a passvalidationResponse can be called again for the same request, and in the reference code a later answer can lower an earlier value. Source [9, 29, 30]Preconditions: A Validation Registry is in use (none is officially deployed).Impact: A validator can withdraw a pass after the requester relied on it.
Left to implementers
Read the response history from events, not only the latest value. Issue 28 and PR 51 propose a monotonic rule; both were open on 2026-10-11.
R Repudiation
Proof of payment is never checkedproofOfPayment lives in the off-chain feedback file. The registry stores no payment data and never verifies the file, its hash or the transaction. Source [1, 8]Preconditions: Readers trust the presence of proofOfPayment without checking the chain.Impact: Fabricated payment proofs make Sybil feedback look grounded.
Left to implementers
Fetch the file, compare feedbackHash, and look up txHash on the named chain for the amount and payee before giving weight.
I Information disclosure
Personal data made permanentFeedback events, hashes and URIs cannot be deleted from the chain. Clients or owners who put personal data in files or tags make it public and permanent. Source [1]Preconditions: Personal data in tags, endpoints or public files.Impact: Privacy harm and possible conflict with erasure rights.
Left to implementers
Keep personal data out of tags and files; use content you can stop serving, but remember the hash stays.
D Denial of service
requestHash squattingvalidationRequest rejects a requestHash that was already used, and the hash is a global key. Anyone who learns a hash first can occupy it. Source [9]Preconditions: The attacker sees the request data or hash before submission.Impact: The legitimate request cannot be recorded under that hash. No exploit report was found; this is a reading of the code.
Left to implementers
Salt request payloads so hashes are not predictable; submit promptly.
D Denial of service
Unbounded readsgetSummary and readAllFeedback loop over every matching entry, and the community audit lists unbounded array returns and quadratic gas. Source [8, 30]Preconditions: An agent with very many entries or clients.Impact: On-chain consumers and RPC reads can fail on popular or spammed agents.
Left to implementers
Read from an indexer or events; pass short reviewer lists.
E Elevation of privilege
Single upgrade key for all registriesAll three proxies are UUPS with _authorizeUpgrade restricted to the owner. On 2026-10-11 the owner on Ethereum and Base was one externally owned account whose holder is not published. Source [5, 10, 14, 15]Preconditions: Compromise or misuse of that key.Impact: New code could rewrite identities, wallets or feedback behavior on those chains.
Left to implementers
Monitor the ERC-1967 implementation slot and owner(); keep your own snapshot of critical data; ask maintainers for a multisig or timelock, which their own upgrade notes advise.
Attack scenarios
A Sybil cluster lifts a new agent to the top of an explorer Source [1, 19]
Preconditions: Explorer ranks by raw average or count; Cheap gas.
An operator registers an agent
It funds 200 fresh addresses
Each address calls giveFeedback with value 100 and tag starred
An explorer that ranks by unfiltered data lists the agent first
Clients without a reviewer list hire it
Impact: Clients pay an untested agent; honest agents lose visibility.
A sold agent keeps receiving payments at the old wallet Source [1, 5]
Preconditions: A payer cached agentWallet; The token is transferred.
The owner sells the agent token
The transfer clears agentWallet
A payer uses the cached address
The new owner binds a different wallet
Impact: Payments reach the former owner; the new owner inherits the reputation.
An upgrade changes registry behavior overnight Source [5, 10]
Preconditions: Control of the owner key of the proxies.
The owner key authorizes a new implementation
The proxy points to new code
Reads and writes now follow the new rules
Impact: Any reliance on registry behavior can break on Ethereum and Base at once.
Preconditions: Readers weight feedback that has proofOfPayment without checking it.
A reviewer writes a file with an invented txHash
It calls giveFeedback with the file URI
A naive scorer counts it as paid feedback
Impact: Sybil feedback passes a payment filter.
Published research findings
On-chain ownership read of the registry proxies: owner() of all three proxies on Ethereum and Base returns 0x547289319C3e6aedB179C0b8e8aF0B5ACd062603, an address with no contract code. Source [10]
Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem: Only 3% (Ethereum), 4% (BSC) and 15% (Base) of agents had a valid file and a live endpoint; 73.5%, 59.2% and 90.6% of reviewers showed coordinated Sybil behavior (data to 2026-05-13). (paper in section G) Source [19]
From Agent Identity to Agent Economy: Describes early adoption as registration-heavy but operationally shallow. (paper in section G) Source [57]
Dissociative Identity: Language Model Agents Lack Grounding for Reputation Mechanisms: Argues that LLM agents lack the persistent identity that reputation mechanisms assume. (paper in section G) Source [58]
Community security audit (PR 51): Reports 1 high, 3 medium, 3 low and 2 informational findings, including the validation response downgrade and unbounded reads; unmerged on 2026-10-11. Source [30]
CVEs and advisories
None found : No CVE and no GitHub security advisory was found for the ERC-8004 reference contracts; the repository advisory list was empty. ReportedSource [31]
ERC-8004 natively provides reputation and partial identity: a verifiable agent token, a signed payee address and a filtered feedback log. It offers no consent, caps, step-up or kill switch, because it moves no money. Controls layers act before authorization (pick agents by trusted reviewers and fresh wallet reads), at signing (refuse stale payees) and after the fact (write payment-backed feedback, watch transfers and upgrades).
The on-chain agentId, owner and agentWallet are verifiable, and the optional /.well-known file proves domain control. Nothing proves who operates the agent. Source [1, 5]
Agent registration (know your agent)
Partial
A permissionless registry for discovery: anyone can mint an identity, with no KYC or know-your-agent check. Source [1]
User consent capture
None
No consent or mandate object; ERC-8226 (Draft) proposes one on top. Source [1, 26]
Spending caps
None
ERC-8004 moves no money, so it has no caps. Source [1, 8]
Merchant or payee scoping
Partial
agentWallet publishes a payee address that the wallet itself signed for; nothing limits what a client may pay. Source [1, 5]
Time windows and expiry
Partial
Only the wallet-binding signature expires (at most 5 minutes ahead in the reference code). Source [5]
Revocation
Partial
Clients revoke their own feedback and owners can unset the wallet; an identity cannot be revoked or burned. Source [1, 5]
No link between feedback and real interactions. Since feedbackAuth was removed, feedback is open to any address; proofOfPayment is optional and unchecked. Source [1, 21]
No mandate or spending limits. An agent identity says nothing about what it may spend or for whom. ERC-8226 (Draft) proposes a mandate layer. Source [1, 26]
No emergency stop. There is no pause or burn; the only lever is an upgrade by one owner key. Source [5, 10]
Validation not available. The Validation Registry is specified, not officially deployed, so third-party checks have no official on-chain home. Source [2]
Where an independent controls layer can act
Before authorization
Decide which agents may be hired getSummary with a curated reviewer list, endpoint probes, /.well-known domain proof, minimum feedback from paying clients. Source [1, 8]
At signing
Confirm the payee Read getAgentWallet just before signing a payment and refuse if the token moved since the wallet was bound. Source [1, 5]
At the edge
Check the endpoint is the agent Match the serving domain against the registration file and its /.well-known file. Source [1]
After the fact
Record outcomes Upload feedback with proofOfPayment and call giveFeedback; monitor Transfer, URIUpdated, MetadataSet and proxy upgrades. Source [1, 10]
Implementer checklist
Never call getSummary with an unvetted reviewer list Measured data shows majority Sybil reviewers on three chains. Source [19]
Read agentWallet immediately before paying A transfer clears it and cached values go stale. Source [1]
Verify proofOfPayment against the chain The registry never checks it. Source [1]
Pin or hash the registration file you approved HTTPS files can change without an event. Source [1]
Alert on proxy implementation and owner changes One externally owned account can upgrade all registries on Ethereum and Base. Source [10]
Do not rely on the Validation Registry address in scripts It is not listed or announced as deployed. Source [2, 10]
Keep spending caps in the payment layer ERC-8004 has none. Source [1]
J. Compliance and regulation
Not legal advice. This is a study summary of public rules as of the dates cited. Ask counsel about your situation.
ERC-8004 moves no money and checks no identities, so most payment rules land on the rails and wallets used next to it, not on the registry. The registry-specific issues are data protection (permanent public records), the absence of KYC or know-your-agent, and reliance on contracts one key can upgrade. ERC-8226 (Draft) is the only standard found that adds a compliance and mandate layer for regulated tokens. Rows are dated; check the source before relying on any of them.
Rules by topic and jurisdiction
Jurisdiction
What applies
Confidence
Consumer protection and liability
United States
Regulation E and Regulation Z decide unauthorized-use liability for account and card payments; an ERC-8004 identity or reputation score does not change that allocation, and no CFPB rule on AI agents was found. Source [63, 64, 65]
Verified
Card network rules
No Visa or Mastercard rule refers to ERC-8004. Agent identity in card programs comes from network registration, and no agent-specific liability rule was public on 2026-10-11. Source [40, 43, 83]
Reported
AML and sanctions
United States
The registries hold and move no funds, so money transmission rules do not reach the registry itself. FinCEN guidance FIN-2019-G001 applies to businesses that transmit value, such as the payment rail an agent uses alongside ERC-8004. Source [1, 59]
Verified
United States
ERC-8004 has no KYC or know-your-agent check. OFAC sanctions obligations apply the same way to digital and fiat transactions, so screening of an agentWallet address falls to whoever sends the payment. Source [1, 60]
Verified
European Union
The Transfer of Funds Regulation applies the travel rule to crypto-asset transfers through providers. ERC-8004 feedback files carry only addresses and a transaction hash, not originator data. Source [1, 72]
Verified
United Kingdom
The Money Laundering Regulations 2017 cover cryptoasset businesses; a registry that moves no assets is outside them, the payment provider is not. Source [1, 78]
Reported
Stablecoin rules
United States
The GENIUS Act (signed 2025-07-18) regulates payment stablecoin issuers; it applies to payments made to an agentWallet in stablecoins, not to the registry. Final rules were still pending on 2026-10-11. Source [61, 62]
Verified
European Union
MiCA governs e-money tokens and crypto-asset service providers (transition ended 2026-07-01); it applies to the payment rail and wallet providers, not to a registry that moves no assets. Source [1, 70, 71]
Verified
Canada
The Stablecoin Act in Bill C-15 received Royal Assent on 2026-03-26 and applies to issuers, not to identity registries. Source [80]
Verified
Strong customer authentication
European Union
PSD2 strong customer authentication applies to payment service providers; ERC-8004 identity is not an authentication factor under it. Source [73, 74]
Reported
AI-specific rules
European Union
AI Act Article 50 transparency duties apply from 2026-08-02; an agent discovered through ERC-8004 that talks to people must still disclose it is an AI. The registry adds no AI Act duty of its own. Source [68, 69]
Verified
United Kingdom
The FCA (2026-03-25) said it will consider whether payments regulation must change for agentic AI; HM Treasury consulted from 2026-07-14 to 2026-10-06. Neither names agent registries. Source [76, 77]
Verified
Singapore
MAS Guidelines on AI Risk Management (issued 2026-10-07, effective 2027-10-07) mention agentic AI for financial institutions that use it; a regulated firm relying on ERC-8004 scores would treat them as a third-party input. Source [81]
Verified
Data protection
United States
California's ADMT regulations (effective 2026-01-01) can apply to a business that uses automated scoring of people; public reputation data about agents may still describe their operators. Source [1, 66]
Reported
European Union
GDPR covers any information relating to an identifiable person. Feedback events, hashes and URIs cannot be deleted from the chain, which conflicts with erasure if personal data is placed there. Source [1, 67]
Verified
United Kingdom
UK GDPR as amended by the Data (Use and Access) Act 2025 applies the same erasure concern to personal data placed in permanent on-chain records. Source [1, 75]
Reported
Canada
PIPEDA governs private-sector personal information, including any personal data in public feedback files. Source [79]
Verified
Singapore
The Personal Data Protection Act 2012 applies to personal data in public records an organization publishes. Source [82]
Reported
K. Observability lens
5 of 5 observability score
Everything the registries record is public by design: token ownership, agentURI, metadata including agentWallet, every feedback value and tag, revocations and responses.
Named events (Registered, URIUpdated, MetadataSet, NewFeedback, FeedbackRevoked, ResponseAppended) at the same proxy addresses on every listed mainnet make indexing simple.
Registration files, feedback files and the /.well-known domain proof are public whenever their URI is public.
Public explorers, subgraphs and a CC BY 4.0 census dataset already exist.
What stays private is only what parties choose not to publish, such as the payment details behind a feedback entry; the quality of the data is the weak point, not its visibility.
Publicly observable
Public signals
What
Where
How
Identity events
Identity Registry 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 on each listed mainnet
Agent0 subgraphs on The Graph (Base, BNB Chain, Ethereum, Monad, Polygon)
GraphQL over indexed identity, feedback and validation events. Source [27]
Upgrade control
owner() and the ERC-1967 implementation slot of each proxy
eth_call and eth_getStorageAt; on 2026-10-11 the owner was 0x547289319C3e6aedB179C0b8e8aF0B5ACd062603 on Ethereum and Base. Source [10]
Private by design
Payments behind feedback. ERC-8004 carries no payment; only an optional proofOfPayment in a file points to one.
Who operates an agent. The registry records an owner address, not a person or company.
Files that are no longer served. Only the URI and an optional hash stay on-chain; HTTPS content can disappear or change.
Who holds the upgrade key. On Ethereum and Base the owner is an externally owned account whose holder is not published. On BSC the Identity and Reputation proxies are owned by a Safe and the Validation proxy by an EIP-7702 account (read-only probe, 2026-10-11).
What an indexer or monitor could capture
New agents and their files from Registered, URIUpdated, Transfer: agentId, agentURI, owner, agentRegistrySource [1, 27]
Payee changes from MetadataSet with metadataKey agentWallet: agentId, agentWalletSource [1]
Feedback stream and Sybil clusters from NewFeedback, FeedbackRevoked, ResponseAppended: agentId, clientAddress, feedbackIndex, tag1, feedbackURISource [1, 19]
Liveness of declared endpoints from Registration file services plus probes: services[].name, services[].endpointSource [18]
Registry upgrades from ERC-1967 Upgraded event and implementation slot: proxy address, implementation address, ownerSource [5, 10]
L. Ecosystem and adoption
Stewards
ERC-8004 team (8004.org): Community effort coordinated by Marco De Rossi (MetaMask) and Davide Crapis (Ethereum Foundation); co-authors Jordan Ellis (Google) and Erik Reppel (Coinbase); maintains the contracts and best practices. Source [1, 2]
ethereum/ERCs editors: Editorial process for the text; returned it to Draft on 2026-01-13. Source [4]
Owner of the registry proxies: One externally owned account on Ethereum and Base (2026-10-11), holder not published; authorizes upgrades and new-chain deployments. Source [10, 33]
Implementers and deployments
Implementers (7)
Name
Role
Status
Identity and Reputation registries on 25 mainnets
Same proxy addresses on every chain listed in the contracts README (as of 2026-08-15). Source [2, 12]
Live
Validation Registry
Specified only; no listed address on any chain. Source [2, 10]
Agent token ids the explorer counts across its networks; method not published. Source [28] Caveat: Count is not quality: ids are free to mint (gas only) and include placeholders. Compare with the census and arXiv:2606.26028 below. Disputed Source [18, 19].
Feedback entries (8004scan)
682,170 entries
Feedback submissions the explorer counts. Source [28] Caveat: Includes Sybil feedback; arXiv:2606.26028 found 59.2% to 90.6% of reviewers coordinated on three chains (data to 2026-05-13). Disputed Source [19].
Unique wallets (8004scan)
496,805 wallets
Distinct addresses seen by the explorer. Source [28] Caveat: Wallets are not people or operators.
Networks (8004scan) versus listed mainnets (README)
30 versus 25 networks
8004scan network count against mainnets in the official contracts README. Source [2, 28] Caveat: 8004scan may include testnets or community deployments. Disputed Source [2].
Agent ids read (CSOAI census)
505,635 agent ids
Ids read with eth_call on Ethereum (51,458), Base (95,776) and BSC (358,401). Source [18] Caveat: Three chains only; read state partial.
Ids declaring an http(s) MCP, A2A or web endpoint (CSOAI census)
13,210 agent ids
Files that declare at least one such endpoint; 231,014 files were not fetched and 52,469 ids had no URI. Source [18] Caveat: Declared, not live: of 2,113 MCP endpoints probed, 580 responded.
Agents with a valid file and a live endpoint (arXiv:2606.26028)
3% Ethereum, 4% BSC, 15% Base share of agents
Share of registered agents whose file was valid and at least one endpoint answered, in the authors' crawl. Source [19] Caveat: arXiv preprint; method is the authors' own. Count is not quality.
Reviewers with coordinated Sybil behavior (arXiv:2606.26028)
73.5% Ethereum, 59.2% BSC, 90.6% Base share of reviewers
Share of reviewer addresses the authors flag as coordinated. Source [19] Caveat: Detection heuristics are the authors' own.
Agents with sustained activity (community report)
about 50 of 119,675 agents
Self-reported by an agent account in a GitHub issue. Source [86] Caveat: Unverified; shown only as context.
Reported From the QuickNode explorer FAQ; the contracts have no fee or payable function.
register(string) gas
about 203,412 gas (67-character IPFS URI); 203,460 gas with a 69-character URI Source [87]
Agent owner
Verified Method: eth_estimateGas from an unfunded test address against public RPCs on Ethereum and Base, measured by the Atlas on 2026-10-11 and re-run the same day. An estimate, not a mined transaction; grows with URI length and metadata.
giveFeedback gas (first feedback from a new client)
about 155,185 gas with empty tags and URI; about 178,504 gas with tag1, an endpoint and an IPFS URI Source [17, 87]
Client, or a sponsor through EIP-7702
Verified Method: eth_estimateGas on Ethereum and Base, 2026-10-11, agentId 1. No published figure exists from the authors or any vendor. Later feedback from the same client costs less. The figure depends on the agent: for agentId 0 on Ethereum a first feedback estimated 172,409 to 193,006 gas the same day.
Illustrative giveFeedback cost on Ethereum
about 0.000012 to 0.000017 ETH at 0.067 to 0.097 gwei Source [87]
Client
Verified Gas prices change by orders of magnitude; on Layer 2 networks the L1 data fee is extra and not included.
Registration (vendor docs)
"Costs dollars" on Ethereum mainnet, "pennies" on Base, Mantle, BNB and Avalanche Source [88]
Agent owner
Reported Qualitative, reflects gas prices in the first half of 2026.
Registration (secondary estimate)
about $1 to $5 on Ethereum mainnet, about $0.20 on Layer 2 networks Source [89]
Agent owner
Reported Secondary estimate; on 2026-10-11 the measured gas cost was cents on mainnet. Always read with its date.
Mainnets listed in the ERC-8004 contracts README (mainnets (cumulative))
Source: README listing dates from the erc-8004-contracts commit history, read 2026-10-11. Listing dates, not deployment dates.
Register an agent and bind a wallet (viem, from the contract tests)erc-8004-contracts tests (Hardhat with viem) contracts 2.0.0 (commit b9e466c)Contracttypescript
Give and revoke feedback (viem, from the contract tests)erc-8004-contracts tests (Hardhat with viem) contracts 2.0.0 (commit b9e466c)Contracttypescript
await reputationRegistry.write.giveFeedback([ agentId, 90, 0, // value, valueDecimals "tag1", "tag2", "", // endpoint "ipfs://feedback", keccak256(toHex("content")),], { account: client.account });// feedbackIndex is 1-based; only the original client may revokeawait reputationRegistry.write.revokeFeedback([agentId, 1n], { account: client.account });
Shortened from the package README quick start. The SDK writes agent ids as chainId:agentId, which is shorter than the global agentRegistry form in the Draft text. Never put a real key in code. agent0-sdk (npm) documentation (external link)Source [90]
Read the summary from trusted reviewers (Solidity interface)ERC-8004 Draft interface Draft 2026-01-25Contractsolidity
function getSummary( uint256 agentId, address[] calldata clientAddresses, // must be non-empty string calldata tag1, string calldata tag2) external view returns (uint64 count, int128 summaryValue, uint8 summaryValueDecimals);
Registration file builder and reputation aggregator simulator: src/playgrounds/erc-8004/ (planned)
O. Playground
Simulation of a registration file builder with a schema derived from the spec text, a global id composer on a fake chain (424242), a reputation aggregator that mirrors the getSummary math with Sybil reviewers and trusted-client filtering, and an EIP-712 setAgentWallet signature with an ephemeral key, with no real funds, wallet or network calls.
Simulation, no real fundsFollows spec version Draft (text of 2026-01-25)
Loading the simulation.
Keys are generated in this browser for this session only, on test chain identifiers or fixture data. No wallet connects and nothing is sent to a network.
P. Compare and compose
ERC-8004 and x402 are built to sit side by side. The x402 protocol moves a signed payment and says nothing about who the counterparty is. ERC-8004 names the agent, publishes its payee address and keeps a public log that a payment can back up.Source [1, 37] A proposal open in the contracts repository would go further and ground feedback in x402 payment proofs as a defense, but nothing like it is in the text today.Source [46] Against Visa TAP and Mastercard Agent Pay, the contrast is in who vouches for the agent. Those programs identify agents to a card network, while ERC-8004 lets anyone mint an identity and leaves trust to public signals, and no source links them.Source [1, 40, 43]
The comparison that matters most for tokenization teams is with ERC-3643 (, Token for Regulated EXchanges) and . ERC-3643 is a Final ERC created on 2021-07-09, stewarded by the ERC3643 Association in Luxembourg, and its reference implementation moved from the now archived TokenySolutions/T-REX repository to the GPL-3.0 ERC-3643/ERC-3643 fork.Source [25, 47, 48, 49] The archived repository’s 4.1.6 release dates from 2024-10-18, while the organization repository marks 4.1.3 as its latest.Source [48, 49] The ONCHAINID key and claim design comes from ERC-734 and ERC-735, which were never merged as EIP files and exist only as closed GitHub issues; ERC-725 is still Draft.Source [50, 51, 52]
Dimension
ERC-3643 plus ONCHAINID
ERC-8004
Status and governance
Final ERC (created 2021-07-09), ERC3643 Association
Draft ERC (2025-08-13), community effort, no association
Access model
Permissioned: a holder’s wallet must be in the Identity Registry and pass isVerified, which needs required claim topics from trusted issuers
Permissionless: any address calls register() and gets an agent id
Trust signal
Issuer-signed claims on the holder’s ONCHAINID (topic, scheme, issuer, signature, data, uri), checked with isClaimValid
Open feedback from any address except owner and operators; validator responses 0 to 100 in a registry that is not officially deployed
Scope
Transfer compliance for one token, checked by the Compliance contract (canTransfer)
Discovery and trust registry for agents and their services (services, supportedTrust)
Who writes
Identity Registry agents register identities; addClaim accepts a CLAIM (purpose 3) or MANAGEMENT (purpose 1) key or the identity itself; MANAGEMENT keys manage keys; the owners of the issuer and topic registries set trusted issuers and claim topics
Owner or operator writes URI, metadata and wallet; any third party writes feedback; anyone appends responses; a named validator responds
Upgradeability
T-REX proxies point to TREXImplementationAuthority; ONCHAINID identities can be proxies
proxies at CREATE2 addresses; one externally owned account holds the upgrade right on Ethereum and Base (2026-10-11), holder not published
Data location
Claims stored on-chain in the identity contract; data may be a hash and uri may point off-chain
off-chain or in a data URI; feedback value and tags on-chain; detail files referenced only in events
License
Text CC0; reference code GPL-3.0
Text CC0; contracts MIT per file headers
Missing on each side
No agent, service endpoint or feedback concept
No issuer-attested compliance claims, no mandate or delegation model
The table rests on the ERC-3643 text, the ONCHAINID contracts and the ERC-8004 sources.Source [1, 10, 14, 25, 26, 48, 53, 54] If you come from T-REX, watch three words. An ERC-3643 Agent is an operator role appointed by the token owner to register identities, mint, burn and freeze; an ERC-8004 agent is the AI service itself.Source [25] The ClaimIssuer contracts you trust play the part of the reviewer list you pass to , and claim topics map loosely to feedback tags.Source [1, 8, 53, 54] The shares a name with the T-REX one but is a different thing: an open ERC-721 directory of agents, not an allowlist that maps wallets to verified identities and countries.Source [25]
ERC-8226, the Regulated Agent Mandate, is the one standard found that connects the two worlds. A verified principal delegates scoped, time-bounded and capped authority to an agent. Token compliance stays with ERC-3643 or ERC-7943, and agent identity comes from a registry such as ERC-8004, which the authors describe as discovery and trust signals without a mandate framework.Source [26] It is a Draft from Brickken authors, and no statement from the ERC3643 Association or Tokeny about AI agents or ERC-8004 was found.Source [26, 47]? unverified That also makes ERC-8226 the closest on-chain analogue of an AP2 mandate.Source [1, 26, 39]
Relations to other protocols
Compatible withERC-8004: Trustless Agents to Stripe MPP (Machine Payments Protocol): The MPP payment discovery draft cites ERC-8004 and calls its off-chain discovery compatible with future on-chain anchoring; no integration is specified. Source [13]
ComplementsERC-8004: Trustless Agents to AP2: Indirect only: ERC-8004 lists A2A agent cards as services and AP2 can be implemented as an A2A extension. ERC-8226 is the closest on-chain analogue of an AP2 mandate. Source [1, 26, 39]
ComplementsERC-8004: Trustless Agents to x402: Neither depends on the other. ERC-8004 publishes x402Support, uses agentWallet as the payee address, and lets feedback files carry proofOfPayment for an x402 payment; Erik Reppel co-authors ERC-8004 and sits on the x402 TSC. Source [1, 37, 38]
Complementsfrom x402: ERC-8004 registration files carry an x402Support flag, feedback files can carry proofOfPayment for an x402 payment, and best practices use agentWallet as the x402 receipt address. Source [91, 92]
ERC-8004: Trustless Agents in the compare matrix (34 dimensions)
Dimension
Value
Confidence
Primary job
On-chain agent identity, discovery and public feedback Three registries: identity (ERC-721 plus a registration file), reputation, and validation (specified only).Source [1]
Verified
Layers covered
Identity and trust; reputation and feedback; discovery No checkout, authorization or settlement layer.Source [1]
Verified
Stewards
ERC-8004 team (community), coordinated by De Rossi (MetaMask) and Crapis (Ethereum Foundation) Co-authors Jordan Ellis (Google) and Erik Reppel (Coinbase); no foundation found.Source [1, 2]
Verified
Governance model
ethereum/ERCs editorial process; contracts controlled by one proxy owner An EIP editor returned the text to Draft on 2026-01-13; one externally owned account owns the proxies on Ethereum and Base (2026-10-11).Source [4, 10]
Verified
License (spec and code)
Spec CC0; contracts MIT per file headers (README says CC0) Source [1, 2, 5]
Verified
First announced
2025-08-13 (created) Merged into ethereum/ERCs on 2025-08-18.Source [1, 6]
Verified
Latest version and date
Draft text of 2026-01-25; contracts 2.0.0 Source [5, 7]
Verified
Maturity
Draft ERC; Identity and Reputation live on 25 mainnets; Validation not officially deployed README list as of 2026-08-15, unchanged on 2026-10-11.Source [2, 11]
Verified
Transports
EVM transactions and reads; files over IPFS, HTTPS or data URI; /.well-known domain proof Source [1]
Verified
Settlement rails
None (moves no money) Registries live on EVM chains; payments happen on other rails.Source [1, 8]
Verified
Agent identity model
ERC-721 token per agent pointing to a registration file; global id agentRegistry plus agentId Source [1]
Verified
User authorization model
None No consent or mandate object; ERC-8226 (Draft) proposes one on top.Source [1, 26]
Verified
Human-present and human-not-present support
Not applicable Registries record identity and feedback, not purchases.Source [1]
Verified
Merchant of record
Not applicable No payment flows through ERC-8004.Source [1]
Verified
Credential type
ERC-721 token plus EIP-712 or ERC-1271 wallet-binding signature Source [1, 5]
Verified
Cryptography
EIP-712, ERC-1271, keccak256 file commitments ECDSA recovery also accepts EIP-7702 delegated accounts in the reference code.Source [1, 5]
Verified
Replay protection
Partial: EIP-712 domain and a 5-minute deadline on wallet binding, no nonce Source [5]
Open registries on public chains, with one upgrade key on Ethereum and Base Source [1, 10]
Verified
Observability score
5 of 5 All state and events are public; quality of the data is the weak point.Source [1, 28]
Verified
Fees and who pays them
No protocol fee; gas only Measured 2026-10-11 with eth_estimateGas: register about 203,412 gas, first giveFeedback about 155,185 to 178,504 gas; cents on mainnet that day, dollars at early-2026 gas prices.Source [85, 87, 89]
Verified
Who pays (short)
Caller pays gas Owner pays to register; client or an EIP-7702 sponsor pays for feedback.Source [1, 87]
Many registrations, few live agents 561,576+ agents on 8004scan (2026-10-11) against 3% to 15% live in arXiv:2606.26028 (data to 2026-05-13). Count is not quality.Source [18, 19, 28]
Reported
Published security research
Yes: an empirical study of Sybil reviewers and liveness; an unmerged community audit; no CVE Source [19, 30, 31]
Verified
Regulatory touchpoints
Data protection (permanent public records); no KYC; payment rules apply to linked rails Source [1, 67]
Verified
Biggest open question
Can reputation be made Sybil-resistant without a gate, and who controls the upgrade key? Source [10, 19]
No. It is a Draft. It moved to Review on 2025-10-08, and an EIP editor returned it to Draft on 2026-01-13. It was still Draft on 2026-10-11, even though registries are listed on 25 mainnets in the contracts README (on Soneium the proxies still ran a placeholder that day). Source [1, 2, 4, 11, 16, 17]
MisconceptionDoes ERC-8004 move money or pay agents?
No. The text calls payments orthogonal, and the registries have no payable function. x402 or another rail moves the money; ERC-8004 only publishes the payee address and lets feedback point to a payment. Source [1, 5, 8]
MisconceptionAre all three registries deployed?
No. The Identity and Reputation registries are listed on 25 mainnets. The Validation Registry is specified, but the contracts README lists no address for it; a contract answers at a scripted address on Ethereum and Base but is not announced, so treat it as not officially deployed. Source [2, 10, 12, 44]
MisconceptionDoes an agent have to authorize feedback with feedbackAuth?
Not any more. The agent-signed feedbackAuth was removed from the contracts on 2025-11-12 and from the text on 2026-01-07. Any address except the owner and operators can rate an agent. Source [1, 20, 21]
MisconceptionDoes a large number of registered agents mean the ecosystem is healthy?
No. Agent count is not agent quality. Ids are free to mint and include placeholders; one study found only 3% to 15% of agents with a valid file and a live endpoint (data to 2026-05-13), and a census found at least 13,210 of 505,635 ids declaring an http(s) endpoint, with 231,014 files not fetched (2026-09-26). Source [18, 19]
MisconceptionWhere does proofOfPayment live?
Only in the off-chain feedback file. The registry stores value, decimals, two tags and the revoked flag; it never stores or checks the payment proof. Upload the file first, then call giveFeedback with its URI and hash. Source [1, 8]
Why does getSummary need a list of client addresses?
Because unfiltered feedback is open to Sybil and spam attacks. The reader must choose reviewers it trusts, and the reference code reverts with an empty list. Source [1, 8]
What happens to the agent wallet when the agent token is sold?
The transfer clears agentWallet, and the new owner must bind a wallet again with a signature from that wallet. Source [1, 5]
Who can upgrade the registries?
Only the contract owner. On Ethereum and Base on 2026-10-11 that was one externally owned account, not a multisig contract, and the holder is not published. On BSC the owners differ: a Safe multisig for Identity and Reputation and an EIP-7702 account for the Validation proxy. Source [5, 10, 14, 15, 17]
MisconceptionIs ERC-8004 the same as ERC-8183 or ERC-8126?
No. ERC-8183 is job escrow with an evaluator and ERC-8126 is a verification standard that requires ERC-8004. ERC-8126 reached Final on 2026-06-02 while ERC-8004 stays Draft. Source [22, 23, 24]
MisconceptionIs the ERC-8004 Identity Registry the same thing as the ERC-3643 Identity Registry?
No. The T-REX registry maps wallets to verified identities and countries for token transfers. The ERC-8004 registry is an open ERC-721 directory of agents. In ERC-3643 an Agent is an operator role, not an AI agent. Source [25]
MisconceptionDoes ERC-8004 check who runs an agent?
No. Registration is permissionless and has no KYC or know-your-agent step, and the text cannot guarantee that advertised capabilities work. Source [1]
R. Open questions and research frontier
Will the Validation Registry be redesigned before an official deployment?
The README calls it still under discussion with the TEE community, and the open rogue-validator issue would change its semantics. Source [2, 29, 30]
Who controls the upgrade key, and will it move to a multisig or governance?
One externally owned account owns the proxies on Ethereum and Base; the project's own notes recommend a multisig or timelock. Source [10, 15]
Can feedback be grounded in real payments without bringing back feedbackAuth?
Issue 99 proposes x402 payment proofs as a Sybil defense; today proofOfPayment is optional and unchecked. Source [1, 46]
Will a JSON Schema for the registration file be published?
Required fields are a reading of an example, and best practices treat some as optional. Source [1, 55]
Will the text return to Review, and why can ERC-8126 be Final while it depends on a Draft?
The sources record both statuses without explaining the gap. Source [4, 24]
How should values with free-form tags be compared?
The study calls values not commensurable, and getSummary averages whatever matches. Source [8, 19]
Can re-execution validation work for non-deterministic LLM agents?
LLM outputs vary, and reputation papers question whether LLM agents have stable identity at all. Source [1, 58]
How does ERC-8004 connect to mandates for regulated assets?
ERC-8226 proposes a mandate layer over ERC-8004 identity for ERC-3643 tokens; no issuer or association statement was found. Source [26, 47]
S. Self-test
Quiz
0 of 10 answered.
Flashcards
0 of 15 marked known. Card 1 of 15.
Prompt
agentId
T. Notes
Notes stay in this browser. Nothing is sent anywhere.