StoneReason · XRPC
Verifiable infrastructure for digital value.
Access, monitor and reconcile activity across blockchain networks through infrastructure that tells you not only what answered, but how strongly it is established — and refuses to answer when it cannot say.
Self-service. One request, no approval queue, no card. Free Beta — no SLA, nothing priced.
"creation": {
"chain_head": 51184176,
"creation_floor": 51184176
},
"live": {
"following": true,
"path": "LIGHT",
"mechanism": "eth_getLogs over a bounded
block window, filtered to one token
contract and the recipient's own topic"
},
"reconciliation": {
"amount": { "standing": "NOTHING_SEEN" },
"finality": { "standing": "NOTHING_TO_SETTLE" },
"observation": { "standing": "ESTABLISHED" },
"timing": { "standing": "NO_DEADLINE" }
}A real response from this deployment. Four standings are
kept apart because they become true in different orders, and
NOTHING_SEEN is not the same as UNKNOWN.
The problem
A response is not the same thing as proof.
Most infrastructure returns a value and stops. You get a number without the one thing that decides whether you can act on it: what established it.
One provider answering is not correctness
A single endpoint returning a balance has told you what that endpoint believes. Agreement between two of them means nothing until their independence is established — and independence is hard to establish, because a public endpoint will not tell you whose upstream it is.
Confirmations are not finality
Twelve confirmations means something different on every chain, and on some it means nothing at all. Ethereum finalises a checkpoint. Bitcoin makes no finality claim and depth is a risk policy. A universal confirmation count flattens the distinction that matters.
Payment state is harder than transaction state
Finding a transfer is not knowing a customer paid you. That needs an amount matched against an obligation, an occurrence attributed to the right session, a deadline, and settlement in the chain's own vocabulary — four answers that come true in different orders.
The model
Five dimensions. Never combined.
There is no verified: true field and no score.
A single number would have to answer five different questions at once, and the
useful answers are mixtures.
The vocabulary is published as part of the API, so the meaning of every value is machine-readable rather than described in a blog post.
A provider said so and XRPC did not check it. Correct as often as that provider is correct.
The answer is real and does not cover the whole question. Returned as 206, not 200.
What supports it, and who. Agreement between sources means nothing until independence is established.
Which view of the chain this is. Four positions, kept
apart. There is no latest_block.
What the chain itself says about settlement, in its own vocabulary. There is no universal confirmation count.
UNESTABLISHED — which is not the same as
weakly known, and not the same as safe.
Products
Three things you can build on today.
Everything below answers a real request on the deployed build. Capabilities differ by network, and the catalogue refuses anything a qualification has not seen answer.
Access
One interface to 66 registered networks, with the trust dimensions attached to every answer. Network state and capability reads are live in Free Beta; balance reads are in the catalogue but not answering on this deployment, and the Access page says so plainly.
Verify
Ask what an answer is worth, and set a floor below which you would rather have no answer at all. The five-dimension vocabulary is published and live; the transaction verification path is gated behind evidence this deployment does not have.
Payments
Detect, attribute, finalise and reconcile an incoming payment against an obligation you stated. Non-custodial: the money goes to your address and XRPC never holds a key. Live on the 9 networks this deployment follows.
Also on the developer surface, with narrower guarantees: a stablecoin directory that treats a ticker as ambiguous rather than as an identity, a route advisor that names what it could not measure, transaction simulation that states it is not a guarantee, delivery of signed bytes that XRPC never alters, and an MCP endpoint for agents where exactly one of fifteen tools can touch a chain. See the full surface →
Payments
From "a transfer happened" to "this customer paid."
A payment session states an obligation: this asset, this amount, this destination, on this network. Everything after that is measured against it.
XRPC reads the chain head before the session exists and records it as a creation floor. A payment at or below that floor was on the chain before you made the offer, so it cannot pay for it. That one rule removes an entire class of double-attribution bug.
Non-custodial by architecture. Funds move directly to your address; XRPC holds no key, signs nothing, and cannot move money.
Detect
A bounded read per session per pass — one token contract, one recipient topic. No block scan, no history, no local store.
Attribute
Each occurrence is named in the chain's own identity — block, transaction and log index — and tied to one session above its creation floor.
Finalise
Settlement is read in the chain's vocabulary. XRPC does not count to a number the chain never promised.
Reconcile
Amount, finality, observation and timing are four separate standings. Only their combination decides whether goods may be released.
Receipt
An evidence record of what XRPC read — and it states in its own body that it is not a proof.
“This is XRPC's record of what it read from the chain, not a proof from the chain. It carries no validator signature and no inclusion proof, and it cannot be checked by anybody who does not trust XRPC. To verify independently, take the native identity of each entry to any node or explorer for that network.”
— the basis.why_not_a_proof field, returned on every receipt.
Coverage
Counted honestly, per capability.
There is no readiness flag and no per-network total. Capabilities become true in different orders on different chains, so one number would have to hide which.
66
Networks registered
Access is broad. Every one carries a finality model and a trust ceiling.
15
Dedicated engines
With a published acceptance record. The other 51 are read through the broad layer.
9
Networks followed for payments
On this deployment. Four more are qualified through the Data plane, which is not deployed here.
0
Networks with local history
XRPC is not an indexer and claims no archive. Local history is earned by real usage.
For developers
One key. One request. The scope you asked for.
Onboarding is self-service and structural: no step waits for a person, and there is no pending-approval state to enter.
Your key is scoped to the products and networks you chose and narrowed to what the catalogue actually serves. Ask for a capability this deployment cannot serve and you are refused at signup rather than issued a key that fails later.
Broadcast — the one capability that spends money — is never granted by onboarding.
# the request
{ "method": "network.status", "network": "base" }
# the answer, and what it is worth
"outcome": "ANSWERED",
"trust": {
"trust_class": "UNVERIFIED_RAW",
"evidence_basis": "SERVICE_LOCAL",
"coverage": "SINGLE_POINT",
"read_context": "SINGLE",
"floor_met": true
}Architecture
What StoneReason does not hold.
No customer keys
XRPC holds no private keys and signs nothing. There is no signing tool, no custody action, and no path by which one could be added quietly.
Signed bytes, unaltered
Delivery is not authorship. Bytes arrive signed by you and leave unaltered; the job records that they were not modified.
Fail-closed capabilities
A capability is offered only where a qualification saw it answer. Missing evidence produces a refusal, never an assumption.
No public admin surface
/admin, /metrics and /debug return 404
on every public host, as a rule at the edge rather than as an absence.
Free Beta
Open, self-service, and honest about its edges.
Get a key in one request and make your first call in a minute. What the Beta does not promise is written down as plainly as what it does.
No SLA. Nothing here measures availability, and one host means a host failure is an outage.
Not priced. There is no pricing and no billing in this build.
Coverage varies. 18 of 540 capability rows are commercially available today. The catalogue is the authority, and it refuses the rest.
Trust is usually source-only. Most answers today are
UNVERIFIED_RAW, and they say so.