zkMe Identity Chain
The zkMe Identity Chain is a Layer 1 EVM-compatible blockchain purpose-built for decentralized identity. It serves as the single source of truth for all identity data within the zkMe Protocol, housing credential smart contracts, anchoring DID registries, and managing a decentralized storage network where encrypted credentials are persisted. Every proof generated by the Credential System, every DID registered by a Holder or Agent, and every verification event recorded by a Verifier ultimately settles on this chain.
In the Agent Economy, the Identity Chain plays a particularly critical role. AI agents require a tamper-proof, always-available identity layer that can process high-frequency verification requests with low latency. Traditional general-purpose blockchains introduce unpredictable gas costs and confirmation delays that are incompatible with real-time agent interactions. The zkMe Identity Chain addresses this by providing instant finality, sub-second block times, and a purpose-built storage layer optimized for identity payloads.
Why a Dedicated Identity Chain
General-purpose blockchains are designed to serve a broad range of applications, from DeFi to gaming to NFTs. This generality comes at a cost: identity workloads must compete with unrelated transactions for block space, gas prices fluctuate based on network congestion from other applications, and storage models are optimized for financial state rather than credential data.
The zkMe Identity Chain eliminates these trade-offs by dedicating the entire chain to identity operations. The following table summarizes the key advantages:
Block space contention
Identity transactions compete with DeFi, NFT, gaming traffic
100% of block space reserved for identity operations
Gas price predictability
Volatile, driven by unrelated demand spikes
Stable, driven only by identity workload
Storage model
Optimized for account balances and token state
Optimized for credential payloads with S3-compatible APIs
Finality
Varies (seconds to minutes depending on chain)
Instant finality per block
Data residency
No native support
Geolocation-specific storage via Storage Provider selection
Validator incentives
Aligned with general transaction throughput
Aligned with data integrity, availability, and identity verification
Architecture
The zkMe Identity Chain is built on the CometBFT (Cosmos/Tendermint) framework with EVM compatibility based on EVMOS. This architecture combines the instant finality and modular consensus of the Cosmos ecosystem with full Ethereum tooling compatibility, allowing developers to deploy existing Solidity smart contracts using Hardhat, Foundry, Remix, and MetaMask without modification.
The architecture comprises two interconnected components:
EVM-Compatible Blockchain. The execution layer runs the LONDON instruction set with support for select SHANGHAI opcodes (EIP-3855, EIP-3860, EIP-1153, EIP-5656, EIP-6780). All credential and identity smart contracts, including the State Contract, Verifier contracts, and Delegate contracts referenced throughout the zkMe documentation, are deployed on this layer. Because the chain uses a Cosmos SDK account model, it operates exclusively with EVM addresses (e.g., 0x1234...7890), simplifying wallet integration for both human users and AI agents.
Decentralized Storage Providers (DSP). The storage layer is a network of independent Storage Providers that store the actual credential payloads (encrypted identity data, Merkle tree nodes, revocation status). Validators on the chain store metadata and financial ledgers with consensus, while Storage Providers handle the data itself. This separation ensures that credential data availability is consistent with chain uptime, storage is distributed across independent providers for resilience, and geolocation-specific storage is supported for data residency requirements.
Consensus Mechanism
The zkMe Identity Chain uses a Proof-of-Stake (PoS) mechanism based on CometBFT consensus. Validators stake the native gas token to participate in block production, with the probability of being selected as block proposer proportional to their stake. Blocks are produced every approximately 1 second with instant finality, meaning that once a block is committed, it cannot be reverted.
The consensus process follows three voting rounds:
Prevote. Validators receive a block proposal and broadcast their initial vote.
Precommit. If more than two-thirds of validators (by stake weight) prevote for the same block, they proceed to precommit.
Commit. If more than two-thirds precommit to the block, it is finalized and appended to the chain.
This BFT (Byzantine Fault Tolerant) property means the network tolerates up to one-third of validators being faulty or offline without halting. Malicious behavior such as double-signing results in automatic slashing of staked tokens.
Validator Responsibilities
Validators on the zkMe Identity Chain have responsibilities beyond standard block production:
Data Integrity Enforcement. Validators challenge the availability and integrity of data stored by Decentralized Storage Providers. They can issue random or targeted challenges to detect underperforming or malicious providers. Providers that fail challenges face stake slashing.
Network Governance. Validators participate in on-chain governance decisions, including parameter adjustments, protocol upgrades, and the approval of new Storage Providers joining the network.
Decentralized Storage Layer
The Decentralized Storage Provider (DSP) network is the persistence layer for all credential data. Storage Providers operate independently, each maintaining a local full node for direct connection to the chain. They expose S3-compatible APIs for data upload, download, and management, making integration straightforward for developers familiar with cloud storage patterns.
How Storage Works
Storage Providers must register by depositing a stake on the Identity Chain. Validators then conduct a governance vote to approve the provider. Once approved, the provider enters active service and begins handling data requests.
Key mechanisms that ensure data reliability:
Virtual Groups. Storage Providers organize data into virtual groups for replication across multiple providers. This ensures that if one provider goes offline, data remains available from other providers in the same virtual group.
Integrity Proofs and Challenges. Validators periodically challenge Storage Providers to prove they still hold the data they claim to store. Providers must respond with cryptographic integrity proofs. Failed challenges result in penalties.
Lifecycle Management. Storage Providers follow a structured lifecycle: Proposal (staking and governance approval), In Service (active data handling), Maintenance (temporary offline for upgrades), and Exit (graceful data migration to successor providers or forced exit with penalties).
Storage Provider Architecture
Each Storage Provider runs a modular architecture with the following core components:
Gater
HTTP gateway implementing S3-compatible protocol
Authenticator
Verifies client authentication for data requests
Uploader
Handles object upload requests, stores payload data
Downloader
Handles object retrieval and challenge response requests
Receiver
Receives replicated data from primary provider, computes integrity hash
Signer
Manages all cryptographic signing operations for the provider
Metadata
Provides query interfaces for object and bucket metadata
BlockSyncer
Synchronizes block data from the Identity Chain
PieceStore
Interfaces with underlying storage backends (S3, MinIO, OSS)
EVM Compatibility
The zkMe Identity Chain is developed on EVMOS (Cosmos EVM), providing full Ethereum Virtual Machine compatibility. Developers can write and deploy the same Solidity smart contracts on the Identity Chain and other EVM-compatible blockchains without code modifications. This compatibility extends to all standard Ethereum tooling:
Hardhat
Full support
Foundry
Full support
Remix
Full support
MetaMask
Full support
ethers.js / web3.js
Full support
The EVM currently runs the LONDON instruction set with support for the following SHANGHAI opcodes:
EIP-3855
PUSH0 instruction
EIP-3860
Limit and meter initcode
EIP-1153
Transient storage opcodes
EIP-5656
MCOPY instruction
EIP-6780
SELFDESTRUCT restriction
Because the chain uses a unified account model (Cosmos SDK accounts mapped to EVM addresses), the native gas token and EVM gas token are the same currency managed by the same bank keeper module. This eliminates the dual-token complexity found in some Cosmos EVM implementations.
Performance Specifications
Block Time
Approximately 1 second
Finality
Instant (single-block finality)
Max Transactions per Block
2,400
Max Block Size
3 MB
Block Gas Limit
4,294,967,295
Unbonding Time
21 days
Consensus
CometBFT Proof-of-Stake
EVM Compatibility
Full (EVMOS-based)
Cosmos SDK
v0.50.13
Network Information
For network connection details (RPC endpoints, block explorers, and faucets), contact the zkMe team or refer to the developer portal.
Role in the Agent Economy
The zkMe Identity Chain is the settlement layer for all agent identity operations. When an AI agent presents credentials to a Verifier, the zero-knowledge proof is verified against state commitments anchored on this chain. When a Holder delegates authority to an agent via the Agent Principal Credential, the delegation binding is recorded on this chain. When a Verifier checks a nullifier to prevent duplicate claims, the nullifier registry lives on this chain.
The chain’s instant finality is particularly important for agent workflows. Unlike human users who can tolerate a few seconds of confirmation delay, AI agents operating in automated pipelines (such as x402 payment flows or multi-step DeFi strategies) require deterministic, sub-second settlement. The Identity Chain’s 1-second block time with instant finality ensures that credential verification never becomes a bottleneck in agent execution flows.
The Decentralized Storage Provider network also plays a direct role in agent operations. Agent credentials, delegation records, and session audit logs are all persisted in the DSP network, ensuring that this data remains available even if individual storage providers go offline. For regulated use cases, the geolocation-specific storage capability allows enterprises to ensure that agent identity data is stored in compliance with jurisdictional data residency requirements.
Last updated