ERC-8004 Trust Signals: What the Registry Can and Cannot Tell You About an AI Agent

ERC-8004 gave AI agents a shared on-chain identity, and that is a real step forward. It is not a trust verdict. This guide explains what the standard records, which signals it leaves out, and how independent evidence about wallets, funding chains and fleets fills the gap. It draws on the public specification and on ChainAware’s weekly tracker of registered agents.

When a standard goes live, people often read more into it than it says. ERC-8004 is a good example. Its name includes the word “trustless,” and its registries carry words such as reputation and validation. As a result, many readers assume that a registered agent has passed some kind of check. In fact, registration is open, cheap and unvetted. An agent that appears in the registry exists. Beyond that, the registry says very little about whether the agent deserves access to money.

That distinction matters because agents now touch real value. They manage positions, settle payments and call other agents. Therefore, every protocol, marketplace and payment team needs a way to decide which registered agents to trust, and how far. The decision needs evidence, and the evidence lives mostly outside the registry.

This article walks through the standard in plain language, then lists the trust signals that surround it. It uses public data throughout: the specification itself, ChainAware’s launch analysis of 274,792 indexed agents and the weekly Agent Trust Tracker. Finally, the article keeps a clear view of limits, because every signal has blind spots.

What ERC-8004 Is

ERC-8004 is an Ethereum standard titled Trustless Agents. Its stated purpose is to discover agents and establish trust through reputation and validation. The specification on the Ethereum EIP site credits Marco De Rossi, Davide Crapis, Jordan Ellis and Erik Reppel as authors, and it builds on four existing standards: EIP-155, EIP-712, ERC-721 and ERC-1271. At the time of writing, the EIP site lists the standard as a Draft. ChainAware tracks live agents on Ethereum mainnet, where the registries went live in January 2026, and on additional EVM chains.

The standard defines three lightweight registries.

• An identity registry gives each agent a portable, globally unique on-chain identity.
• A reputation registry lets clients post feedback about an agent.
• The validation registry lets an agent’s owner request independent checks of the agent’s work.

Minimalism drives the design. The registries store small, standard records and leave heavy logic to other layers. In addition, the standard describes trust models as pluggable and tiered. Depending on the value at risk, a system can lean on reputation, on stake-secured re-execution, on zero-knowledge proofs or on trusted execution environments.

Why the Standard Exists

Before ERC-8004, agents from different platforms had no shared way to introduce themselves. One framework might name an agent one way, and a second framework would use another name. Discovery was hard, and trust signals could not travel with the agent. The standard attacks that problem by giving agents a common identity format and a common place to publish feedback.

This is useful for the whole ecosystem. A developer can register an agent once and let any compatible client find it. Likewise, a buyer can look up an agent in a shared registry. Meanwhile, researchers gain a public dataset to study. Without ERC-8004, a project like ChainAware’s tracker would have nothing to index.

Anatomy of an ERC-8004 Registration

The identity registry builds on ERC-721, the standard for non-fungible tokens. Each agent becomes an NFT. The agent’s identifier is the token identifier, and the token’s URI points to a registration file. Globally, an agent is identified by a combination of a namespace, a chain identifier, the registry address and the agent identifier.

The table below shows the main fields and how much trust each one can carry.

Field	What it holds	Trust value
Identity token	An ERC-721 token that names the agent	Proves existence and uniqueness only
Owner address	The wallet that controls the token	High: its history can be checked
Agent wallet	The address linked to the agent, starting as the owner’s address	Medium: shows the money path
Registration file	JSON with name, description, endpoints and supported trust models	Low: self-reported claims
On-chain metadata	Optional key-value data set by the owner	Low: self-reported
Reputation entries	Feedback posted by other addresses	Low to medium: depends on who posts
Validation records	Responses from designated validators	Higher, if the validator is credible

A pattern emerges from the table. Fields that the operator writes freely carry little trust. In contrast, fields that connect to on-chain history carry more. A good scoring approach therefore concentrates on the owner address and the agent wallet, and on what surrounds them.

The Registration File

The registration file is a JSON document, and it can live on IPFS, on an HTTPS endpoint or inside a data URI. It lists the agent’s name, description and image. Beyond that, it lists the services the agent offers, such as web endpoints or other agent protocols, and it can name the trust models the agent supports.

The file works like a business card. It tells others how to reach the agent and what the agent claims to do. However, it carries no proof of the claims. An owner can describe a sophisticated trading engine in the file and deploy a trivial script. The standard itself acknowledges this limit and notes that it cannot cryptographically guarantee that advertised capabilities are functional and non-malicious.

The Agent Wallet

Separately, the standard reserves an agent wallet field. It starts as the owner’s address. Changing it requires a signature from the new wallet, using EIP-712 for ordinary accounts and ERC-1271 for smart contract wallets. The field clears when the token transfers and must be verified again.

This rule is a sensible protection against hijacked metadata. For risk analysis, it also creates a useful anchor: the agent wallet is a verified address that a counterparty can inspect. Its history, funding and activity become evidence.

The Optional Trust Field

The registration file can include a list of supported trust models. This field is optional. When it is absent or empty, the specification says the standard serves discovery only and makes no claim about trust. This detail matters, because many registered agents leave the field empty. For them, the registry gives an address and a description, and nothing more.

The Reputation Registry in Detail

The reputation registry is the part of ERC-8004 that most people mean when they say “agent reputation.” It lets a client submit feedback about an agent, and it stores a compact record on-chain.

