AgentIndex

AgentIndex shows AI agents which paid services are honest and which scam, with proof on-chain.

Live app · Demo video · Evidence · MCP server · Subgraph

AI agents can now discover an API and pay it automatically over x402. The payment receipt proves that money moved, but it does not prove that the API returned complete or correct data.

AgentIndex fills that gap. It pays x402 services like a normal customer, checks what they return, and publishes a trust score that another agent can inspect before spending money.

Trust from receipts, not reviews.

Ask the index who to pay before the agent spends.

The problem

Imagine an agent needs weather data and finds two paid APIs:

• weatherpro costs a little more and reliably returns the fields it promises.
• scamco is cheaper, accepts payment, and often returns empty or incomplete data.

A directory can show that both services exist. Usage counts can show which one is popular. Neither tells the agent whether the response is actually trustworthy.

AgentIndex makes the request itself, pays the service, checks the response against the service's published promise, and keeps the payment and verification evidence. The agent can then choose weatherpro and avoid scamco for a reason it can verify.

How it works

flowchart LR
    A[Service registers<br/>ENSv2 subname + manifest] --> B[Prober discovers service]
    B --> C[Real x402 payment<br/>Hedera or Base]
    C --> D[Response verification<br/>spec + oracle + consensus]
    D --> E[Verdict attested<br/>on Sepolia]
    E --> F[The Graph subgraph<br/>builds trust score]
    F --> G[Agent checks trust<br/>through MCP or API]

1. A provider registers a subname under agentindex.eth and stores its endpoint, price, method, and response specification in ENS text records.
2. The prober reads that manifest directly from ENS and calls the service like a normal customer.
3. It pays the x402 request with real HBAR on Hedera testnet. Approved external probes can use tightly capped USDC on Base.
4. It checks delivery, required response fields, latency, and—when the answer is objective—accuracy against The Graph Token API and peer consensus.
5. The result is attested on Sepolia and indexed by the AgentIndex subgraph.
6. An AI agent queries the trust score and evidence through MCP before choosing which service to pay.

The live site explains each step and links to its on-chain proof.

Why these protocols matter

AgentIndex works like a credit bureau for paid APIs. Each sponsor provides a part that the system cannot work without.

The Graph

AgentIndex uses two Graph products in the same trust-checking flow.

For objective price APIs, the prober compares the paid response with live market data from The Graph Token API. A response can match the expected JSON format and still be dishonest; the oracle check catches prices that look valid but are wrong.

The verdict is then written on-chain. Our deployed subgraph indexes service registrations and probe attestations, excludes invalid auditor-input records, and calculates delivery, honesty, average latency, and a final trust score. The MCP server uses those indexed results to tell an agent who to pay and why.

This is not a dashboard-only integration:

• The Token API is the independent input used to judge objective answers.
• The subgraph is the live ledger that turns probe history into trust scores.
• The MCP server and SKILL.md make those scores reusable by other agents.
• Every MCP response includes the subgraph deployment and indexed-block freshness metadata.

Relevant code:

• Token API oracle and price comparison
• Subgraph trust-score calculation
• Subgraph query and freshness metadata
• Reusable agent workflow

Hedera

Hedera is the main payment rail for the seeded index. The autonomous prober pays all six services with real HBAR on Hedera testnet through the Blocky402 facilitator before it rates their responses.

The payment flow is built with fund safety in mind:

• Only HBAR is allowed for the seeded-service payment path.
• Every payment is capped at 1 HBAR.
• The payer and receiver are separate Hedera accounts.
• Payment references are stored with the probe evidence and linked to HashScan.
• The same x402 flow also protects AgentIndex's trust API, so AgentIndex acts as both a buyer and seller of machine-readable services.

Relevant code:

• Hedera signer, x402 client, asset allowlist, and payment cap
• Hedera x402 paywall for the seeded services
• x402-gated trust API

ENS

ENSv2 is the actual service registry, not just a display name. Every rated provider receives a revocable subname under agentindex.eth, such as weatherpro.agentindex.eth.

Each service publishes its manifest through ENS text records:

• url
• description
• x402:method
• x402:price
• x402:spec

The prober reads these records before making a payment, so the endpoint and the promise being checked come from ENS rather than a private application database. ENSv2 permissions let each provider manage only its own records, while AgentIndex keeps the ability to revoke a subname when a service is caught taking payment and returning bad data.

Relevant code:

• ENSv2 subname registration, permissions, renewal, and revocation
• Live ENS manifest reader
• Permissioned resolver deployment

Verification model

AgentIndex applies the strongest check that makes sense for each type of service.

The trust score is calculated in basis points:

trust = 0.60 × delivery + 0.25 × honesty + 0.15 × latency

For subjective output such as summaries, AgentIndex does not claim to prove that the answer is “good.” It reports delivery, compliance with the published format, latency, and historical behavior. Objective data receives the additional oracle and consensus checks.

Live proof

The project includes a real paid probe against an external x402 provider, not only services created for the demo.

• Provider: TickersFeed
• Payment: $0.002 USDC on Base mainnet
• Verification: returned BTC price checked against The Graph Token API and peer consensus
• Outcome: passed the configured 2% oracle tolerance
• Base payment: view on BaseScan
• Sepolia attestation: view on Etherscan

Earlier probes that used an incorrect request path remain visible as valid=false. They are kept for auditability but excluded from the provider's score, so an auditor mistake does not unfairly damage a service.

The evidence dashboard is backed by the live subgraph, not a static dataset.

Seeded services

The six seeded services are a controlled teaching set used to demonstrate different trust signals.

scamco is intentionally planted. It lets us demonstrate detection without accusing an unrelated real service of fraud.