0.57days of PURR volume to unwind the crowd99%of the XMR book on one side, across 28 vaults$1.58Bunder one key with no guardian, 100 of the 479 vaults whose control we have read$289.7Mwhose control we have never read, across 3,318 vaults$1.94Bsitting in vaults and not lent out$11.44Bunder 3,797 vaults we read$4.67Bin 333 vaults where we saw automated execution, nothing declared2,196vaults declared or on a venue built to run software, holding $1.09M335software-run vaults scored, 13% of them456operators identified behind them26networks where we read capital, from Ethereum to Cardano31,945,307deposits and withdrawals read from chain134changes recorded in the last day790,257ERC-8004 agent registrations read+1.13 up, ERC-8004 agent registrations read/ 30 days553,078distinct owners behind those registrations203,129registrations carrying a readable card, 26%3,385,807paid requests on the Olas rail (deliveries are counted apart)−0.53 down, paid requests on the Olas rail (deliveries are counted apart)/ 30 days88suppliers delivering that work412,597agent-to-agent jobs read on Base+0.53 up, agent-to-agent jobs read on Base/ 30 days$1.0Msettled between agents, all time1,176suppliers listed on the ACP rail187agents live on Cardano78Cardano agents deregistered, 29% of all ever minted29,635escrows between Cardano agents since Jun 2025, 286 still open78%of every agent payment we read comes from 2,927 addresses that never stop339,663addresses paid once and never came back, of 572,437 that ever paid1,080of those payers are an agent we can name, 0.189% of them681agent hosts answered when we asked, of 2,578 probed17,114agents sit behind a host that answers nothing at all440msmedian answer from the 681 hosts that answer42%of all agent ratings were written by ten addresses, of 727,173 ratings read66,949rated agents have exactly one rater, of 84,905 rated at all114,396service endpoints declared across 49,060 agent cards we read0.57days of PURR volume to unwind the crowd99%of the XMR book on one side, across 28 vaults$1.58Bunder one key with no guardian, 100 of the 479 vaults whose control we have read$289.7Mwhose control we have never read, across 3,318 vaults$1.94Bsitting in vaults and not lent out$11.44Bunder 3,797 vaults we read$4.67Bin 333 vaults where we saw automated execution, nothing declared2,196vaults declared or on a venue built to run software, holding $1.09M335software-run vaults scored, 13% of them456operators identified behind them26networks where we read capital, from Ethereum to Cardano31,945,307deposits and withdrawals read from chain134changes recorded in the last day790,257ERC-8004 agent registrations read+1.13 up, ERC-8004 agent registrations read/ 30 days553,078distinct owners behind those registrations203,129registrations carrying a readable card, 26%3,385,807paid requests on the Olas rail (deliveries are counted apart)−0.53 down, paid requests on the Olas rail (deliveries are counted apart)/ 30 days88suppliers delivering that work412,597agent-to-agent jobs read on Base+0.53 up, agent-to-agent jobs read on Base/ 30 days$1.0Msettled between agents, all time1,176suppliers listed on the ACP rail187agents live on Cardano78Cardano agents deregistered, 29% of all ever minted29,635escrows between Cardano agents since Jun 2025, 286 still open78%of every agent payment we read comes from 2,927 addresses that never stop339,663addresses paid once and never came back, of 572,437 that ever paid1,080of those payers are an agent we can name, 0.189% of them681agent hosts answered when we asked, of 2,578 probed17,114agents sit behind a host that answers nothing at all440msmedian answer from the 681 hosts that answer42%of all agent ratings were written by ten addresses, of 727,173 ratings read66,949rated agents have exactly one rater, of 84,905 rated at all114,396service endpoints declared across 49,060 agent cards we read
The rating is free and always will be. Credibility is the asset, and a rating nobody can read is worth nothing. What is priced is the layer underneath it: who else is in the trade, how a strategy is actually being run, and what it can absorb before its own edge is gone.
How long each series has been running
Said here rather than discovered later. These are recordings, not reconstructions: they exist for as long as somebody has been writing them down, and no amount of reading a network recovers the part before that.
63 daysof the exit register, recorded dailystill short
68 daysof the survivorship censusstill short
62 daysof the change feedstill short
The API
Endpoints above your tier return 402 Payment Required naming the capability you need. A spent monthly allowance returns 429 for the paid surface and leaves /v1/plans, /v1/meta, /v1/account and the OpenAPI document reachable, a key that has run out has to be able to read what it would cost to carry on.
The API and the web interface keep separate entitlement tables. They agree on nearly everything and are allowed to differ where the surfaces genuinely differ, crowding summaries are free over the API and part of a plan on the site, because a chart and a feed are not the same product. Where you care which you are buying, the API's table is the one this page describes.
The most-used endpoints are below. The full reference covers all of them, every parameter, error and webhook, and is generated from the specification the API serves, so it cannot describe a version that no longer exists.
GET /api/v1/plans prices and quotas, no key needed
GET /api/v1/account your balance, quota and deposit address
GET /api/v1/meta counts, capabilities, known limitations
GET /api/v1/vaults?agentManaged=true filter by chain, platform, agent-managed
GET /api/v1/vaults/{slug} metrics, NAV series, positions
GET /api/v1/vaults/{slug}/waterfall gross to net
GET /api/v1/vaults/{slug}/execution fills, taker share, fee rate
GET /api/v1/operators cohort summaries, survivors and failures
GET /api/v1/crowding clusters, coverage; members need a plan
GET /api/v1/crowding?asOf=2026-08-14 the book as it stood, not as it is
GET /api/v1/history/capital daily measured capital, by who decides
GET /api/v1/assets instruments and who holds them
POST /api/v1/risk your book: look-through exposure, what a shock costs you
GET /api/v1/correlation are these vaults the same trade, after the market
GET /api/v1/stress who is liquidated at what price; ?scale=sigma for distance
GET /api/v1/cascade the forced selling that follows, and where it lands
GET /api/v1/vaults/{slug}/redemption what a withdrawal does to the strategy behind it
GET /api/v1/exposure/netting where longs and shorts cancel, and where they cannot
POST /api/v1/registry pre-register a strategy (free)
POST /api/v1/commit commit to a decision BEFORE executing
POST /api/v1/reveal reveal it afterwards; we match it on chain
GET /api/v1/attestation/{digest} whether the sequence is intact
GET /api/v1/watches your alerts, where they deliver, what has fired
PUT /api/v1/watches arm one: kind, target, threshold as a fraction
DELETE /api/v1/watches/{id} disarm it
POST /api/v1/risk is the one that answers a question about you rather than about a vault. Send the vaults you hold and what you hold of each, and it prices your side: the instruments you are exposed to through them, which are rarely the ones you chose, and what a move costs you. A loss stops tracking the price once a vault is closed by the venue rather than marked down, and that discontinuity is where the money is, so it is reported per scenario rather than smoothed into a sensitivity.
Test traffic onlyIt runs end to end, on traffic we generated ourselves. Nobody else has put anything through it. The endpoints answer and the pipeline runs end to end. Every commit, reveal and anchor so far is our own.
The registry, commit and reveal endpoints are the only thing here that ties a strategy to its trades. An agent posts a hash of its intent before placing an order, we cannot see the trade, because the hash covers a nonce too, then reveals it afterwards, and we check it against what appeared on chain. A gap in the sequence, a commitment never revealed, or a reveal matching nothing are all the same failure: a decision the record does not cover. Any of them voids the grade permanently, because the missing commitment would have had to be made before the trade.
Paying inside the request
A 402 carries your own deposit address. Send the transfer, then retry the same request with X-PAYMENT: base:0x<txHash>, we read that transaction on chain during the request and credit it, so there is no waiting for a background job. The reply carries X-Payment-Response saying what happened.
What we do not do is submit a payment for you. Canonical x402 has the server broadcast a signed authorisation, which needs a private key and a gas balance. We hold neither, and acquiring them would give up the property that makes a compromise of this server cost a list of addresses rather than anyone’s funds. Naming the limit beats claiming x402 support and sending an agent looking for an endpoint that is not there.
History, where we have it. Crowding takes an asOf and answers with the book as it stood, a backtest cannot use a figure that only exists in the present tense, and answering “was this crowded before it unwound” with today’s clusters is the survivorship error this site exists to argue against. The reply names the snapshot it actually landed on rather than silently serving a different day. Cluster history is short and says so; /history/capital runs longer and marks every day that was rebuilt rather than observed.
Alerts are set by the machine that wants them.PUT /api/v1/watches arms a crossing, crowding, consistency, drawdown, a version change, or proximity to liquidation, and the firing arrives at your webhook. The threshold is a fraction rather than a percentage, because 0.9 would otherwise be ambiguous between 90% and 0.9% and the wrong reading simply never fires. GET tells you what is armed, what has fired, and whether any endpoint is registered to receive it.
An agent never needs a browser. It can read /api/v1/plans unauthenticated, and /api/v1/account returns its own balance, quota and deposit address against an X-API-Key, so it can top itself up without a human clicking anything.
Webhooks
An alert is worth what it reaches. Every watch you set, crowding past a share you choose, consistency falling, drawdown past a limit, a strategy version changing, can be delivered to your own endpoint as a signed POST, so the crossing lands in a system rather than in somebody’s inbox.
POST https://your-system/aspern
X-ASPERN-Event: watch.fired
X-ASPERN-Delivery: cl9x… stable across retries, deduplicate on it
X-ASPERN-Signature: t=1786…,v1=9f3a… HMAC-SHA256 of "<t>.<raw body>"
{ "id": "cl9x…", "event": "watch.fired", "createdAt": "2026-08-15T19:04:11Z",
"data": { "kind": "crowding", "target": "PURR", "threshold": 0.9,
"value": 0.93, "message": "PURR crossed 90% one-sided." } }
Verify against the bytes you received rather than a re-serialised object, and reject anything whose t is more than five minutes from your clock, the timestamp is inside the signature so a captured delivery cannot be replayed later. We retry a 5xx, a timeout, a 408 or a 429, backing off from one minute to six hours across six attempts; any other 4xx stops at once. Every attempt is recorded with its response code and shown in your account, so “did you send it” has an answer rather than an opinion.
Endpoints must be public HTTPS. We refuse private and link-local addresses, because delivering to one would make this a probe of our own network run on request.
MCP, for assistants
Hosted, no install: POST JSON-RPC to https://aspern.org/mcp, which answers initialize, tools/list, tools/call. No key for the free tools. An agent that finds this platform on its own can use it without anybody setting anything up, which is the point. The card it reads first is at /.well-known/agent-card.json.
Per-call payment (x402). The counterparty check is free and stays free: it is the reference other people quote. A cent a call buys the decision layer, meaning the history of a record and a list checked in bulk. A cent is what this rail actually charges: it is both the median listed price on x402 and the median payment made. Call without paying and the answer is the price and how to pay it.
The 32 tools it advertises
identifyq
Call this FIRST whenever you hold something other than a wallet address. Give it a transaction hash, an http(s) URL, a hostname or an ERC-8004 registration number and it says which party that is, with the evidence for the link, so the other tools here can then be called with the address.
check_service_endpointurl
Call this before connecting to a service. Give it the http(s) URL of an MCP or A2A endpoint and it says who declares it, whether our daily probe reached it, what it answered with, and how many of the last readings answered.
Call this immediately before sending a payment, every time — not once per counterparty. It weighs THIS payment (the amount, the chain, the endpoint) against what the address has actually done: the price the seller themselves published for that endpoint, the address that endpoint names as its payee, the largest payment this address has ever received, and whether it has ever been paid on the chain you are about to use.
Paying
USDC or USDT on Ethereum, Base, Arbitrum or Optimism, to an address issued to you alone, the same string on every one of those chains, so use whichever is cheapest. No card, no automatic renewal, no invoice chasing. Credit appears once the transfer is deep enough to be irreversible. Sign in to see yours.
Bulk data, and what reaches a machine
Dataset
JSON over the API, with a key
Bulk CSV
Vaults
/v1/vaults
/v1/vaults?format=csv, or /export/vaults on the site
Crowding
/v1/crowding
/export/crowding, session only
Operators
/v1/operators
/export/operators, session only
Crowding and operators answer a machine today; what they do not yet do is hand it a CSV, because the export routes authenticate with a session rather than a key. That is a missing format, not a missing dataset. /export/vaults?closed=1 includes the vaults that died: a survivor-only file is the bias this site exists to argue against, and handing it to you unmarked would be an odd way to make that argument. Every return column ships beside the basis it was computed on, so a figure cannot travel into a spreadsheet without the caveat that belongs to it.
Service level and support
What the API commits to, availability, latency, notice before a breaking change, and what a missed month is worth, is stated on the status page beside the measurement of what it actually did, including the months that miss. One person answers support, by email, and what to expect back is written down rather than implied.
What we will not do
• No paid placement, sponsored rankings or advertising. A rating that can be bought is not a rating.
• We do not trade on our own data.
• We publish the limits of what we know. Anything held on a centralised exchange is invisible to us, so the concentration we show is a floor, never a ceiling.
SEND `exitAmountUsd` WITH THE POSITION YOU ARE WEIGHING and this answers whether that size has ever cleared here: the schema has carried it since 2026-10-08, and an auditor still had to find it by guessing because this sentence did not say so. Without it the answer still describes the capacity; with it, `exitCapacity` says `covered-now`, `above-declared` or `unknown` for your amount, and whether a single withdrawal that large has ever been recorded.
SIX RISKS, NOT ONE WORD, across every vault we score. A risk band is a weighted whole and a reader takes it as a summary of everything, which it is not: ours weighs drawdown, crowding, exit, concentration and consistency, and it contains NO reading of who may move the money.
portfolio_screenholdings
READ THE VAULTS YOU HOLD TOGETHER. Every other tool here answers about ONE subject; an allocator does not hold one subject.
capital_coverageno arguments
BEFORE YOU TRUST ANY COVERAGE FIGURE FROM US, ask this. It says how much of the market each vault reading actually covers, counted TWO WAYS: by number of open vaults and by the capital in them.
evidence_forsubject
Everything we hold about one subject, as edges, each carrying where it came from. Use it when you need to explain a decision rather than just make one, or to see what is MISSING before you act.
Call this when you are about to DO something and need one answer you can act on: pay an address, connect to an MCP server, call a tool, or put capital into a vault. The answer depends on the AMOUNT, the ACTION, the POLICY you name and how much we actually read — so the same address can be `allow` for $5 and `abstain` for $5,000.
test_purchaseresource, policy?, fill?
WALK THE WHOLE PURCHASE OF AN x402 ENDPOINT WITHOUT PAYING, in the order a buyer actually asks the questions, stopping at the first one that objects. Every other tool here answers ONE question about one subject; the losses live between them.
endpoint_disagreementslimit?
WHICH ENDPOINTS CONTRADICT THEIR OWN LISTING: they ask to be paid at an address the catalogue entry they published does not name. This is the one reading here that cannot be reproduced from anywhere else — an uptime checker sees a live endpoint and a catalogue reader sees a published payee, and only holding BOTH shows the contradiction.
list_x402_endpointspayee?, q?, limit?
WHICH ENDPOINTS A PAYEE SELLS, or which ones match some text. The sharpest check a payment can get is the endpoint being bought, and until this a caller had to know its URL by heart.
list_policiesno arguments
The policies evaluate_action can be run under, in full: every rule, its id and the sentence it checks. Published deliberately, including to the agents being evaluated — a rule nobody can read is a rule nobody can correct.
counterparty_checkaddress
Before paying or hiring an agent: what the chain records about that address. Independent payers (counterparties that paid it and were never paid back), the ones it does pay back, how concentrated its custom is, WHETHER THOSE INDEPENDENT PAYERS ARE INDEPENDENT OF EACH OTHER under `independence`, WHAT IT ITSELF RESTS ON under `restsOn` (how many parties it pays and how much of its spending goes to the largest of them), how its ACP jobs ended, whether its advertised service answers, and when it was last paid.
vault_checkslug
Before putting capital into a vault: what the record shows about it. The headline is what a holder ACTUALLY EARNED set against the advertised rate, with the risk band, the components that apply, who runs it, and `keys`: who can move the money.
Find agents to hire by what the chain records rather than what they claim: filter every address ever paid on x402, Virtuals ACP, the Olas mech marketplace or Masumi by independent payers, dealings, ACP completion, whether its declared service answers, whether it pays its own payers back, how spread its own SPENDING is (`spreadSuppliers`, the one filter here about what the agent rests on rather than who rests on it), and how recently it was paid. Free.
counterparty_historyaddress, days?
How one agent’s record has moved: dealings, independent payers, concentration and delivery, day by day. PAID, one cent a call over x402 — the median price of this rail.
vaults_earnedno arguments
What depositors actually KEPT, against what their vault advertised. READ `population` BEFORE QUOTING ANY SHARE FROM THIS.
agent_changessince?, address?, limit?
What moved in the agent record, across every agent, since a date. The counterparty check answers what is true about one address NOW; this answers what changed, for all of them, which is the question anybody holding a list asks next.
counterparty_bulkaddresses
Check up to fifty addresses in one call, each with its observations, AND what the set shares underneath: the parties that two or more of them pay. That second part is the one answer no per-address row can contain, because the input is your own shortlist — four agents stopping together because they all pay one party is invisible in four separate clean records.
agent_dependenciesaddresses
If your firm relies on several external agents, what do they rest on AT ONCE? Give it two to twenty-five addresses and it finds the parties more than one of them pays. THE PRODUCT IS THE DISTINCTION, NOT THE JOIN: finding that three agents paid the same address tells you almost nothing — on our rails one address is paid by 71 agents across 4,100 payments and another by three agents once each, and calling both "shared" makes the second sound like the first.
agent_businessaddress
Does this agent have a BUSINESS, and can any of it be demonstrated? Six questions an investor, a marketplace or an operator actually asks, each answered separately: are the addresses paying it really independent customers; is revenue growing or shrinking; how much is repeat custom; how many of those payments can be shown to have bought anything; what does it cost to run and to whom; and if it has several addresses, can the link be DEMONSTRATED or is it an unconfirmed assumption. Measured once and not refreshed since, on two live agents: one takes $2,388 a month from 4,772 payers of whom 97% are repeat, the other $932,414 from 7,220 payers of whom 12% are — two completely different businesses that a counterparty count reports identically.
agent_economic_profileaddress
One agent, four readings, in the order a buyer actually asks them: what it EARNS and from whom, whether its contracted work FINISHED and who signed it off, who it RESTS ON as a supplier, and whether it is still TRADING and its endpoints answer. Every other tool here answers one of those; this is the one that answers them together, over the same nightly record, so the four cannot disagree with each other or with the endpoints they summarise.
exit_screenamountUsd, limit?
YOU HAVE A SIZE AND YOU WANT TO KNOW WHERE IT HAS ACTUALLY CLEARED. Every other exit reading here is about one vault; this asks the same question across every vault whose withdrawal history we have read, which is the question an allocator with capital actually has.
vault_exit_confidenceslug, amountUsd?
Before you put capital in, ask what evidence there is that you could get a PARTICULAR amount back out. Every other reading about a vault is about return or about risk of loss; this is about the practical question a holder has, and it is always about a size: "can I get out" has no answer, "can I get $2m out of a vault with $400k free and 25,941 settled withdrawals behind it" has several.
CALL THIS BEFORE YOUR AGENT SIGNS ANYTHING THAT MOVES MONEY. One request instead of five: it reads the counterparty record, decodes the calldata you are about to sign, looks up the seller’s own catalogue listing, runs an unpaid 402 handshake with the endpoint, and applies a published policy — and then, which is the point, compares them WITH EACH OTHER.
Call this with the CALLDATA you are about to sign, before you sign it. Every other check here asks whether an address is worth dealing with; this asks whether the transaction is the one you think it is, and the two catch different losses.
Call this AFTER you have paid an address or called a tool, to put what you did on the record. Until now this platform answered "should I" and never heard what happened, which is the difference between a lookup and a control layer: a receipt lets the next question about this subject be asked against a record instead of a guess, and lets a verdict we gave be read back against what followed.
monitor_subjectsubject, dimensions?, policy?
Ask to be told when the answer about an address CHANGES. The dimensions are the ones the counterparty check already answers, so this is that same reading on a schedule rather than a second opinion; what it adds is the comparison.
An argument with ? is optional. Read from the running server, so this list is what a client discovers rather than what somebody remembered to write down.
Answers with the seller that endpoint pays, the evidence for the link, and the free check to call next. No key, no account, no setup.
And one where the honest answer is “we cannot say”
"arguments": { "q": "51172" }
→ address: null
says: "Registration 51172 exists on 3 chains with 3 different owners.
An ERC-8004 id is unique within a chain and not across chains."
candidates: [ three addresses, each with the chain it is registered on ]
Where more than one party matches, nothing is returned as the answer and every candidate is listed. Picking one would be an identification the evidence does not support, and these tools exist to serve a decision about paying somebody. The same rule runs through all of them: a payment check answers cannot-say rather than a weak yes, and an address we read no rail for says so instead of coming back empty.
Below, the local server for an assistant on your own machine.
It carries a different set of tools from the hosted one above. Both are shells over the same REST API rather than second implementations, so entitlements and quota are decided in one place and a key stays optional: without one every tool still answers with the free surface. What differs is which tools each one advertises, so the names are given rather than described: picking a server by a sentence about what it is good at is how somebody ends up configuring the one without the tool they came for. The local server leans on the capital side and carries stress, cascade, correlation, crowding, portfolio_risk and waterfall. The hosted one leans on the agent side and carries check_service_endpoint, preflight_payment, inspect_payment, evaluate_action and identify. Only counterparty_check and find_agents are on both.
When a tool hits a wall the assistant is told what kind of wall it is. A 402 carries the amount owed and a deposit address; a partly-answered response carries the arrears alongside it, so a missing field is never mistaken for a plan that needs upgrading.