How Feedback Works

A client calls a function to give feedback. Each entry stores a signed value with a number of decimals, two optional tags and a flag that shows whether the client later revoked the entry. Other data, such as an endpoint reference, a feedback file link and a hash of that file, appears in emitted events and stays off-chain storage. A client can revoke its own feedback, and anyone can append a response, for example to flag spam or to show a refund.

The registry can also return an on-chain summary. To limit spam, the summary function requires the caller to name the client addresses whose feedback should count. The specification expects more complex aggregation to happen off-chain.

One rule protects against the most obvious abuse. The specification forbids the agent’s owner or an approved operator from submitting feedback for that agent. A developer cannot simply rate their own agent from the owner address.

Why the Rule Is Not Enough

The rule closes the front door and leaves the side door open. An operator who controls several wallets can post feedback from wallets that are not the owner or an approved operator. The contract cannot know that those wallets share a controller. Yet the specification admits the risk directly: Sybil attacks are possible and can inflate the reputation of fake agents. It expects reputation systems to filter by reviewer.

Consider a simple case. One operator controls twenty wallets and twenty agents. Each wallet posts a positive review for several agents it does not own. The registry now shows agents with long lists of positive feedback, and nothing in the on-chain data marks the reviews as coordinated.

A defense must look at the reviewers, not the review count. Three questions help.

1. How old is the reviewing wallet, and does it have unrelated activity?
2. Who funded the reviewing wallet, and does the same source fund the agent’s owner?
3. Does the reviewer post for many agents from one operator and nobody else?

Reviewers with real history, independent funding and a record of unrelated activity carry weight. In contrast, reviewers created last week and funded by the owner’s own feeder carry almost none. This is the same fleet logic that drives farm detection, applied to feedback.

What Good Reputation Weighting Looks Like

A sound weighting step has four parts. It discounts feedback from wallets that share a feeder with the agent’s owner. Likewise, newly created wallets receive a discount. Third, it favors reviewers that have also paid or transacted with the agent, since economic activity is harder to fake than a rating. Finally, it reports confidence alongside the score, so that a thin record looks thin.

Protocols that rely on registry feedback alone should add at least a simple version of this step. Otherwise, they measure the operator’s effort, not the agent’s quality.

The Validation Registry and Pluggable Trust

The validation registry takes a different route. It lets an agent’s owner or operator request an independent check, and it lets a designated validator answer. The request carries a reference and a hash. Then the validator responds with a number from 0 to 100, and it can respond more than once, for example to show progress from a soft to a hard confirmation.

Incentives and slashing stay out of scope in the specification. Specific validation protocols supply those. The standard names several trust models that such protocols can use:

• Reputation-based trust, where clients vouch for the agent.
• Stake-secured re-execution, where validators re-run the work and risk a deposit if they approve bad results.
• Zero-knowledge machine learning proofs, where the agent proves that a computation ran correctly.
• Trusted execution environment oracles, where hardware attests to the code that ran.

These models give the standard a route toward real cryptographic assurance. In practice, they are still maturing. Most agents today rely on reputation-style signals or on third-party scoring. Therefore, the practical question for most teams is how to read signals around the registry, not how to wait for perfect validation.

What the Registry Can and Cannot Tell You

With the three registries in view, the boundaries become clear.

What the Registry Tells You Reliably

• Existence. Does this agent have a valid registration?
• Ownership. Which wallet owns the identity token?
• Agent wallet. What address links to the agent?
• Description. Where does the registration file say the agent does, and where does it run?
• Feedback history. Which reports have other addresses posted, and when?
• Validation history. Validator responses, with the result of each.

These facts are valuable. They let a counterparty find an agent, address it and refer to it consistently.

What the Registry Cannot Tell You

• Whether registration was vetted. No one reviews a registration before it goes live.
• Whether the claims are true. The registration file is self-described.
• Whether feedback is independent. Reviewers can share a controller.
• Whether the owner has a bad record. The registry shows who owns the token. It does not show that wallet’s history.
• Where the money came from. Funding sits outside the record.
• Whether the agent is one of many. Each registration stands alone, so fleets stay invisible.

The Gap, Summarized

The registry gives structure. A scoring layer supplies judgment. Judgment cannot live inside an open registry, because the registry would need to decide whom to believe, and in doing so it would become a gatekeeper. Keeping the registry neutral and letting independent scorers compete is the healthier design. Our guide to KYA versus agent identity explains how this split fits into a wider Know Your Agent process.

The Trust Signals That Surround the Registry

Independent scoring supplies the missing signals. ChainAware’s Agent Trust Score reads three core groups of evidence, then adds a fleet view. Each group fills one of the gaps listed above.

Signal 1: The Owner Wallet’s Fraud Probability

The owner wallet is the most direct link to a real party. ChainAware’s behavioral models estimate a fraud probability for the wallet from its on-chain history. A wallet that behaves like previous fraud accounts raises risk even when nobody has reported it. This matters because new attack wallets appear constantly, and a blacklist can only name those that someone already caught. The article on forensic versus AI-based crypto analytics explains the difference.

For a deeper look at a suspicious owner, teams can run the wallet through ChainAware Investigation. It returns a seven-section report in about a minute, covering identity, activity, counterparties, risk, circular flows and AML exposure.

Signal 2: The Feeder Address

The feeder is the address that funded the owner wallet. It is one of the most informative signals available, and the one that operators find hardest to fake. The reasoning is simple. An operator can write any registration file. It cannot rewrite who sent its first funds.

