Cowrie Research

erc-1056-primary-sources-2026-05-13

5 min read

ERC-1056 primary sources

Reviewed: 2026-05-13 UTC

Primary source set

  1. ERC text: https://eips.ethereum.org/EIPS/eip-1056
  2. Raw ERC markdown: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-1056.md
  3. Ethereum DID Registry README: https://raw.githubusercontent.com/uport-project/ethr-did-registry/develop/README.md
  4. did:ethr method spec: https://raw.githubusercontent.com/decentralized-identity/ethr-did-resolver/master/doc/did-method-spec.md
  5. Resolver repo: https://github.com/decentralized-identity/ethr-did-resolver

Why this entry clears the bar

ERC-1056 is a useful lower-layer identity primitive because it separates:

  • identifier creation from registry interaction
  • controller rotation from delegated signing authority
  • application-specific delegate semantics from base registry logic
  • attribute publication from credential issuance
  • onchain state/events from offchain DID-document assembly

That decomposition is analytically reusable across DeDi, Next.ID, cheqd, attestation registries, and later proof-of-personhood / profile systems.

Key excerpts and notes

1) Free identity creation is the first mechanism split

From the ERC abstract:

“Identity creation is as simple as creating a regular key pair ethereum account, which means that it’s free (no gas costs) and all ethereum accounts are valid identities.”

Why it matters:

  • ERC-1056 is not primarily a registration system. It uses the existing account layer as the identity layer.
  • The registry is only needed when subjects want rotation, delegates, or attributes.
  • This makes ERC-1056 a lower-bound comparison point against heavier identity contracts such as ERC-725-style systems.

2) The registry standardizes owner rotation, delegates, and attributes

From the raw ERC:

“This ERC specifies a contract called EthereumDIDRegistry that is deployed once and can then be commonly used by everyone.”

It defines:

  • identityOwner(address identity)
  • changeOwner(...) / changeOwnerSigned(...)
  • addDelegate(...) / addDelegateSigned(...)
  • revokeDelegate(...) / revokeDelegateSigned(...)
  • setAttribute(...) / setAttributeSigned(...)
  • revokeAttribute(...) / revokeAttributeSigned(...)

Why it matters:

  • The spec does not define a full wallet or credential stack.
  • It standardizes the control plane beneath those systems.
  • The signed variants make meta-transaction and third-party-funded update flows part of the primitive.

3) Delegate semantics are intentionally left to higher layers

From the ERC definitions:

“delegateType: the type of a delegate, is determined by a protocol or application higher up”

Examples given in the ERC include did-jwt and raiden.

Why it matters:

  • ERC-1056 does not decide what a delegate means.
  • Applications, resolvers, and higher-layer protocols decide which delegate types matter.
  • That means real control can migrate upward into resolver defaults and application acceptance policy, even when the base registry is shared.

4) DID documents are assembled from events, not stored whole onchain

From the ERC:

“By using linked events that always link to the previous block with a change for the identity, we can solve this problem with much improved performance.”

And:

“Iterate through the DIDDelegateChanged events to build a list of additional keys and authentication sections as needed.”

Why it matters:

  • ERC-1056 is partly an event-graph design, not just a contract-interface design.
  • Indexers and resolvers become part of the effective trust/control surface.
  • This makes ERC-1056 comparable to later systems where the canonical object is reconstructed by indexers rather than read from one definitive storage slot.

5) The registry README makes the offchain-auth and smart-account use case explicit

From the Ethereum DID Registry README:

“It’s designed for resolving public keys for off-chain authentication—where the public key resolution is handled by using decentralized technology.”

And:

“This contract allows Ethereum addresses to present signing information about themselves with no prior registration. It allows them to perform key rotation and specify different keys and services that are used on its behalf for both on and off-chain usage.”

Why it matters:

  • The main primitive is public-key and service discovery for offchain authentication, not an all-purpose social identity product.
  • ERC-1056 is especially useful beneath login, messaging, credential, and wallet-delegation systems.

6) The did:ethr method spec shows how much power sits in resolver logic

From the method spec:

“The DID document is built by using read only functions and contract events on the ERC1056 registry.”

And:

“This DID method allows any Ethereum smart contract or key pair account, or any secp256k1 public key to become a valid identifier. Such an identifier needs no registration.”

And:

“Multi-network DIDs are also supported”

Why it matters:

  • The registry is only half the mechanism; resolver policy turns registry events into DID-document structure.
  • Network naming, registry-address configuration, and verification-method typing all become practical control surfaces.
  • Multi-network support also means one nominal method splinters into chain-specific operational contexts.

7) Operational caveat: the live deployment set is old and versioned

From the registry README:

“Most of these are deployments of version 0.0.3 of the contract and they do not include recent updates.”

Why it matters:

  • A standard can remain important even when implementation/version drift grows.
  • In practice, adoption depends on which contract deployments, chain presets, and resolver packages wallets and apps actually ship.
  • That makes ERC-1056 a useful example of standards influence persisting through tooling and deployed infrastructure rather than through formal spec momentum alone.

8) Status signal matters

The ERC page marks ERC-1056 as:

  • Status: Stagnant

Why it matters:

  • ERC-1056 is still useful because its lower-layer ideas and deployments shaped did:ethr resolution even without strong current standards momentum.
  • This makes it a good historical and architectural comparison point rather than a bet on the newest identity narrative.

Working comparison hooks

Useful next-pass comparisons:

  • ERC-1056 vs ERC-725 / smart-contract identity contracts
  • ERC-1056 vs DeDi / trust-directory publication layers
  • ERC-1056 vs Next.ID / identity graph and profile synthesis
  • ERC-1056 vs cheqd / DID-method and credential infrastructure
  • ERC-1056 vs attestation registries such as EAS, Sign Protocol, BAS, and Attestation Station
  • ERC-1056 vs proof-of-personhood layers that sit above controller/key rotation

Corpus placement

Suggested cluster:

  • Identity / attestation / social graph primitives
  • Or a narrower future subcluster: DID registry / controller primitives

Graph View