Virtuals grew out of PathDAO, a 2021 company under Jansen Teng and Wee Kee Tiew, and relaunched on Base as the place to give an agent capital. It is the loudest capital-formation rail in the sector, and the Agent Commerce Protocol is a genuine attempt to put a job state machine underneath the tokens.
What Virtuals actually owns
- Tokenised agents — an ERC-721 identity plus an ERC-20 with a bonding curve.
- GAME — the planning loop, the cognition layer of the marketplace rather than a separate company.
- ACP — the job lifecycle, with an evaluator step. An escrowed job with an evaluator is the closest thing in this sector to a real labour market.
- Vaults and tax wallets — where an agent's share of its own economics accrues.
An ACP job payment is a money event. If a bound operator wallet paid or received an ACP settlement above dust, that actor is doing work. A bonding-curve buy of the agent's token is not, and never will be. Why those two get merged, and what it costs →
Our qualifier, run over their catalog
Below is the join, updated on our own cadence. Two things about the denominator matter more than any of the numbers:
- Attempted is ours, not theirs. It counts the identities we have actually ingested and checked — not the platform's total. A rate over somebody else's published census cannot be reproduced by the reader.
- A wallet declared by several agents counts once. This turned out to matter enormously, and it is the finding on this page.
Their catalog, as their own fields describe it
Their fields, counted on our rows. Neither rail is a sale.
How many people are behind the names
Read the first row before the rest. The operator key comes from the catalog's own creator account id, recorded since 12 September. On 7 November it was known for every one of the 86,263 identities we read, so the ratio describes the whole catalog we read. We publish the coverage in the same block precisely so it cannot be quoted without it.
Our qualifier over those same rows
Measured by our own collector. As of 2026-11-10 17:36 UTC. The full document, with caveats attached to every figure, is at /api/partners.
Read every number above against this one
The overwhelming majority of this catalog has not launched. Their own status field says so: a small minority is tradeable, and the rest is pre-graduation. Any figure computed over the whole catalog is therefore mostly a statement about agents that have not started yet — which is why we publish the split in the same block rather than in a footnote.
This is also why our own liveness ladder caps an ungraduated Virtuals agent with no job payment at L4, no matter what else it declares. A name that has not launched cannot be a worker, and the ladder refuses to let it look like one. The cap, in the ladder →
The ACP row is worth separating from the token row for the same reason. An ACP identity means the agent is registered on the job rail; a token address means it is registered on the token rail. Neither is a sale. Registration on a job protocol is the strongest structural signal in this catalog that an agent is meant to work rather than to trade — and it is still only a registration.
The job rail, decoded from the chain
About half this catalog carries an ACP identity, which makes the field nearly useless on its own — registration is free. So we read the Agent Commerce Protocol contract on Base directly: jobs created, funded into escrow, submitted, evaluated, and either paid out or refunded. No API key, no dashboard, no permission required.
Agent Commerce Protocol · read from Base
As of 2026-11-10 17:36 UTC. Amounts are USDC at six decimals — a unit we confirmed by matching a funding event against the USDC transfer in its own transaction receipt, not by deciding the numbers looked about right.
A payment of zero is not a payment
The single most important line in that block is the zero-value share. The contract emits a PaymentReleased event when a job settles — and most of the time it releases nothing at all.
Counting those events as payments, which is the obvious thing to do and what any dashboard built on event counts would do, would have reported this rail at several times its real size. It is the same error as counting a routing hop as spending, and we only avoided it because we opened one of the transactions and found no token transfer in it. So both numbers are published: jobs with a payout event, and jobs that actually paid.
The tickets that are real are tiny — cents, sometimes fractions of a cent. That is not a criticism. It is what a working machine-to-machine payment rail looks like, and it is exactly why dollar totals here will always read small beside any DeFi figure. The same pattern on the x402 rail →
This is where L7 becomes sayable
Everywhere else on this page we withhold L7, because an outbound USDC transfer from an agent's wallet cannot be told apart from a token trade. Here it can: a provider paid a non-zero amount for a job, through an escrow with an evaluator attached, is a payment for work by any definition we would accept.
Paid for work — the first L7 on this catalog
Read that as a floor, not a census. It counts only wallets we have already bound, on jobs inside the range we have indexed, with the shared-wallet exclusion applied. Every one of those constraints pushes the number down. What L7 requires →
Names, wallets, and people are three different counts
The block above is the one we expect to matter most over time. A catalog of 86,263 agent identities run by 30,362 creator accounts, one of which holds 20,752 of them (7 November 2026), is a different object from 86,263 independent agents, and the platform's own creator id settles it exactly — no inference from funding patterns, no clustering heuristic to argue with.
We store only the opaque account number. The catalog returns an email address, a username and social handles beside it; none of those enter this graph, because counting distinct operators needs an identifier and nothing more. What we do and do not store →
The finding: one wallet, many agents
The single most consequential thing we learned running this join is that a large share of declared agent wallets are not agent wallets at all. They are operator wallets, declared by many agents at once. The worst case we have found so far is one address declared by 20,750 different agents.
At the top of that distribution the pattern stops looking like an operator at all. The single busiest address is declared by 20,750 identities from one creator account, created across about eleven weeks — and a handful of them ever launched a token. That is bulk creation, the Virtuals analogue of the mint bursts we already measure on ERC-8004, and we treat it the same way: a shape in the data, not an accusation about a person. Creating names in bulk is permitted and cheap, which is exactly why a name count cannot be an agent count.
Every one of those identities is excluded from our bound set automatically, because they share a wallet. That is the exclusion earning its place: without it, a single address would have contributed tens of thousands of phantom agents to a figure labelled bound.
The rest of the figure is published live rather than written into this sentence, because it only grows as we read further into the catalog: it was 84 when we first measured it, on a sample a fraction of the current size. Any count that treats each of those names as a separate live agent multiplies one operator's activity by that number. It is the farm-inflation problem in its purest form, and it does not require anyone to be acting in bad faith — a person who launches a hundred characters from one wallet has done nothing wrong. It simply means the catalog is counting names and we are trying to count actors.
So identities sharing a wallet are excluded from our bound set entirely, and we publish the share they represent rather than quietly dropping them.
Why we do not call any of this L7
L7 is withheld on this catalog, on purpose. L7 means a payment for work. From a raw wallet read, a bonding-curve buy, a token launch, a liquidity add and a DEX swap all look exactly like an outbound USDC transfer. We read the ACP job rail itself since 12 September (on 7 November: 10,019 jobs, 1,075 of them paid, $135.17 released in all, and 65.7% of payout events released nothing), but a catalog wallet's transfers are not tied to its jobs, so we still cannot separate an agent selling a service from an operator trading a token — and we would rather publish a narrower true number than a wider flattering one.
Corrected 7 November 2026. Three sentences on this page still described our reading of mid-September: the operator key on "a fraction of the rows", "thirty thousand agent names", and "ACP job state is not ingested yet" (the job rail has been read since 12 September). They now give the figures of 7 November.
What we publish instead is exactly what we measured: the declared wallet sent USDC to a different address after the agent existed. That is a real, checkable, useful fact. It is not a labour market.
Two further corrections are already applied to it. Self-transfers are excluded, because moving your own money between your own wallets is not paying anybody. And transfers that happened before the agent's own launch date are excluded and counted separately — a declared wallet is frequently years older than the agent declared on it, and counting that history as agent activity is the same error that once overstated our own headline by 46%. The ladder, and why L7 is where public ranking starts →
What would move this from a measurement to a market
- ACP job state. Ingesting job identifiers, budgets, evaluators and settlement would let us separate an agent that sold a service from an operator that traded a token. This is the single highest-value connector left unbuilt.
- Same-funder clustering across distinct wallets. We currently catch wallets shared explicitly. A farm that gives each of its fifty personalities a distinct wallet funded from one source is not yet caught, which is why every rate on this page should be read as an upper bound.
- A published constituent address set. The same ask we make of every operator. Our own, published →
What we refuse to publish about Virtuals
- FDV as TVL. The fully diluted value of $VIRTUAL or of any child agent token is a crowd's opinion, not capital at work.
- Holder counts as adoption. Token holders are fans. They are never a binding.
- Token addresses as wallets. We record the token address and never bind to it.
- Their census as our denominator. Every rate above is over identities we ingested and checked.