DID:ethr excels at providing a robust, enterprise-grade identity layer directly on Ethereum L1 and L2s. It leverages the Ethereum blockchain as the root of trust, using smart contracts like the EthereumDIDRegistry for key management and updates. This results in high security and censorship resistance, but inherits the cost and speed constraints of its underlying chain. For example, a key rotation on Ethereum Mainnet can cost $10-50 in gas, while on Arbitrum it may be under $0.01, demonstrating its performance is a direct function of the chosen execution environment.
DID:ethr vs DID:pkh: The Ethereum-Centric DID Method Showdown
Introduction: The Core Architectural Fork
A technical breakdown of the two dominant Ethereum-centric DID methods, highlighting their foundational design choices and target ecosystems.
DID:pkh takes a different, maximally agnostic approach by using a public key hash (PKH) as the DID identifier, as defined by the CAIP-10 standard. This creates a DID method that works across any blockchain (e.g., did:pkh:eip155:1:0x... for Ethereum, did:pkh:bip122:000000000019d6689c085ae165831e93... for Bitcoin). Its strength is unparalleled interoperability for multi-chain applications, but it lacks the built-in, on-chain update mechanisms of did:ethr, pushing key rotation and service endpoint management to off-chain solutions like did:key or did:web.
The key trade-off: If your priority is on-chain verifiability and sophisticated key management within the Ethereum ecosystem, choose DID:ethr. It is the standard for protocols like Verifiable Credentials using EthereumEIP712Signature2021. If you prioritize cross-chain portability and a minimal identifier for wallets across Bitcoin, Cosmos, Solana, and beyond, choose DID:pkh. It's the foundational method for projects like Ceramic Network and is central to the decentralized identity stack from the W3C Credentials Community Group.
TL;DR: Key Differentiators at a Glance
A direct comparison of two dominant Ethereum-centric DID methods, highlighting their core architectural philosophies and ideal application scenarios.
DID:ethr: Native Smart Contract Control
Built for on-chain programmability: Uses a smart contract registry (ERC-1056/EIP-5805) for key management and delegate assignment. This enables complex, gas-efficient logic for credential revocation, multi-sig recovery, and enterprise workflows. Ideal for DeFi protocols, DAOs, and enterprise SSO requiring granular, on-chain control.
DID:ethr: Enterprise & Interoperability Focus
W3C standardization leader: Backed by the Decentralized Identity Foundation (DIF) and major players like Microsoft and ConsenSys. Integrates seamlessly with Verifiable Credentials (VCs) and the W3C DID-Core spec. The best choice for projects prioritizing regulatory compliance, cross-chain identity (via CCIP), and integration with existing IAM systems.
DID:pkh: Simplicity & Wallet-Native UX
Directly maps to existing wallet addresses: A DID is simply your Ethereum (or other chain) address prefixed with did:pkh. No registry contracts or on-chain transactions are needed for creation. This provides a frictionless, zero-cost onboarding experience. Perfect for consumer dApps, NFT communities, and social logins where user adoption speed is critical.
DID:pkh: Multi-Chain by Design
Inherently chain-agnostic: The pkh (public key hash) method natively supports Ethereum, Cosmos, Solana, and others via the CAIP-10 standard. Offers a unified identity layer across ecosystems without custom integrations. Choose this for multi-chain applications, wallet providers, and protocols like Ceramic Network and IDX that manage data across chains.
DID:ethr vs DID:pkh: Feature Comparison
Direct comparison of Ethereum-centric decentralized identity methods for protocol architects.
| Metric / Feature | DID:ethr | DID:pkh |
|---|---|---|
Primary Use Case | General-purpose DIDs for apps & enterprise | Wallet-based authentication for users |
Core Identifier | Ethereum address or ERC-1056 controller | Public Key Hash (e.g., 0x..., bc1q..., tz1...) |
On-Chain Registry | ||
Key Rotation Support | ||
EIP-712 Signatures | ||
Multi-Chain Support | EVM chains via CAIP-10 | Any chain in CAIP-10 (EVM, Bitcoin, Solana, etc.) |
Standard Governance | ERC-1056 (Ethereum Foundation) | W3C Community Group (WalletConnect, Spruce) |
DID:ethr vs DID:pkh: Ethereum-Centric DID Methods
A technical breakdown of two dominant Ethereum-based DID methods. Choose based on your protocol's need for on-chain governance versus maximum wallet compatibility.
DID:ethr: On-Chain Governance
Key Strength: DID documents are stored and updated directly on the Ethereum blockchain (or L2s like Arbitrum, Optimism). This provides immutable, censorship-resistant control over public keys and service endpoints. Ideal for protocols requiring provable, on-chain identity states, such as DAO membership credentials or decentralized legal agreements.
DID:ethr: Transaction Overhead
Key Weakness: Every DID document update (e.g., key rotation) requires an on-chain transaction, incurring gas fees and latency. This makes it costly for high-frequency identity operations and impractical for users not holding ETH for gas. A significant trade-off for applications needing agile identity management.
DID:pkh: Zero-Cost Simplicity
Key Strength: No on-chain transactions or registry contracts are needed. The DID is derived cryptographically from the user's existing blockchain account. This enables instant, free DID creation for every user, eliminating a major barrier to entry for mass-market consumer applications.
DID:pkh: Limited On-Chain Attestations
Key Weakness: Lacks a native, standardized method for on-chain DID document updates or complex attestations. While great for authentication, it's less suited for sophisticated credential ecosystems (like Verifiable Credentials with revocation registries) that require stateful, updatable DID documents managed by smart contracts.
DID:ethr vs DID:pkh: Ethereum-Centric DID Methods
Key strengths and trade-offs for two primary Ethereum-based Decentralized Identifier methods.
DID:ethr: Enterprise & Interoperability
Standardized for complex identity: Built on the W3C DID Core spec and ERC-1056 (EthereumDIDRegistry). This matters for enterprise adoption and integrating with broader SSI ecosystems like Verifiable Credentials (VCs).
DID:ethr: On-Chain Management
Full on-chain control: DID documents are updated via smart contract transactions, providing a transparent, immutable audit trail. This matters for high-stakes, compliant identity where proof of key rotation or delegation is required.
DID:pkh: Simplicity & Ubiquity
Zero-cost, instant creation: A DID is derived directly from a wallet's public key hash (e.g., did:pkh:eip155:1:0xabc...). This matters for mass-market dApps where user onboarding friction must be eliminated.
DID:pkh: Cross-Chain Native
Inherent multi-chain design: The PKH method natively supports chains via CAIP-10/CAIP-2 (e.g., eip155:1, bip122:000000000019d668). This matters for wallet-centric apps operating across Ethereum, Bitcoin, Solana, and other L1s.
DID:ethr: Higher Friction & Cost
Gas fees for management: Every key rotation or service endpoint update requires an on-chain transaction and gas. This is a significant barrier for high-volume, low-margin applications.
DID:pkh: Limited Functionality
No native attestations: The method defines only the identifier, not a full DID document with service endpoints or key management capabilities. This limits its use for complex credentialing or decentralized messaging without additional layers.
When to Choose Which: A Use-Case Analysis
DID:ethr for DeFi & DAOs
Verdict: The default choice for on-chain governance and sophisticated smart contract integration. Strengths: Native integration with Ethereum accounts (EOAs and smart contract wallets like Safe). Directly binds to an on-chain registry, enabling verifiable, revocable credentials for Sybil resistance, KYC proofs, and voting power delegation. Works seamlessly with standards like EIP-712 for signed messages and EIP-1271 for contract signatures. Trade-off: Requires paying gas fees for DID document updates and resolution, which can add up for large user bases.
DID:pkh for DeFi & DAOs
Verdict: A pragmatic, low-friction alternative for lightweight identity linking.
Strengths: Zero-cost creation and resolution, as it's a deterministic method based on a public key hash. Ideal for associating multiple wallet addresses (e.g., from Ethereum, Polygon, Arbitrum) under a single, chain-agnostic DID for basic reputation or whitelisting without on-chain transactions.
Trade-off: Locks you into the pkh method's limited, static document structure. No built-in support for key rotation, service endpoints, or revocation without moving to a different DID method.
Cost Analysis: Gas Fees and Operational Overhead
Direct comparison of operational costs for Ethereum-centric Decentralized Identifier methods.
| Metric | DID:ethr (Ethereum) | DID:pkh (EIP-155) |
|---|---|---|
On-Chain Creation Cost | $5 - $50+ | $0 |
On-Chain Update Cost | $5 - $50+ | $0 |
Primary Cost Driver | Ethereum L1 Gas | Off-Chain Signatures |
Key Management Standard | EIP-191 / EIP-712 | CAIP-10 / EIP-155 |
Requires Smart Contract | ||
Supports Key Rotation | ||
Native Multi-Chain Support |
Final Verdict and Decision Framework
A decisive breakdown of when to choose the enterprise-grade DID:ethr versus the wallet-native DID:pkh for your identity layer.
DID:ethr excels at providing a robust, enterprise-ready identity standard anchored to the full security and programmability of the Ethereum mainnet. Its use of on-chain Ethereum Attestation Service (EAS) registries and ERC-1056 standard allows for complex, verifiable credentials and delegated key management, making it ideal for regulated applications like KYC/AML or corporate credentials. For example, its integration with Veramo and Spruce ID frameworks provides a mature toolchain for developers building sophisticated identity systems.
DID:pkh takes a fundamentally different approach by leveraging the user's existing blockchain account (Public Key Hash) as their DID, prioritizing seamless user onboarding and interoperability across ecosystems. This results in a key trade-off: while it offers near-zero friction for users of wallets like MetaMask or Rainbow and works across chains (Ethereum, Polygon, Solana via CAIP-10), it provides less inherent infrastructure for complex attestations or key rotation without additional layers, making it more suitable for lightweight, user-centric applications.
The key trade-off is between control/complexity and adoption/simplicity. DID:ethr transactions incur mainnet gas fees (e.g., ~$2-10 for registry updates), a cost justified for high-stakes credentials. DID:pkh generates a DID instantly with no transaction cost, but its verification relies on the security of the connected wallet's chain.
Choose DID:ethr if your priority is a sovereign, feature-rich identity system for applications requiring complex attestations, regulatory compliance, or advanced key management. It is the definitive choice for enterprise DeFi, professional credentialing, and any scenario where the identity itself is a valuable, mutable asset.
Choose DID:pkh if your priority is maximum user adoption and cross-chain portability for consumer dApps, social platforms, or NFT communities. It is the superior alternative for projects where reducing onboarding friction is critical and where identity is used primarily as a lightweight, persistent identifier across interactions.
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.