did:ethr vs did:web: Blockchain vs Web Hosted DIDs

On-Chain Verifiability: DID Documents are anchored to Ethereum (or other EVM chains like Polygon, Arbitrum). This provides a cryptographically secure, global, and permissionless root of trust. This matters for high-stakes identity, like enterprise credentials, asset tokenization, or legal agreements, where non-repudiation is critical.

No Central Point of Failure: DID resolution occurs via the blockchain, independent of any single server's uptime. This matters for building censorship-resistant applications and ensuring identity availability aligns with the underlying chain's 99%+ uptime. Relies on public RPCs or your own node infrastructure.

Cost & Speed Advantage: DID Documents are hosted on a web server (e.g., https://example.com/.well-known/did.json). Creation and updates involve zero gas fees and sub-second latency. This matters for prototyping, high-volume/low-value use cases (like user sessions), or applications where blockchain costs are prohibitive.

Server-Side Management: You control the entire lifecycle of the DID Document via standard HTTPS operations. This matters for enterprises with existing PKI, internal systems requiring rapid schema changes, or scenarios where legal ownership maps to web domain control. Integrates easily with OAuth2, SIOPv2, and traditional web infra.

• Sovereign, User-Centric Identity (wallets like MetaMask, Rainbow).
• Verifiable Credentials with maximum trust minimization (e.g., EBSI, Dock Network).
• DApps needing on-chain attestations (e.g., Gitcoin Passport, Orange Protocol).
• Long-term, non-revocable identifiers that must outlive any company.

• Corporate or Brand Identifiers (e.g., a company issuing employee badges).
• High-frequency credential updates where gas costs are unsustainable.
• Closed ecosystems or pilots where a trusted web domain is sufficient.
• Bridging Web2 and Web3 without immediately forcing users onto chain.

Cryptographic proof anchored to Ethereum: DID documents are signed updates to a smart contract (EthereumDIDRegistry). This provides a globally consistent, tamper-proof state, enabling trustless verification without relying on the issuer's server. Critical for high-stakes credentials like diplomas or legal agreements.

On-chain transaction overhead: Every DID creation, key rotation, or attribute update requires paying gas fees and waiting for block confirmations. This makes it prohibitively expensive for high-volume, ephemeral identities (e.g., session IDs for gaming). Complexity increases with Layer 2 solutions like Arbitrum or Polygon.

Hosted on your existing web infrastructure: The DID document is a simple JSON file served over HTTPS (e.g., https://example.com/.well-known/did.json). No blockchain fees or delays. Ideal for rapid prototyping, internal systems, or scenarios where you control and trust the hosting domain.

Relies on DNS and web server security: The DID's integrity depends entirely on the security of the hosting domain. If the server is compromised or goes offline, the DID becomes unverifiable or unavailable. Not suitable for long-term, resilient identities that must outlive a specific company or service.

Sovereign, long-lived identities where cryptographic proof is non-negotiable.

• Use Cases: Enterprise credentials, academic attestations, portable KYC, cross-chain DeFi identities.
• Key Tools: Ethr-DID-Resolver, Veramo, SpruceID's didkit.

Low-friction, controlled-environment identities where you manage all endpoints.

• Use Cases: Internal employee IDs, IoT device management within a private network, temporary conference badges, testing W3C Verifiable Credentials.
• Key Tools: Simple HTTP servers, did:web resolver libraries from Microsoft, Transmute.

Key Weakness: Operational overhead. Requires managing blockchain transactions (gas fees), wallet security, and smart contract interactions. Updates incur costs and latency (block confirmation times). This matters for high-volume, low-margin applications or teams without blockchain DevOps expertise. It introduces a dependency on the health and fees of the underlying L1/L2.

Key Weakness: Dependency on domain control. The DID's integrity is tied to the security and availability of your web server and DNS. If the domain expires, is seized, or the server goes down, the DID becomes unresolvable. This matters for mission-critical, decentralized applications where uptime and censorship resistance are non-negotiable. It re-introduces a central point of failure.