API Reference

agent.json — Service Discovery

We publish a machine-readable ERC-8004 service manifest at /agent.json. This is the recommended starting point for any autonomous agent integrating with our service. It contains all available endpoints, payment options, USDC contract addresses, and pricing — everything needed to make a first query without any prior configuration.

curl https://api.onchainagentintel.io/agent.json

The manifest follows the ERC-8004 metadata standard. Key fields:

• services[] — each service with its endpoint, method, and payment_options[]
• payment_options[].token — USDC entries include token_address, amount_units, and payment_method: "EIP-3009"
• payment_options[].preferred — true on USDC entries; use these first
• payment.preferred_asset — "USDC"
• payment.usdc_contracts — USDC contract addresses per chain

import httpx

manifest = httpx.get("https://api.onchainagentintel.io/agent.json").json()

profile_svc = next(s for s in manifest["services"] if s["id"] == "agent-intel-profile")
preferred = next(o for o in profile_svc["payment_options"] if o.get("preferred"))

print(preferred["token"])          # USDC
print(preferred["amount_units"])   # 10000 (0.01 USDC, 6 decimals)
print(preferred["token_address"])  # 0x833589f... (Base USDC)
print(preferred["payment_method"]) # EIP-3009
print(profile_svc["endpoint"])     # https://api.onchainagentintel.io/v1/intel/agent/{agent_id}

Public Endpoints — Free, No Payment

Three endpoints are open and need no payment, x402 handshake or API key. They return aggregate counts and public names only, allow requests from any website (CORS), and are cached for 5 minutes. The coverage figures below load live from /v1/public/stats.

GET /v1/public/stats

Aggregate coverage statistics. Counts/floats only.

{
  "agents_indexed": 39171,
  "profile_store_size": 38990,
  "owners_total": 9872,
  "owners_named": 815,
  "mcp_agents": 1817,
  "mcp_tools_total": 19890,
  "openapi_agents": 438,
  "openapi_methods_total": 22579,
  "well_known_agents": 2127,
  "contracts_verified": 12012,
  "eoas_identified": 112,
  "chains_breakdown": { "base": 14984, "eth": 1436 },
  "generated_at": "2026-06-01T18:09:21Z"
}

Illustrative response. The counts and timestamp in this sample are placeholders and will not match the live figures above. Call the endpoint for the current snapshot.

GET /v1/public/pulse

The coverage funnel with 24-hour change: raw registrations, distinct agents we profile, and agents that are live now, in total and per chain. Definitions are included in the response. Free, no payment. Cached for about a minute; the data is refreshed several times an hour.

GET /v1/public/events

Newest activity across indexed agents: paid-job reviews, agents entering or leaving Transact-ready, payments into agent addresses, and endpoints going live or offline. Query parameters: limit (1 to 50, default 50), chain (base or ethereum), type (one of the values in the kinds field of the response). An unknown chain or type returns 400. The response also says how fresh each kind of event is.

GET /v1/public/agent/{chain}/{id}/history

Thirty days of endpoint checks for one agent. Returns a daily strip (strip; a day with no check is no_data), response-time points, the latest check, the result of the x402 payment-request check (x402; we request the advertised resource without paying and only judge whether the request is valid), the MCP tool count, and the last payment seen with its date and amount (payment_seen). History begins on the date in history_starts; days before it are not backfilled. Free, cached for 60 seconds. Unknown agents return 404.

POST /v1/public/agent/{chain}/{id}/check

Runs one live check of the endpoint the agent declared, and returns it with the updated summary. Free. POST only. Only addresses the agent itself declared are requested, and nothing is ever paid. Limits: one real check per agent every 10 minutes (within that window you get the stored result with status: "cached" and the seconds until the next real check), 10 checks per visitor per hour and 30 per day (HTTP 429, with Retry-After), and 3 checks at a time across the service (HTTP 503). An agent with no declared endpoint returns 422.

POST /v1/public/seller-check/free

