Sato Hub
Measured daily

The Onchain Agent Economy

See how many agents register and how much x402 payment activity happens, chain by chain.

Take the data
  • Updated2026-10-16
  • Free to reuseCC-BY
Registered agentsRegistered agentsAgent IDs in the ERC-8004 registry on the largest chain, read from the chain itself. Every chain keeps its own count; the page never adds chains together.
3,919,209
0G · largest chainas of
New registrationsNew registrationsAgent IDs added to the ERC-8004 registry in one full UTC day: the newest day with a reading, on the chain that added the most among the chains read that day. That day can trail Latest day below when a chain's read lands late. Today's partial day never counts.
23,106
Base · one UTC dayas of
x402 transactionsx402 transactionsTransactions sent by known x402 payment processors in one UTC day, on the busiest of the chains read that day. An upper bound: it counts every transaction those keys send, and not each one is an agent paying for something.
6
Sei · one UTC dayas of
Chains trackedChains trackedChains with at least one reading in the latest weekly collection. Each chain's numbers stay separate.
13
Each read on its ownas of

One full UTC day

Latest day

Latest dayA day counts once it is over in UTC and our daily read has finished it. Today's partial readings never appear here.
UTC

New agent registrations

+23,106

Base

  • 0G+10,428
  • BNB Chain+878

Agent IDs added that day, per chain.

x402 transactions

52,530

Solana

  • Avalanche2
  • Sei2

Sent by x402 payment processors. An upper bound.

x402 endpoints asking to be paid

83.3%

Basen=60 · 36,387 listed

  • Solana66.7%n=60 · 636 listed

Share of sampled listings that answered with a payment request.

How we measureShowHide

New ERC-8004 agent identities. Registrations on 2026-10-15, per chain — top 4 of 26 chains read. Chains are never added together.

x402 facilitator throughput. Transactions sent by known facilitator keys — an upper bound, not screened for self-payments. Not every such transaction is an agent paying for something. Held from these figures: Pieverse on BNB Chain; Polygon Facilitator on Polygon; Figment on Solana; FluxA on Base; three.ws on Solana — the readings are exact but are not shown as x402 activity while the evidence behind each hold stands. Some shown readings carry a note about what the sample could not see. An operator is held for a day automatically when, on at least 50 sampled settlements, we are 95% confident that 90% or more of them paid one address — and when a new or sudden reading of 50 or more transactions could not be sampled at all, until it is checked. Reasons and evidence are on /numbers/x402-facilitator-throughput.

Listed x402 resources that answer HTTP 402. A sample of Bazaar listings probed that day; answering 402 means the endpoint asks for payment, not that anyone paid.

A day counts once it is over in UTC and our daily read has finished it; today's partial readings never appear here. Each figure is one chain or one operator. None is a total.

Weekly read

Chain by chain

Each registry or rail counts a different thing. Open one for its full numbers.

X40

x402 payment rail

Payment rail
Transactions, 1 day
19,204
Chain
Solana
as of
View

Can't be read onchain

KEY

Key-management / server-wallet providers

Wallet keys

These providers mint ordinary EOAs from a TEE or MPC ceremony — a Privy wallet is indistinguishable from a MetaMask wallet by construction.

Not readable onchain
n/a
no reading yet
View
How we measureShowHide

