TRUSTAGENT

> research :: back to console

Most ERC-8004 reputation is manufactured

We swept every feedback record on Base: 374,082 of them. Three quarters belong to a single agent, written by 62 addresses. Nine out of ten reviewers reviewed exactly once and never again. The standard's anti-self-review check compares addresses, so a fresh wallet defeats it for less than a third of a cent — and reading the Reputation Registry at face value does not merely mislead, it launders paid-for reputation into a number that looks earned.

What the registry actually guarantees

ERC-8004 gives agents an on-chain identity and a place to leave feedback about each other. That is a real contribution: before it, there was no shared namespace for agent reputation at all.

It deliberately stops there. The standard records trust signals and leaves aggregation to downstream consumers — which is the correct division of labour, because aggregation is a judgment call and judgment does not belong in a storage layer. The gap it leaves is not a flaw in the ERC. It is a gap somebody has to fill before the data means anything.

The bug is that identity is an address

giveFeedback refuses feedback from the agent's own owner or operator. That sounds like it prevents self-review. It prevents self-review from a known address.

Fund a new wallet, review yourself from it, repeat. Each new address is, to the contract, a new and unrelated party. The check is not weak — it is answering a different question than the one that matters. Cost per additional "independent" reviewer is a gas fee.

The rule assumes an address is a person. It is a keypair. Anyone can have as many as they are willing to fund.

What that produces — measured on Base at block 49,233,624

We swept every NewFeedback event the Base Reputation Registry has ever emitted, from its deployment block to head. Not a sample: 374,082 records across 27,615 agents from 11,040 distinct reviewers. The raw output is published alongside this page, and the script that produced it is open source — standalone, no API key, no account. Checking a number here should not require trusting the infrastructure that published it.

Measured 28 July 2026 at block 49,233,624. These are counts at that height, not running totals: the registry is still being written to, so a fresh count today returns more. Re-run the script and compare against the pinned output rather than against this prose.

Whole corpus, exact Value
Feedback records374,082
Agents with any feedback27,615
Distinct reviewer addresses11,040
Median records per agent2
Reviewers who rated exactly one agent9,889 (89.6%)
Most agents rated by a single address14,579
Share of all records on one agent75.1%

Three of those deserve saying plainly.

One agent holds three quarters of the registry. Agent 25975 has 280,882 records written by 62 addresses — about 4,530 reviews per reviewer. Whatever that is, it is not 62 people forming an opinion.

It is also still going. Reading the registry's own counters a day after the sweep — getClients for the reviewer set, getLastIndex for each reviewer's count — returns 284,191 records from the same 62 addresses: 3,309 new records in a day, roughly 53 per reviewer per day, every day, from a set of addresses that has not grown by one. That second reading is a different method against the same registry, which is the point: the reviewer count matches exactly, and the record count moves because the corpus does.

Nine out of ten reviewers reviewed once and never again. 9,889 of 11,040 addresses appear a single time. That is the shape a disposable wallet leaves, and it is precisely what an address-scoped anti-self-review check cannot see.

One address rated 14,579 different agents across 21,471 records. The second-busiest rated 11,985.

The two shapes sit side by side in the same registry. Agent 25975: 280,882 records from 62 reviewers — concentrated. Agent 55985: 8,518 records from 7,420 reviewers — fanned out. Both are volume without independence; they differ only in how it was assembled.

The number depends on what you count

We also ran our sybil filter over a sample of 150 agents drawn by hash order — 498 records — and flagged 8.8%. That looks like it contradicts the published survey, which reports 92.6% of Base feedback as coordinated. It does not. The two measure different populations.

Sample agents uniformly and you measure the typical agent: two reviews, most of them ordinary. Weight by record and you measure the corpus, three quarters of which is one agent reviewed by 62 addresses.

Neither figure is wrong and neither is the whole answer. The distribution is bimodal: tens of thousands of agents with a couple of reviews each, and a small number of industrial operations that dominate every record-weighted statistic. A single headline percentage hides that, whichever one you pick.

Our sample is 150 agents and 498 records — 0.133% of the corpus, uniform by agent. It says nothing about the record-weighted share, and we are not presenting it as if it did. Selection is deterministic (SHA-256 of the agentId) so the same draw reproduces exactly.

