How many ERC-8004 agents actually accepted a payment today?

On Base, 10 distinct ERC-8004 agents accepted a test payment from our Agent Zero wallet and returned a substantive HTTP 200 response, across three dated pilots: 2 on 2026-10-12 (task 0982b), 3 on 2026-10-12 (task 0983), 5 on 2026-10-13 (task 0988). Each payment was an EIP-3009 transferWithAuthorization in Base-USDC against the agent's own advertised payTo. The on-chain settlement tx hashes are listed in docs/0988-buy-round/RESULT.md and the snapshot.json companion. Ethereum: zero agents paid in this window — no Ethereum ERC-8004 agent cleared the cheapest-cost gate before the pilot windows closed.

What are the 10 stages of the funnel?

Registered on-chain -> Advertises a paid endpoint (any payment field in card, well-known, metadata.payment_options) -> Endpoint answers (HTTP reachable at all, 200..599) -> Returns a valid x402 402 challenge (parseable accepts[] non-empty, v1 or v2) -> Includes a payTo (0x + 40 hex) -> Publishes a parseable price (payTo + positive price field) -> Price in normal range (min advertised price_usd Payable cold (no login or API key gate) -> Our test purchase settled on-chain (EIP-3009 transfer confirmed) -> Delivered after payment (HTTP 200 with substantive body after settlement = Proven). The precise counting rule for each stage is in METHOD.md.

Why is the deterministic funnel count different from the pilot count?

Stages 1-7 are deterministic — they read today's live profile store, which carries one row per ERC-8004 (chain, agent_id) pair with a parsed metadata card, a live reachability probe, and any stored x402 challenge. Stages 8-10 are observed via test purchases. The two measurement regimes can disagree in a known direction: a pilot can deliver on an agent whose price lives on an endpoint we did not persist back into live_endpoints.x402_challenge.accepts[] (the Convert Guru case, plus five 0988-era agents). We count those as `observed_outside_pool` so the primary funnel stays monotonic and the honest view is still visible. Base: 4 deliveries inside the deterministic stage-7 pool, 6 outside it, 10 total.

What are the drop-off reasons at each stage?

On Base, in descending volume: not_advertised 23,269 (99.4% of all registered Base agents emit no payment field in metadata, well-known, or metadata.payment_options), no_402_challenge 93 (advertises but never returns a parseable 402), unreachable 15, price_missing 1 (the Forge Knowledge Engine agent prices in ETH-wei, excluded from the USD cap). In the test-purchase pilots: pay_failed 17 (facilitator verify-only valid but the agent's own server rail returns 400/402/422/405), missing_accepts 5, method_not_allowed 2, settled_no_delivery 1 (YieldAgentX402 took the USDC and still returned a 402), auth_walled 1. The drop_reason_enum in snapshot.json is the full list of code paths; see METHOD.md § Drop-off reason enum.

Is this a scoring change?

No. The Readiness/Trust composite, bucket thresholds, and published scoring rules are unchanged by this snapshot. The funnel is a tracked measurement — it reports what the system can already count. Any change to scoring/methodology is propose-only in our operating posture (STANDING POLICY, documented in CLAUDE.md § 5b). If a future snapshot ever drives a scoring edit, that edit will be gated separately and explicitly.

How can I reproduce the snapshot?

The snapshot script is scripts/metrics/payability_funnel_snapshot.py in our public repo. It reads one input (the live profile store at ~/.openclaw/erc8004_agent_profiles.json) and three pilot evidence files (docs/0982b-test-purchase-pilot/evidence.json, docs/0983-product-readiness/pilot-evidence.json, docs/0988-buy-round/pilot-evidence.json). Run `python3 scripts/metrics/payability_funnel_snapshot.py --date YYYY-MM-DD --write` and it writes `metrics/payability-funnel/ /funnel.json` + `funnel.csv`. The daily snapshot timer is at `scripts/systemd/payability-funnel-snapshot.{service,timer}`.

Of 23,403 ERC-8004 agents on Base, 10 delivered a response when we paid them

One honest sentence. Of 23,403 registered Base agents, 134 advertise a paid endpoint, 25 publish a parseable price in the normal range, and 10 delivered a real response when we paid them in three dated test-purchase pilots across 2026-10-12 and 2026-10-13. On Ethereum: 2,946 registered, 7 advertise, 2 priced, 0 paid in this window.

The funnel

Each row is a count of agents (and, separately, distinct payTo operators — a lower bound on operator identity, since one operator may use multiple payTos). Stages 1-7 are deterministic — they read today's live profile store, and two readers of the same blob get the same answer. Stages 8-10 are observed — they come from running test purchases and watching what happens.

Base — `chain_id` 8453

#	Stage	Agents	Operators	% registered
1	Registered	23,403	23,352	100.0 %
2	Advertises paid endpoint	134	116	0.57 %
3	Endpoint answers (HTTP reachable)	119	101	0.51 %
4	Returns valid x402 402 challenge	26	9	0.11 %
5	Includes a payTo	26	9	0.11 %
6	Publishes a parseable price	26	9	0.11 %
7	Price in normal range (≤ $1.00/call)	25	8	0.11 %
8	Payable cold (no login / API key)	8	8	0.03 %
9	Our test purchase settled on-chain	4	4	0.02 %
10	Delivered after payment	4	4	0.02 %

Six additional Base agents outside today's deterministic stage-7 pool also delivered a response when we paid them. The pool-restricted row is 4; the full observed-delivery count across the three pilots is 10. The gap exists because the price for those six lives on an endpoint our profile store does not yet persist in live_endpoints.x402_challenge.accepts[].

Ethereum — `chain_id` 1

#	Stage	Agents	Operators	% registered
1	Registered	2,946	2,945	100.0 %
2	Advertises paid endpoint	7	6	0.24 %
3	Endpoint answers (HTTP reachable)	7	6	0.24 %
4	Returns valid x402 402 challenge	2	1	0.07 %
5	Includes a payTo	2	1	0.07 %
6	Publishes a parseable price	2	1	0.07 %
7	Price in normal range (≤ $1.00/call)	2	1	0.07 %
8	Payable cold (no login / API key)	0	0	0.00 %
9	Our test purchase settled on-chain	0	0	0.00 %
10	Delivered after payment	0	0	0.00 %

Ethereum stages 8-10 are 0/0 by sample, not by proof. We did not attempt an Ethereum purchase in these pilots because no Ethereum ERC-8004 agent cleared the cheapest-cost gate in the windows available to us. Our standing per-call cap is $0.50; the two Ethereum priced agents sit at $0.08 and would pass, but Ethereum gas economics make a USDC round-trip at that unit price a slow experiment to repeat. We publish the zero honestly rather than skip the row.

Where agents drop out

Deterministic drop-off reasons on Base, in descending volume:

not_advertised: 23,269 of 23,403 (99.4 %) — this is the dominant finding. Almost every registered Base ERC-8004 agent emits no payment field in its on-chain metadata, well-known card, or metadata.payment_options. Registered is not advertised.
no_402_challenge: 93 — advertises a payment field but never returns a parseable 402 at the probe URL.
unreachable: 15 — advertises but the host does not answer HTTP at all.
price_missing: 1 — one agent (Forge Knowledge Engine) prices in ETH-wei and so is excluded from the USD cap by our stage-6 USDC-only rule.

Observed drop-off reasons in the three pilots, in descending volume:

pay_failed: 17 — facilitator verify-only green, but the agent's own server rail returns 400/402/422/405. The signature is valid; the server disagrees with the facilitator about which rail counts.
missing_accepts: 5 — 402 returned with no parseable accepts[].
method_not_allowed: 2 — the advertised probe URL is POST-only; our GET-first probe missed the method.
settled_no_delivery: 1 — YieldAgentX402 took the USDC and still returned a 402.
auth_walled: 1 — three.ws returned 401 at the pay step despite a 402 at the probe step.

The price shape

Across the 25 Base agents with a parseable USDC price in the normal range, the distribution is:

min $0.01, median $0.05, max $0.50.
zero agents above $1.00; the one excluded agent prices in ETH-wei, not above-cap USDC.

That is a narrow band. The field test last week ran a wider price reading across endpoints (not agents) with a visible tail above $1. The agent-level view here looks tighter because aggregation collapses co-hosted endpoints that share a payTo onto one operator cluster; it tells a slightly different story and both are honest.

Method, in one paragraph

Stages 1-7 come from ~/.openclaw/erc8004_agent_profiles.json — the live profile store written by erc8004_discovery.py, agent_reenrich.py, and live_probes.py. One row per ERC-8004 (chain, agent_id). Stages 8-10 come from three dated pilot evidence files: 0982b (5 attempts / 2 delivered, 2026-10-12), 0983 (6 attempts / 3 delivered, 2026-10-12), 0988 (25 attempts / 5 delivered, 2026-10-13). Every test payment used Base-USDC under EIP-3009 transferWithAuthorization, signed by the Agent Zero payer wallet 0xB9148CD4…8D45 (ERC-8257 agentWallet for agentId 19353). Standing caps: $0.50/call, $5.00/round. Full combined spend across the three pilots: $0.5854 USDC ($0.0220 + $0.5300 + $0.0334) — less than a dollar to get the delivery column from zero to ten. Full method and the pre-pinned grading at METHOD.md and GRADE.md.

This is not a scoring change

The Readiness/Trust composite, bucket thresholds, and the published scoring rules are unchanged by this snapshot. The funnel is a tracked measurement — it reports counts the system can already produce. Any change to scoring/methodology is propose-only in our operating posture, and if a future snapshot ever drives a scoring edit, that edit will be gated separately and explicitly.

Cadence

The snapshot is a oneshot systemd timer at 06:00 UTC daily, writing metrics/payability-funnel/<date>/funnel.json + funnel.csv inside our repo. A new Payability tab in the LAN Command Center renders today's funnel plus the delta vs the prior snapshot and the top drop-off reasons; the /api/payability-funnel endpoint that drives it is LAN-only. Public dataset snapshots will land under /data/payability-funnel-<date>/ when they move the needle; we do not plan to publish a public page for every day.

Downloads

dataset.csv — one row per (chain, stage), flat.
snapshot.json — full structured snapshot (schema v1), including drop-off histograms, price distribution, and the list of delivered agents with their tx hashes.
METHOD.md · DATA-DICTIONARY.md · GRADE.md.

Cite: Onchain Agent Intel (2026). ERC-8004 Agent Payability Funnel — Base + Ethereum mainnet, 2026-10-13. https://onchainagentintel.io/data/payability-funnel-2026-10-13/. CC BY 4.0.

Of 23,403 ERC-8004 agents on Base, 10 delivered a response when we paid them — the payability funnel we're tracking from now on