Each registry or rail counts a different object and charges a different price of entry. Free and permissionless is not the same market as bonded, and a launchpad is not a registry. Each card shows the largest single chain; open it for every chain and step.

  • ERC-4337 smart-account infrastructure. One unit: one deployed smart account
  • ERC-7715 permission grants (MetaMask Delegation Framework). One unit: one delegation redeemed (a scoped permission actually exercised by a session key)

    How measured · RedeemedDelegation events on the singleton DelegationManager over the trailing window, read with eth_getLogs and no sampling; a grant emits nothing, so this is a floor on permissions granted. The trailing window, read once a week.

  • ERC-8004 Identity Registry. One unit: one registered agent id Overlaps with olas; never add them.

    How measured · The ERC-8004 Identity Registry's own agent-id counter (`_lastId`, one storage read at the chain head) on that chain, covering the whole registry with no sampling. The latest daily reading.

  • Morpheus / Lumerin. One unit: one GPU provider or model (NOT an agent)
  • Olas (Autonolas). One unit: one deployed service (a running agent service, not a blueprint) Overlaps with erc8004; never add them.

    How measured · totalSupply() on the confirmed Olas service registry contract on that chain. The latest weekly reading.

  • SingularityNET service registry. One unit: one paid gRPC service endpoint (NOT an agent)
  • Metaplex Agent Identity (Solana). One unit: program account (UPPER BOUND — includes initialised-but-unused and duplicate accounts)
  • SATI / 8004-solana (Solana). One unit: program account (UPPER BOUND — includes initialised-but-unused and duplicate accounts)
  • Tempo — Machine Payments Protocol rail. One unit: TIP-20 transfer carrying an invoice memo (MPP-SHAPED, not proof of an MPP payment)
  • Virtuals Protocol. One unit: one agent-token LAUNCH at stage 1; one graduated agent NFT at stage 2. These are different objects and must never be conflated.

    How measured · The length of the public tokenInfos array on Virtuals' BondingV5 contract on Base, found by binary search for the first index that reverts. The latest weekly reading.

  • Virtuals Agent Commerce Protocol (ACP v2) job funnel. One unit: one job (a client agent's work request to a provider agent, escrowed in USDC) Overlaps with virtuals; never add them.
  • x402 payment rail. One unit: one settlement (a machine paying a machine for an HTTP request)

    How measured · For every catalogued x402 facilitator key, the transactions it sent in the last complete UTC day (on EVM chains its nonce at the last block before each UTC midnight, end minus start; on Solana its fee-payer signatures in that day), summed per chain over the operators not held from public figures — an upper bound on settlements, not screened for self-payments. The last complete UTC day.

Registries that can't be read onchain are listed with the reason, because a missing fingerprint is itself a finding.

Reading these numbersShowHide

Sato Hub measures 12 of 13 agent platforms from public chain data on 13 chains, each reported on its own, as of 2026-10-16.

Reading the numbers

  • Nothing here adds up, on purpose. An ERC-8004 registration, an Olas staked service, a Virtuals token launch and a paid Mech task are different objects. There is no total on this page and none in the export.
  • Every number names its step and its chain. Each answer picks the largest single chain and says how many chains were counted separately.
  • A sampled rate is never multiplied by a population. You will not find an “estimated active agents” figure here, because we would be making it up.
  • Missing readings say so. Where a public node prunes its history we say “not measured” and why. A missing reading shows as n/a and never rounds to zero.
  • Thin samples are kept, not quoted. A rate on fewer than 20 observations reads “not enough readings (n=…)”; the detail is on each registry's page.
  • Solana is covered as an upper bound. The Solana identity registries are counted by program account (at most this many), and Tempo's memo-tagged transfers are counted as MPP-shaped settlement. No row here covers Solana payment settlement.

What this data cannot settle

  • Whether a registered agent is an agent. Registration is permissionless and free on most of these registries. It proves an entry exists, not that software runs behind it.
  • What BNB Chain agents do after registering. Its count is exact and daily; its lifecycle is not measurable over a 30-day window from any keyless endpoint we could find. The log archive is roughly two hours deep.
  • Solana payments, and whether a Solana account is an agent. The Solana registries are read by program-account count, an upper bound that includes unused and duplicate accounts. Solana x402 settlement needs an indexer we do not run. Any claim about “the agent economy” built from this page should say both.
  • Whether a smart account is an agent. Only some sampled smart accounts also held an ERC-8004 agent ID or paid a listed x402 seller in the same week, and the share differs by chain. See Wallet providers for each chain's own share.
  • Who runs a wallet. These are observations of public software. No identities, no IPs, no per-caller profiles.

What we cannot attribute

13 of 46 confirmed smart-account contracts have no directory listing to attribute them to. Privy (server and embedded), Turnkey, Coinbase CDP Server Wallets, Dynamic and Fireblocks can't be measured from chain data at all: they mint ordinary EOAs, and when their user deploys a smart account the factory belongs to a different company. So the Wallet providers view covers account-abstraction vendors well and wallet-infrastructure vendors not at all. That follows from how these wallets are built; more effort would not close it.

The two headline numbers

How measured · The ERC-8004 Identity Registry's own agent-id counter (`_lastId`, one storage read at the chain head) on that chain, covering the whole registry with no sampling. The latest daily reading.

How measured · For every catalogued x402 facilitator key, the transactions it sent in the last complete UTC day (on EVM chains its nonce at the last block before each UTC midnight, end minus start; on Solana its fee-payer signatures in that day), summed per chain over the operators not held from public figures — an upper bound on settlements, not screened for self-payments. The last complete UTC day.

Reference

QuestionsShowHide

Questions people ask about the onchain agent economy

How many onchain agents are there?
No single number answers that, and this page refuses to invent one. 12 venues are measured for the week beginning 2026-W42, each counting a different object: an ERC-8004 registration, an Olas staked service, a Virtuals launch and a paid task are four things. Every figure is published with its stage named.
Why is there no total?
Because a total would be wrong in a way that looks right. The same operator can register on four chains and appear four times; a launchpad token and a registry id are not comparable units. There is no total on this page and none in the export.
What cannot be measured?
1 catalogued venue cannot be censused from chain data at all, and each is listed with the architectural reason rather than dropped. An absent fingerprint is a finding.
How current are these figures?
They are collected weekly; this view is the week beginning 2026-W42, and each row carries its own coverage window. A row that banked nothing is null — unknown, never zero.
Can I reuse these numbers?
Yes, under CC-BY, from the adoption export in JSON, CSV and NDJSON. Carry the stage name and the evidence tier with the figure; rates computed on fewer than 20 observations are stored but are not findings.
SourcesShowHide

Sources — the standards these venues implement

Cite this pageShowHide

Cite this page

Sato Hub. "The onchain agent economy." Sato Hub, updated 2026-10-16, accessed 2026-10-16. https://satohub.ai/agent-economy

Data last refreshed 2026-10-16; this page is rebuilt daily. Citations carry the date so a reader can tell which snapshot a claim came from. Catalog data is licensed CC-BY-4.0.

Join the Sato Hub Briefing

Sign up for the Briefing: the agents, tools, and infrastructure that actually shipped, and why they matter.