Resolve a did:solidus DID in Under 10 Lines

"Resolving a DID" means one thing: hand a did:solidus identifier to the network and get back its DID Document, the public keys and capabilities behind it.

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
  }'

Eight lines, one dependency (curl), one real network round trip, not a mock, not a fixture, not a binary you have to download and trust first. Swap in your own did:solidus identifier once you have one. One behavior worth knowing before you do: a DID that was never anchored on the chain resolves to "result": null rather than an error, so a typo and a genuinely missing DID look identical from the outside.

What comes back

The call above returns a DID Document: the record any DID resolves to. Three fields worth naming before you move on: verification_method lists the public key(s) attached to this identifier; authentication names which of those keys can prove "I am this DID" (challenge-response, login); assertion_method names which key(s) can sign statements, including issuing a Verifiable Credential to someone else. One shape note, because it will trip you up if you're expecting textbook DID Core JSON-LD: the raw RPC serves the chain's own snake_case field names, verification_method, not verificationMethod, not DID Core's camelCase serialization. The underlying structure is DID Core's; the wire format is the chain's own. The full field-by-field walkthrough, service, capability_invocation, recovery_policy, and what an inactive DID's document looks like, lives on 008 — What's in a DID Document; this page stops at "here's the call, and here's roughly what you're looking at."

What this proves, and what it doesn't

It proves nothing about consensus, block production, validator count, or throughput: a single read against the state tree is not a load test, and nothing here should be read as a claim about the network's speed or scale under any other workload. It is also, today, a direct call to Solidus's own endpoint rather than a lookup routed through DIF's Universal Resolver alongside other DID methods, that integration hasn't happened yet.

Try it against a different identifier

The most useful thing to do with the snippet above is break it: resolve a DID you know exists, then resolve one you made up. The first returns a document; the second returns null. That distinction matters more than it looks: it's the same behavior a pairwise DID relies on. A pairwise, per-verifier identifier is deliberately never anchored on-chain, so resolving one this same way returns exactly the null case above, on purpose. See 001 — Pairwise DIDs for why that's a feature, not a bug, and what a relying party actually sees presented to it instead.

Where to go next

For how presentation and resolution fit together end to end, how-it-works is the overview page this one plugs into. For the concept underneath this call, what a DID actually is, and why did:solidus specifically is registered in the W3C DID Method Registry rather than "a W3C standard", see 003 — What Is a DID. For the full structure of what just came back, see 008 — What's in a DID Document. And for the canonical, spec-level reference on resolution itself, independent of this one worked example, see the Lexicon's DID Resolution entry; this page is that entry's worked example, not a replacement for it.