Universal Resolver
Also called DIF Universal Resolver, Universal DID Resolver
However many different DID methods exist, did:web, did:key, did:ion,
did:solidus, dozens more: a piece of software that wants to resolve
"give me the DID Document for this DID" shouldn't have to hard-code logic
for every method it might ever encounter. The Universal Resolver exists to
be the one thing that does: a single HTTP API in front of a set of
pluggable "driver" containers, one per DID method, each of which knows how
to talk to that method's specific resolution mechanism (a blockchain RPC
call, a Sidetree batch replay, a plain HTTPS fetch for did:web). A client
calls one endpoint with any supported DID; the Universal Resolver routes it
to the right driver and hands back a DID Document. It's the same job a DNS
resolver does for domain names, generalized to self-sovereign identifiers
that aren't all backed by the same kind of infrastructure.
Where it comes from
The Universal Resolver is a Decentralized Identity Foundation (DIF) open-source project, built and maintained principally by Markus Sabadello and his company, Danube Tech: Sabadello also co-edits the W3C DID Core and DID Resolution specifications at the standards-body level. Community- contributed drivers now cover roughly 30 DID methods. Solidus designed none of it and has not contributed a driver for did:solidus.
Solidus status
There is no did:solidus driver in the Universal Resolver today. Solidus's own internal planning names writing one as "the one cheap real move" still outstanding, described as days of engineering effort, gated on nothing but actually doing it, and explicitly flags that it must not be described as shipped before it exists. Until a driver lands, did:solidus DIDs resolve only through Solidus's own RPC method; every product built to consume the shared Universal Resolver endpoint instead of a method-specific integration currently can't see a did:solidus identity at all.
Proof: verified live, 2026-07, curl "https://dev.uniresolver.io/1.0/identifiers/did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J"
returns {"didResolutionMetadata":{"error":{"type":"METHOD_NOT_SUPPORTED", ... "detail":"Method not supported: solidus"}}}. The exact same DID
resolves fully, full DID Document, verification methods and all, by
calling solidus_didResolve directly against rpc.solidus.network. Anyone
can run both commands and see the gap between "resolves on Solidus's own
RPC" and "resolves through the shared resolver the rest of the ecosystem's
tooling calls" first-hand: that gap is precisely the roadmap item.
Where it comes from
Someone else specified this. Solidus assembles it.
The Universal Resolver is a Decentralized Identity Foundation (DIF) open-source project: one HTTP API in front of a set of pluggable "driver" containers, one per DID method, so a client can resolve any supported DID to its DID Document without hard-coding method-specific resolution logic itself. The same job DNS resolvers do for domain names, generalized to self-sovereign identifiers. It's built and maintained principally by Markus Sabadello and his company, Danube Tech (Sabadello also co-edits the W3C DID Core and DID Resolution specifications) with community-contributed drivers now covering roughly 30 DID methods. Solidus designed none of it and has not yet contributed a driver for did:solidus.
How to check this
Planned. Nothing built.
Verified live, 2026-07: `curl "https://dev.uniresolver.io/1.0/identifiers/did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J"` returns `{"didResolutionMetadata":{"error":{"type":"METHOD_NOT_SUPPORTED", ... "detail":"Method not supported: solidus"}}}`. The exact same DID resolves fully, full DID Document, verification methods and all, by calling `solidus_didResolve` directly against `rpc.solidus.network`. Anyone can run both commands and see the gap between "resolves on Solidus's own RPC" and "resolves through the shared resolver the rest of the ecosystem's tooling calls" first-hand: that gap is precisely the roadmap item.