For wallet teams
A balance your interface can stand behind.
Wallets are judged on one screen. If the number on it is wrong — stale, partial, or read from a node that had forked — the user finds out at the worst possible moment, and the wallet gets the blame rather than the provider.
The problem
Every chain is a separate integration. Different RPC shapes, different address forms, different ideas of what a token is. A wallet on six networks is six code paths that drift.
A partial read looks like a complete one. If one token family could not be reached, most APIs return what they have. The user sees a total that is quietly missing something.
Freshness is invisible. A balance from a node that is behind looks identical to one from a node at the head. Nothing in the response lets the interface say “this may be a moment out of date”.
Retrying makes it worse. When a read fails, the honest move is to say so. Retrying against a second provider until one answers is shopping for the answer you wanted.
What StoneReason does
One request shape for every network, and an answer that says what it is worth.
One integration
The same balance.get on every supported network. The address
form, the token model and the settlement vocabulary are the API’s problem,
not yours.
Coverage is stated
An answer that could not reach part of what you asked about says which part. Your interface can show the number and the gap, which is what a careful wallet does anyway.
Freshness and finality, separately
How recently it was read, and what this chain means by settled, are two fields rather than one adjective. An unfinalised head and a finalised block look different in the response.
What works today
Free Beta, and narrow on purpose.
- Native balances on 6 networks: arbitrum, avalanche, base, bsc, ethereum and polygon.
- Token balances on the same networks, by contract address. Decimals are not assumed: the amount is the smallest unit and says so.
- Network and engine state, so a wallet can tell “the chain is quiet” from “we cannot see the chain”.
A first call
curl https://api.stonereason.com/v1/rpc \
-H 'authorization: Bearer $XRPC_KEY' \
-H 'content-type: application/json' \
-d '{"method":"balance.get","network":"base",
"address":"0x742d35Cc6634C0532925a3b844Bc454e4438f44e"}'Omit asset for the native coin. Name a contract
address to read a token. Both return the amount in the smallest unit, as a
string — a float would round a wei value above 253.
What it does not do
Written here rather than discovered during an integration.
No portfolio call. There is no single request that returns everything an address holds. A wallet asks per asset, which is slower and is the only shape that can report coverage honestly.
No key handling, ever. There is no method that accepts a seed, a passphrase or a private key. Signing stays in your wallet, where it belongs.
No transaction history. History needs an index this deployment does not run.
No push updates. Balance changes are not streamed on this deployment; a wallet polls. Payment watching is a separate product and does push.