The Identity Chain: EID
What It Is
EID stands for Elastos Identity Chain. Technically, it is a fork of go-ethereum (the same family of software that powers the Elastos Smart Chain), but it is tuned for one job: storing and resolving decentralized identifiers (DIDs) and their documents, not for general-purpose DeFi or app logic.
The network uses Chain ID 22, so wallets and tools must point at EID explicitly; it is not the same chain as ESC or the Elastos main chain.
If you are comparing to “Ethereum-like” networks: EID still speaks EVM for these identity operations, but you should assume different chain parameters, RPC endpoints, and predeployed system contracts than on ESC. Always use an EID-capable provider when testing DID flows.
EID uses PBFT-style consensus operated by the 12 Elastos Council members who run the full supernode stack (ELA + all sidechains). That alignment means identity updates benefit from deterministic, fast finality: once a block is committed by the PBFT quorum, you do not wait many confirmations to treat a DID publication as settled. For users, that feels closer to “instant” than proof-of-work style chains.
DID-Specific Precompiled Contracts
Standard Ethereum has a small set of “precompiles”: built-in contracts at fixed addresses that the client executes natively for efficiency. EID extends that idea with three DID-specific precompiled contracts:
| Address (decimal) | Address (hex) | Role |
|---|---|---|
| 22 | 0x16 | operationDID: performs DID write operations — create, update, and deactivate DIDs. Each operation requires a valid P-256 proof. |
| 23 | 0x17 | resolveDID: accepts a DID string (for example did:elastos:icJ4z2DULrHEzYSvjKNJpKyhqFDxvYV7pN) and returns the full DID document: JSON describing public keys, authentication methods, service endpoints, and related metadata. |
| 2007 | 0x7D7 | kyc: KYC (Know Your Customer) verification operations. |
Putting resolution and listing in the protocol layer keeps hot paths (especially reads) efficient and consistent across every node. Developers still interact through familiar EVM and JSON-RPC surfaces, but the heavy lifting is optimized inside the client.
How DID Documents Are Stored
Publishing a DID is not a mysterious side process: it is an ordinary EVM transaction that invokes the appropriate precompile. The precompile parses the DID document, validates signatures according to the rules of the document, and then persists the result in structured storage:
DIDLog: the authoritative record of DID operations and state as applied on-chain.- A LevelDB-backed index: for fast lookup and query paths the node uses when serving resolution.
That split (canonical log + indexed store) is why resolution can stay responsive even as the number of registered identities grows.
Resolving DIDs Over JSON-RPC
Clients and SDKs do not have to craft low-level contract calls for every integration. Nodes expose a dedicated JSON-RPC method:
did_resolveDID: resolve a DID string to its document through the node’s RPC API.
Behind the scenes this ties into the same resolution rules the precompiles enforce, so wallets, backends, and scripts get a single, well-defined interface.
Write-Once, Read-Many: Why a Separate Chain?
Identity data has a different access pattern than typical smart-contract state:
- Registrations and updates are relatively infrequent writes.
- Reads (resolution, discovery, verification) happen constantly, from wallets, storage services, dApps, and oracles.
That is a classic write-once, read-many workload. Putting it on a dedicated chain:
- Isolates identity traffic from congestion on chains dominated by contract calls and token transfers.
- Lets the protocol optimize for fast, predictable lookups and stable finality for identity events.
- Keeps a clear security and governance boundary: identity is a shared root of trust for the whole ecosystem.
Public Endpoints
For the complete list of EID RPC endpoints (including alternate providers), see Network Endpoints. The usual Elastos-hosted defaults are https://api.elastos.io/eid (mainnet) and https://api-testnet.elastos.io/eid (testnet).
Always verify the exact path and TLS requirements in your client’s documentation; treat these as service URLs your app configures, not as user-facing “websites.”
How It Connects
EID sits at the center of a practical identity stack, understandable without reading every repo:
- EID ↔ DID SDKs: Language SDKs (JavaScript, Java, C, Swift, and others) wrap DID creation, updates, and resolution so apps do not hand-roll cryptography or RPC details.
- DID SDKs ↔ Essentials: The Essentials wallet holds keys and signs DID operations; users approve identity actions in a familiar wallet flow.
- Essentials ↔ Hive: Hive decentralized storage uses DID-based authentication; your identity proves which vault and files you control without a corporate login server.
- EID ↔ ESC (ELink): On the smart-contract side, the ELink oracle can read DID-related data from EID so contracts can react to verifiable identity state in a controlled way.
DID documents on EID are generally public (that is how global resolution works). What stays private are verifiable credentials and selective disclosures; the holder chooses when and with whom to share claims about themselves.
Together, these pieces mean one identity layer can anchor wallets, storage access, and on-chain logic without duplicating identity databases across every product team.
What Readers and Builders Should Expect
Non-technical readers can remember EID as the public phone book for machine-readable identity: your wallet helps you sign updates; the chain holds the latest agreed document anyone can look up.
Developers should expect:
- Publishing a DID is a transaction with fees and finality; plan for retries, error handling, and testnet rehearsal.
- Resolution is the high-frequency path: cache responsibly in apps, but treat the chain as source of truth when freshness matters.
- Interoperability flows through SDKs and RPC first; direct precompile interaction is for advanced tooling or protocol work.
Use the testnet endpoint when iterating on DID document shape, key rotation, or service endpoints. Identity mistakes are less costly there, and you still exercise the same resolution and validation rules.