ERC-1056

• Name: ERC-1056 (Ethereum Lightweight Identity / EthereumDIDRegistry / did:ethr)
• URL: https://eips.ethereum.org/EIPS/eip-1056
• Category: DID registry standard / lightweight identity-controller primitive / key-and-attribute registry
• Summary: ERC-1056 is best understood not as a full identity product or credential system, but as a lower-layer controller registry for Ethereum-native identifiers. Its core move is to treat any Ethereum account as a usable identity by default, then add a shared onchain registry for owner rotation, typed delegates, and expiring attributes that can be resolved into a DID document offchain. That makes ERC-1056 a useful comparison class for later identity and attestation systems because it separates five layers that later products often flatten together: free identifier creation, controller rotation, delegated signing authority, attribute publication, and resolver-side DID-document assembly. In practice, the real control surface sits in registry deployment/version choice, resolver/indexer behavior, application-defined delegateType and attribute naming, and the one-owner model that sits beneath more complex multisig or contract-based control.
• What it does:
  • Treats any Ethereum address as a valid identity without requiring a registration transaction
  • Defines a shared EthereumDIDRegistry contract with owner lookup and owner-rotation functions
  • Lets an identity add and revoke typed delegates with explicit expiration times so different keys can act on its behalf for specific purposes
  • Lets an identity publish and revoke arbitrary attributes, including service endpoints or public-key material interpreted by higher-layer DID tooling
  • Supports signed versions of owner / delegate / attribute updates so third parties can fund transactions on behalf of the identifier owner
  • Uses linked events and resolver logic to reconstruct DID state and DID documents offchain instead of storing full documents onchain
  • Supports did:ethr resolution across multiple EVM networks, with chain-specific DID forms and registry addresses
• Key claims:
  • The strongest analytical move in the ERC is that identity creation is free because the identifier is just an Ethereum account. The registry only becomes necessary when the subject wants rotation, delegation, or richer public metadata.
  • The spec is explicit that ERC-1056 was motivated by the cost and friction of contract-based identity registration in earlier schemes such as ERC-725. That makes it a lower-bound comparison point for later identity systems that add more structure but lose the no-registration property.
  • ERC-1056 is especially useful because it separates controller authority from signer authority. The owner can stay fixed or rotate, while delegates of higher-layer, application-defined types can handle specific offchain or protocol tasks for limited time windows.
  • The event model is a key part of the mechanism. The registry stores ownership, delegate, and attribute changes as events, and the DID document is then reconstructed by following those events rather than by reading a single canonical document blob onchain.
  • The ethr-did-resolver materials make the next control surface explicit: resolver libraries decide how registry events become DID-document entries, including multi-network naming, verification-method typing, and default document construction when no registry events exist.
  • The registry README also exposes an important operational caveat: many published deployments are older contract versions, while newer behavior depends on tool and deployment adoption. So practical authority sits not only in the standard, but in whichever registry deployments and resolver defaults applications actually trust.
  • ERC-1056 is marked Stagnant, which makes it analytically useful in a second way: it shows how a nominally simple identity primitive can remain influential through resolver libraries and deployed registries even when the standard itself is no longer actively advancing.
  • ERC-1056 belongs in the corpus because it gives the identity cluster a clean lower-layer comparison point beneath attestation systems, profile graphs, and credential wallets. It makes explicit where authority sits before any credential is issued: in the controller address, delegate policy, attribute naming, resolver implementation, and chain-specific registry deployment.
• Whitepaper: No standalone ERC-1056 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the ERC text, the raw ERC markdown, the Ethereum DID Registry README, and the did:ethr method specification collected in ../../whitepapers/erc-1056-primary-sources-2026-05-13.md.
• Sources:
  • https://eips.ethereum.org/EIPS/eip-1056
  • https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-1056.md
  • https://github.com/uport-project/ethr-did-registry
  • https://raw.githubusercontent.com/uport-project/ethr-did-registry/develop/README.md
  • https://github.com/decentralized-identity/ethr-did-resolver
  • https://raw.githubusercontent.com/decentralized-identity/ethr-did-resolver/master/doc/did-method-spec.md

Surface split

• Onchain surface: the shared EthereumDIDRegistry, owner rotation, delegate expiry, signed registry updates, and emitted registry events are the direct protocol surfaces a verifier or resolver can inspect.
• Offchain surface: resolver defaults, indexer completeness, chain-specific registry selection, attribute naming conventions, and application-specific delegateType semantics determine what a did:ethr identity actually means in practice.
• Useful comparison lens: ERC-1056 deliberately keeps identity thin at the registry layer, so most downstream trust still migrates into wallets, resolver libraries, app policy, and higher-layer credential systems.

Internal linkages

• Closest account-possession descendants: did-pkh and caip-122.

• Higher-layer attestation systems that actually add issuer, schema, or verification rails: ethereum-attestation-service and sign-protocol.

• Reusable question: is the product really giving you a controller registry, or a fuller credential graph built on top of one?

• Last reviewed: 2026-06-03 UTC