Agent trust methodology
The data is only as trustworthy as the method behind it, so here is the method. This is version 0.3.0, scoped to Ethereum mainnet and Base. Any threshold change is a new version and a full rebuild, never a silent edit.
What we read
We index the two live ERC-8004 registries from their deploy blocks: Identity (a token per agent, pointing at an off-chain registration file) and Reputation (client feedback as on-chain attestations). We fetch every declared registration file, and we index native-USDC settlement on Base across the wallets in the dataset. The Validation Registry is not deployed on any chain, so it's omitted.
Every count is derived from the raw on-chain logs and is reproducible from them. Nothing is asserted that the evidence can't reconstruct.
The six checks
Triggers when: The agent's latest registration file didn't resolve or didn't parse, or the file churned across versions under a stable URI.
What it does not mean: A dead file isn't proof an agent is inactive, and an unsupported URI scheme (DID, ENS, Arweave) is a limit of our fetcher, not a dead agent. We split those out.
Triggers when: The agent has five or more feedback entries and no observed native-USDC settlement on its owner wallet after registration, on Base.
What it does not mean: This is as much a statement about our coverage as about the agent. Off-chain, other-token, other-chain and undeclared-wallet payment are invisible to it.
Triggers when: The registration file declares x402 support, but the owner wallet shows no observed inbound USDC on Base.
What it does not mean: Declaring a paid endpoint is a marketing decision; the same settlement-scope caveat applies. Nested x402 config objects are undercounted by the boolean match.
Triggers when: Raters and the rated are entangled: a reciprocal ring, a shared one-hop funding source, or a rater who now owns the agent (post-transfer, since the contract blocks owners rating their own agent).
What it does not mean: Circular feedback has honest explanations. The evidence is summarised because dense rings produce hundreds of thousands of instances per agent.
Triggers when: Most of an agent’s feedback lands inside a one-hour window, on an agent older than a day, with at least five feedback entries.
What it does not mean: The age gate stops brand-new agents, whose feedback naturally clusters at launch, from tripping it.
Triggers when: At least half of an agent’s feedback authors have only ever rated this one agent, across at least three raters.
What it does not mean: Below three raters there is no distribution to judge. A single-purpose rater can be a genuine one-time client.
Thresholds (v0.3.0)
| Check | Threshold |
|---|---|
| DUP-01 dense-ring escalation | 10+ distinct circular counterparties |
| DUP-02 single-purpose raters | 50% of authors (80% escalates), min 3 raters |
| DUP-03 burst window | 70% of feedback in 1 hour, agent age 24h+, min 5 |
| RECON-01 / RECON-02 reputation floor | 5+ feedback entries |
What holds every check
- Observations, not verdicts. No agent gets a trust score, a ranking, or a label. Codes are neutral; the evidence does the work.
- Absence is scoped. Settlement observed only on Base native USDC across the agent's owner wallet, post-registration. Absence here is not absence of settlement.
- Evidence-linked. Every flag cites the raw rows that triggered it, so anyone can re-derive it.
- Version-stamped. Every flag records the methodology version it was computed under.
- Untrusted input. Registration files are parsed defensively as data, never executed or followed.