Why Most DID Resolvers Are a Centralized Single Point of Failure

Most DID resolvers rely on a single, trusted HTTP API endpoint. This creates a single point of failure for availability and censorship.\n- Censorship Risk: The gateway operator can block or filter DID queries.\n- Availability Risk: A DDoS attack or server outage breaks all identity lookups.\n- Trust Assumption: Users must trust the gateway's integrity and uptime, violating decentralization principles.

Even with decentralized storage (like IPFS), the pointer to the DID Document is often a mutable record on a centralized registry (e.g., Ethereum Name Service, Verifiable Data Registry).\n- Keyholder Risk: Registry controllers can theoretically reassign or freeze DIDs.\n- Upgrade Monopoly: Resolution logic and client libraries are controlled by a single entity.\n- Network Effects: Lock-in to dominant registries like ENS creates systemic risk, mirroring DNS centralization.

Resolution is performed by client libraries (e.g., did:ethr resolver) that hardcode trusted gateways and verification methods.\n- Software Monoculture: All apps depend on the same library's security and availability.\n- Gateway Pin: Libraries pin to specific Infura/Alchemy nodes, inheriting their centralization.\n- Slow Evolution: Protocol upgrades require mass client updates, creating coordination failures and fragmentation.

Networks like Ceramic Network and ION (Sidetree protocol) decentralize the resolution layer itself.\n- P2P Replication: DID Documents are anchored to a blockchain but replicated across a peer-to-peer network.\n- No Single Gateway: Any node can serve resolution requests, eliminating API bottlenecks.\n- Censorship Resistance: A global node set makes it infeasible to block all lookups.

Fully on-chain resolvers, like those for did:ethr, use smart contracts as the canonical state layer.\n- Verifiable State: Resolution logic is enforced by blockchain consensus, not a trusted server.\n- Permissionless Writes: Anyone can update their DID by submitting a transaction.\n- Client Diversity: Any node can independently verify and serve data, preventing library pinning.

Emerging designs like W3C Decentralized Web Nodes and Bluesky's AT Protocol propose incentivized, federated networks for data hosting and resolution.\n- Market for Availability: Node operators are compensated for hosting and serving DID Documents.\n- Protocol-Level Interop: Standardized schemas allow different clients and servers to interoperate.\n- Gradual Decentralization: Reduces reliance on any single company's infrastructure, similar to BitTorrent or IPFS.

Architects often treat the DID method's registry (e.g., a smart contract) as the decentralized component, but the resolution endpoint is a centralized API. This creates a single point of failure for the entire identity system.\n- Vulnerability: A single server outage or takedown request can brick all associated DIDs.\n- Reality: The DID document, the core credential, is served from a traditional web server.

The W3C standard deliberately does not mandate a decentralized resolver. It provides a framework, leaving the hard problem of verifiable data availability to implementers. Most projects take the easy path.\n- Result: DID:Web and many early DID:Ethr implementations rely on HTTPS, not blockchain state.\n- Architect's Duty: You must design the data availability layer, not just the identifier format.

The robust pattern is a hybrid: a minimal on-chain anchor (e.g., a hash on Ethereum, Solana) points to data stored on a resilient P2P network like IPFS or Arweave. The resolver fetches from the network, not a proprietary API.\n- Key Benefit: Censorship resistance inherits from the underlying storage layer.\n- Key Benefit: Resolution latency shifts to ~2-5s from P2P networks, a trade-off for decentralization.

Ceramic provides a decentralized data protocol specifically for mutable, versioned streams (ideal for DIDs). It uses IPFS for storage and a blockchain for consensus on state transitions.\n- Key Benefit: DID documents are live streams, updatable yet verifiable.\n- Key Benefit: Eliminates the "static file" problem of basic IPFS anchoring.

ENS demonstrates a working, decentralized resolver for .eth names. It uses Ethereum for registration/ownership and a network of gateways (like publicnodes.com) for permissionless resolution.\n- Key Insight: The smart contract is the source of truth; anyone can run a compliant gateway.\n- Architectural Proof: $2B+ in primary sales and renewals secured by this model.

Even with a decentralized DID resolver, the Verifiable Credentials (VCs) referenced in the DID document are often stored centrally. This re-introduces the SPOF one layer down.\n- Critical Flaw: A DID can be resolved, but its credentials are unavailable or censored.\n- Mandatory Design: VCs must also be stored on resilient, permissionless networks with content-addressed integrity proofs.