The data layer

Data surfaces

Every page that renders the index, and its machine-readable equivalent.

The same dataset, rendered for different questions. Each surface has a JSON or markdown twin, so anything a person can look at an agent can fetch.

Live activity#

Flow of funds — settlements as they land, agent to service. The tip polls every ten seconds; once you page back into history the polling stops, so a refresh cannot yank you off the page you were reading.

text

/flows.json?per=50          the same feed as JSON
GET /api/v0/flows?limit=50  the API equivalent, cursor-paged

Transactions — the whole ledger, sortable and filterable, with every filter in the URL so a filtered view is a link you can send.

text

GET /api/v0/transactions?limit=50&min_probability=0.5

The graph#

Explore — the payment graph as an interactive bubble map. Entities sized by their own volume, coloured by role, settlements aggregated into payer→payee edges over a window you can scrub.

Worth knowing how to read it:

Facilitators are a toggleable layer, drawn as dashed nodes. An attributed payment routes payer → facilitator → payee, because the relayer is the transaction's sender, not a party to the payment. A flow drawn straight through says which kind it is: payer-submitted, or route unknown.
Windows are 7 / 30 / 90 / 180 days. The default 7 days is scrubbable to the individual payment.
Every figure is per-entity or per-pair. No site-wide totals here.

text

/explore.json?days=7
GET /api/v0/graph?days=7        whole days only — stable and cacheable
GET /api/v0/graph?window=500    the live tip, by row count

Profiles#

/agents/<wallet> — a payer's view: outbound volume, who it pays, chains, facilitators used, an activity heatmap, nearest neighbours.

/agents/<namespace>-<chain>-<agentId> — one ERC-8004 registry entry, e.g. /agents/eip155-8453-1199: its card, trust breakdown, feedback and the wallet it published. The chain is part of the address because an agentId is only unique within one registry.

/merchant/<wallet> — the same wallet from the other side: inbound volume, distinct and repeat customers, services being paid for, listed price against average paid, and where the endpoint serves from.

/facilitators/<key> — one operator: relayed volume, the pairs it routes between, its wallets.

text

GET /api/v0/agents/<wallet>
GET /api/v0/merchants/<wallet>
GET /api/v0/entities/<wallet>/settlements?limit=50
GET /api/v0/facilitators

Every profile renders its own share card at request time from live data, so a link unfurls with real figures rather than a generic image.

Directories#

Services — the priced x402 directory. Card or table view, filterable, with an exact matched count rather than a fetch-window figure. Each row carries an Add skill control: the label copies a discover prompt for your agent, and the file icon opens a per-service SKILL.md.

Unified Services — the catalog grouped by the JOB an endpoint does, so every provider of one capability is compared on a shared request, response and price. The going rate is call-weighted, not a median. See Price and pick a service.

Agents — indexed ERC-8004 identities, card or table.

Wallets — every address the index has seen, cursor-paged.

Leaderboard — agents ranked by trust. Offset-paged, because a rank is a position. Agents with no feedback are hidden by default.

text

GET /api/v0/endpoints?q=<search>     note: the API path is /endpoints, the page is /services
GET /api/v0/unified                  capability catalogue
GET /api/v0/unified/<slug>           one capability: offers + going rate
GET /api/v0/unified/<slug>/recommend shortlist, by criteria you pass
GET /api/v0/agents?q=<search>
GET /api/v0/wallets
GET /api/v0/leaderboard?limit=25&offset=0

Note

The page moved from /endpoints to /services, and the old path is a permanent redirect. The API path stays /v0/endpoints — renaming a published endpoint breaks integrations that did nothing wrong.

Attestations#

/kya — the Know Your Agent tool: connect → compose → sign → publish, plus a paste-and-verify tab. /kya/<digest> is the public verified-signature page, showing the canonical bytes and the signature so a reader can recompute both.

text

POST /api/v0/kya                    verify and store
POST /api/v0/kya/verify             verify only
GET  /api/v0/kya/<digest>           one attestation
GET  /api/v0/kya/agents/<wallet>    attestations by one signer

Read one digest or one signer at a time. There is no site-wide attestation feed or count — the aggregation rule applies here too. Mechanism: the KYA memo.

Aggregates and health#

Stats — the only place site-wide aggregates exist: index coverage, settled volume, and 90-day series for volume, settlements and distinct buyers and sellers. Every headline figure with a series shows it.

Status — capture lag per chain, gap counts, rollup and enrichment freshness, and an hourly ingest chart counted rather than sampled. Its verdict reads all of that, not just whether the site responds.

Machine surfaces#

URL	What it is
`/docs.md`	These docs as one markdown index
`/get-started.md`	The machine quickstart, current with what is deployed
`/skill.md`	The Roundhouse agent skill
`/llms.txt`	Agent reference for this origin
`/discovery.md`	The generated service directory
`/services.json`	The service directory, enriched, filterable and paged
`/sitemap.xml`	Crawlable page index

Plus every docs page at its own URL with .md appended. Full list: sitemap.

Next steps#

The data model — what is behind each surface
Agent surfaces — the machine side, in detail
API reference — every endpoint and parameter