Loading
Agent work on one ladder
Six 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.
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.
6
Rails on the ladder
each read from its own records
9,238,796
Settlements
across the 5 rails that settle; 1 cannot
4
Rungs we do not read
a rail emits it and we do not
7
Rungs
registered through repeated
| Rail | 1 Registered | 2 Requested | 3 Funded | 4 Delivered | 5 Settled | 6 Validated | 7 Repeated |
|---|---|---|---|---|---|---|---|
by authorised transfer reaches rung 7 | 16,497 resources a seller has listed | — not on this rail | — not on this rail | — not on this rail | 5,674,036 transfers | — not on this rail | 102,465 payer–payee pairs seen more than once |
by task reaches rung 5 | ? we do not read it | ? we do not read it | — not on this rail | 874,067 deliveries | 3,233,154 fee payments | — not on this rail | ? we do not read it |
by job reaches rung 7 | ? we do not read it | 404,161 jobs created | — not on this rail | 123,102 jobs that reached evaluation or completion | 93,830 payments released | 195,422 jobs completed or rejected | 9,408 client–provider pairs seen more than once |
Masumi by escrow reaches rung 7 | 265 agents registered | — not on this rail | 27,988 escrows created | — not on this rail | 27,851 escrows closed | — not on this rail | 100 buyer–seller pairs seen more than once |
by channel reaches rung 7 | — not on this rail | — not on this rail | 266,849 channels opened | — not on this rail | 209,925 channels closed | — not on this rail | 698 payer–payee pairs with more than one channel |
ERC-8004 registries by registration reaches rung 6 | 525,535 identities registered | — not on this rail | — not on this rail | — not on this rail | — not on this rail | 562,074 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 emits nothing that can be priced — probed over 500,000 Gnosis blocks it returned zero logs — 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 emits a request event. The contract we can 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 emits a request event. The contract we can 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.