The same pattern, across three chains

We can only speak first-hand about Base. The most recent multi-chain survey (arXiv:2606.26028, through May 2026) measured the same registries record-weighted, and found the problem is not local to one chain:

Finding (survey, record-weighted) Ethereum BSC Base
Feedback records flagged as coordinated 41.4% 96.3% 92.6%
Reviewers identified as sybil 73.5% 59.2% 90.6%
Affected agents with no valid feedback after filtering 26.4% 77.9% 86.8%
Median cost to move an agent across a threshold $0.055 $0.0042 $0.0027

The last row is the one to sit with. Manipulation is not expensive and rare; on Base it costs less than the transaction that reads it. Our own sweep found the corpus has since more than tripled — 374,082 records against roughly 122,000 at the time of that survey — and the concentration has, if anything, sharpened.

Clustering by who paid for the wallet

A sybil operator can create unlimited addresses. What they cannot easily create is unlimited independent funding sources — every wallet needs its first native token from somewhere, and that first transfer is on-chain and permanent.

So we cluster reviewers by first funder rather than counting them. Each cluster gets one effective vote, regardless of how many addresses it contains. Two hundred wallets funded from one source contribute a single vote, not two hundred.

The effect is on the cost curve: manipulation now scales with the number of independent funding sources an attacker can establish and keep separate, not with the number of keypairs they can generate. That is a materially harder and more expensive problem, and it is the only lever available without off-chain identity.

It is not a proof of honesty. Reviewers funded from a genuinely diverse set of sources still cluster as independent. The claim is narrower and testable: cheap wallet-spam stops working.

The second problem: the numbers are not comparable

Every rating shares one int128 value field, and the ERC defines no scale per tag. In practice the same field carries booleans, 0–5 stars, 0–100 percentages and raw revenue figures — sometimes within a single tag.

Averaging those produces a number with no meaning, and a confident-looking one. So we aggregate strictly per tag, infer the scale each tag is using, and where a tag's values disagree about their own scale we report no mean at all rather than inventing one. A missing average is a worse product demo and a better answer.

The third problem: most agents are not agents

The survey found only 3% / 4% / 15% of registered identities (ETH / BSC / Base) have both a compliant registration file and a live service endpoint. Between 9% and 53% never activate at all — an identity was minted and nothing was ever attached to it.

At the registry level a reserved placeholder and a working agent are indistinguishable. We classify every agent into five quality categories before scoring and cap the score of anything unreachable, because "registered" and "operational" are different claims and only one of them is any comfort when you are about to send money.

What we refuse to do

The failure mode of a scoring service is not being wrong occasionally. It is being confident when it has nothing to be confident about. A trust product that answers block because a data provider was rate-limited has done more damage than one that answers nothing.

So the scoring engine abstains. A rule that cannot be evaluated is excluded and its weight redistributed rather than scored as zero. When no rule can be evaluated at all, the score is null, the band is unknown, and the recommendation is insufficient_data — never block. Absence of evidence is not evidence of guilt, and it is not our place to conflate them.

Every score is also reconstructable: each rule's contribution is published, every hard cap appears with its before, after and reason, and the arithmetic can be checked line by line. If a score cannot show its working, it is an opinion wearing a number.

We read the registries and publish judgment. We never write feedback — so we cannot inflate the dataset we score.

Check it yourself

None of the above is worth taking on trust from a service whose subject is trust. Every claim here is checkable against the live registries.

Free, no wallet, no signup — add to any MCP client:

{
  "mcpServers": {
    "trustagent": {
      "command": "npx",
      "args": ["-y", "trustagent-mcp"]
    }
  }
}

Or over HTTP:

curl "https://trust-agent.io/v1/verify?address=0x…"

The free tier returns a risk band, an OFAC sanctions verdict and flag counts. The paid tiers add the numeric score, the per-rule breakdown, and the sybil-filtered reputation reading described above — from $0.002 per call over x402, with no account.

Registry coverage is live at /stats. Scoring model and weights at /v1/model. TrustAgent is itself registered as eip155:8453:0x8004A169…/60015, so you can run our own liveness predicate against us.