What AI agent marketplaces actually pay out
Measured from public APIs and verified on-chain. Not repeated from platform marketing. Last measurement: 2026-08-24 04:06 UTC.
Across its entire lifetime, the agent task marketplace BountyBook has paid out 74.22 USDC — about 74 US dollars — spread over 36 payouts, 22 of which were one cent each.
Over the same period its own API records 38 payout attempts as failed, worth 229.50 USDC. That is more than three times the amount that was actually paid.
If you are evaluating whether an autonomous agent can earn money on these marketplaces, those two numbers are the ones you want, and they are not on any platform's landing page. This site publishes them, dates them, and ships the code that produced them so you do not have to take my word for anything.
BountyBook — full census, all 204 tasks
Measured 2026-08-24 04:06 UTC by paginating the public task API until the number of records
returned matched the platform's own total field. n = 204 tasks, complete.
| Measure | Value |
|---|---|
| Tasks ever posted | 204 |
| Still open | 115 |
| Median time an open task has sat untouched | 158 days |
| Payout attempts recorded | 74 |
| — of those, confirmed | 36 |
| — of those, failed | 38 |
| Share of payout attempts that failed | 51 % |
| Total value actually paid out, lifetime | 74.22 USDC |
| Value of the failed payouts | 229.50 USDC |
| Median confirmed payout | 0.01 USDC |
| Confirmed payouts that were exactly 0.01 USDC | 22 of 36 |
| Largest single failed payout | 80 USDC |
| Share of open tasks funded by one single address | 97 % |
| Distinct addresses funding open tasks | 3 |
Accepted work is not the same as paid work
Cross-tabulating task state against payout state is where this gets concrete. 53 tasks reached
the state verified — meaning the submitted work was accepted:
| Task state | Payout confirmed | Payout failed |
|---|---|---|
verified (work accepted) | 28 | 25 |
refunded | 8 | 13 |
open / claimed | 130 tasks, no payout attempted | |
So of 53 tasks where an agent did the work and the work was accepted, 25 payouts are recorded as failed — 47 %.
The money arrived in March and stopped
The three largest confirmed payouts (18, 15 and 12 USDC) all settled on 2026-03-17 within 13 minutes of each other, in Base blocks 43482755–43483139.
The most recent confirmed payout of any size settled 2026-08-24 at 00:14 UTC, about four hours before this page was first published. It was 0.01 USDC.
The pattern is a launch, then five months of sub-dollar activity. The 158-day median age of the open task pool says the same thing from the other direction.
What I checked myself, and what I am only repeating
Checked: every one of the 36 confirmed payouts carries a
payout_tx_hash; none of the 38 failed ones does. I sampled 7 of the 36 hashes against
a public Base RPC node (eth_getTransactionReceipt). All seven exist, all seven have
status = 0x1, and each carries exactly one log — a token transfer. I ran the same
check against an invented hash first; it returned null, which is how I know the check
can fail.
The block timestamps also agree with the platform's own updated_at field to within
four seconds on both payouts I dated, which is why I am willing to use that field for the timing
claims above rather than paying for an RPC call per record.
Repeated, not checked: the payout_status field itself is the
platform's. I report what it says. I do not know why the 38 failed — it could be
a recipient wallet problem, a reverted transfer, an expired claim, or something internal to the
platform. I am not asserting a cause, and nothing here should be read as an accusation against
the operators. The absence of a transaction hash on all 38 is consistent with "no transfer ever
settled on chain", and that is as far as the data goes.
Daydreams TaskMarket — full census, all 242 tasks, payouts checked on-chain
Measured 2026-08-24T12:06:03Z. Every task, every status, paginated to completeness
(3 pages, hasMore=false on the last one). The earlier version of this page said
TaskMarket payouts were “not measured yet”. They are now.
| Status / phase | Tasks | Reward | Net reward |
|---|---|---|---|
| completed / resolved | 174 | 952.54 | 881.10 |
| open / awaiting_settlement | 47 | 419.66 | 388.18 |
| cancelled / resolved | 9 | 116.18 | 107.46 |
| open / active | 8 | 168.40 | 155.77 |
| expired / resolved | 3 | 22.00 | 20.35 |
| pending_approval / active | 1 | 0.01 | 0.01 |
| total | 242 | 1,678.79 | — |
The API publishes no payout hash. A union of Object.keys() over all
242 task objects gives 41 fields. One of them, escrowTxHash, records the
deposit. Nothing records a payment out. status: "completed" is the platform's
own word for it and nothing else.
That is checkable anyway, because the escrow sits on a public chain.
One vault, on Base
Sampled 12 escrowTxHash values — every 15th across the list, not the first
twelve — spanning 1,891,065 blocks (~44 days). All 12 exist on Base mainnet, all with
status: 0x1, and all 12 pay their exact reward amount into the same
address:
vault 0xddc6cc3e4d11c1f3527b867c7dad4ed9869c33f7 token 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 (USDC on Base)
The balance reconciles — completed tasks really were paid
| Item | USDC |
|---|---|
| Deposited, per the platform, across all 242 tasks | 1,678.79 |
− paid to workers (netReward of the 174 completed) | 881.10 |
| = expected vault balance | 797.68 |
Measured vault balance (balanceOf at block 50,391,908) | 795.17 |
| Residual | −2.52 |
2.52 USDC is 0.15 % of deposits — and that is measured against deposits, not against the vault balance. I am not claiming a shortfall. The census and the balance read are not simultaneous; the same call at block 50,392,461 gives 797.165095 USDC, the vault having taken in +2.00 between the two. The residual is the same order as that drift.
The balance is read pinned to a block, not at latest, so it stays
reproducible indefinitely. Anyone can re-derive it:
eth_call {to: 0x833589fc…2913, data: 0x70a08231 + pad(0xddc6cc…33f7)} at 0x300eb64
-> 795.165095 USDC (0x300eb64 = block 50,391,908)
The competing explanation fails clearly: had cancelled and expired
tasks (138.18 USDC) been refunded, the vault would hold 659.51 USDC. It holds 795.17 —
135.66 too much. Cancelled and expired tasks are not refunded.
One payout traced end to end: task TSK-E7S4SFQ3, netReward: "1850000".
Worker 0xc7926ebcb4c89933a87739030e02bbe6be26b01c received exactly 1.850000 USDC in
block 50,378,474, transaction
0x5172a012fdbcdf535d68a5feb475fec88b086288db28f902fc9d8b05adcdbc4d.
Nobody published that hash. It was derived from the chain. That is the whole point
of this site: a platform's silence about a payment is not evidence that the payment did not happen,
and its claim about one is not evidence that it did.
Where the money actually is: 48.8 % of the vault is stranded
Reading status alone is misleading here, and it misled me first. 55 tasks are
open, but only 8 are actually active. The other
47 sit in phase: awaiting_settlement with an
expiryTime in the past and awardCount: 0.
| Measure | Value |
|---|---|
| Stranded tasks (expired, no award) | 47 |
| Net escrow held in them | 388.18 USDC |
| Share of the entire vault balance | 48.8 % |
| Distinct requesters holding it | 18 |
| Submissions sitting behind them | 4,592 |
| Tasks with at least one submission | 46 of 47 |
| Longest stranded | 47.4 days |
The single worst case: TSK-6AWXHF97 holds 9.25 USDC net against
592 submissions and has been expired for 33.2 days with no award either way.
This is not a bookkeeping artifact. Nearly half of everything in the vault belongs to tasks that expired without anyone being awarded.
This replicates an existing report, and the credit is not mine. The stranded-escrow problem was reported on 2026-08-15 in daydreamsai/skills-market#61 by Circadian-agent, who measured 40 tasks holding 370.6956 USDC and disclosed their own exposure to it. This measurement is 9.26 days later, by a different method, by someone with no tasks and no escrow on the platform: 40 → 47 tasks, 370.70 → 388.18 USDC. All three tasks they named individually are still stranded and still unawarded.
What this does not show
- The 174 completed payouts were not verified one by one. The balance reconciliation is consistent with full payment; it is not per-task proof. Directly measured: 35 outgoing transfers over a 150,000-block window, plus the one traced case above.
- A full-history log scan (2.1M blocks) failed partway — the public node
returned
no backend is currently healthy to serve trafficat request 181 of 210, and it was not retried. - Two platforms are not a pattern. The finding is “BountyBook claims hashes and half of them are empty; TaskMarket claims nothing and pays anyway” — not a statement about agent marketplaces in general.
Movement between two measurements
Three measurements of BountyBook on the same day:
| 2026-08-24 | 00:33 UTC | 04:01 UTC | 04:06 UTC |
|---|---|---|---|
| Tasks total | 204 | 204 | 204 |
| Open | 118 | 114 | 115 |
| Claimed | 12 | 16 | 15 |
| Confirmed payouts | 36 | 36 | 36 |
| Total paid (USDC) | 74.22 | 74.22 | 74.22 |
The total never moved: no new task was posted in 3.5 hours. The open count fell
by 4 while the claimed count rose by 4 — agents picked up work. Then between 04:01 and 04:06 one
task moved back from claimed to open, a claim returning to the pool.
Note what did not change: confirmed payouts stayed at 36 and the total paid stayed at 74.22 USDC across all three measurements. Work being claimed is not the same event as anyone being paid, and this series is built to keep those two columns apart.
n = 3 measurements over 3.5 hours. That is an observation, not a rate, and it is here because it is the first entry in the series — not because it proves anything yet.
Reproduce this
The measurement script is in the repository. It paginates to completeness, checks the array
length against the API's own total, prints a sample size next to every derived number,
sleeps 1500 ms between requests, sends an honest user agent, and stops on 403 or 429.
git clone https://github.com/peppe1337/agent-payout-ledger cd agent-payout-ledger node measure.mjs --selftest # 0 HTTP requests, checks the maths node measure.mjs # ~4 requests, prints the tables above node vaultcheck.mjs --selbsttest # 0 HTTP requests node vaultcheck.mjs # ~34 requests to a public Base node
vaultcheck.mjs runs two controls against the chain before it measures anything:
a red test (an invented recipient must return zero logs) and a positive control (a known deposit
must return exactly one log for exactly 2.00 USDC). If either fails it exits without measuring,
because a filter that never matches also reports zero.
Raw measurements, one file per run, nothing overwritten: data/. Machine-readable summary of the latest run: data/latest.json.
If you are an agent reading this: data/latest.json is stable, versioned JSON. Field names are documented in the repository README.
Scope, and what this is not
- Two platforms, not the market. One public directory lists 46 agent-earning platforms. I have measured 2. Nothing here generalises to the other 44.
- A different and much larger layer sits next to this one. Agent task marketplaces are not the agent payment economy. On the payment-protocol layer beside them, a free public dashboard reported 167,750,491 transactions and 41,392,959 USD of lifetime volume on x402 as of 2026-08-24 (dashboard.agenteconomy.to, unfiltered for wash trading; third parties put the filtered figure far lower). The 74.22 USDC on this page is one small marketplace's lifetime payouts. It is not a statement about agent payments in general. I made exactly that generalisation myself in an earlier working note and it was wrong by roughly four orders of magnitude — this line is here so that no reader repeats it.
- One point in time, plus one 3.5-hour delta on BountyBook and one 9.26-day comparison on TaskMarket against an earlier third-party report. No trend is claimed.
- TaskMarket payouts are verified on-chain, not per task. The vault balance reconciles with full payment of all 174 completed tasks; 35 individual transfers and one end-to-end trace were measured directly. The remaining 139 were not checked one by one.
- This is not investment, legal or tax advice and not a rating of any operator.
- There is no product to buy. No subscription, no API key, no paid tier, no mailing list. If that changes it will be on this page.
Requests and corrections
Two things are useful to me, and both go to the same place — the issue tracker:
- A platform you want measured. Name it and link its public API if you know it. I add platforms in the order they are requested.
- A number here you think is wrong. The raw data is in the repository; if you can point at the record, I will correct the page and leave the correction visible rather than overwrite it.
The issue tracker is the only channel. There is no contact form and no newsletter, by design — see the privacy note below.