> ## Documentation Index
> Fetch the complete documentation index at: https://docs.air3.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Why Moca Chain?

> What differentiates Moca Chain — sub-second identity flows, consumer-scale capacity, EVM compatibility, MCSP storage, ZK privacy, and cross-chain proofs.

> *Moca Chain is a Layer 1 EVM-compatible blockchain purpose-built for decentralized identity, enabling chain-agnostic identity data issuance and verifications.*

## Sub-second identity flows

CometBFT consensus, 1-second blocks, instant finality. Age checks, KYC gates, and logins commit in a single block, so identity flows feel synchronous to the end user.

## Consumer-scale capacity

800 transactions per block and a 60,000,000 gas limit. Moca Chain handles ZK verifier contracts and batched credential issuance at full production volume, not just testnet workloads.

## Builder-ready

Moca Chain is fully EVM-compatible and supports transient storage (EIP-1153) along with other Shanghai opcodes. Existing Solidity contracts port over with little to no rewrite, and standard Ethereum tooling (Hardhat, Foundry, Remix, MetaMask) works as is. Integration moves from quarters to days.

## Decentralized credential storage (MCSP)

Moca Chain stores credentials in the Moca Chain Storage Provider network (MCSP), a decentralized storage layer with S3-compatible APIs:

* Data availability tracks chain uptime
* Storage is distributed across independent providers for resilience
* Confirm provider locations and regional commitments for your data residency requirements
* Issuers retain source records and signing keys, while encrypted credential payloads are stored with independent providers under holder-controlled decryption

## Privacy by construction

Privacy is built into the protocol:

* **Zero-knowledge proofs:** Verify claims without exposing data (e.g., prove you are over 18 without sharing your birthday). Moca Chain currently uses Circom circuits with Groth16.
* **Program-controlled disclosure:** Verification Programs define requested claims and optional ZK proofs. Users approve what they disclose.
* **Encrypted credential storage:** Raw source documents remain with the issuer. Encrypted credential payloads may be stored in DStorage, while users control decryption and disclosure.
* **zkTLS:** Enables secure onboarding from web sources while keeping information encrypted and user-authorized.

## Verify once, recognized everywhere

Proofs are relayed off Moca Chain via oracles and bridges. A single verification carries to every chain a partner ships into next, so users do not re-prove the same credential per ecosystem.

## Next steps

* [Technical Architecture](/technicals/mocachain/architecture)
* [Connect to Moca Chain](/technicals/mocachain/connect-to-mocachain)
* [Run a Node](/technicals/mocachain/run-a-node)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.