did:ethr
Identity Protocol
Comunidade
Links
Detalhes
Licença Permissive (Apache-2.0) — ethr-did-resolver and ethr-did libraries at https://github.com/decentralized-identity/ethr-did-resolver; ERC-1056 registry contract published openly
Status de Dev 🟢 Ativo
Proprietário Decentralized Identity Foundation ecosystem — specification contact listed in the W3C registry is Mircea Nistor. Lineage runs from uPort through Consensys Mesh to the Veramo project; the ethr-did-registry contract and ethr-did-resolver are community-maintained
Órgão de Governança DIF (resolver maintenance) | Ethereum EIP/ERC process (ERC-1056) | None (the deployed registry contract is immutable with no admin key or upgrade path)
País International — contributor base spans Europe and the USA; the underlying chains are jurisdiction-independent
Ano de Início 2018
Stack Solidity (ERC-1056 EthereumDIDRegistry contract); TypeScript/JavaScript (ethr-did-resolver, ethr-did); resolver implementations in other languages available
Financiamento Community-maintained — originally funded through uPort/Consensys; now maintained by DIF community contributors and the Veramo project. No dedicated funding entity
Última Investigação 1 de jul. de 2026
Identity Protocol Atributos
Origins Ethereum identity / uPort — created to give every Ethereum account a usable decentralized identifier without requiring a transaction or new infrastructure, addressing the cost and friction of on-chain identity registration
Database ERC-1056 EthereumDIDRegistry smart contract — an event-log-based registry rather than a document store; DID documents are reconstructed by replaying DIDOwnerChanged, DIDDelegateChanged and DIDAttributeChanged events
Query Language Ethereum JSON-RPC event log queries — the resolver reads registry events for the address and replays them; no separate query language
Data Formats W3C DID Document reconstructed from registry events; identifier is an Ethereum address with an optional chain namespace (did:ethr:<chain>:0x...); attributes encoded as bytes32 keys in registry events
Mobile Support Library-level — implemented inside resolver libraries and wallets; no standalone application
Web Support Library-level — resolution runs over Ethereum JSON-RPC; the DIF Universal Resolver additionally exposes an HTTPS endpoint
Native Apps Library-level — embedded in resolver libraries; no standalone application
Terms Free to create and resolve — an unregistered address resolves to a valid default DID document at zero cost. Gas fees apply only for optional on-chain updates such as key rotation, delegate addition or service endpoints
Funds N/A — no funding entity attached to the method; the deployed contract has no operating cost
Based On W3C DID Core 1.0; ERC-1056 Ethereum Lightweight Identity Registry; Ethereum and EVM-compatible chains; secp256k1 key material. Ancestor of Verida's did:vda, which began as a fork of ethr-did-resolver
Permissions Cryptographic and delegation-based — owner key controls the identifier; delegates may be granted time-bounded authority for specific purposes, all recorded on-chain
Authentication & Identity Address-derived by default, with optional on-chain delegation — control begins as possession of the Ethereum private key, and can be extended through registry-recorded owner changes and delegate assignments, allowing key rotation without changing the identifier
Storage Model On-chain event log — no DID document is stored anywhere; state is derived by replaying registry events. Unmodified identifiers require no storage at all
Interoperability Broad EVM coverage — the registry contract is deployed on Ethereum mainnet and many EVM chains, with a chain namespace in the identifier; supported in the DIF Universal Resolver, Veramo, and most EVM-oriented SSI tooling. Compatible with W3C VCs and EIP-4361 sign-in flows
Data Portability Chain-bound — an identifier includes its chain namespace, so it cannot be moved between chains without becoming a different DID, though the same underlying key can control identifiers on several chains
Governance & Decision Making Open standard with immutable deployment — ERC-1056 went through the public EIP process; the deployed registry contract has no admin function, no owner and no upgrade mechanism, so governance over existing identifiers is effectively absent by construction. Resolver maintenance is community-governed under DIF
Protocol Maturity / Standardization Registered W3C DID method built on a published ERC, with roughly eight years of production use, mature Apache-2.0 tooling, and DIF Universal Resolver support. The method specification is a community document rather than a W3C Recommendation; ERC-1056 is the more formal artifact
Identity Standards W3C DID Core 1.0; ERC-1056; compatible with W3C Verifiable Credentials and EIP-4361 (Sign-In with Ethereum, already on the SCS tab in this file); registered in the W3C DID Extensions methods registry
DID Methods Supported did:ethr (defines this method), with chain-namespaced variants across EVM networks
Key Management On-chain rotation and delegation — owner changes and time-bounded delegates are recorded as registry events, giving verifiable key history without changing the identifier. This is the principal advantage over deriving identity from a raw address alone
Credential Types N/A — a DID method specification; defines no credential types. Compatible with W3C Verifiable Credentials issued against identifiers of this method
Verification Method Event replay against the chain — the resolver reconstructs the current document from registry history, with correctness resting on the underlying chain's consensus. Default documents require no chain read of registry state beyond confirming absence of events
Privacy Features Weak — an Ethereum address is a public, highly correlatable identifier already linked to on-chain financial activity, and any registry updates are permanently public. Pairwise use is possible by generating fresh addresses, but the method offers no privacy features of its own
Authentication Methods secp256k1 signature by the controlling key or an authorised delegate; commonly paired with EIP-4361 Sign-In with Ethereum for session authentication
Revocation Mechanism Registry events — delegates are time-bounded and expire automatically; owner changes supersede prior control; attribute revocation is recorded as an event. Full history remains publicly auditable
Agent Types Supported Any key-controlling entity — individuals, organizations, services and devices
Wallet/Client Types SDK / library integration — resolver implementations across the SSI tooling ecosystem; no method-specific wallet
Recovery Mechanisms Owner transfer via the registry — the current owner can assign a new owner, enabling recovery patterns including multisig or smart-contract-account control. If the controlling key is lost with no prior delegation, no recovery is possible
Compliance / Regulations Not addressed by the method. Public correlatability of Ethereum addresses is a material consideration under data-protection regimes, since an address plus registry history is durable, non-erasable personal data where it maps to an individual
Credential Exchange Protocols DIDComm, OpenID4VC, and any W3C DID-resolving protocol; widely used with Veramo tooling and with EIP-4361 web sign-in flows
Trust Framework Blockchain consensus with no administrator — the registry contract is immutable and permissionless, so there is no operator, foundation or governance body able to alter or revoke identifiers
Cost Model Free for creation and resolution of default identifiers; gas fees on the host chain for optional updates. Cost varies with chain, which is why EVM L2 deployments are common
Censorship Resistance High — the registry contract is immutable with no admin key, resolution is a permissionless chain read, and default identifiers require no transaction at all, so there is nothing to block. Constrained only by access to a node or RPC endpoint for the host chain