The feeder falls along a spectrum.

Feeder type	Flag	Reading	Typical response
Verified centralized exchange	FEEDER_CEX_VERIFIED	Strongest positive signal, because the exchange applied its own checks	Raise trust, still check the other pillars
Ordinary traceable wallet	No flag	Neutral, so judge on other evidence	Standard policy
Unknown or untraceable	FEEDER_UNKNOWN	Risk, because the source of funds cannot be established	Apply limits and monitoring
Confirmed fraud or rug pull history	FEEDER_RUG_HISTORY	Hard suppression of the score	Block or escalate

ChainAware traced a feeder for roughly 38% of indexed agents, so the signal is missing for many. When it is present, it carries weight. At launch, only 1.0% of agents had a verified-exchange feeder, while 9.5% had an unknown feeder and 0.3% had a feeder with rug pull history. A further 741 agents had been funded by confirmed rug pull operators.

Signal 3: The Creator’s Record

The creator’s wallet history carries forward. Past rug pulls and honeypot deployments are strong negatives. Bad actors rarely stop after one attempt, and a creator that funds a fresh owner wallet passes along a shadow of its history. The launch analysis flagged creator rug pull history for 0.02% of agents and creator honeypot history for only a handful of agents. These flags are rare, yet they are decisive when present.

Signal 4: Fleet-Level Farm Detection

Fleet detection compares agents with one another. It looks at shared funding, registration timing and clustered ownership to find groups that one operator probably controls. At launch, 21.1% of indexed agents carried the farm flag. Later tracker weeks put the share between roughly 16% and 19%. These figures show that coordinated operators account for a large part of the registry.

Signal 5: Delegation and Account Type

EIP-7702 lets an ordinary account delegate execution to contract code. The EIP7702_DELEGATED flag marks owner accounts that do. Delegation has legitimate uses, such as batching and gas sponsorship, so the flag is not a verdict. Nevertheless, it changes how an account behaves and deserves a second look, especially when it appears next to an unknown feeder. The Week 40 tracker showed delegation up 33.8% since Week 35, as the Week 40 report describes.

From Signals to a Score: How the Agent Trust Score Works

In turn, the score turns these signals into one number between 0 and 1,000, a tier and a set of flags. Three pillars drive it: the owner wallet’s fraud probability, the feeder address and the creator’s criminal record. Fleet-level detection adds the last layer. A fraud-history feeder hard-suppresses the score, whatever the other pillars show. By contrast, a verified-exchange feeder lifts it, although only when the rest of the evidence agrees.

The five tiers map to access decisions.

Tier	Score	Suggested access
Sovereign	800-1000	Full autonomous access, including large-value flows
Trusted	600-799	Standard integrations, with monitoring available
Provisional	400-599	Monitoring required, low-risk workflows only
Elevated Risk	200-399	Restricted: size limits, velocity caps and real-time monitoring
Untrusted	0-199	Block at the access control layer

Coverage includes Ethereum, BNB Smart Chain, Base and Avalanche C-Chain, and Mantle support is in progress. The free tier allows 1,000 queries per month with no signup. Larger teams can use the fraud detection API, and agents can call the same intelligence through the Prediction MCP. The launch article explains the model and the first registry analysis in full.

Why a Score and Flags Together

A score alone hides the reasons. Flags alone give no ranking. Together, they let a team set a policy by tier and explain each decision by flag. For example, a protocol can require Sovereign tier for vault access and also reject any agent with a farm flag. When a protocol declines an agent, it can name the flags that drove the decision. That record protects the protocol and gives the operator a path to improve.

What the Data Shows About the Registry

A trust layer is only useful if it finds real differences between agents. The public numbers show that it does.

The Launch Analysis

At launch, ChainAware’s analysis covered 274,792 indexed agents. The tier split showed a polarized population.

Tier	Share of agents at launch
Sovereign	20.9%
Trusted	12.7%
Provisional	14.6%
Elevated Risk	25.8%
Untrusted	26.0%

Together, 51.8% of agents sat in the two lowest tiers. At the same time, one in five agents (21.1%) carried the farm flag. The distribution has two peaks, a large group at the top and a larger group at the bottom, with fewer agents in the middle. Meanwhile, the Week 29 tracker saw the same shape across 317,589 agents, where 27.5% were Untrusted and 21.3% were Sovereign, as the Week 29 report shows.

A Timeline From the Weekly Tracker

A weekly view adds a time dimension. Figures in the list come from the published posts.

Week	What the tracker reported
29	11,026 new agents, down 54.9%. Median trust of new agents 406.
30	22,989 new agents, more than double. Median trust 299, the Elevated Risk tier.
31	21,378 new agents, but unique owners fell 58.7% to 8,413. Agents per owner reached 2.54. Median trust 200.
32	15,652 new agents. Median trust 521. The first full flag breakdown showed 18.73% of agents flagged as farms.
34	31,979 new agents, an all-time high. Median trust 563.
36	24,173 new agents. Median trust 918, a record and the first weekly median in the Sovereign tier.
38	17,001 new agents. Agents per owner 2.30. Median trust 200.
39	5,720 new agents, the lowest since Week 14.
40	6,893 new agents. Farm share 16.12%. Population 518,885.
41	10,706 new agents. Median trust 101, the lowest since Week 5. Population 568,590.

What the Timeline Teaches

Three lessons stand out.

