0.56days of PURR volume to unwind the crowd99%of the XMR book on one side, across 27 vaults$1.43Bunder one key with no guardian, 55 of the 433 vaults whose control we have read$359.0Mwhose control we have never read, across 3,338 vaults$1.91Bsitting in vaults and not lent out$11.35Bunder 3,771 vaults we read$4.62Bin 328 vaults where we saw automated execution, nothing declared2,178vaults declared or on a venue built to run software, holding $1.04M330software-run vaults scored, 13% of them453operators identified behind them26networks where we read capital, from Ethereum to Cardano31,750,734deposits and withdrawals read from chain237changes recorded in the last day665,378ERC-8004 agent registrations read−0.05 down, ERC-8004 agent registrations read/ 30 days429,666distinct owners behind those registrations202,388registrations carrying a readable card, 30%3,369,653paid requests on the Olas rail (deliveries are counted apart)−0.59 down, paid requests on the Olas rail (deliveries are counted apart)/ 30 days88suppliers delivering that work412,095agent-to-agent jobs read on Base+0.22 up, agent-to-agent jobs read on Base/ 30 days$1.0Msettled between agents, all time1,176suppliers listed on the ACP rail189agents live on Cardano76Cardano agents deregistered, 29% of all ever minted29,409escrows between Cardano agents since Jun 2025, 156 still open78%of every agent payment we read comes from 2,878 addresses that never stop336,847addresses paid once and never came back, of 567,288 that ever paid1,069of those payers are an agent we can name, 0.188% of them674agent hosts answered when we asked, of 2,571 probed17,117agents sit behind a host that answers nothing at all407msmedian answer from the 674 hosts that answer44%of all agent ratings were written by ten addresses, of 698,452 ratings read40,407rated agents have exactly one rater, of 58,352 rated at all108,597service endpoints declared across 46,139 agent cards we read0.56days of PURR volume to unwind the crowd99%of the XMR book on one side, across 27 vaults$1.43Bunder one key with no guardian, 55 of the 433 vaults whose control we have read$359.0Mwhose control we have never read, across 3,338 vaults$1.91Bsitting in vaults and not lent out$11.35Bunder 3,771 vaults we read$4.62Bin 328 vaults where we saw automated execution, nothing declared2,178vaults declared or on a venue built to run software, holding $1.04M330software-run vaults scored, 13% of them453operators identified behind them26networks where we read capital, from Ethereum to Cardano31,750,734deposits and withdrawals read from chain237changes recorded in the last day665,378ERC-8004 agent registrations read−0.05 down, ERC-8004 agent registrations read/ 30 days429,666distinct owners behind those registrations202,388registrations carrying a readable card, 30%3,369,653paid requests on the Olas rail (deliveries are counted apart)−0.59 down, paid requests on the Olas rail (deliveries are counted apart)/ 30 days88suppliers delivering that work412,095agent-to-agent jobs read on Base+0.22 up, agent-to-agent jobs read on Base/ 30 days$1.0Msettled between agents, all time1,176suppliers listed on the ACP rail189agents live on Cardano76Cardano agents deregistered, 29% of all ever minted29,409escrows between Cardano agents since Jun 2025, 156 still open78%of every agent payment we read comes from 2,878 addresses that never stop336,847addresses paid once and never came back, of 567,288 that ever paid1,069of those payers are an agent we can name, 0.188% of them674agent hosts answered when we asked, of 2,571 probed17,117agents sit behind a host that answers nothing at all407msmedian answer from the 674 hosts that answer44%of all agent ratings were written by ten addresses, of 698,452 ratings read40,407rated agents have exactly one rater, of 58,352 rated at all108,597service endpoints declared across 46,139 agent cards we read
This site publishes several counts of what looks like the same thing. Each is correct and each answers a different question, and a reader comparing two pages cannot tell a legitimate narrowing from a disagreement. So the narrowing is published: what was discovered, what survives each stage, and what drops out at every one.
The stage keys are the population names. Every figure on this site carries an evidence block naming the population it was computed over, and that name is a key below. A total and the population it is a total of can be joined without asking us.
Vaults
Which vaults is a capital figure a total of?
Discovered3,978
Open3,771−207
dropped here: recorded as shut, and kept rather than deleted
Valued2,627−1,144
dropped here: no price we trust for the underlying, or a venue that publishes what was put in rather than what is held now - the size is refused rather than guessed
Software-managed2,506−121
dropped here: no evidence that software decides, which is not the same as evidence that a person does
2,506 of 3,978 vaults (63.0%) reach software-managed. The other 1,472 drop out at a named stage above, never silently.
Of the 1,144 open vaults with no capital figure, 349 do carry one we measured: $45.92M of net deposits, read from the vault accounts themselves. That is what depositors put in, not what is held now, and no total on this site adds the two together - so every capital figure here excludes it. It is on each vault's own page.
Exit capacity
Which vaults does the withdrawable figure cover?
Open lending vaults633
Supply and borrow both read633
dropped here: one side of the register could not be read, so the vault sits in none of the three exit states
Every one of the 633 lending vaults discovered survives to supply and borrow both read.
Real-world exposure
Which vaults is the real-world figure a total of?
Open vaults3,759
Told us what they hold1,155−2,604
dropped here: the vault names no underlying asset, so there is nothing to classify
Underlying classified966−189
dropped here: we hold the symbol and could not place it in any class, which is ours rather than theirs
In a real-world class765−201
dropped here: the underlying is ether, bitcoin, a chain token or a staking receipt, all crypto, and nobody is uncertain about that
765 of 3,759 vaults (20.4%) reach in a real-world class. The other 2,994 drop out at a named stage above, never silently.
Agent earnings
How much of what agents earn can we follow?
Paid on a rail233,202
Earnings we could price233,114−88
dropped here: paid in something we hold no price for at that moment
Money we can follow67,152−165,962
dropped here: it moved somewhere we do not read, such as an exchange, an unlinked treasury or a chain outside our perimeter. Ours, not theirs.
67,152 of 233,202 earners (28.8%) reach money we can follow. The other 166,050 drop out at a named stage above, never silently.
Agent work
What is a completion rate on the job book a rate of?
Jobs read412,095
Phase observed258,330−153,765
dropped here: we never saw a phase for it, which is a hole in our reading of the book rather than a job that did nothing
A recorded outcome204,628−53,702
dropped here: still in request, negotiation or evaluation, which is not yet a result and is never counted as a failure
204,628 of 412,095 jobs (49.7%) reach a recorded outcome. The other 207,467 drop out at a named stage above, never silently.
x402 settlements
Why does the same rail carry four different totals?
Settlements held16,611,430
Not quarantined16,610,527−903
dropped here: the pairing of an authorisation to a transfer is one we no longer trust, so the row is kept for re-reading and never published in a total
Carries a timestamp16,610,527
dropped here: no block timestamp, so it could not be placed in a window. Today that is none of them
Recipient and amount recovered16,603,104−7,423
dropped here: neither is in the authorisation event and the paired Transfer could not be found, so both are null rather than guessed at
Checkable against a price16,603,102−2
dropped here: no amount could be resolved, so there is nothing to compare with the seller’s own listing
Who can move the money
Which vaults does a control finding cover?
Open vaults3,771
Control we could read433−3,338
dropped here: the venue publishes no access control, so there are no roles to read, which is most venues, and is our limit rather than a finding about the vault
433 of 3,771 vaults (11.5%) reach control we could read. The other 3,338 drop out at a named stage above, never silently.
A small share by count and 97% by capital. The venues that publish access control are the large ones, so the count understates the reach and the capital overstates it. Neither figure alone is the answer.
Depositor returns
Whose return is the up-or-down split a split of?
Positions read8,395
Return reconstructable3,832−4,563
dropped here: we hold no value on both sides of their entry, so there is nothing to measure a return from
3,832 of 8,395 positions (45.6%) reach return reconstructable. The other 4,563 drop out at a named stage above, never silently.
Who runs it, asked of the firm
How many vaults does a firm we infer to be automated run?
Open vaults3,771
Linked to an operator1,444−2,327
dropped here: nobody has merged them to a firm or a leader, which is a limit of our linking rather than a vault that runs itself
That operator runs without a human per decision448−996
dropped here: the firm is inferred to have a person deciding case by case, or no mode could be inferred at all
448 of 3,771 vaults (11.9%) reach that operator runs without a human per decision. The other 3,323 drop out at a named stage above, never silently.
174 of those, holding $1.42B, carry no evidence of their own and are therefore NOT in this site's software-managed count. Two readings on two bases: that one is about the vault, this one is about the firm. They are never added, and neither overrules the other. A vault promoted on its operator's evidence would be the mistake the classifier refuses in the other direction.
Who runs it
Which operators is a firm figure a total of?
Operators we hold527
Running an open vault453−74
dropped here: every vault we linked them to is shut, or none was ever linked
453 of 527 operators (86.0%) reach running an open vault. The other 74 drop out at a named stage above, never silently.
Agent identities
How many registrations are economically usable?
Registered665,378
Card read and parsed202,388−462,990
dropped here: the card is a pointer we have not fetched, or it could not be read at all
Declares a service endpoint13,364−189,024
dropped here: the card names no endpoint, so there is nothing to ask
That endpoint answers12,446−918
dropped here: the host refuses, has gone, or would not answer in time
12,446 of 665,378 registrations (1.9%) reach that endpoint answers. The other 652,932 drop out at a named stage above, never silently.
Every population name in use
A figure’s evidence block names one of these. The ones marked as decomposed narrow above; the rest are named and measured but not yet broken into stages, which is a smaller claim rather than a missing one.
vaults_discovered
Every vault this platform has ever found, open or shut. The widest count there is.
vaults_open
Discovered vaults not recorded as shut. Closed ones are kept rather than deleted, which is what makes survivorship measurable.
vaults_closednamed only
Discovered vaults recorded as shut. The complement of vaults_open, and the half a survivor list leaves out: count(vaults_open) + count(vaults_closed) = count(vaults_discovered) over one snapshot.
vaults_valued
Open vaults we can put a size on, which is the denominator behind every capital total here. A vault whose underlying we cannot price is published unvalued rather than estimated; one we read as holding nothing is valued at zero, which is a reading rather than a gap.
vaults_agent_managed
Open vaults with evidence that software decides. Absence of evidence is not evidence that a person decides.
lending_open
Open vaults on a lending venue, whether or not their register could be read.
open_lending_vaults_with_supply_and_borrow_read
Lending vaults where both sides of the register were read, so the vault can be placed in exactly one exit state.
What a narrowing is not
A stage that loses rows is not a stage that failed. Refusing to value a vault whose underlying we cannot price is the behaviour this platform is built around, and the count of refusals is a measure of honesty rather than of coverage. What would be a failure is a figure published without saying which stage it was computed at, which is the thing these chains exist to make impossible.
How each figure resolves to the read behind it: evidence. Where our figures disagree with somebody else’s: what others report. What we read at all: the perimeter.
16,603,102 of 16,611,430 settlements (99.9%) reach checkable against a price. The other 8,328 drop out at a named stage above, never silently.
Mostly because of WHEN, not what. Every rung here was counted in one pass at 16 October 2026, and the two narrowings below the top are both small. The rail takes on more than ten thousand settlements a day, so two pages reading it hours apart differ by more than any predicate on this chain does. That is what an outside audit found on 25 September, reading four totals off four pages and unable to tell a narrowing from a disagreement. The figure beside each of those pages carries its own snapshot, and this chain is what they are snapshots OF.
open_vaults_with_a_classified_underlying
Open vaults whose underlying we could place in a class at all. A symbol we hold and cannot classify is our gap rather than theirs.
registrations
Every ERC-8004 identity registration read from a chain, whatever it points at.
registrations_named
Registrations whose card we fetched and parsed. A card that is only a pointer we have not followed is a gap in our reading rather than a defect in the registration.
registrations_with_endpoint
Registrations whose card names a service endpoint, so there is something to ask.
registrations_endpoint_answering
Registrations whose declared endpoint answered the last time it was asked.
rail_earners
Addresses paid on an agent-commerce rail, which is the population every revenue figure is a total of.
counterparty_earnersnamed only
Addresses paid on x402 as a seller that lists a paid resource, on ACP as a provider, or on the mech marketplace: the population the counterparty check reads. Narrower than rail_earners on x402, where a transfer to a recipient that lists nothing is not counted as a sale. Not drawn as a chain beneath rail_earners, although it is one, because the two counts come off different nightly jobs and a chain whose stages are read at two moments cannot be checked at all.
rail_earners_priced
Earners whose payment we could put a dollar figure on at the moment it was made. One paid in an asset we hold no price for is counted and not valued.
rail_earners_followed
Earners whose money we can follow to any outcome at all. The rest is a statement about our linkage rather than about the agents: revenue moved to an exchange, to an unlinked treasury, or onto a chain we do not read looks identical from here to revenue that never moved.
agent_work_eventsnamed only
Events on a rail where an agent did something for somebody: jobs, tasks, payments, channels and escrows. The nouns differ per rail and are added under one heading rather than treated as interchangeable. A registration is NOT in here, because declaring that an agent exists is not work.
agent_identity_eventsnamed only
Registrations and ratings: somebody declaring that an agent exists, or rating one that does. Counted apart from work because a registry spike reads as an agent boom only when the two are added together.
x402_priced_resourcesnamed only
Services listed in the x402 catalogue that publish a price.
depositor_positions_read
Depositor positions read from the venues, one row per address per vault, latest reading only. The widest depositor count there is.
reconstructable_depositor_positions
Depositor positions whose entry and value history we hold on both sides of the entry, so a return means something. A position we can see but cannot date is counted and not measured: any return for it would be a guess about when the money arrived.
vaults_with_flow_historynamed only
Vaults whose deposits and withdrawals we hold over the window, so growth can be split from performance.
gmx_open_positionsnamed only
Every open position on GMX across both chains, counted rather than sampled.
ostium_open_positionsnamed only
Open positions on Ostium in a page the venue serves, which is a floor rather than a total.
avantis_listed_pairsnamed only
Pairs Avantis lists, with the venue’s own open interest against each.
vaults_with_a_linked_operator
Open vaults we have linked to a firm or leader. A vault with no operator here is one nobody has merged to a name, which is a limit of our linking rather than a vault that runs itself.
vaults_whose_operator_is_automated
Open vaults whose OPERATOR we have inferred runs without a human deciding each case. A second reading of who runs a vault, on a different basis from the vault’s own evidence: this one is about the firm, that one is about the vault. They are never added together and neither overrules the other.
operators_with_a_vault
Firms and leaders running at least one open vault we read. An operator nobody has linked to a vault is not here, which is a limit of our merging rather than a fact about the market.
positions_read_on_perp_venuesnamed only
Open positions we read from the perpetual venues themselves, per vault and per instrument. A venue we do not read carries positions that are absent here rather than zero.
instruments_snapshottednamed only
Instruments whose mark, mid and impact prices we record on a schedule. An instrument nobody in our cohort holds is not snapshotted, so its absence says nothing about the market.
open_vaults_with_underlying_read
Open vaults whose own contract told us what they are denominated in. A vault that does not answer is unread rather than unbacked.
open_vaults_with_access_control_read
Open vaults whose venue publishes access control and whose roles we could read. Most venues publish none, so this is a small share by count and a large one by capital: the venues that publish it are the large ones, and neither figure alone is the answer.
operators_all
Every operator record we hold, including those whose vaults have all closed. Kept rather than deleted, which is what makes a firm’s whole book readable.
open_vaults_in_a_real_world_class
Open vaults whose underlying is a named real-world instrument or a stablecoin whose issuer invests reserves. Crypto is classified and deliberately outside this: nobody is uncertain whether ether is a Treasury bill.
vaults_askable_on_chainnamed only
Open vaults holding a contract we can ask directly how much it holds, so the size is read from the chain rather than taken from a venue. A vault on an order book has no such contract and is absent here rather than unproven; the confirmed share is published against the askable ones, never against every vault.
index_universenamed only
Vaults eligible to be index constituents at a rebalance: measurable in that period and above the size floor. Chosen using only what was known at the time, so a vault that later died keeps its loss and one that later grew does not appear early.
preregistered_declarationsnamed only
Strategies declared to us before the result was known, including the ones that went on to fail. Small and deliberately self-selected — the value of pre-registration is that it cannot be chosen after the fact, not that it is representative of anything.
acp_jobs_read
Jobs on the Virtuals ACP v2 contract we read end to end. A job still in negotiation has not failed and one whose phase we never saw is our gap rather than an outcome, so neither is counted against a completion rate.
acp_jobs_with_a_phase
ACP jobs we saw a phase for. A job read from the contract whose phase we never observed is a hole in our reading of the book, not a job that did nothing.
acp_jobs_that_ended
ACP jobs that reached an outcome — delivered, refused or expired. This, and not the whole book, is the denominator under every completion rate we publish: a job still in request, negotiation or evaluation has not failed and counting it as a failure would defame the provider.
x402_authorised_transfers_read
Authorised EIP-3009 transfers of USDC we read on five chains, whether or not they were x402 payments. The primitive predates x402 and serves other things, so this population is the widest possible reading of the rail and each member carries the strongest tier that can be shown for it. Every settlement row we hold, quarantine included: the top of the x402 chain on /reconciliation.
x402_settlements_published
Authorised transfers not held in quarantine. A quarantined row is one whose pairing of an authorisation to a transfer we no longer trust — it is kept so the reading can be re-done, and is never published in a total.
x402_settlements_dated
Published settlements carrying a block timestamp, which is what places one in any window or hour-of-day. Loses nothing today: every row we hold is dated, so any figure filtering on it is the same population under a longer predicate.
x402_payments_against_a_listed_price
Settlements with a recipient and an amount, which is what the pre-flight price check compares against the seller’s own dearest listing. Equal to the population above since the amount backfill finished, and kept as its own key because the two answer different questions and will part again the moment a transfer cannot be paired.
x402_settlements_with_a_recipient
Dated settlements whose recipient and amount were both recovered from the paired Transfer. Neither is in the authorisation event, so a transfer that could not be found leaves both null — and this is the population every figure about a seller, a price or a dollar total is over.
x402_payersnamed only
Addresses that paid on x402 over the blocks we hold, separated by observable behaviour rather than by any label they carry. No class claims agency: paying every hour of the day is a fact about a schedule, not about who wrote it.
open_vaults_with_a_risk_scorenamed only
Open vaults carrying a published risk score, which is what the six dimensions are read from. A score needs history and a readable underlying, so a vault missing here is one we could not measure rather than one that scored badly, and the dimensions table is silent about it rather than drawing it as safe.
agent_vaults_with_a_scorenamed only
Vaults read as software-run that also carry a risk score. A score needs history and a readable underlying, so the shortfall against vaults_agent_managed is our reading rather than a judgement about the vault.
chains_carrying_a_vault_we_readnamed only
Chains where at least one open vault is read. NOT the count of chains this platform touches, which is larger and includes chains carrying only a registry, a payment rail or a service catalogue. The two differ by eleven and an audit once read them as a contradiction.
flow_events_readnamed only
Deposit and withdrawal EVENTS read from chain, one row each. A count of movements and not of vaults or of depositors: a single depositor entering and leaving is two.
vaults_with_comparable_realised_and_advertisednamed only
Open vaults where a realised return can be set against an advertised one: both readings exist and the realised window is long and dense enough to compare. A SMALL MINORITY of open vaults, because a venue that quotes nothing, or a share price that never moves, is excluded rather than counted as in line. A short list here therefore means few comparable and never few that performed.
vaults_where_depositor_returns_are_measurablenamed only
Open vaults where we can measure what DEPOSITORS kept, rather than what a unit held throughout would have earned. It needs per-depositor equity over time, which only some venues publish, so this is a narrow set and its narrowness is about those venues and not about the vaults. A count here is NOT comparable with a count of vaults whose share-price return can be set against an advertised rate: different question, different evidence, and dividing one into the other means nothing.
changes_recorded_in_a_daynamed only
Recorded changes to anything this platform tracks over the last twenty-four hours. An event count over a rolling window, so it is never comparable with an all-time total on the same strip.
registration_ownersnamed only
Distinct addresses holding at least one ERC-8004 registration. Fewer than the registrations, because one owner can register many agents, and an owner is not an operator: nothing here says a person or a firm is behind it.
registrations_with_a_readable_cardnamed only
Registrations whose agent card was held inline on chain and could be read. A registration pointing at a card we could not fetch is counted as a registration and not as a card, so this is a floor on what is declared.
mech_paid_requestsnamed only
Requests on the Olas mech marketplace that were PAID, one row each: the settled rung. Deliveries are a separate population and the two are never added, because one task produces up to both. Narrower than agent_work_events, which sums every rail under one heading.
mech_providers_deliveringnamed only
Distinct addresses that delivered at least one mech request. Counted from delivery rows, so a supplier paid but never seen delivering is absent.
acp_providers_listednamed only
Distinct providers named on the ACP job book. Listed rather than active: a provider with one expired job from last year is in this count.
masumi_agents_livenamed only
Cardano agents whose Masumi registration token has not been burned. Live means the token exists, which is a claim about registration and not about whether the agent answers.
masumi_agents_mintednamed only
Every Cardano agent ever registered on Masumi, live or deregistered. The denominator behind any share of them, kept because a deregistration rate needs one.
masumi_escrows_openednamed only
Masumi escrows ever opened between Cardano agents, one row each. An all-time event count, and not the number currently open, which is smaller by three orders of magnitude and was published as "open" for a time.
scheduled_readersnamed only
The readers this platform runs on a schedule, which is the population behind every freshness claim here. It measures OUR jobs and not the sources they read: a reader that ran ten minutes ago may still have been served stale data by a venue.
commerce_rails_readnamed only
Agent-commerce rails we read end to end. A rail absent here is one we do not read, which is different from a rail with no activity.
x402_payments_readnamed only
Every x402 payment this platform has read off a chain, all time. An EVENT count: one address produces many, so it is never added to a count of addresses and never compared with a count of agents.
agent_hosts_probednamed only
Distinct hosts named by an agent card that we asked for an answer. Hosts, not agents: thousands of agents can name one host, which is why the agent count behind an outcome is a separate population.
agents_behind_a_probed_hostnamed only
Agents whose declared service lives on a host we probed, counted per agent rather than per host. The two differ by an order of magnitude and reporting one as the other overstates how much of the market a single dead host takes down - or understates it.
erc8004_ratings_readnamed only
Ratings written into an ERC-8004 reputation registry that we have read. An EVENT count. A rater can write many, which is the finding rather than a caveat.
erc8004_rated_agentsnamed only
Agents carrying at least one rating. A THING count, and deliberately not the number of ratings: most of these carry exactly one, from one rater.
agent_service_endpoints_declarednamed only
Service endpoints an agent card declares, counted per endpoint. What an agent SAYS it can do, never evidence that any of it answers - that is agent_hosts_probed.