Products

What you can call today.

XRPC is one platform with one authorisation model and one capability catalogue. Everything below is reachable on the deployed build; where something is gated, this page says what gates it rather than leaving it off the list.

Core products

These are what a customer buys into. Each has its own page.

Access

Read network state across 66 registered networks through one interface, with the five trust dimensions attached to every answer.

Verify

Ask what an answer is worth. Set a floor, and get no answer rather than a weak one you did not ask for.

Payments

Non-custodial payment sessions: detect, attribute, finalise, reconcile, and issue an evidence receipt.

Developer-plane capabilities

Narrower in scope, live on the developer surface, and documented rather than marketed. None of these has its own page yet, because none of them needs one.

Probed against the deployed build. "Answers" means a real request returned a real result, not that a module compiles.
CapabilityEntry pointStateWhat it will not do
Stablecoin directory GET /v1/directory Answers Treat a ticker as an identity. USDC comes back is_ambiguous: true, because identity is the pair of network and native identifier.
Route advisor POST /v1/advisor/routes Answers Claim a cheapest or fastest route. No fee or latency measurement exists in this build, so the advice names what it could not measure.
Simulation POST /v1/simulate Answers on 7 EVM networks Present a simulation as a guarantee. Every answer carries its caveats, and unsupported networks are refused rather than approximated.
Send POST /v1/send Answers Sign anything. It takes bytes you signed and hands them to a chain unaltered; the job records that they were not modified.
Source mesh POST /v1/sources Configures and qualifies Route through your source yet. A configured endpoint is asked who it is and checked against the network's own identifier; route selection still uses XRPC's endpoints.
Compliance boundary GET /v1/compliance Reports UNCONFIGURED Screen anything. No provider is configured on this deployment and it says so, rather than returning a clean result that means nothing.
Checkout GET pay.stonereason.com/c/{token} Answers as JSON Render a hosted page. The payer surface is structured data over the one payment truth; there is no HTML checkout in this build.
MCP endpoint POST mcp.stonereason.com/mcp Answers — 15 tools listed, 6 execute Let an agent exceed its key. Exactly one tool can touch a chain, and a tool with no execution path says executed: false rather than returning an empty result.
Monitor — payment delivery Webhook and WebSocket Live for payment events Watch arbitrary chain events. Generic watches return CAPABILITY_NOT_AVAILABLE.
Streams GET /v1/streams Lists; creation reaches UNESTABLISHED Accept a stream with nowhere to deliver. Following a stream needs the Data plane, which this deployment does not run.

How a capability becomes available

Two questions are answered separately for every capability on every network, and they usually differ:

  • Engine support — what the engine can do.
  • Service exposure — whether a request can reach it.

A single supported column would have to say either yes, which is false to a caller, or no, which is false to the code.

On top of both sits the commercial catalogue, which is fail-closed: a capability is offered on a network only where a qualification artefact records that it was seen to answer there.

On this deployment that is 18 of 540 rows. The rest are refused — including at signup, so you are never issued a key for something that cannot work.

How coverage is counted →