First, volume and quality move independently. Week 34 set the registration record, while Week 41 set the trust low. A dashboard that celebrates registration growth says nothing about whether the new agents deserve access.

Second, concentration shows up as a ratio. When registrations hold up while unique owners fall, a few operators drive the growth. Week 31 and Week 38 both followed that pattern, and both showed a median trust of 200. The Week 31 report and the Week 32 report explain how concentration and farm flags connect.

Third, funding is getting harder to trace. In Week 41, the share of agents with an unknown feeder nearly doubled to 12.84%. A weaker funding signal makes the other pillars matter more, and it raises the value of fleet detection.

The Week 36 report also shows that records cut both ways. A record-high median in one week fell back within seven days, which shows how much a single large operator can move the figure.

How to Read Trust Signals: A Practical Checklist

Use the list below when you assess any ERC-8004 agent. The order moves from validity to risk.

1. Confirm the registration. Check that the agent is registered, that the owner wallet is clear and that the registration file resolves.
2. Compare the tier. Sovereign and Trusted agents justify more access than Elevated Risk or Untrusted agents.
3. Read the flags. A farm flag or a fraud-history feeder flag overrides a polished registration file.
4. Look at the feeder. A verified-exchange feeder is positive. An unknown feeder calls for limits.
5. Check the delegation flag. EIP-7702 delegation is not bad by itself, yet it deserves a closer look next to other warning signs.
6. Treat feedback counts with care. Look at who posted the feedback, not how much there is.
7. Search for validation records. A credible validator’s response carries more weight than a pile of ratings.
8. Re-check later. Scores change as behavior changes, so schedule the next look.

Step by Step: A One-Minute Lookup

A lookup takes about a minute and needs no signup.

1. Open the Agent Trust Score tool and enter the agent or its owner address.
2. Read the tier and score first, since they give the headline.
3. Scan the flags, because they explain the score.
4. Compare the tier with the access you plan to grant.
5. For automated flows, call the same data through the API or the MCP instead of the page.

When the score raises a concern, open a deeper review. The article on wallet forensics and AML reports shows how analysts use Investigation for that step.

A Worked Example: Reading Two Registrations

This example is illustrative. Both agents and numbers are invented to show the method, and they do not describe real registrations.

Two agents ask a lending protocol for vault access. Both appear in the ERC-8004 registry, and both have polished registration files with clear service descriptions. Each shows dozens of positive feedback entries.

The protocol starts with the owner wallets. Agent A’s owner wallet is two years old, funded by a verified exchange, and active in unrelated protocols. Meanwhile, Agent B’s owner wallet is three weeks old. An unlabeled address funded it, and that address funded eleven other owner wallets in the same hour.

Next, the protocol looks at the feedback. Agent A’s reviewers include old wallets with independent funding and real transaction history. In contrast, Agent B’s reviewers are mostly new wallets funded by the same unlabeled address that funded the owner.

The scores follow. Agent A lands in the Trusted or Sovereign range and receives the vault access it requested. In contrast, Agent B carries a farm flag and an unknown-feeder flag, so it lands in Elevated Risk. The protocol declines the request and stores the flags as the reason.

Nothing in the registry separated the two agents. The registration files looked equally professional, and both showed positive feedback. Instead, the difference sat in the wallets behind them.

Why Funding Evidence Resists Manipulation

Of all the signals around ERC-8004, funding evidence deserves a closer look, because it behaves differently from the others. A registration file is free text. Feedback can come from many wallets. Funding, by contrast, leaves a record that the operator cannot edit after the fact.

Three properties make funding evidence hard to game.

Cost. Obtaining funds from a verified exchange requires passing that exchange’s checks. Operators who want the strongest positive signal must therefore pay in time, identity and compliance effort. By contrast, operators who skip the effort end up with an unknown or untraceable feeder.

Linkage. Farms need many wallets, and many wallets need funding. Operators usually draw that funding from a small set of sources, because splitting every top-up across unrelated origins costs effort. Shared feeders therefore expose fleets, even when each owner wallet looks independent.

Permanence. The first funding transaction of a wallet stays on the chain forever. An operator can change its registration file tomorrow. It cannot change who sent the first funds yesterday.

The Limits of Funding Evidence

None of this makes funding evidence perfect. A determined operator can route money through several hops, or it can fund wallets through exchange accounts that pass basic checks. Heavy obfuscation tends to push the feeder into the unknown category, which carries its own penalty. Still, a score that relies on funding alone would miss operators who use clean sources. For that reason, the Agent Trust Score combines the feeder with the owner wallet’s fraud probability, the creator’s record and fleet-level detection.

How ERC-8004 Fits the Wider Agent Standards Landscape

ERC-8004 does not stand alone. Several other efforts address parts of the same problem, and each one covers a different layer. Understanding the landscape helps teams combine the pieces.

Identity and KYA Frameworks

Trulioo describes Know Your Agent as an identity layer built around a Digital Agent Passport, a tamper-proof token that carries an agent’s origin, legitimacy, authorization and user consent. Its explanation of KYA frames the idea in payments terms. Baselayer raised a $35 million Series A to extend its verification tools to agents, according to coverage of the round. These frameworks mainly answer who is behind an agent.

Payment Protocols

Payment protocols address authorization and transport. Google’s Agent Payments Protocol, known as AP2, uses verifiable credentials and signed mandates to record what a user asked for and approved. Its announcement describes it as an extension of existing agent communication standards. OpenAI and Stripe launched the Agentic Commerce Protocol, which lets an agent pay through a shared payment token, as Payments Journal reported. These protocols mainly answer what the agent may do and how it pays.

