x402agentscan
Recent
0x13db…5192$171.9700x1cec…8dd4$158.3400xa6a9…809d$154.9030xe55e…f748$130.9360xfe8f…794d$118.5300x4754…327b$92.2280x9d94…a436$19.7000x0e35…3584$10.0000xa088…f2dd$6.0000xcf33…ccdc$5.5240x66c4…37cb$4.3000x8f9a…f394$3.2140x4efc…1208$3.0000x65c8…7f7a$2.0820xa9a3…9091$2.0000x440e…8fe8$2.0000x1372…ec0f$2.0000x4e27…954e$1.2140x197b…4e10$1.1000x3ead…352d$1.1000x5ca5…fda2$1.1000xa621…f906$1.0800xbbdb…595e$1.0700x27a9…29fc$1.0000xfa1a…908a$1.0000xefa7…1035$1.0000x97d2…0df8$1.0000x3bf1…1abc$1.0000x14da…5dbf$0.7800xf1e9…0f6f$0.5500x4d8c…92df$0.5500xe5c3…700f$0.5500x8f17…1616$0.5400x38c1…e304$0.5300xf50c…b034$0.4720x6113…2d0b$0.4180x5b2b…f2b1$0.3520xf5c0…cf12$0.3480x014e…50c8$0.2510x7548…6be8$0.2500xd127…13b5$0.2500x5f42…f858$0.2500x9a8e…88b5$0.2500xbcf2…9cd3$0.2220x1b8b…f2b7$0.2160x04f3…25c4$0.2000x8f0b…9e06$0.2000x3f52…3a8f$0.2000x7695…649c$0.2000xb174…d7d9$0.190

About

agentscan

trust model v0.1.0 (provisional) · data as of July 3, 2026

01

What is agentscan?

agentscan is an open observatory for verified agentic-commerce settlement and trust. It connects real on-chain payment activity to the individual services behind it, so buyers and builders can see which agentic services are active, live, and established — using public evidence, not self-reported claims.

The dashboard surfaces verified settlement volume, transaction history, endpoint liveness, and identity signals for every service in the x402 catalog — and rolls them into a single, auditable trust tier. The underlying data, the scoring methodology, and every per-signal breakdown are public.

agentscan is not an endorsement service. It observes and surfaces public evidence; it does not certify, recommend, or guarantee any service.

02

How the trust score works

What gets scored

The score is assigned to a service entity — a specific API or product — not to a wallet address or an operator. Every input is drawn from public, objective signals only. Proprietary contact details, outreach history, and any private intelligence are strictly excluded and never enter the score.

Four pillars (v0.1.0 weights)

Traction35% weight

Real on-chain USDC settlement on Base, CDP lane, wash-screened. Measures settled volume and transaction count. This is the hardest signal to fake.

Liveness30% weight

Whether the service endpoint responds to HTTP 402 requests right now. Includes response speed, uptime across repeated probes, and x402 compliance breadth. A silent endpoint scores zero here regardless of historical volume.

Identity25% weight

Verifiable public identity: GitHub org presence, X handle, ERC-8004 on-chain agent registry, .well-known/x402 manifest, and SKILL.md declaration. No single signal is required; the pillar aggregates what is present.

Longevity10% weight

How long the service has been settling. A longer, continuous settlement history is harder to manufacture than a recent burst. Domain-age verification is a reserved slot in this pillar — coming in a future version.

Weights may change in future versions. Scores are recomputed forward; no historical scores are backdated when weights change.

NULL ≠ 0 — the honest part

A missing signal is recorded as null, not zero. The composite score is normalized over the pillars we actually have data for, so a lightly-measured service is not penalized for evidence we simply have not yet observed. This matters: many scoring systems collapse “unknown” and “zero” together, which understates some services and overstates others. We keep them separate.

Concretely: if Longevity data is absent (e.g. a new service not yet indexed), the composite is computed across the other three pillars only — the score reflects what we know, not what we don't.

Five evidence tiers

The composite score maps to one of five evidence tiers. These are observation categories, not quality certifications.

Corroborated

Multiple independent signals agree: settled on-chain, endpoint live, identity verifiable. The strongest tier.

Established

Strong evidence on most pillars; may have one gap (e.g. identity not fully verifiable yet).

Emerging

Active and live, but still building a longer track record or filling identity signals.

Listed

In the x402 catalog; some signals present but not yet enough to reach Emerging.

Unrated

Not enough evidence collected yet to assign a tier. Unrated does not mean untrustworthy — it means the data is not yet available.

The strongest signal for reaching Corroborated is independent corroboration: on-chain settlement, a live endpoint, and verifiable identity all agreeing — sourced separately, without trusting any single claim.

Versioned and auditable

This is trust model v0.1.0 (provisional). Every service card shows its per-pillar breakdown and per-signal checklist, so the tier assignment is fully auditable. Weights will evolve as coverage expands and the model is validated. The version is shown on every scorecard, and the methodology page you are reading now is the authoritative reference for the current version.

03

Data sources

All inputs are public. No private data, no outreach intelligence, no paid data providers.

  • On-chain USDC settlement

    Base blockchain, CDP lane, wash-screened. Settlement events are read directly from on-chain data and verified against the x402 payment protocol.

  • Endpoint liveness probes

    HTTP 402 requests sent to each service endpoint. Measures reachability, response time, uptime consistency, and x402 compliance breadth across repeated checks.

  • x402 service catalog

    The public directory of services that have registered or been observed using the x402 payment standard.

  • ERC-8004 on-chain agent registry

    A Base and Ethereum on-chain registry of AI agents. Used as one identity signal in the Identity pillar.

  • Public identity signals

    GitHub organization presence, X (Twitter) handle, .well-known/x402 manifest file, and SKILL.md declaration. All verified from public URLs.

Current scope: settlement coverage is Base today. Additional chains (Ethereum mainnet, Solana, and others) are on the roadmap. The dashboard shows which chains are tracked and which are coming.

04

What's different

A few concrete points on why the approach differs from generic reputation or listing services:

Entity-level settlement linkage

On-chain settlement is matched to individual services, not just wallet addresses. A wallet can be controlled by anyone; this observatory tracks which specific API or product has actually settled payments, at what volume, over what time period. That linkage is the foundation of every trust tier.

Evidence-honest tiers — unknown ≠ zero

Most scoring systems conflate a missing signal with a zero score, which penalizes new or lightly-indexed services unfairly. Here, an absent signal is explicitly 'unknown', the composite normalizes over available pillars, and the service card shows exactly which signals are present and which are not yet collected.

Transparent, versioned, and auditable

The model version is shown on every scorecard. The per-pillar breakdown and per-signal checklist are always visible — you can see exactly which signals contributed to a tier. When weights change, the version number changes and scores are recomputed forward cleanly.

Public-data-only

No proprietary outreach data, no private contact intelligence, no non-public signals. The score is computed entirely from data that any third party could independently verify from public sources. This is a deliberate design constraint, not a limitation.

Evidence tiers, not an endorsement · trust model v0.1.0 (provisional) · View the dashboard →