ERC-8004 in practice: the trust features almost nobody uses

1. The payment wallet: set by signature, cleared on transfer

ERC-8004 reserves one metadata key, agentWallet, for "the address where the agent receives payments". It starts as the owner's address. It can only be changed with a signature from the new wallet itself (EIP-712, or ERC-1271 for a contract wallet), and it is cleared automatically when the registration NFT is transferred. That makes it the one field in the standard a reader can trust without trusting the agent.

We checked the zero row against our two records of registration transfers: a history scan, and the live registry feed since late September. 132 of the 185 cleared registrations have a recorded transfer; none of the 402 default ones do. Our history scan is thin after July, which is the likely reason the rest show none. A first, independent sample of 586 gave 65.7%, 34.0% and 0.3%. Our own count of transferred registrations (21.7% of all minted) misses the same recent transfers, so it is a floor.

What it means. A third of agent identities on Base have changed hands, and their new owners have not proven a payment wallet. An integration that reads agentWallet gets the zero address for them and must decide on its own where the money goes. Platforms that mint a registration and then hand it to a user can fix this by having the user sign setAgentWallet as part of the hand-over.

2. Endpoint domains: proof published by almost no one

A registration can list endpoints on any domain, including ones its owner does not control. The standard's optional fix is a file at https://{domain}/.well-known/agent-registration.json whose registrations list names the agent. Our liveness sweep now reads it for every sampled registration whose HTTPS endpoint is not on the domain that serves its registration file.

• First two sweeps (12 Oct 2026): 1 of 642 such registrations was verified. For 9 to 13 more per sweep, some endpoint domain answered at that path. Most answers were HTML pages, or files listing other agents or a registration on another chain, not them.
• One platform's API host carried 271 of the 329 registrations in the first sweep, and it publishes no proof file. The verified rate today mostly describes that one platform, so we publish the concentration beside it (probe.domain.tophost.v1).

Profile links on shared platforms (github.com, x.com and similar) and placeholder names (example.com) are not counted: no agent can publish a proof there.

3. Reviews: the filter the standard asks for keeps almost nothing

ERC-8004's getSummary requires the caller to pass the reviewers it trusts (clientAddresses), because unfiltered feedback is easy to fake. The obvious list is the wallets that actually paid the agent. We publish that list for any agent (/api/payers, the MCP tool payer_set), and measured what such a filter would keep.

• The Base registry held 510,935 feedback entries from 14,914 reviewers on 31,784 agents. The ten largest reviewers wrote 48.0% of them.
• On the agents whose income we read, there are 619 distinct reviewer and agent pairs. In 6 of them (about 1%) the reviewer had paid the agent, in a counted transfer, before its first review.
• Paying first is not independence. One agent's 85 reviews all came from a single wallet that had paid it 45 times. Per review, the grounded share looks like 8.7%; per pair, it is 1%. We count pairs.

4. The money around agents: four risks, measured

Address poisoning. A poisoner plants a look-alike of an address an agent pays, so a later payment copied from history goes to them. We measured our own watch against the method of Tsuchiya, Dong, Soska and Christin (Blockchain Address Poisoning, USENIX Security 2025), which counts a look-alike when the first 3 and last 4 hex characters match.

• The two rules agree on 79,257 plants. Of 82,132 plants either rule counts, our earlier rule (first 4 and last 4) found 80,509 and the paper's found 80,880.
• A second check, read from the chain, found every sampled plant real. All 300 sampled plants were sent by somebody other than the agent wallet, to an address with no contract code. The 50 plants only the paper's rule catches passed the same check, and so did the 50 only ours catches (fake-token plants that match on the last 4 characters alone).
• The watch now counts both (poison.events.24h.v2); no new loss followed.
• Timing: first copies arrive fast (median 13 minutes), but 71% of plants come more than 20 minutes after the payment they imitate, and more than a third a day or more later. A fixed 20-minute window, as in the paper's Ethereum setting, would miss most of them on agent wallets.
• The paper's third kind, a look-alike sending the wallet a few dollars of a real token, is now read hourly. In its first hours there were none among about a thousand incoming transfers. The free kinds (zero-value and fake tokens) are what poisoners use here.

Sandwiches. Using the five sandwich heuristics of Qin, Zhou and Gervais (Quantifying Blockchain Extractable Value, IEEE S&P 2022), we read the blocks of 120 randomly chosen agent swaps from the last 60 days.

• None was sandwiched.
• In the same blocks, 143 of 4,255 swapping transactions (3.4%) matched the pattern, so the method does see sandwiches on Base.
• At that background rate, seeing none in 120 has a chance of about 1.6%. Agents' swaps look less exposed than the average swap. We have not yet tested why.

Token approvals. A drainer rarely needs the agent to send it money; an approval lets the spender take it. We read every approval that paying agent wallets gave in the 30 days to 12 October 2026, on the stablecoins, WETH and cbBTC, directly and through Permit2.

• The scale: 1,489 wallets gave 50,590 approvals to 261 spenders. 720 of those approvals were unlimited.
• Who received them: 256 of the spenders are contracts; 5 are plain keys.
• What is still exposed: 509 unlimited approvals are still standing on 440 wallets, read live from the token contracts, but only about $10,000 sits behind them. Agent hot wallets keep little float, so the exposure is wide and shallow, and it deepens every time a wallet is refilled.
• Concentration: 272 wallets have each given one upgradeable escrow contract an unlimited USDC approval.
• No pulls: no transfer out of a wallet after an approval to a plain key or a one-off unlabelled contract was found.

The list, the spenders and the plain-key approvals with their transactions are at /api/approvals, refreshed daily.

Rank padding. Our L9 level means three or more counterparties in 30 days. 99 of 120 L9 agents have three that are independent of them: a contract, or an address that at least two different agents pay. The other 21 reach L9 only by counting addresses no other agent pays. We now publish both figures side by side (rank.l9.independent.v1).

What changed on our side

• Poisoning rule v2, and the incoming tiny-transfer read.
• An approval watch (/api/approvals): the roadmap item "allowance drains" now has data.
• L9 with independent counterparties, published beside L9.
• The payer set with payment-grounded feedback, free.
• Endpoint-domain verification in the liveness sweep.
• An append-only log over our signed statement roots, built like Certificate Transparency (/api/statements/log): keep a signed head, and a later consistency proof shows our history was not rewritten.
• A data check that flags steps in our own series that no dated change explains (/api/steps).

Each one is in the October changelog with its definition.

Method and limits

• All Base. Registry calls are read from a public node; the sweeps sample the registry's token ids uniformly. Figures in this article are frozen to 12 October 2026; the linked definitions carry the live values.
• Payers are observed payers. They come from the stablecoin income we read into ranked agents' wallets and from payments between registered agents. An agent paid through a route we do not read looks unpaid here.
• A detection or a plant is a shape with evidence, never a verdict. A sandwich match is a pattern, not proof of intent.
• Every count can be re-run from the public API and the definitions; the evaluation files are kept with their parameters.

Questions people actually ask