Where ERC-8004 Sits

ERC-8004 sits between the two. It gives agents a public identity and a shared place for feedback and validation, and it does so on open infrastructure. Unlike closed credential systems, it exposes every registration to any observer. That openness is the reason a project like ChainAware’s tracker can measure the whole registry.

Where Behavioral Evidence Fits

None of these layers measure how an operator behaves with money. A passport proves origin. Meanwhile, a mandate proves permission. Likewise, a registry entry proves existence. Behavioral evidence adds the missing question: how risky is this operator? A commentary on the liability picture in agentic commerce notes that traditional behavioral signals such as device and typing patterns disappear when software buys on a user’s behalf. That deep dive is opinion, not settled rule, yet the underlying point holds. When human signals vanish, risk teams need new signals that describe the agent and its operator.

A Closer Look at Fleet Detection

Fleet detection deserves its own section, because it catches what no single-agent check can see. A single agent can look healthy while hundreds of siblings sit behind it. Detecting the group requires comparing agents with one another.

Signals That Suggest a Fleet

Several signals point to a shared operator.

• Shared feeders. Many owner wallets funded by the same source.
• Registration timing. Dozens of agents registered within the same short window.
• Template metadata. Near-identical registration files with only names changed.
• Clustered ownership. Many agents controlled by few owner wallets.
• Reviewer overlap. The same small group of wallets posting feedback across many agents.

No single signal proves a farm. Legitimate teams also register agents in batches and reuse templates. The combination, however, is hard to explain innocently, and that is where detection earns its value.

What to Do With a Fleet Flag

A farm flag should change how a counterparty treats the whole group. Three responses work well.

1. Treat linked agents as one risk unit. Aggregate limits across the group.
2. Apply the weakest tier in the group to all members, until the operator proves independence.
3. Review the operator, not just the individual agent.

These responses prevent a common trick. Operators split a large request across many agents so that each request looks small. Aggregation at the operator level closes that loophole.

Designing an Access Policy by Tier and Flag

Policy turns scores into rules. A good policy combines tiers with flag overrides. The example below is a starting point, and each team should adjust it to its own risk appetite.

Requested access	Minimum tier	Flag overrides
Read-only data	Provisional	Reject on FEEDER_RUG_HISTORY
Small payments or swaps	Provisional	Cap value on FEEDER_UNKNOWN
Standard integrations	Trusted	Reject on FARM_DETECTED unless reviewed
Vault or lending access	Sovereign	Reject on any farm, unknown-feeder or rug-history flag
Treasury permissions	Sovereign	Add human approval above a threshold

Rules like these have three advantages. They are easy to explain to auditors, they are easy to automate and they give operators a clear target. A short rollout plan helps teams adopt them.

1. Week 1: inventory. List every place where an agent can touch money or permissions, and rank each place by value at risk.
2. Week 2: observe. Look up the counterparties you already see and record their tiers without blocking anyone.
3. Week 3: write policy. Define one rule per access level.
4. Week 4: enforce and re-check. Turn the rules on for new agents, add a scheduled re-score and review exceptions weekly.

The plan needs no heavy integration. It needs a clear owner and the discipline to write the policy down.

Four Fraud Patterns That the Registry Alone Cannot Show

Reading the weekly data in order reveals patterns that single reports hide. Each pattern exploits the open design of the registry, and each one calls for a different defense.

Pattern 1: Concentration Bursts

A concentration burst appears when registrations rise or hold steady while the number of unique owners falls. Therefore, a few operators account for the growth. Week 31 is the clearest case. Registrations dropped only 7.0% to 21,378, yet unique owners collapsed 58.7% to 8,413. Agents per owner more than doubled to 2.54, and median trust fell 33.1% to 200.

Week 38 repeated the shape. Registrations rebounded 74.5% to 17,001, owners grew only 10.2% to 7,405, and agents per owner reached 2.30. Median trust again dropped to 200.

Week 30 offers the contrast. Registrations more than doubled to 22,989, and owners grew almost as fast, up 96.9%. That is broad-based growth, and it carried no concentration signature. Trust was still low, with a median of 299, but the pattern differed.

Defense: Watch the agents-per-owner ratio. Aggregate limits by owner and by feeder, so that one operator cannot multiply its access across many agents.

Pattern 2: Farms That Stay Large

Farm detection flagged 21.1% of agents at launch. Later weeks showed 18.73% in Week 32, 18.39% in Week 33, 17.05% in Week 34 and 16.12% in Week 40. The share eased as the population grew, but the absolute number of flagged agents did not shrink. On an index of 568,590 agents, even 16% is a large group.

Farms matter for three reasons. They inflate registry counts. Next, they manufacture reputation by reviewing one another. And they position operators to claim incentives or access that was meant for many independent parties.

Defense: Never read an agent count as a count of independent participants. Ask how many operators stand behind it, and treat linked agents as one risk unit.

Pattern 3: Funding That Gets Harder to Trace

The unknown-feeder share stood at 9.5% at launch. By Week 41, it had nearly doubled to 12.84%. The feeder is the hardest signal to fake, and an untraceable feeder weakens it. Operators who want to hide their funding can add hops, yet each hop leaves a trace, and heavy obfuscation tends to push the feeder into the unknown category, which carries its own penalty.

Defense: Raise review thresholds when the unknown-feeder share rises. Cap value for unknown-feeder agents instead of blocking them outright, since some privacy-minded operators are legitimate.

