Loading
Agent work on one ladder
All six rails read together 2026-10-16 04:31 UTCSix rails, seven rungs, one vocabulary. Olas counts tasks, ACP counts jobs, Masumi counts escrows and x402 counts transfers; none of those means the same thing as any other, so this places all of them on the same ladder and states what each rail can and cannot say at every rung.
A figure here can sit behind the same figure on the rail’s own page. That page reads its tables as you open it; this one compares six rails and so reads them together, at the moment above. The difference is two moments, not two answers.
The rungs are never added together. A registration, a request and a settlement answer different questions, and a total that mixes them lets a rail with a chatty request event outrank a rail where money actually moves. That total is how the agent economy is usually sized. It is not published here.
What became of every job
99,086 of 411,938 moved money, 24%, worth $1.03MThe middle column is a partition rather than a funnel: a job’s phase is the latest state it reached, not a stage it passed through, so these sum to every job created and none is counted twice. The grey band is jobs we hold a creation event for and no later reading of. It is drawn because leaving it out would shrink the diagram to the part that flatters us and make every share beside it wrong. “None recorded” means no payment we can see, which on a rail whose escrow event has never once been emitted is not the same as nobody being paid.
What a service charges, against how often it finishes
355 services with a price and at least 30 resolved jobs
Bubble area is how many jobs reached a verdict, so a service with more evidence behind it looks heavier. The rate is completed over completed plus rejected, never over jobs created: the second would score a service by how many of its jobs we have read a phase for, which is a fact about us. 2,051 services are not on this chart because fewer than 30 of their jobs reached a verdict, 96,198 jobs between them. Two resolved jobs and both completed is a hundred per cent, and it would sit at the top beside services with thousands behind them.
6
Rails on the ladder
each read from its own records
5
Rails that settle
1 cannot; their counts are not addable to each other
4
Rungs we do not read
a rail emits it and we do not
7
Rungs
registered through repeated
16,558,064 authorised transfer on x4023,365,078 task on Olas Mech213,299 channel on Tempo MPP96,565 job on Virtuals ACP29,222 escrow on Masumi
| Rail | 1 Registered | 2 Requested | 3 Funded | 4 Delivered | 5 Settled | 6 Validated | 7 Repeated |
|---|---|---|---|---|---|---|---|
by authorised transfer · rung 7 · read 20 hours ago | 64,716 resources a seller has listed | — not on this rail | — not on this rail | — not on this rail | 16,558,064 transfers | — not on this rail | 231,967 payer–payee pairs seen more than once |
by task · rung 5 · read 20 hours ago | ? we do not read it | ? we do not read it | — not on this rail | 929,605 deliveries | 3,365,078 fee payments | — not on this rail | ? we do not read it |
by job · rung 7 · read 2 days ago | ? we do not read it | 411,938 jobs created | — not on this rail | 125,769 jobs that reached evaluation or completion | 96,565 payments released | 197,572 jobs completed or rejected | 9,750 client–provider pairs seen more than once |
Masumi by escrow · rung 7 · read 22 hours ago | 265 agents registered | — not on this rail | 29,378 escrows created | — not on this rail | 29,222 escrows closed | — not on this rail | 100 buyer–seller pairs seen more than once |
by channel · rung 7 · read 20 hours ago | — not on this rail | — not on this rail | 270,894 channels opened | — not on this rail | 213,299 channels closed | — not on this rail | 767 payer–payee pairs with more than one channel |
ERC-8004 registries by registration · rung 6 · read 20 hours ago | 653,670 identities registered | — not on this rail | — not on this rail | — not on this rail | — not on this rail | 695,569 feedback records | — not on this rail |
What each rung proves
1
Registered
A declared identity or service exists.
A registration is a claim, not economic activity.
2
Requested
Demand or intent was created.
Asking for work costs nothing and commits nobody.
3
Funded
Economic value was committed.
Committed is not spent: an escrow can still refund.
4
Delivered
The provider claims work was produced.
The claim is the provider’s. Nothing here inspects the deliverable.
5
Settled
Payment was released or transferred.
The strongest evidence any of these rails carries, and still not proof a human wanted it.
6
Validated
The result was accepted, evaluated, or independently checked.
Often self-evaluated. Who judged it matters more than that it was judged.
7
Repeated
A recurring economic relationship exists.
The only rung that needs two events, and the hardest to fake cheaply.
What each rail cannot say, and why
x402
The rail carries settlement and nothing either side of it. A buyer asking, a seller answering and a file changing hands all happen over HTTP between two parties and never reach a chain.
- Requested
- Nothing precedes the transfer on chain. The request is an HTTP call carrying a 402 response, seen only by the two parties to it.
- Funded
- There is no escrow. Authorisation and settlement are the same act.
- Delivered
- The deliverable is an HTTP response. No record of it exists on chain.
- Validated
- The protocol has no acceptance, dispute or evaluation step.
Olas Mech
Read from the balance tracker, not the marketplace contract. The marketplace ABI declares a request event, but the deployed contract emitted none we could find over 500,000 Gnosis blocks probed, so the requester side of each task is not in our records.
- Registered · ours
- Mech providers register as Olas services in a registry we do not index. We see a provider when it first delivers, which is later and is a different fact.
- Requested · ours
- The marketplace ABI declares a request event; the deployed contract emitted none we could find over the 500,000 Gnosis blocks probed. The balance tracker we do read carries deliveries and payments, so demand that never resulted in either is invisible to us.
- Funded
- A requester funds a balance rather than an individual task, so no per-task commitment event exists to count.
- Validated
- The marketplace records no acceptance or evaluation of a delivered result.
- Repeated · ours
- The balance tracker names the provider and not the requester, so a recurring pair cannot be assembled from what we hold.
Virtuals ACP
Phase is the latest state a job reached, not a stage it passed through — so the phase distribution answers "where are jobs now", never "how many got this far".
- Registered · ours
- Providers hold identities in the Virtuals registry. We index the jobs, not the registry behind them.
- Funded
- A budget is declared when the job is created, on every job, and is not a commitment. The escrow event is decoded and has never been emitted in the range we cover, so committed value cannot be told apart from advertised value here.
Masumi
One Cardano transaction can carry several application actions. These count escrows, not transactions, and the two are not the same number.
- Requested
- Nothing reaches the chain before the escrow. A buyer and seller agree off-chain and the agreement arrives already funded.
- Delivered
- Delivery happens off-chain and the escrow closing is the only evidence of it.
- Validated
- There is no separate acceptance step; closing the escrow is the whole of it.
Tempo MPP
A channel is a relationship, not a payment. What passes through an open one is settled off-chain between the parties and is not visible here, so a closed channel says value moved without saying how much or how often.
- Registered
- There is no registry. A party appears by opening a channel.
- Requested
- Opening a channel is the first act; nothing precedes it on chain.
- Delivered
- Whatever the channel pays for is exchanged off-chain.
- Validated
- No acceptance or dispute step exists.
ERC-8004 registries
Not a marketplace, and included to show where a registry sits: it reaches the first rung and the sixth-from-last, and never carries a payment. A registration is a claim and belongs at level 0 for exactly that reason.
- Requested
- A registry records who exists. No work is asked for through it.
- Funded
- No value passes through the registry.
- Delivered
- Nothing is produced through the registry.
- Settled
- Nothing settles through the registry.
- Repeated
- Repeat business is not a thing the registry can record. Whether two parties transacted twice is a question for the rails above.
Rungs a rail does emit and we do not read
These are ours, not the protocols’. Everything else missing from the grid above is a stage that rail genuinely does not have, which closes nothing and can never be fixed by working harder. This list can.
- Olas Mech · Registered Mech providers register as Olas services in a registry we do not index. We see a provider when it first delivers, which is later and is a different fact.
- Olas Mech · Requested The marketplace ABI declares a request event; the deployed contract emitted none we could find over the 500,000 Gnosis blocks probed. The balance tracker we do read carries deliveries and payments, so demand that never resulted in either is invisible to us.
- Olas Mech · Repeated The balance tracker names the provider and not the requester, so a recurring pair cannot be assembled from what we hold.
- Virtuals ACP · Registered Providers hold identities in the Virtuals registry. We index the jobs, not the registry behind them.
What each rail is and where it settles: the market. Which markets we read at all: what we cover.