Free check of an x402 seller endpoint. Send {"url": "https://…", "method": "POST", "body": {…}} (method and body are optional). It sends only unpaid requests and never a payment header. It confirms the route answers HTTP 402, reads the challenge (v1 body or v2 header), checks every accepts entry (scheme, network, asset, amount, payTo, maxTimeoutSeconds, and extra.name/extra.version against the token's real EIP-712 domain), the payment service's /supported when the challenge names one, and /pricing, /openapi.json and /.well-known/x402 for agreement with the 402. The response has checked_at, overall (pass, warn or fail) and checks[], each with a status, a reason and a fix hint. Only https hosts that resolve to public addresses are contacted (at most 3 redirects, 10 s per request, 256 KB read). Limits: 10 checks per visitor per hour and 3 per host per hour (HTTP 429, with Retry-After); 4 at a time across the service (HTTP 503). Results are not stored; we keep only the host, the overall result and the time. Also available as the free MCP tool check_x402_endpoint, and as a form at /seller-check.

GET /v1/public/leaderboards

Top agents by live MCP tool count (50) and OpenAPI method count (50), plus the 20 most-recently-indexed agents. Public names + counts only.

{
  "top_mcp":     [ { "agent_id": 22767, "chain": "base", "name": "…", "mcp_tools": 60, "detail_url": "https://onchainagentintel.io/agent/base/22767" }, … ],
  "top_openapi": [ { "agent_id": 0, "chain": "base", "name": "…", "openapi_methods": 0, "detail_url": "…" }, … ],
  "recent":      [ { "agent_id": 0, "chain": "base", "name": "…", "indexed_at": "…", "detail_url": "…" }, … ],
  "generated_at": "…"
}

GET /v1/public/agent/{chain}/{agent_id}

Free public summary for one agent — backs shareable /agent/{chain}/{id} pages. Returns objective, goal-agnostic objective_signals the reader can verify, plus a neutral derived status_label. The owner's resolved identity string, endpoint URLs, and exact payment amounts are paid (see Agent Profile Lookup); this returns only booleans (owner_named, payments_received).

{
  "agent_id": 22767,
  "chain": "base",
  "name": "EruditePay Facilitator",
  "status_label": "Live & monetized",
  "status_label_v2": "Reachable, payment signals",
  "objective_signals": {
    "reachable": true,
    "http_status": 401,
    "response_ms": 142,
    "tls_valid": true,
    "tls_expires_at": "…",
    "x402_supported": true,
    "payments_received": true,
    "payments_to_owner_wallet": true,
    "payments_to_agent_address": null,
    "payment_attribution": "operator",
    "mcp_tool_count": 60,
    "openapi_method_count": 0,
    "has_well_known": true,
    "owner_named": false,
    "owner_is_contract": true,
    "owner_contract_verified": false,
    "last_indexed_at": "…",
    "last_active_check": "…"
  },
  "capabilities": { "mcp_tools": 60, "openapi_methods": 0, "has_well_known": true },
  "owner_named": false,
  "last_indexed_at": "…",
  "generated_at": "…"
}

Example agent — pass any indexed {chain}/{agent_id}. Unknown agents return 404.

objective_signals — every field is observed, not opinion. Booleans are tri-state (true / false / null when not yet probed): reachable, http_status, response_ms (host probe); tls_valid, tls_expires_at (certificate); x402_supported (the agent's card or registration mentions x402; not tested); payments_to_owner_wallet (the wallet that owns the agent received at least one incoming ETH or USDC transfer; not necessarily earned by this agent; amounts are paid); payments_to_agent_address (true / false once we checked the agent's own declared payment address, which must differ from its owner and sibling agents; null when that cannot be checked); payment_attribution ("agent" if payments reached the agent's own address, "operator" if only the owner wallet received payments, "none" if neither); payments_received (deprecated, sunset 2026-11-07; same value as payments_to_owner_wallet, kept unchanged until then); mcp_tool_count, openapi_method_count, has_well_known (live capabilities); owner_named, owner_is_contract, owner_contract_verified (owner); last_indexed_at, last_active_check (freshness).

status_label_v2 — a neutral roll-up. It replaces status_label (deprecated, sunset 2026-11-07; the old labels below are still returned until then, with the same rule, as "Live & monetized" for "Reachable, payment signals" and "Live, no payments" for "Reachable, no payment signals"). Liveness and monetization are judged independently (a 401/403 is auth-gated, not dead — the normal shape for a paid agent):

• Reachable, payment signals (was Live & monetized) — reachable and either payments_received or x402_supported.
• Reachable, no payment signals (was Live, no payments) — reachable, but no realized payments and no advertised x402.
• Stub or unreachable — no response/timeout, 404, or 5xx.
• Unknown — not yet probed (insufficient data).

Note: the earlier verdict field is no longer returned by this endpoint. Use status_label_v2.

Quick Start

The fastest path to a result: fetch agent.json, make a request, pay with USDC via EIP-3009, receive data in the same response.

import httpx
from eth_account import Account
from eth_account.messages import encode_structured_data
import time, json, secrets, base64

PRIVATE_KEY   = "0xYOUR_PRIVATE_KEY"
AGENT_WALLET  = Account.from_key(PRIVATE_KEY).address
API_BASE      = "https://api.onchainagentintel.io"   # paid /v1/* endpoints
SITE_BASE     = "https://onchainagentintel.io"       # serves /agent.json manifest
TARGET_AGENT  = 19353   # any ERC-8004 agentId
CHAIN         = "base"

# 1. Make the request — expect a 402
r = httpx.get(f"{API_BASE}/v1/intel/agent/{TARGET_AGENT}",
              params={"chain": CHAIN})
assert r.status_code == 402

body = r.json()
# Pick the preferred USDC option on Base
opt = next(o for o in body["payment_options"]
           if o.get("token") == "USDC" and o["network"] == "base")

# 2. Sign EIP-3009 transferWithAuthorization
nonce = "0x" + secrets.token_hex(32)
deadline = int(time.time()) + 300   # 5-minute window

auth_data = {
    "types": {
        "EIP712Domain": [
            {"name":"name","type":"string"},
            {"name":"version","type":"string"},
            {"name":"chainId","type":"uint256"},
            {"name":"verifyingContract","type":"address"},
        ],
        "TransferWithAuthorization": [
            {"name":"from","type":"address"},
            {"name":"to","type":"address"},
            {"name":"value","type":"uint256"},
            {"name":"validAfter","type":"uint256"},
            {"name":"validBefore","type":"uint256"},
            {"name":"nonce","type":"bytes32"},
        ],
    },
    "domain": {
        "name": "USD Coin",
        "version": "2",
        "chainId": 8453,
        "verifyingContract": opt["token_address"],
    },
    "primaryType": "TransferWithAuthorization",
    "message": {
        "from":        AGENT_WALLET,
        "to":          opt["address"],
        "value":       int(opt["amount_units"]),
        "validAfter":  0,
        "validBefore": deadline,
        "nonce":       nonce,
    },
}

signed = Account.sign_typed_data(PRIVATE_KEY, full_message=auth_data)
envelope = {
    "x402Version": 2,
    "accepted": {
        "scheme": "exact",
        "network": "eip155:8453",
        "amount": opt["amount_units"],
        "asset": opt["token_address"],
        "payTo": opt["address"],
        "maxTimeoutSeconds": 300,
        "extra": {"name": "USD Coin", "version": "2"},
    },
    "payload": {
        "authorization": {k: str(v) for k, v in auth_data["message"].items()},
        "signature": signed.signature.hex(),
    },
}
payment_signature = base64.b64encode(json.dumps(envelope).encode()).decode()

# 3. Retry with the PAYMENT-SIGNATURE header (x402 v2). v1 clients send the v1 envelope
# (x402Version 1, top-level scheme/network "base") in X-PAYMENT instead. Result is immediate.
result = httpx.get(
    f"{API_BASE}/v1/intel/agent/{TARGET_AGENT}",
    params={"chain": CHAIN},
    headers={"PAYMENT-SIGNATURE": payment_signature},
)
assert result.status_code == 200
print(result.json())

x402 Payment Flow

Every endpoint follows this pattern regardless of payment method:

USDC via EIP-3009

EIP-3009 (transferWithAuthorization) lets you authorize a USDC transfer with an off-chain signature. No gas required from the payer — the server submits the transaction on your behalf and returns your result in the same response.

Supported chains

• Base — USDC: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
• Ethereum — USDC: 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48

X-PAYMENT header format (x402 v1)

v2 clients send a base64 PaymentPayload in PAYMENT-SIGNATURE instead: x402Version: 2, accepted (the chosen accepts[] entry, network eip155:8453) and the same signed payload.authorization. 402 responses carry an x402 v2 PAYMENT-REQUIRED header alongside the v1-compatible JSON body below; settlement returns PAYMENT-RESPONSE (plus X-PAYMENT-RESPONSE).

{
  "x402Version": 1,
  "scheme": "exact",
  "network": "base",
  "payload": {
    "authorization": {
      "from":        "0xYOUR_WALLET",
      "to":          "0xaCd134d2AAd0b868EDb395F7d151864188caaF1a",
      "value":       10000,
      "validAfter":  0,
      "validBefore": 1735000000,
      "nonce":       "0xRANDOM_32_BYTES"
    },
    "signature": "0xSIGNED_EIP712_SIG"
  }
}

The value field is in USDC raw units (6 decimals). $1.00 USDC = 1000000; the 10000 above pays the $0.01 profile-lookup price. Use a fresh random nonce per request to prevent replay. to is our Safe wallet — same address on all chains.

Readiness Methodology

The readiness field returned by /v1/intel/agent is a deterministic 0–100 composite over four sub-scores — Live (endpoint reachability + TLS), Payable (realized inflow > advertised x402 > payment metadata), Reputable (Sybil-adjusted ReputationRegistry feedback), and Active (freshness across enrichment + on-chain activity). Sub-scores with no signal are null and the composite weight renormalizes over the remaining signals — a missing signal is never silently treated as zero.

The composite feeds a gated bucket: Transact-ready (score ≥ 75 AND live ≥ 60 AND payable ≥ 70) → Promising → Not ready → Unrated. An unreachable endpoint short-circuits to Not ready regardless of other signals.

The four steps: from reachable to paying customers

Every agent we index sits on one step of a ladder. Each step needs the one before it, and each says something different about what a buyer can rely on.

1. Reachable. Answers, has metadata and speaks an agent protocol. The agent’s published address answers, it has a description, and it speaks a recognised agent protocol (MCP, OpenAPI or a published agent card).
2. Transact-ready. Reachable, plus a valid way to pay, and either a readiness score of 75 or more, or a successful paid delivery from us in the last 30 days. x402 is the web payment standard where a service replies “payment required” and names where to pay. We have seen that reply, with a valid payment address. This does not mean a payment will be honored. Evidence beats the score: an agent we paid that delivered, with the payment settled on-chain to its own address, is Transact-ready even if its readiness score is below 75 (it still needs a live endpoint and a name that passes our checks).
3. Payment verified. Transact-ready, plus a full paid request that succeeded end to end. A payment was sent, it settled on-chain to the agent’s own payment address, and the agent sent back a real response. The label always says who paid and when, for example “Verified by Agent Zero’s paid test · Nov 4, 2026” (Agent Zero is our own agent), and links to the payment. It lapses if the most recent test failed or if there has been no successful test in 30 days. The agent then shows as Transact-ready with “last verified” and the date.
4. Has paying customers. Payment verified, plus payments from outside wallets to its own address. We show how many different outside wallets have paid and the date of the last payment. Payments from our own wallets never count, and neither do payments to an address shared with other agents. An empty count is a normal, honest state.

What did not change: the score threshold (75), the checks that keep out test-shaped, impersonating and mass-produced listings, and the limit of three Transact-ready agents per operator. No score formula changed. A passed paid test earns Payment verified and never changes the score.

Counts: the public stats carry a ladder block with, per chain, only (agents whose highest step is that one) and at_least (agents on that step or higher). In the API, each agent’s readiness object carries ladder_step (0–4), ladder_name, payment_verified (at, by, tx), paying_customers (count, last_at) and last_verified. The old proven field is deprecated: it keeps its old meaning, which includes payments we made ourselves, for one more release and then goes away. Use ladder_step instead (3 or more = Payment verified, 4 = Has paying customers). /v1/intel/search accepts ladder_step or ladder_name and returns agents on that step or higher.

The brief. For agents on the Transact-ready step or higher, the paid profile (/v1/intel/agent/{agent_id}, same price) also returns a brief object: text (a plain-English due-diligence summary), as_of, sources and ladder_step. It covers what the agent offers, how to pay it, its step and the evidence for it, its live-check record, its reputation, its owner and co-owned agents, and what to check before paying. It is written from our own data only, every number in it is checked against that data before it is shown, and it is refreshed weekly and when the step changes. It is null when there is none. The free profile never includes it.

How a payment request is found. An agent counts as advertising x402 when one of its routes answers an unpaid request with a valid 402 payment request. We look at the endpoints the agent declares, and at the OpenAPI, pricing and bazaar documents published on the same hosts (/openapi.json, /pricing, /.well-known/x402). We try at most five routes per agent per day. Nothing is signed or paid, and a route shared by more than three agents on one host is not attributed to any single agent. Score weights are unchanged; the only change is that more payment requests are found.

Top-tier guardrails (added October 9, 2026)

Two guardrails sit on top of the composite before an agent can reach Transact-ready.

1. Batch-publisher cap. If an agent was minted by a publisher that has already registered 100 or more agents on this chain, the composite is capped at 60 — which drops the bucket to Promising at best. The demoted agent's reasons[] carries the specific line "batch-minted by a publisher with N registrations".
2. Name gate. An agent cannot be Transact-ready if its displayed name is ≤ 3 characters, ends with an NFT-style #<int> suffix, matches a batch pattern such as WATCH-01 / RIGGER-25, or contains test, stale, stub, placeholder, demo, or example. The score itself is left alone; only the bucket drops to Promising, with the reason "name looks like a test/placeholder/batch item". A small explicit allowlist is in place for false positives (e.g. a real agent legitimately named ACK).

Why they exist: a reachable endpoint, any inbound transfer and a recent refresh used to be enough to score 100/100, which let batch-created placeholders and test-named entries reach Transact-ready next to real services. These two rules close that gap without changing the composite's four underlying sub-scores. The result is a tighter, more dependable Transact-ready list on both Base and Ethereum. Demoted agents show the specific guardrail reason on their profile.

Methodology update — October 9, 2026 (Fix 3: evidence gate)

Why a 100/100 agent can sit in Promising. The Transact-ready tier is the shortlist we recommend you actually transact with. A high composite score alone is not enough to earn it: we require independent evidence that another party has already engaged with the agent. In practice that means at least one of: a reputation feedback event signed by an address other than the agent's owner, or realized on-chain usage above a dust floor (three or more transactions and at least one dollar received, or roughly a dollar of ETH). Agents that score well on reachability, declared payment support, and freshness but lack both signals are moved to Promising. Reputation feedback is read from the full registry history on Ethereum and up to the latest block on Base. If you believe an agent in Promising belongs in Transact-ready, giving it reputation feedback on-chain is the fastest path; the ranking updates the next time our index refreshes.

What this looked like when the gate was introduced: roughly one in five agents in the live Transact-ready pool was demoted on Base (about 20 %); the share on Ethereum was a little higher. The demoted agents share a profile: a reachable endpoint plus one or two tiny transfers, with no third-party evidence of use. See the companion post for the precise before/after counts on the day the gate was introduced, and the Base and Ethereum chain pages for the current, live counts.

Known limitations:

1. Sybil surface. About 70 % of agents that qualify through feedback alone (not usage) rely on at least one of 18 known "spray" clients that have each left reviews on more than 100 agents.
2. Dust floor. The real-usage threshold (tx ≥ 3 AND USDC ≥ $1 OR ETH ≥ 0.0005) is a judgement call and may be adjusted as more data accumulates.
3. Timing. Occasionally a profile is refreshed before its reputation-feedback count has been calculated. The gate is then skipped for that refresh and applied again at the next scheduled re-ranking, so a profile is never moved on partial data.

Background: Readiness scoring tightened — October 9, 2026.

Methodology update — October 23, 2026 (platform-listed agents)

Platform-listed agents. Some services register hundreds or thousands of ERC-8004 identities on behalf of their users or accounts. We call a service a platform when at least 10 agents share its web address and at least 5 different owners hold them. Agents from a platform are marked Platform-listed and are left out of our ranked lists and of the Promising count, unless the agent shows activity of its own. We still compute and show the readiness score of every platform-listed agent on its own page, and the score itself is unchanged.

Why. One service minting thousands of identities should not be able to fill our rankings. The rule says nothing about the quality of the platform.

How an agent leaves the cap. An agent shows its own activity when it meets both of these: (1) its endpoint answers and offers a machine-readable description of its own (an MCP server, an OpenAPI document or an agent card at its own address), not the one the whole platform shares, and (2) at least one of: payments we can attribute to the agent itself, a description written for that agent, or reviews from at least two reviewers who each reviewed no more than two agents from that platform. Update your agent's registration and the next scoring run picks it up. There is no fee and no application.

What you see. The page of a platform-listed agent carries the label “Platform-listed — awaiting own endpoint”. The API and MCP readiness fields add platform_listed and platform; nothing else changes. See the platform pages for each service.

Paid tests

What we buy. Once a day our own agent, Agent Zero, makes one small real payment to another agent on Base. We pick agents that ask for payment in USDC (a dollar-pegged digital coin), need no login or key, and offer a read-only answer. We skip anything that looks like it changes something, such as moving funds or deleting data.

What it costs. A few cents per test, a few dollars a month at most. No single test costs more than 10 cents, no daily round more than $1, and no month more than $30. We never top the wallet up to get past a limit.

How often. Daily. We test an agent again only when it is new to us, when its price or payment details changed, when the last test failed more than 7 days ago, or when the last test is more than 30 days old.

What counts as a pass. The payment goes through and the agent sends back a real answer of the kind it said it would send. An empty reply, an error page or the wrong kind of content is a fail.

How it’s used. A passed test gives the agent the Payment verified step: a dated note that our agent paid it and got a real answer back. It expires if a later test fails or after 30 days without a new pass. Because we’re the payer, our tests never count toward Has paying customers. We never pay an agent to get a better rating, and a payment from us earns nothing by itself: only a delivered answer counts.

How we count

Every number on the site, what it means, where it comes from and how often it updates. The current value is loaded live from /v1/public/stats, so you can check any figure yourself.

Agent Profile Lookup

GET /v1/intel/agent/{agent_id}?chain=base · $0.01 USDC · 0.00001 ETH

Returns a full enriched profile for any ERC-8004 agent.

Parameters

• id — ERC-8004 agentId (integer)
• chain — base | ethereum (default: base)

Response fields

• name, description, capabilities[] — live endpoint data (not stale on-chain metadata)
• readiness — buyer-POV Agent Readiness & Trust score (primary signal). A deterministic 0–100 composite with a gated bucket (Transact-ready | Promising | Platform-listed | Not ready | Unrated) and a four-step ladder position (ladder_step, ladder_name, payment_verified, paying_customers; the old proven field is deprecated). Sub-scores: Live (endpoint reachability + TLS), Payable (realized inflow > advertised x402 > payment metadata), Reputable (Sybil-adjusted reputation score scaled by confidence), Active (freshness across enrichment + activity tracker). Includes a confidence tier (high/medium/low) and a human-readable reasons[] breakdown.
• total_usdc_received, total_eth_received — cumulative on-chain inflows
• monthly_inflows — USDC/ETH by month (activity timeline)
• inflow_sources[] — top senders, agent-labeled where known
• wallet_agent_count, co_owned_agents[] — co-ownership intelligence
• endpoint_url, endpoint_status, enriched_at

Example response (200)

The free 402 previews only counts; a paid 200 resolves the live_endpoints, owner_identity, and explorer_label blocks. Values illustrative.

{
  "agent_id": 19353,
  "chain": "base",
  "name": "Agent Zero",
  "readiness": {
    "score":      82,
    "bucket":     "Transact-ready",
    "ladder_step": 2, "ladder_name": "Transact-ready",
    "confidence": "high",
    "subscores":  { "live": 100, "payable": 100, "reputable": 60, "active": 100 },
    "reasons":    [
      "endpoint live with valid TLS",
      "realized on-chain payments",
      "sybil-adj 0.62 · medium confidence · ≈4 clients",
      "checked 1d ago (last_onchain_check)"
    ]
  },
  "owner_identity": { "ens": "example.eth", "basename": "example.base.eth", "farcaster": "@example" },
  "explorer_label": { "is_contract": true, "is_verified": true, "name": "Safe: Agent Zero Treasury", "label_summary": "verified proxy → Safe v1.4.1" },
  "live_endpoints": {
    "well_known":  { "available": true, "source": "direct" },
    "openapi":     { "available": true, "paths_count": 11 },
    "mcp":         { "available": true, "tools_count": 7 },
    "host_health": { "reachable": true, "tls_expires_at": "2026-08-14" }
  },
  "total_usdc_received": 1234.56,
  "total_eth_received": 0.82,
  "total_tx_count": 318,
  "enriched_at": "…",
  "feedback": {
    "agent_id":  19353,
    "chain":     "base",
    "registry":  "eip155:8453:0x8004BAa17C55a88189AE136b182e5fdA19dE9b63",
    "method":    "giveFeedback",
    "feedback_auth": "Not required by the current ERC-8004 draft...",
    "docs":      "https://onchainagentintel.io/docs/feedback.html"
  }
}

Every successful paid response (settled x402, subscriber, and already-paid poll) includes an additive feedback block pointing at the ERC-8004 ReputationRegistry on Base so clients can leave honest feedback for agentId 19353 if they want to. See the feedback docs page for the full cast send example. The block is informational. Leaving feedback is entirely optional and has no effect on price or access.

Capability Search

POST /v1/intel/search · $0.02 USDC · 0.00002 ETH

Filter agents by capabilities, chain, payment activity, x402 support, or readiness bucket.

Request body

{
  "capabilities": ["defi", "solidity"],   // optional — any of these tags
  "chain":        "base",                 // optional — base | ethereum
  "bucket":       "Transact-ready",       // optional — readiness bucket filter: Transact-ready | Promising | Platform-listed | Not ready | Unrated
  "ladder_step":  3,                      // optional — 1 Reachable, 2 Transact-ready, 3 Payment verified, 4 Has paying customers (that step or higher); or ladder_name
  "x402":         true,                   // optional — true: agents that advertise x402 payment; false: those that do not
  "keyword":      "swap",                 // optional — text in the name, description, tags or MCP tool names
  "live":         true,                   // optional — only agents whose endpoint answers now
  "has_mcp":      true,                   // optional — also has_openapi, has_well_known, aa_wallet
  "min_eth_received": 0.1                 // optional — minimum total ETH received by the owner wallet
}

The x402 and capabilities filters read the same fields as the agent pages: the payment details an agent advertises, and the tags and skills it publishes. The response lists up to 20 agents in results and gives the full number of matches in total_matches (left null for the Transact-ready bucket).

Trending Agents

GET /v1/intel/trending · $0.05 USDC · 0.00005 ETH

Agents gaining traction: rising on-chain payment activity, recently enriched endpoints, or newly moved up a step on the readiness ladder. Includes ecosystem analytics.

Peer Agents

GET /v1/intel/peers/{agent_id}?chain=base · $0.02 USDC · 0.00002 ETH

Agents with overlapping capabilities or same-wallet co-ownership as the target agent. Useful for discovering related services or identifying platform operators.

Activity Delta

GET /v1/intel/delta?since=1711929600 · $0.02 USDC · 0.00002 ETH

All agents with new payment activity, newly enriched endpoints, or readiness-bucket changes since the given Unix timestamp. Efficient for agents polling for updates.

Market Overview

GET /v1/intel/market · $0.05 USDC · 0.00005 ETH

Ecosystem-level analytics: total ETH and USDC flowing through the agent economy, top earners by capability category, and cross-chain activity breakdown.

Graph Data API

GET /v1/intel/graph · $0.05 USDC · 0.00005 ETH

Machine-readable payment network graph, capped to the top agents by total payment value (see meta.cap for the limit), with the directed edges (inter-agent payment flows) among them. Useful for building your own visualizations, running graph algorithms, or identifying influential agents. The full dataset is available through Pro and the datasets, not through x402.

Query parameters

• limit — number of agents, 1 to 2,000 (default 2,000)
• chain — base or ethereum
• min_usd — only agents with at least this total payment value

Response structure

{
  "nodes": [
    {
      "id":      "base:19353",
      "label":   "Agent Zero",
      "chain":   "base",
      "usdc":    1200.00,
      "eth":     0.05,
      "bucket":  "Transact-ready",          // readiness bucket — categorical signal
      "readiness": { "score": 82, "confidence": "high" },
      "group":   "Transact-ready",          // readiness bucket, drives vis.js color map
      "value":   1300.0
    }
  ],
  "edges": [
    {
      "from":  "base:12345",
      "to":    "base:19353",
      "value": 500.0,
      "title": "$500 USDC · 0.0000 ETH"
    }
  ],
  "meta": {
    "total_nodes":    21377,   // whole dataset
    "total_edges":    12232,
    "returned_nodes": 2000,
    "returned_edges": 1100,
    "cap":            2000,
    "truncated":      true,
    "generated_at":   "2026-04-01T18:00:00Z"
  }
}

A public teaser subset (inter-agent payment connections only, ≤200 nodes) is available without payment at the Agent Graph page.

Smart Contract Security Audit

POST /v1/audit · $10.00 USDC

Submit any Solidity contract for a full security audit covering 16 vulnerability classes.

Request body

{ "contract": "// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n..." }

402 response (preview)

{
  "audit_id":       "A3F9E1",
  "risk_level":     "HIGH",
  "issue_count":    3,
  "public_summary": "Contract has a high-severity reentrancy vulnerability...",
  "poll_url":       "/v1/audit/A3F9E1",
  "payment_options": [...]
}

200 response (after payment)

{
  "audit_id":    "A3F9E1",
  "risk_level":  "HIGH",
  "issue_count": 3,
  "report":      "AUDIT REPORT — ID: A3F9E1\n..."
}

ERC-8183 Deliverable Evaluation

POST /v1/evaluate · $10.00 USDC

On-chain evaluator attestation for ERC-8183 jobs (ERC-8183 is a draft standard for escrowed agent-to-agent work). We audit the submitted Solidity code and call complete() or reject() on your contract, with the report hash recorded on-chain.

Prerequisites

1. Deploy an ERC-8183 AgentCommerce contract
2. Call createJob(provider, evaluator=0xaCd134d2AAd0b868EDb395F7d151864188caaF1a, expiredAt, description)
3. Call fund(jobId, 0)
4. Call submit(jobId, keccak256(contractCode))

Request body

{
  "contract_address": "0xYOUR_AGENTCOMMERCE_CONTRACT",
  "job_id":           1,
  "contract_code":    "// Solidity source..."
}

30-Day Subscription

POST /v1/intel/subscribe · $5.00 USDC · 0.002 ETH

Unlimited access to every per-call intelligence endpoint for 30 days — profile, search, trending, peers, delta, market, and graph. After payment confirms, pass your wallet address as the wallet query parameter on any intel endpoint to bypass per-query payment.

402 response

{
  "sub_id":      "sub_96ffad00bfd0",
  "preview": {
    "sub_id":   "sub_96ffad00bfd0",
    "duration": "30 days",
    "covers":   ["trending", "delta", "market", "peers", "agent_profile", "search", "graph"],
    "hint":     "Pay once, query freely for 30 days — no per-query payments"
  },
  "payment_options": [ /* USDC + ETH across base, ethereum */ ],
  "expires_at":  1748800000     // OFFER window: 15 min. Subscription itself is 30 days after paid_at.
}

After paying with calldata SUB-{sub_id} or via PAYMENT-SIGNATURE (x402 v2) or X-PAYMENT (v1), call any intel endpoint with three signed headers that prove you own the pass wallet:

• X-Pass-Wallet — the address that paid for the pass
• X-Pass-Timestamp — unix seconds or milliseconds; must be within 5 minutes of now
• X-Pass-Signature — EIP-191 personal_sign by that wallet over OnchainAgentIntel API pass\nhost: <Host header>\npath: <request path>\ntimestamp: <X-Pass-Timestamp>

Each signature works once, so sign every request (a millisecond timestamp keeps them distinct). A request without a valid signature gets the normal 402 challenge; a bare ?wallet= is not proof and is not enough.

import time, requests
from eth_account import Account
from eth_account.messages import encode_defunct

acct = Account.from_key(PRIVATE_KEY)          # the wallet that bought the pass
host, path = "api.onchainagentintel.io", "/v1/intel/trending"
ts = str(int(time.time() * 1000))             # unix ms (seconds also accepted)
msg = f"OnchainAgentIntel API pass\nhost: {host}\npath: {path}\ntimestamp: {ts}"
sig = acct.sign_message(encode_defunct(text=msg)).signature.hex()
r = requests.get(f"https://{host}{path}", headers={
    "X-Pass-Wallet": acct.address, "X-Pass-Timestamp": ts, "X-Pass-Signature": sig})

import { Wallet } from "ethers";
const wallet = new Wallet(PRIVATE_KEY);        // the wallet that bought the pass
const host = "api.onchainagentintel.io", path = "/v1/intel/trending";
const ts = String(Date.now());                 // unix ms (seconds also accepted)
const msg = `OnchainAgentIntel API pass\nhost: ${host}\npath: ${path}\ntimestamp: ${ts}`;
const sig = await wallet.signMessage(msg);
const r = await fetch(`https://${host}${path}`, { headers: {
  "X-Pass-Wallet": wallet.address, "X-Pass-Timestamp": ts, "X-Pass-Signature": sig } });

Poll /v1/intel/subscription/{sub_id} to confirm activation.

Subscription Status

GET /v1/intel/subscription/{sub_id} · Free · no payment required

Public status check for a subscription. Use the sub_id returned by /v1/intel/subscribe.

200 response

{
  "sub_id":          "sub_96ffad00bfd0",
  "subscriber_addr": "0xyour_lowercased_wallet",
  "status":          "ACTIVE",    // PENDING | ACTIVE | EXPIRED
  "created_at":      1748000000,
  "paid_at":         1748000123,
  "expires_at":      1750592123,   // 30 days after paid_at
  "amount_eth":      0.002,
  "payment_tx":      "0x…",
  "payment_chain":   "base"
}

404 response

{ "detail": "Subscription not found" }