Pattern 4: Delegation Growth

EIP-7702 delegation rose 33.8% between Week 35 and Week 40. Delegation lets an ordinary account hand execution to contract code. It brings real benefits, such as batching transactions and sponsoring gas. Yet it changes how an account behaves, since the account can now do more than a simple key pair.

Defense: Treat delegation as a prompt to look closer, not as a verdict. Review delegated accounts before granting permissions that matter.

How the Patterns Reinforce Each Other

The four patterns feed one another. Concentration bursts bring more farm-flagged agents. Farms prefer opaque funding. Opaque funding lowers trust scores. Lower scores pull down the weekly median. A single operator-driven registration wave can produce all four signs in one week. This is why a score should combine several pillars instead of relying on one.

What Fraud Looks Like in an Open Registry

It helps to name what these patterns make possible. The tracker cannot prove intent in any single case. It shows distributions, and the distributions show where risk concentrates.

• Reputation farming. Operator-controlled wallets review one another’s agents to look established.
• Incentive capture. Many agents from one operator claim programs built for independent users.
• Disposable agents. An operator creates agents, uses them for a harvesting action and abandons them. The creator’s record then moves to a new wallet.
• Laundered credibility. A creator with a bad record funds a clean-looking owner wallet.
• Counterparty exposure. Honest platforms integrate a farm agent and take on its risk.
• Misleading claims. An agent describes sophisticated capabilities in its registration file and delivers nothing of the kind.

The study discussed in our article on how investors should evaluate AI trading agents supports the last point. A May 2026 paper from researchers affiliated with Pantera Capital, Stanford, IC3 and Ava Labs examined more than 1,900 AI-tagged crypto projects and found that even agents with fully public wallets could not always be verified as autonomous. Claims in a card or a whitepaper need evidence behind them.

Who Benefits From Reading These Signals

Different teams meet registered agents in different places. Each one can act on the signals in a specific way.

DeFi Protocols and DAOs

Protocols can set tier thresholds for vault, lending and treasury access. They can also reject any agent with a farm flag or a fraud-history feeder, whatever its tier. The guide to Web3 trust verification systems maps the five categories of trust problems, and agent access touches several of them.

Agent Marketplaces and Registries

Marketplaces can rank listings by trust and show flags next to each one. Ranking by star rating or registration age rewards the easiest metrics to manufacture. A visible tier and flag set rewards operators that keep a clean, traceable record.

Payment and Fintech Teams

Where settlement runs on-chain or through stablecoins, wallet-level trust becomes a direct input to risk rules. The tier can set limits, and the flags can trigger review. Payment teams also face a wider problem, since agents remove the human signals that fraud models rely on. Behavioral evidence about the operator restores part of that signal.

Investors and Strategic Partners

Investors should ask any agent project to show its funding chain and fleet structure. A project that cannot, or will not, has told you something. The data also gives investors a market view. A registry with more than half a million entries and a record-low median trust is a market that needs a trust layer.

AI Agent Developers

Developers who build agents can use the score for two purposes. They can check counterparties before they pay or call another agent. Alternatively, they can monitor their own agents’ standing and fix problems early. Agents can call the score through the Prediction MCP, which turns trust checking into a machine-to-machine step. ChainAware’s own fleet works this way, as the overview of the 32 Claude sub-agents shows.

Compliance and Security Teams

Compliance teams already ask where money came from and who stands behind an account. The feeder check applies that familiar question to agents. For regulated teams, autonomous compliance screening shows how agents and screening fit together.

How Operators Can Improve Their Standing

A trust layer should reward good behavior. Operators who want better tiers can take clear steps.

• Fund owner wallets from a verified exchange account.
• Avoid sharing one funding source across many unrelated owner wallets.
• Keep owner wallets active and consistent over time.
• Separate treasury, operating and test wallets, and document their roles.
• Avoid funding from addresses with fraud-linked history.
• Seek feedback from independent, established clients.
• Request validation from credible validators when the use case justifies it.

None of these steps is a trick. They are signs of an operator with a traceable, stable record, which is exactly what a counterparty wants to see.

Mistakes to Avoid When Using Registry Data

Teams repeat a handful of mistakes. Avoiding them saves time and losses.

• Counting reviews as trust. The volume of feedback is easy to manufacture, so read the reviewers.
• Believing the registration file. It is a claim, not a proof.
• Ignoring the owner. The agent can be new while its owner has a long record, or the reverse.
• Checking once. Fleets, owners and funding evolve.
• Treating the registry as a whitelist. A registered agent is only a known agent.
• Blocking every unusual signal. An unknown feeder or a delegated account calls for limits and review, not automatic rejection.
• Using one threshold for everything. A low-value task and a treasury permission deserve different tiers.

Implementation Notes for Developers

Developers who add registry signals to a product face a few design choices. The notes below describe the patterns that work best.

Keep the layers separate in code. Store registry facts, such as identity and feedback, apart from scores and flags. Registry facts change on-chain events. Scores change as behavior changes, so they need different refresh schedules.

Cache with care. A score from last month may no longer apply. Choose a time to live that matches the value at risk, and force a fresh lookup before large actions.

Log every decision. Record the tier, the flags, the policy rule that fired and the time of the lookup. Compliance teams and operators will ask why an agent was declined, and the log answers in seconds.

Fail safe. If a lookup fails, fall back to a low-limit policy instead of full access.

