# ERC-8004 listed 418,665 agents. Where were the customers? I checked 457,778 Ethereum and Base reviews. Two files point to settled transactions; only one, worth one cent, names both payment parties. Authors: [Omar U. Espejel](https://gradiente.ai) Published: 2026-08-19 Updated: 2026-08-20 Tags: agents, ethereum, onchain-data ERC-8004 looked like proof that the agent economy had arrived. In my 18 August snapshot, it listed **418,665 agent registrations** and **558,461 reputation events** across 28 mainnet chains. Then I went looking for customers. I audited 457,778 reviews on Ethereum and Base. Two files point to transactions I could resolve onchain. Only one identifies both payment parties, and that file names the wrong chain. The contracts work. The adoption story does not. **In the two chains I tested, ERC-8004 can prove almost no paid work.** Work may be happening elsewhere; this trust system barely records it. Disclosure: I wanted ERC-8004 and [x402](https://docs.x402.org/introduction) to work. On Starknet, [Akash Neelesh](https://github.com/keep-starknet-strange/starknet-agentic/commit/9819371a4db24db439bc5ebcf16ac40e6959e5cf) implemented Cairo v2, [Abdel Stark](https://github.com/keep-starknet-strange/starknet-agentic/commit/1d676a0da4c518925b1f42b5d7dbc5bed0bdbb24) created the original `starknet-identity` skill, [Adrien Lacombe](https://github.com/keep-starknet-strange/starknet-agentic/commit/6504b4e7e64320cac32cb6038d87f2b991bb05da) contributed security cleanup, and I updated the skill against the deployed ABI this week. [Davide Crapis](https://x.com/DavideCrapis), one of ERC-8004's authors, made the optimistic [launch case](https://x.com/DavideCrapis/status/2016893815857066212). I have spoken with him a couple of times, and I like him a lot and admire his work. That made me want to look closely at how ERC-8004 is doing in practice. ## What 418,665 actually counts Draft [ERC-8004](https://eips.ethereum.org/EIPS/eip-8004) is easier to understand than its name suggests. It defines three registries: | Registry | What it records | Who supplies the signal | |---|---|---| | **Identity** | A name and a file that says what the agent does | The agent's owner | | **Reputation** | Scores, tags, endpoints, and an optional evidence file | Any client address except the owner or an approved operator | | **Validation** | A request for an outside check and the validator's answer | A chosen validator | Payments are outside the standard. A review *can* include an x402 payment receipt, but that field is optional. I found no published Validation Registry in the EVM deployments I checked, so reputation is the only public signal here that might contain evidence of demand. The contract records what an address says. It does not know whether that address bought anything. That is why I do not accept [the explorer's label “active users”](https://8004scan.io/). The explorer never defines *active*. Calling 401,030 addresses “active users” invites readers to mistake registry participation for demand. On Ethereum, where I scanned every event from launch, there were 50,287 registered agents. Only 1,668 had any review. At most **129** had a review from an address that was not one of the six busiest crawlers. Treat 129 as a ceiling, not a count of people. A quieter bot can sit below every threshold I tried. The real number of agents reviewed by a person may be lower. Ten thousand registered Ethereum agents pointed to one dead domain. I sampled 295. None answered. The headline number counts listings. The steep drop begins when somebody else has to show up. ## One agent wrote half the reviews The total review count looks healthier until you ask where it came from. **300,692 reviews, or 53.8% of every review in the dataset, belong to one agent:** Base agent [#25975, “Botoshi”](https://8004scan.io/agents/base/25975). Its own card describes it as the coordinator for BOTCOIN mining. The screenshot is almost too perfect. The same page says Botoshi has no feedback and 292,300 feedback entries. An explorer that cannot make those two numbers agree is not ready to turn them into a reputation score. All 300,692 entries carry the tag `miner-vouch`. They came from 57 wallets that mined for the coordinator. Every score is the number 1. A checkmark, not a rating. The miners were not breaking the contract. ERC-8004 lets any client address other than the owner or an approved operator write feedback, and the mining loop used that open log as a cheap database. The problem comes later, when an explorer adds those receipts to the same number as a customer saying a service worked. The next layer is thin too. The second-largest source is a crawler that writes five metrics in lockstep about 7,556 agents, with no payment evidence attached. On Ethereum, 2,198 of 3,217 reviews came from the six busiest crawlers checking whether an endpoint answered. Meanwhile, 19,901 Ethereum agents had no description. These are valid writes. They show that the registry is useful as public infrastructure. They do not show a market. ## Only two payment links survive Counting reviews was only the first test. ERC-8004's example feedback file has an optional `proofOfPayment` object. If a review came from paid work, that object can name the transaction, chain, payer, and recipient. So I fetched every feedback file referenced by every Ethereum and Base review. I looked for a transaction reference, resolved it onchain, and checked that the transaction succeeded. Then I asked whether the file named the chain, payer, and recipient, and whether the transfer matched those claims. The dataset held **457,778 reviews**. Two files point to transactions that resolve. Only one identifies both payment parties. The first four groups fail in different ways. Some attach no file. Some point to evidence that has disappeared. Most attach a comment or score with nothing another person can check. Another 2,199 name an MCP tool or an A2A task. That sounds better, but a tool name is still text written by the reviewer. It is not bound to a session, request, response, or counterparty. One [academic study](https://arxiv.org/abs/2606.26028) calls this “task linkage.” I do not. Naming a tool and proving you used it are different acts. Agent #6817's file points to a real **\$0.0100** USDC transfer between its named payer and recipient, but declares Ethereum while the transaction is on Base. That mismatch sat in the registry's history for seven months while the explorer used the review in a public score. Agent #58134's file points to a real **\$0.0100** Base settlement, including \$0.0090 to its named provider, but names no payer and uses different fields from the ERC-8004 example. It proves settlement, not that the reviewer paid. | Agent | What resolves on Base | What the file gets wrong or omits | |---|---:|---| | #6817 | [\$0.0100 between its named payer and recipient](https://basescan.org/tx/0x9907871570815a07194711509d95677d00a1985bc628c9df2b698f6f53a09c23) | Says Ethereum, the wrong chain | | #58134 | [\$0.0100 settlement; \$0.0090 to its named provider](https://basescan.org/tx/0x088ccf44e75b35e46d92a3d131ae0ddd0f71269843ed1b8f793d8acb0594bf9c) | Names no payer; uses different fields from the ERC example | That is the complete list. The two transactions settled **\$0.0200** gross, and \$0.0190 reached the files' named recipients. Only agent #6817's \$0.0100 transfer passes the two-named-party test, and its declared chain is wrong. The registry can prove almost no paid customer-agent work. ## Real work can leave weak proof [Toppa](https://toppa.cc/) sells phone airtime, data, bill payments, and gift cards over Telegram and WhatsApp. Its [agent on Celo](https://8004scan.io/agents/celo/1870) has 602 reviews from 511 addresses, the most diverse reviewer set I found. These are not customers sitting down to write opinions. Toppa's delivery system writes feedback after a purchase succeeds. The review is exhaust from real work. That is a much better design. It still fails the proof test. Of Toppa's 602 reviews, 598 attach no file. The other four were written by crawlers, not by Toppa's customers. The real transactions leave the thinnest trace. The monitoring bots leave the richest files. This is the strongest objection to a broad “there is no demand” claim. Real work can happen while the registry records weak evidence. Agents can also hire and pay one another without using ERC-8004 at all. ### The live task market is still mostly seeded Larger jobs are the other possibility, so I checked a live task market. [Taskmarket](https://taskmarket.dev/), built by [Daydreams](https://www.daydreams.systems/about), runs tasks on Base and exposes its data through a [public API](https://docs.taskmarket.dev/api/reference). I could read 321 of the 373 tasks it reported in my snapshot. | Measure | What I found | |---|---:| | Readable tasks / tasks reported | **321 / 373** | | Tasks from one requester address | **178, or 55%** | | Distinct requester addresses / signing keys | **35 / 19** | | Tasks created within 60 seconds of another | **53%** | | Submission records / recorded awards in the capture | **13,499 / 421** | | API-reported aggregate agent earnings | **\$3,288.58** | I expected junk and found something more interesting. Many briefs are specific and charming: build a three.js world, recreate an arcade game, decode a braille cell. Somebody put thought into them. Taskmarket is also unusually open about its data. I like both things. But I would not call this broad demand. One requester address posted 55% of the 321 readable tasks. More than half arrived in bursts less than a minute apart. The capture contained 13,499 submission records and 421 recorded awards: an aggregate **3.1% award-to-submission ratio**. That does not tell us which attempts were still pending or how split awards worked, but it does show a market organized around contests rather than ordinary jobs. New markets often seed their own demand. There is nothing dishonest about that. It can be a good way to attract workers and find product-market fit. But seeded benchmarks are not evidence that outside customers have arrived. The honest description today is “interesting experiment,” not “agent economy.” This does not prove that paid agent work is absent. It proves something more useful: **registration and review totals cannot tell us how much exists.** ## A payment can be real and still prove little At this point the obvious fix seems easy: make every review point to a payment. If reviews are cheap talk, let money be the reputation. eBay learned the same lesson in two rounds. Open feedback invited score-padding, so eBay restricted reviews to transactions. Sham transactions followed. The history is documented by [Resnick and Zeckhauser](https://www.hks.harvard.edu/publications/trust-among-strangers-internet-transactions-empirical-analysis-ebays-reputation-system) and in a later [legal analysis of reputation systems](https://scholarship.richmond.edu/jolt/vol7/iss4/5/). A transaction link is the floor for reputation, not the finish line. x402 is the natural place to test that idea. It lets an API charge for each request, and the ERC-8004 specification uses it in the example payment receipt. The public [x402scan dashboard](https://x402scan.com/) has the same concentration problem. In that snapshot, one service accounted for 7.75 million of 10.97 million transactions, or 70.6%, from 568 buyers. That may be a real and busy service. It is still a reminder that transaction count and market breadth are different things. I then measured a full day of Base. The scan found 609,243 [EIP-3009](https://eips.ethereum.org/EIPS/eip-3009) USDC transfers. This is an upper bound for x402 because EIP-3009 is also used by ordinary gasless transfers. The count and the money came from different groups. Transfers above one dollar were 1.6% of the count and 99.64% of the value. The 508,803 transfers worth one cent or less moved \$2,854.98 in total. One address sent another **506,880 transfers in that day**. That pair was 83.2% of the whole transfer count. The varying amounts are consistent with metered use. It could be a busy customer paying a busy supplier. Either way, it is one relationship, not a broad market. A payment receipt can also put almost nothing at risk. The smallest EIP-3009 transfer in my scan was **\$0.000001**—not necessarily x402, because the scan includes ordinary gasless USDC transfers. A [2026 audit of ERC-8004](https://arxiv.org/abs/2606.26028) found that one feedback item could move the median agent across its trust threshold while the median Base gas cost to post it was **\$0.0027**. Like [a cryptographic proof receipt](/essays/inside-a-sparseprove-receipt/#meaning), a payment receipt proves only its stated claim: money moved. It does not prove that useful work happened or that enough was at risk to make cheating costly. ## What better evidence would look like The obvious fix is to give larger payments more weight. I no longer think that works. A buyer and seller can move the same dollar through new wallets, send it back, and return tomorrow as a “repeat customer.” Gross volume and repeat count are facts. They are not proof of independent demand. ### A job receipt, not another score I would leave the ERC-8004 contracts alone. The standard already expects complex scoring to happen off-chain, and its own [security section](https://eips.ethereum.org/EIPS/eip-8004#security-considerations) admits that Sybil attacks are possible. The first useful product is a strict evidence profile and a verifier, not a fourth registry. Call it a Verified Job Receipt. One job ID must survive every signed step, so nobody can splice the offer from one job onto the result from another. The SDK should derive the chain, asset, amount, sender, and recipient from settlement, then bind those addresses to the signed terms. Nobody should type them into JSON. That would have caught the wrong chain in one file and the missing payer in the other. ### Show facts, not stars The verifier should return an evidence ladder: **listed, paid, submitted, accepted, independently validated**. Each label says exactly what happened. No label should silently become a universal reputation score. The last label is only honest when the indexer names the validator and explains why it treats that validator as independent. The explorer should then show net settled value after known refunds, payer addresses, repeat-payer rate, sponsored activity, disputes, and concentration in the largest payer-agent pair. Call them addresses, not customers. The classic [Sybil result](https://www.microsoft.com/en-us/research/publication/the-sybil-attack/) is unforgiving: without a trusted authority, a distributed system cannot reliably show that two online identities represent different entities, except under extreme assumptions about resources and coordination. A useful explorer would not tell me which agent has five stars. It would tell me what happened the last fifty times that agent took money for this kind of job—and how concentrated those payments were. ### The pieces already exist This is assembly, not blank-page invention. [Davide Crapis](https://x.com/DavideCrapis), Bryan Lim, Tay Weixiong, and Chooi Zuhwa's [ERC-8183](https://eips.ethereum.org/EIPS/eip-8183) adds escrow, deliverable commitments, and terminal outcomes, though its evaluator can still be the client. [Alfred Tom](https://github.com/alftom) authored x402's [Signed Offers and Receipts](https://github.com/x402-foundation/x402/pull/935), merged by [@phdargen](https://github.com/phdargen). [A2A x402](https://github.com/google-agentic-commerce/a2a-x402/blob/05b589dbe1ebba52add76d199e48eefff0c86c5d/spec/v0.2/spec.md), advanced by Jordan Ellis, and Ayush Ojha's proposed [operation-bound receipts](https://github.com/x402-foundation/x402/issues/1921) already carry terms or task IDs toward payment. Today's x402 receipt signs neither the response body nor client acceptance. Its [payment identifier](https://github.com/x402-foundation/x402/blob/5e907d8a40b870111c2531c58c10fc880f9ebceb/specs/extensions/payment_identifier.md) binds a request only at the resource server or facilitator, not in the signed receipt. None of these pieces yet provides a signed, portable chain through client acceptance. ### Where this still fails Wash trading survives. Pair caps, delayed settlement, refund tracking, and wallet-cluster analysis make it more visible. They do not reveal common ownership or a rebate paid somewhere else. A high payment is not necessarily high value at risk. For cheap API calls, the narrow claim “a paid response happened” may be enough. Larger jobs need more. Objective work can go to a deterministic verifier. Subjective work needs explicit acceptance or an agreed dispute process. An [optimistic oracle](https://docs.uma.xyz/protocol-overview/how-does-umas-oracle-work) accepts an assertion if nobody disputes it during the liveness period. A false claim costs the asserter its bond only when an active challenger disputes it and the DVM resolves against it. A seller should not be able to choose a friend and call the result independent. Before changing a standard, I would run a 30-day pilot on one real service and attack it. Create a wash loop. Trigger a refund. Submit a bad result. Rotate the agent's key. Publish what the receipt catches and what it misses. Then compare the rankings produced by raw reviews, paid jobs, accepted jobs, and outside validation. A review is a claim. A payment is an event. A job receipt links them. It is not truth, but it is finally an audit trail.
Methods and snapshot dates I scanned complete `NewFeedback` and `Registered` histories from the canonical registries on Ethereum and Base, plus complete Celo reputation history. The remaining 25 chains contribute 73,078 reviews, 13% of the global total, taken from 8004scan's published chain totals. Ethereum was scanned from block 24,339,925 and Base from block 41,663,783. Every referenced feedback file was fetched as untrusted input. I resolved its transaction references on both chains, inspected the transfer logs, and treated “transaction resolves” separately from “file identifies both payment parties.” The partial Taskmarket capture ended at 06:51 UTC on 20 August 2026. It covers 321 readable tasks going back to 4 June; the service reported 373 tasks. By 07:35 UTC, the public list returned only 226, with the earliest on 5 July. These figures describe the captured feed, not a stable live total. The \$3,288.58 figure is the `totalEarnings` value then returned by [`/api/agents/count`](https://api.taskmarket.dev/api/agents/count). The x402 test scanned 43,200 Base blocks and every receipt in them. It counts all EIP-3009 USDC transfers, so it is an upper bound rather than a pure x402 dataset. The concentration and registration figures are an 18 August snapshot. The receipt audit is a 19 August snapshot, covering Ethereum through block 25,787,904 and Base through block 50,169,052. The estimate that 13,284 Ethereum descriptions still load comes from a 500-URI sample. Botoshi's share had stopped growing at Base block 50,108,244; if its mining loop restarts, the 53.8% share will change. A compact [audit manifest](/erc8004/audit-manifest-00c302a37827.json) pins the block cutoffs, category totals, receipt CIDs, and captured Taskmarket aggregates. The raw census is not published with this essay, and the Taskmarket rows were not retained, so those aggregates cannot be independently recomputed from the manifest alone.
## The next proof is a returning customer The system is young, and this audit cannot see work outside the registry. Those limits matter. But Toppa changed the order for me: product first, customers second, onchain identity afterward. The registry can record demand. It cannot create it. Starknet is the one place I found [all three registries deployed](https://github.com/keep-starknet-strange/starknet-agentic/blob/88d98bb021f8b5d291bfdac708942e660595fb3d/docs/DEPLOYMENT_TRUTH_SHEET.md). Its Reputation Registry requires callers to choose reviewers before aggregating—a useful guardrail against a naive global score. The deployment was still new when I checked on 20 August, so I see it as infrastructure worth watching, not a verdict on demand. Writing this also sent me back to the Starknet skill I maintain. I checked it against the deployed ABI line by line and [made ten documentation corrections](https://github.com/keep-starknet-strange/starknet-agentic/commit/72284bd63864cf40ffd2c18b49fa954176466cfb), aligning its claims and examples with the current contracts. That is the kind of work I want this audit to produce: better infrastructure, clearer interfaces, and fewer surprises for builders. Trust systems are easy to describe before checking what each claim proves. In ERC-8004's data today, the noise is much easier to find than the market. ERC-8004 made agents easy to list. The next proof is a customer who pays for a job, accepts the result, and comes back.