Resolve a Decentralized Identifier, Yourself, Right Now

One HTTP request resolves a decentralized identifier, and you can send it right now. That's the whole page. Everything below is what the response means and how you'd know it's honest.

What's real is the mechanism: the resolution itself, and a separate, checkable claim about the method it belongs to.

Try it yourself

You don't need the explorer's UI to do this, the same call works from any terminal, against the same public endpoint:

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

No API key beyond what's public, no account, no waiting on a block: a DID resolution is a plain read against the chain's state tree. Try the explorer's /lookup page with a made-up string instead of the one above, and you'll get {"result": null} back: a DID that was never anchored on-chain looks identical, from the outside, to one that's simply wrong. That null is not a bug; it's the honest answer to "does this identifier exist."

What resolution actually returns

The raw response is the chain's native JSON, with a few lower-level fields (recovery metadata, timestamps, capability relationships) trimmed here for readability: the structure and field naming are exactly what the RPC returns:

{
  "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"],
  "service": [],
  "active": true
}

You don't need to parse every field to follow the shape. verification_method is the public key attached to the identifier, the thing a signature gets checked against. authentication names which key can prove "I am this DID." assertion_method names which key can sign statements, including issuing a verifiable credential. service would list endpoints if this DID advertised any; this one doesn't. One honest note on formatting: this is the chain's own snake_case field naming (verification_method, not the DID Core spec's verificationMethod): the document's structure comes from W3C DID Core, the serialization is Solidus's own RPC convention.

If a phone number is the DID, this is the contact card behind it: keys and endpoints, not a name and address, and unlike a phone book, there's no company you have to ask.

The registration claim, stated correctly

Keep two separate facts apart, because they prove different things. The claim above, that this specific identifier resolves, is about one DID. The claim below is about the method, did:solidus itself, as a class:

did:solidus is registered in the W3C DID Method Registry. Not "a W3C standard." Not "W3C-approved." A method registration is a listing in the community-maintained registry of who has defined a DID method under W3C DID Core's extension mechanism, nothing more, nothing less. Check it yourself, independent of anything Solidus tells you:

curl -s https://api.github.com/repos/w3c/did-extensions/pulls/713 | jq '{state,merged,merged_at}'

{
  "state": "closed",
  "merged": true,
  "merged_at": "2026-07-04T16:12:59Z"
}

Pull request #713, "Register did:solidus method," to w3c/did-extensions, merged. That's what registration means: the method specification lives in the registry other implementers consult before building a resolver for a method they haven't seen before. It is not an endorsement of Solidus, and it is not a statement that DID Core itself, the underlying standard, is something Solidus authored. Solidus implements DID Core; it did not write it.

What resolution buys you

A resolver is the part of this design that's easy to take for granted. Nobody had to grant you an account to run either command above. There's no dashboard login gating the /lookup page, no partnership agreement required to query rpc.solidus.network, no support ticket to open if you want to check whether an identifier is real. That's the actual point of a decentralized identifier: the check is independently reproducible by a stranger, using nothing but the public endpoint and public registry, not a claim you have to take on Solidus's word. For a relying party, that translates directly: an identity claim tied to a did:solidus DID is verifiable by anyone who bothers to look, not gatekept behind whichever company issued it.

Compare that to the usual arrangement, where "verify this identity claim" means calling the originating company's API, waiting on their uptime, and trusting their answer because there's no independent way to check it. Here the check doesn't route through Solidus at all: it routes through the chain's own public state, which anyone can read without asking permission first. That's what "decentralized" is actually buying you in this identifier: not a slogan, a specific, reproducible fact about who gets to answer "is this real."

Where to go next

Resolve a different DID against the same /lookup page and watch a fabricated string come back null, that's the fastest way to feel the difference between "anchored" and "made up." For the opposite case (a DID built to be deliberately unresolvable by design, not by accident) see one seed, many identities: pairwise DIDs. For the lower-level interface behind both the explorer's UI and the curl command above, see query the chain yourself over JSON-RPC. And for the block-level context this DID Document actually lives inside, start from how to read a Solidus block.