Handle partial data. A feeder was traced for about 38% of agents, so many lookups will show no funding evidence. Treat missing data as a reason for caution at high value, and as normal at low value.

Expose a path to appeal. Operators who improve their history should be able to earn a better tier. A trust layer that cannot change its mind becomes a blacklist.

Calling the Score From an Agent

Agents can query the score themselves. Through the Prediction MCP, an agent can look up a counterparty before it pays or delegates work. The decision logic stays simple, because the output has a fixed structure. For example, an agent can proceed automatically with Sovereign counterparties, ask for confirmation with Provisional ones and decline Untrusted ones. The article on the Prediction MCP for AI agents explains the wider design, and the guide to blockchain data providers for AI agents maps the data sources that agents can use.

Metrics That Show Whether the Signals Work

A trust process deserves measurement. Teams can track a short list of indicators and tune thresholds with data.

• Approval rate by tier. Higher tiers should show higher approval rates.
• Loss and dispute rate by tier. Lower tiers should account for more incidents. If they do not, the thresholds need work.
• Farm-flag share. A rising share signals growing operator concentration.
• Unknown-feeder share. Growth here weakens the funding signal.
• Re-check coverage. The percentage of active agents scored within the chosen time window.
• Overrides. Every manual override needs a reason, and a pattern of overrides points to a policy gap.

Leadership benefits from these numbers too. They turn a vague promise of agent security into a visible control with measurable results.

A Short Glossary of ERC-8004 Trust Terms

The glossary below defines the terms used in this article.

• ERC-8004: an Ethereum standard for agent discovery and trust, built around identity, reputation and validation registries.
• Identity registry: the registry that mints an ERC-721 token for each agent and points to its registration file.
• Registration file: a JSON document with the agent’s name, description, endpoints and supported trust models.
• Agent wallet: the address linked to the agent, which starts as the owner’s address.
• Reputation registry: the registry where clients post feedback about an agent.
• Validation registry: the registry where validators answer an owner’s request to check an agent’s work.
• Sybil attack: the use of many fake identities by one party to gain influence or rewards.
• Feeder wallet: the address that first funded the owner wallet.
• Farm-detected: a flag for agents that appear to belong to one operator’s fleet.
• EIP-7702: an Ethereum upgrade that lets an ordinary account delegate execution to contract code.
• Agent Trust Score: ChainAware’s 0 to 1,000 rating for ERC-8004 agents, with five tiers and named flags.

Limits of the Signals

Honest use of any signal needs a clear view of its limits. The list below applies to ChainAware’s score and to any similar system.

• Coverage is partial. ChainAware traced a feeder for about 38% of indexed agents, so the funding signal is missing for many.
• A clean feeder is not a clean agent. Bad actors can use exchange accounts, so combine the pillars.
• An unknown feeder is not proof of fraud. Privacy-minded users and bridge routes also hide origins.
• Flags describe risk patterns. They are not proof of wrongdoing, and they justify limits and review, not automatic judgment.
• Scores reflect the evidence available at the time. Behavior changes, so scores change.
• The tracker covers indexed agents. It does not cover every agent everywhere, and weekly medians can swing when one large operator dominates a week.
• On-chain scoring covers on-chain agents. Agents that never touch a public chain need their own behavioral sources.

These limits explain why the score combines several pillars and why teams should pair it with identity checks, authorization records and their own policy.

How ERC-8004 and a Trust Score Divide the Work

The registry and the score do different jobs, and neither replaces the other.

First, the registry provides structure. It gives agents a common name, an owner and a place to publish a registration file, and it gives clients a place to post feedback. Standards like this make an ecosystem interoperable.

The scoring layer provides judgment. It turns open data into a rating that a protocol can act on. Different scorers can offer different methods, and buyers can compare them. Our overview of the agent trust infrastructure race maps how providers approach the problem. The important rule for buyers is to use a scorer that shows its evidence, so that the rating can be checked.

Overall, the split keeps the registry neutral. It also lets the market improve scoring methods without changing the standard. For readers who want the DeFi builder’s perspective, the article on why trust comes before integration walks through the first steps.

Where Agent Registries Are Heading

Several trends will shape the next stage.

Validation Will Mature

Stake-secured re-execution, zero-knowledge proofs and trusted execution environments promise cryptographic assurance. As validation protocols mature, high-value flows will lean on them. Reputation and scoring will still matter, since they cover the large set of agents that never request validation.

Registries Will Spread Across Chains

ChainAware already indexes agents on Ethereum, BNB Smart Chain, Base and Avalanche C-Chain, with Mantle in progress. As more chains adopt the standard, a counterparty will need cross-chain evidence about each operator. Funding chains and fleets do not respect chain boundaries, so scoring will need to follow them.

Machine-to-Machine Checks Will Grow

Agents will check each other before they transact. A human cannot sit in a loop that runs thousands of times a day. Therefore, trust checks need to be fast, structured and callable by software. The overview of the Web3 agentic economy explains why machine-readable trust becomes core infrastructure.

Evidence Will Beat Claims

As agent numbers grow, counterparties will stop trusting self-reported descriptions. They will favor evidence such as funding history, fleet structure and behavior over time. Public blockchains give this evidence a head start, because the data is open and the history is permanent.

Why Review-Based Rankings Fail

