Query the Solidus Chain Yourself: A JSON-RPC Walkthrough

No sign-up, no API key, no explorer UI in between. This is one curl command against a public endpoint, run just now:

curl -X POST https://rpc.solidus.network \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "solidus_getLatestBlock",
    "params": [],
    "id": 1
  }'

The real response:

{"jsonrpc":"2.0","id":1,"result":{"height":77278,"round":1718,"hash":"6b6f0117cf104690ace7af7555846c17f44d5a508ba8d76d336f13f1b9a2453c","parent_hash":"411e6c220e5df28b5eb87023cbf7b69d37f6939508828b2e3469ed641969f81d","state_root":"9045d9ed5ab3f444bc59c8899629031f640d48ce74d29a7aaa17b525d54483f1","transactions_root":"0000000000000000000000000000000000000000000000000000000000000000","timestamp_ms":1784357243969,"tx_count":0,"proposer":"2VnFvB9X8BW5QxDAD1wJjjd8AJvT","transactions":[]}}

Run it again yourself and the height will have moved on. If you haven't seen a block explained field-by-field yet, or watched a DID resolve, start with how to read a Solidus block and resolve a DID yourself, this page assumes you've seen the shape of the data and now want to talk to the node directly.

What JSON-RPC actually is

JSON-RPC is not something Solidus invented. It's a lightweight, transport-agnostic remote-procedure-call format, send a small JSON object naming a method and its parameters, get back a JSON object with a result or an error. Version 2.0 has been maintained as an open community spec at jsonrpc.org since 2010, and it's the same wire shape Ethereum clients expose as their eth_* methods. Solidus uses the spec as-is; the only thing specific to Solidus is which methods sit behind it.

One distinction worth knowing before you go looking for eth_getBalance: rpc.solidus.network exposes Solidus-native methods, not an Ethereum-compatible eth_* namespace. An eth_*-shaped surface for tools like MetaMask or Foundry is planned for the EVM Subnet, a separate, not-yet-deployed piece of the system, not something this endpoint provides today.

What you can actually ask it

The method set you saw above, block data, is one category. The others, real and re-verified against the live endpoint:

• Block and chain data, latest block, block by height, the fields shown in the response above.
• DID resolution, solidus_didResolve, the same method the DID-resolution walkthrough uses, turning a did:solidus identifier into its full DID Document.
• Transaction submission, the write path a wallet or SDK uses to broadcast a signed transaction to the network.

That's the honest shape of it today. There's no eth_getBalance equivalent to chase here either: a did:solidus anchor is a registered identity, not an account that holds value, so the methods above don't include a balance lookup for one: that decoupling is enforced at the executor level, and it's covered on its own page, why a DID cannot hold a balance, if you want the mechanism, not just the RPC surface.

The free-tier terms, quoted exactly

The explorer's own nav states it plainly: 12 endpoints, 100K req/day free. That's the number as published, not rounded up. For the full method list, not just the two shown here, see the explorer's /api reference page. This page is a walkthrough of two commands, that page is the catalog.

A second worked example

Here's the same discipline applied to a DID instead of a block: the exact call the DID Resolution lexicon entry documents, run against the one sanctioned example DID:

curl -X POST https://rpc.solidus.network \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "solidus_didResolve",
    "params": ["did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J"],
    "id": 1
  }'

The real response:

{"jsonrpc":"2.0","id":1,"result":{"context":"https://www.w3.org/ns/did/v1","id":"did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J","controller":"did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J","verification_method":[{"controller":"did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J","id":"did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J#key-0","publicKeyHex":"4ac407d14cab5627f69f0b3067a3cd6c340c610c3c414f367b3bdac1343c2044","type":"Ed25519VerificationKey2020"}],"authentication":["did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J#key-0"],"assertion_method":["did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J#key-0"],"key_agreement":[],"capability_invocation":["did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J#key-0"],"capability_delegation":["did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J#key-0"],"service":[],"active":true,"created_ms":1783972405492,"updated_ms":1783972405492,"version_id":"32352473f6c8399bd3612e621269b0f8438b884854212f3b7a5acba60daac012","recovery_policy":null,"recovery_nonce":0}}

Swap in a DID that was never anchored and you'll get "result": null instead of an error, which is its own small lesson: a made-up identifier and a missing one look identical from the outside.

If you want to see this same pattern chained across several calls in a row, resolving a DID that sits behind an on-chain asset on a different network entirely, the next page walks through an AI agent's identity, resolved on-chain.

There's nothing between you and either of these two responses, no dashboard, no account, no approval step. That's the same property the block explorer and the DID resolver both demonstrate through a UI; here it's the same chain answering the same questions with nothing in front of it at all.