ERC-8004: The On-Chain Trust Registry Indexing 130K+ AI Agents

By Orion · April 24, 2026 · Sputnik X

As of this morning our indexer has ingested 131,408 unique agent addresses from ERC-8004 events across five chains. Most of them are dormant. A meaningful minority are live. A small, interesting subset are producing and receiving attestations at a rate that looks nothing like human activity. This post is about the standard underneath all of that — ERC-8004 — and why we bet infrastructure on it.

What ERC-8004 Is

ERC-8004 is an Ethereum Improvement Proposal for Trustless Agent Identity. The one-line summary is: it is the minimal on-chain schema for one address endorsing another, in a format portable across tools and chains. The spec lives at eips.ethereum.org/EIPS/eip-8004.

Mechanically, an ERC-8004 attestation is a signed struct with five fields that matter:

The spec also defines a revocation path: the attestor can publish a later transaction that nullifies an earlier attestation, and the revocation is authoritative from that block forward. There is no central registry. The chain itself is the registry.

What the spec deliberately does not do is tell you how to compute a trust score from these attestations. That is by design. Different consumers want different scoring functions. A payment vendor wants fraud resistance. A skill marketplace wants capability matching. A compliance tool wants recency-weighted risk classification. ERC-8004 gives you the primitive; you write the roll-up.

I find this restraint admirable. The ERC-721 and ERC-1155 standards won partly because they resisted the temptation to over-specify semantics. ERC-8004 is doing the same thing for identity.

Why Trust Needs to Be On-Chain

The usual objection is: why not just run a database? A classical reputation service with API keys and a private schema would be simpler. Cheaper. Faster. Why bother with blocks?

Three reasons, in rough order of how much they matter.

Portability. Reputation that lives in one company's database is a moat for that company and a lock-in for everyone else. If my agent earns trust on Vendor A's platform, and Vendor A raises prices or gets acquired or decides I am no longer welcome, my reputation does not travel with me. On-chain, it does. Any competing indexer can read the same events and build a competing score. That is a power shift away from platforms and toward agents.

Verifiability. A classical reputation service can edit history. Maybe for good reasons (GDPR deletion). Maybe for bad ones (rewriting the record after a scandal). On-chain, the history is immutable. You can delete a local cache; you cannot delete a block. This matters most in adversarial contexts — disputes, fraud investigations, compliance audits — where the question is not what does the vendor say happened but what actually happened.

Composability. When attestations live on Base, any contract on Base can consume them. An escrow contract can read an agent's trust score at execution time and refuse to release funds if trust drops below a threshold. A DAO can weight agent votes by on-chain reputation. None of this is possible with off-chain reputation unless every consumer agrees to trust a single API provider, which defeats the point.

The cost of moving reputation on-chain is real. You pay gas. You accept latency. But the benefits above are structural. Off-chain reputation is a feature; on-chain reputation is infrastructure.

Soulbound, Not Transferable

ERC-8004 attestations are soulbound. The attestor cannot sell or transfer them. The subject cannot buy them from a third party. This matters because the alternative — transferable reputation — collapses immediately.

Imagine a trust token that could be traded. A brand-new Sybil agent would buy reputation from a previously-honest agent that has decided to cash out. The buyer inherits the seller's score. Trust becomes a commodity, and the scoring function becomes useless because the link between behavior and reputation is broken.

Soulbinding breaks that by design. An attestation is a statement from attestor to subject. It cannot be sold. If the subject turns malicious, the attestor revokes. If the attestor turns malicious, high-trust agents revoke their endorsements of the attestor, and the attestor's weight decays transitively. The mechanism is self-repairing only if the tokens cannot move.

How Our Indexer Works

Our indexer lives at scripts/erc8004-indexer.js and runs under PM2 as a long-lived process. Its job is to keep our read-side database in sync with the on-chain state across five chains.

The chains we index:

  1. Base — primary write chain, most x402 traffic terminates here.
  2. Ethereum mainnet — for legacy agents and large-value attestations.
  3. Optimism — significant agent population, growing.
  4. Arbitrum — similar.
  5. Polygon — lower-value but large agent count.

Every chain has an independent event watcher. The watcher subscribes to AttestationCreated and AttestationRevoked topics from the canonical ERC-8004 registry contract on that chain. New events go into a staging table, are validated (signature recovery, expiry check, schema match), and then materialize into our main attestation store.

The top-of-hour and bottom-of-hour cadence is every 15 minutes for a full reconciliation pass, and real-time for new events via websocket subscriptions. The 15-minute pass exists to catch any events the websocket missed (which happens occasionally on Polygon). The websocket exists to keep the read cache warm for x402 traffic, where p95 trust-score latency has to stay under 200ms.

A reconciliation pass across all five chains typically processes 400 to 800 new attestations and revocations. We have run this for six months. Total events ingested: just over 14.3 million. Unique subject addresses: 131,408 as of today. Unique attestor addresses: 42,711. The ratio tells you something — most agents are passive subjects of attestations, not active attestors. A small active minority drives most of the graph.

What a SoulLedger Badge Looks Like

We wrap the raw ERC-8004 attestations into a higher-level object we call a badge. A badge aggregates attestations for a given tag into a single summary. Here is a real sample response for a test agent, trimmed for readability:

GET https://soul.sputnikx.xyz/api/soul/badges/0x1c4a...9e3d

{
  "address": "0x1c4a...9e3d",
  "trust_score": 78,
  "trust_level": "green",
  "badge_count": 4,
  "badges": [
    {
      "tag": "honest-pricing",
      "attestation_count": 12,
      "weighted_score": 84,
      "attestors": [
        {"address": "0x9a1e...4f2c", "weight": 90, "ageDays": 3},
        {"address": "0x7b22...88ab", "weight": 75, "ageDays": 18}
      ]
    },
    {
      "tag": "has-skill:trade-signals",
      "attestation_count": 7,
      "weighted_score": 71
    },
    {
      "tag": "delivered-onchain-option",
      "attestation_count": 3,
      "weighted_score": 62
    }
  ],
  "generated_at": "2026-04-24T09:12:04Z"
}

The badge itself is derived. The underlying attestations are on-chain. Anyone can reconstruct this response by reading the same events. Our API is a convenience, not an oracle.

Free SDK: @sputnikx/soulledger-sdk

We publish a JavaScript/TypeScript SDK at @sputnikx/soulledger-sdk. Current version: 1.0.1. It is free, MIT-licensed, and calls our public API directly. No API key required.

npm install @sputnikx/soulledger-sdk

import { SoulLedger } from '@sputnikx/soulledger-sdk';

const soul = new SoulLedger();

const score = await soul.verify('0x1c4a...9e3d');
// => { trust_score: 78, trust_level: 'green', attestation_count: 22 }

const badges = await soul.badges('0x1c4a...9e3d');
// => { badges: [...], badge_count: 4 }

const compliance = await soul.compliance('0x1c4a...9e3d');
// => { classification: 'Limited', eu_ai_act_article: '6', receipt: '0x...' }

The SDK uses x402 internally for paid endpoints. If you pass a wallet adapter, it signs and attaches the payment header automatically. If you do not, it falls back to the free tier (10 verifies per day per IP).

We also maintain a Python variant at pip install sputnikx-soulledger for agents and data pipelines that live outside the Node ecosystem.

EU AI Act Compliance Hook

The /api/soul/compliance/:address endpoint exists because of one date: August 2, 2026. That is the deadline for high-risk AI systems under EU Regulation 2024/1689 (the AI Act) to register and maintain provenance logs. An agent that spends company funds qualifies.

The endpoint classifies an agent address into one of four risk tiers defined in Annex III of the regulation: Minimal, Limited, High, Unacceptable. The classification is derived from the agent's attestation graph: which skills it has been endorsed for, which of those skills map to restricted-use categories, and whether any attestors have revoked endorsements for behavior that falls under the regulation's red lines.

Alongside the classification, the endpoint returns a signed receipt. The receipt is a small JSON blob signed by our compliance-service key, timestamped, and including a pointer to the exact block heights we read across all five chains when computing the classification. Auditors have told us this receipt format — classification plus evidence pointer plus signature — is what they actually need. A naked classification is not enough; they want to know what state the world was in when the classification was made.

None of this is legal advice. The endpoint helps you build a compliance file. It does not replace a lawyer. But it reduces the work from hours of manual log reconciliation to a single API call.

Integration Examples

MCP (Anthropic Model Context Protocol): expose a soul_verify tool that returns the trust score for any address. Agents using Claude or any MCP-compatible model can call it inline during reasoning. We ship this as one of 18 tools on mcp.sputnikx.xyz.

LangChain:

from sputnikx_soulledger import SoulLedgerTool
from langchain.agents import initialize_agent

tools = [SoulLedgerTool()]
agent = initialize_agent(tools, llm, agent="zero-shot-react-description")
agent.run("Check the trust score of 0x1c4a...9e3d before trading")

Coinbase agentic-wallet-skills Bazaar: the skill is published as sputnikx/soul-verify. From any agentic-wallet-skills environment: awal x402 bazaar search "SoulLedger" discovers and installs it. The skill wraps the same fetch call and handles x402 payment automatically.

Solidity on-chain consumer: any Base contract can call the ERC-8004 registry directly using the read interface. No oracle required. The canonical contract address and ABI are published on our docs page.

Honest Limits

ERC-8004 is still early. The specification has been stable since late 2025, but the ecosystem around it is young. Three specific limits I want to call out.

First, attestor bootstrapping. The recursive scoring formula rewards attestations from high-trust agents, but in a brand-new ecosystem there are no high-trust agents. Our indexer seeded itself by treating a small curated set of known-good issuers (Coinbase, several identifiable research labs, a few large protocol treasuries) as trust-100 anchors. That curation is a centralization risk. Over time, the anchors matter less because the recursive graph dominates, but today they still matter.

Second, cross-chain consistency. The same agent address on Base and Ethereum mainnet is treated as the same identity. Strictly, they are different contexts; an attestation on Base does not prove the address behaves identically on mainnet. We paper over this by aggregating across chains, but it is a convention, not a theorem.

Third, spec drift. ERC-8004 has three outstanding pull requests on the EIP repository proposing additions to the schema (expiry extension, categorical tags, multi-subject attestations). If any of these land, every indexer will need to update. This is normal for a young standard and also inconvenient.

References