ERC-8004’s reputation registry lets clients publish feedback about agents. The specification forbids an owner or approved operator from reviewing their own agent, which blocks the simplest abuse. It cannot stop the next one. Review-based rankings share a basic weakness. Anyone can create 50 wallets, register 50 agents and let them upvote a 51st. That is a plain Sybil attack, and a score built on votes cannot see it. The example is an illustration, yet the tracker shows that such fleets are real: 21.1% of agents carried the farm flag at launch.

Consider how little the attack needs. A fleet of wallets submits friendly feedback, each wallet looks independent, and the registry records every entry as valid. In addition, a ranking that sums or averages that feedback rewards the fleet. Therefore, any ranking built on reviews inherits the weakness of cheap identities.

What Replaces the Votes

ChainAware takes a different route. The Agent Trust Score uses on-chain behavior only, with no reviews, no ratings and no self-reported data. Faking a clean funding history costs real money and time, while 50 upvotes cost almost nothing. Moreover, an attacker’s own address and feeder address pass through ChainAware’s machine-learning fraud detection, so abnormal behavior lowers the score instead of raising it.

Some on-chain data can still be faked, for example through wash activity or long-lived clean wallets. The difference lies in cost and in detection: every extra step leaves patterns that fraud models are trained to find. For that reason, behavior is a stronger base for trust than opinion.

Why ChainAware Is Credible Here

The fraud models behind the score have a long record. ChainAware reports 95% accuracy for its per-address fraud model, which anyone can verify against public data through ScamDB, and its rug pull model predicted 90.1% of rug pulls before they happened in a PancakeSwap test documented on the rug pull verification page. Those models feed the score, which is why it works as a prediction and not as a ranking.

Key Facts at a Glance

• ERC-8004 is an Ethereum standard for agent discovery and trust, with identity, reputation and validation registries.
• Registration is open and unvetted, so an agent’s existence says nothing about its trustworthiness.
• Owner self-review is blocked by the specification, yet the same document states that Sybil attacks remain possible.
• The standard says it cannot cryptographically guarantee that advertised capabilities are functional and non-malicious.
• ChainAware’s Agent Trust Score rates agents from 0 to 1,000 across five tiers, from Untrusted to Sovereign.
• The score combines the owner wallet’s fraud probability, the feeder address, the creator’s record and fleet-level farm detection.
• At launch, 51.8% of 274,792 indexed agents sat in the two lowest tiers, and 21.1% carried the farm flag.
• By Week 41 of 2026, the index held 568,590 agents, and the median trust of new registrations had fallen to 101.

Frequently Asked Questions

What is ERC-8004?

ERC-8004 is an Ethereum standard called Trustless Agents. It gives AI agents an on-chain identity through an ERC-721 token, and it adds a reputation registry for feedback and a validation registry for independent checks.

Does an ERC-8004 registration mean an agent is safe?

No. Registration is open and unvetted. It shows that an agent exists. The standard itself says it cannot cryptographically guarantee that an agent’s advertised capabilities are functional and non-malicious.

Can an agent’s owner review their own agent?

No, not directly. The specification forbids the owner and approved operators from submitting feedback for their own agent. However, an operator that controls other wallets can still post feedback from them. The specification acknowledges that Sybil attacks are possible, and it expects reputation systems to filter by reviewer.

What is a feeder wallet?

A feeder wallet is the address that first funded an agent’s owner wallet. Its history is evidence about the owner. A verified-exchange feeder is the strongest positive signal, an unknown feeder is a risk signal, and a feeder with fraud history hard-suppresses the score.

What is a farm-detected agent?

Farm-detected agents belong to a group whose funding, ownership or registration patterns suggest one operator controls them. At launch, 21.1% of indexed agents carried the flag.

What does the Agent Trust Score measure?

It measures the owner wallet’s fraud probability, the feeder address and the creator’s rug pull and honeypot history, then adds fleet-level farm detection. The result is a 0 to 1,000 score, a tier and named flags.

Which chains does the Agent Trust Score cover?

Coverage today includes Ethereum, BNB Smart Chain, Base and Avalanche C-Chain. Mantle support is in progress.

Is the Agent Trust Score free?

The score is free for public indexed agents, with 1,000 queries per month and no signup. Higher-volume teams can use the API or the Prediction MCP. See the Agent Trust Score page for current details.

How often should an agent be re-checked?

Check on a schedule that matches the value at risk, and check again before large or unusual actions. Behavior changes, so an old score is only a claim until someone verifies it again.

How does this relate to Know Your Agent?

Registry signals feed the behavior input of a wider KYA process, which also covers identity, authorization, integrity and status. Our guide to KYA versus agent identity explains the full picture.

Conclusion: Structure From the Registry, Judgment From Evidence

ERC-8004 solved a real problem. Agents now have a shared way to name themselves, publish what they offer and collect feedback. That is progress, and it gives the ecosystem something to measure.

The standard does not claim more than it delivers. It says plainly that it cannot guarantee that advertised capabilities work as described, and it admits that Sybil attacks are possible. Trust therefore has to come from evidence outside the registry: the owner’s history, the funding chain, the creator’s record and the fleet behind the agent.

The public data shows why this matters. A registry that grew past half a million agents in months also produced a record-low median trust score. Open systems scale volume easily, and they scale quality only when someone measures it.

Start small. Pick one agent integration that you already run, look up the counterparty’s score, and write down which tier you would allow for which action. That exercise produces a first policy. Then add the re-check and keep the evidence trail.

Readers who want to go further can review the Agent Trust Score, explore the Prediction MCP, or see how the Token Audit covers token-level risk that often sits next to agent risk. In addition, the weekly tracker shows how these signals move every week.