Moca Network

Moca Network: An identity layer built around Moca Chain, AIR Kit and MOCA

Moca Network is positioning MOCA as the economic and governance layer for portable identity, credential verification and data services across applications and blockchains. Its practical value depends on developers, partners, validators, storage providers and users adopting the system beyond the existing Mocaverse community.

What Moca Network is trying to provide

Moca Network describes itself as a chain-agnostic identity network for privacy-preserving verification and data interoperability. Its stated use case is to let users prove facts such as age, qualifications or memberships without exposing the underlying information, while allowing applications to treat identity and credentials as reusable infrastructure rather than isolated account data. This is a project description, not independent evidence that the network has achieved broad adoption.

The system is presented as two connected components: Moca Chain, an identity-focused Layer 1 for credential storage and verification, and AIR Kit, a software development kit for adding accounts, credentials and verification flows to applications. Moca ID is described as a consumer-facing identity product built on AIR Kit, linking the broader Moca Network concept to the Mocaverse user experience.

How Moca Chain is structured

Moca Chain is documented as an EVM-compatible blockchain based on EVMOS and the Cosmos SDK, using CometBFT consensus. The documentation lists approximately one-second blocks, single-block finality, a maximum of 100 validators, and MOCA as the native token. These parameters describe the documented design and configuration; they should not be read as a guarantee of production performance or decentralization.

The architecture also includes a Moca Chain Storage Provider network. According to the technical documentation, storage providers hold payload data while metadata, permissions and payments are recorded on-chain, with S3-compatible interfaces for applications. The design therefore introduces operational dependencies beyond the blockchain itself: storage-provider availability, replication, integrity proofs and the continued operation of the application interfaces used by partners.

Identity, privacy and cross-chain verification

Moca’s proposed credential model uses selective disclosure and zero-knowledge proofs. The documentation references Circom circuits and Groth16 proofs for cases such as age, KYC or accreditation checks, allowing a verifier to receive a result without receiving every underlying attribute. AIR Kit documentation also presents credential issuance and verification as developer workflows, which suggests the intended users include application teams, credential issuers and businesses rather than only individual token holders.

Cross-chain functionality is handled through oracles, bridges and relayers that carry proofs or verification results to other networks. This can reduce repeated verification for users, but it also creates trust and availability assumptions around the selected bridge, oracle, verifier configuration and credential issuer. The project’s own documentation describes the mechanism; the reliability of each deployment must be assessed separately.

What MOCA does

MOCA has several stated roles. The project identifies it as the utility and governance token for transaction fees, identity services, data generation, storage, verification and DAO participation. Moca Chain materials additionally describe uses involving gas, validator staking, storage, oracle services and verification fees. The token is therefore intended to connect activity on the identity infrastructure with economic incentives, although the existence of a stated use case does not establish meaningful demand or fee revenue.

The Foundation lists a fixed maximum supply of 8,888,888,888 MOCA and identifies Ethereum and Base as supported token networks. Its published allocation table assigns tokens to network incentives, ecosystem and treasury, strategic partners, liquidity, operations, team members, launch contributors and the community sale. The same table states that the strategic-partner vesting schedule was still to be confirmed, making unlock transparency and future circulating supply important issues for ongoing review.

Governance and control

The Foundation says MOCA holders can vote on Moca Improvement Proposals covering governance parameters and ecosystem initiatives. Moca Chain documentation describes a proposal process involving a minimum deposit, a voting period, participation thresholds and automatic on-chain execution for approved proposals. This indicates a token-based governance model, but the practical distribution of voting power, validator influence, delegation and treasury control remains more important than the existence of a formal voting process.

The project is supported by Moca Foundation and is closely associated with Animoca Brands. Animoca Brands has described Moca Chain integrations involving AIR Kit, identity credentials and partner applications, while also presenting large addressable-user figures. Those figures represent partner reach or estimated addressable audiences, not proof that those users actively use Moca Chain, hold MOCA or generate recurring protocol fees.

Practical dependencies and open questions

Moca Network’s model depends on several parties making compatible choices: developers must integrate AIR Kit or Moca Chain, issuers must create trusted credentials, verifiers must accept the resulting proofs, storage providers must preserve data availability, and cross-chain infrastructure must relay messages correctly. Privacy claims also depend on implementation details, key management, circuit design and the behavior of applications that receive verification results. A zero-knowledge proof can limit disclosure, but it does not by itself make an issuer truthful or an application trustworthy.

The Ethereum MOCA contract is publicly visible on Etherscan, where the token’s maximum supply and verified contract source are displayed. The project’s MiCA whitepaper reports that a Chainlight security audit was completed in 2024, but the whitepaper is a project-filed disclosure rather than a substitute for reviewing the audit scope, findings and remediation evidence. Users should also distinguish the ERC-20 and Base representations from the native MOCA currency used by Moca Chain.

Key takeaways

• Moca Network is centered on portable identity, credentials and verification rather than being only a gaming token.
• Moca Chain is documented as an EVM-compatible, CometBFT-based Layer 1 with decentralized storage and cross-chain identity infrastructure.
• AIR Kit is the main developer-facing integration layer for accounts, credentials and verification workflows.
• MOCA is intended for fees, staking, storage, oracle and verification services, as well as governance.
• The published token allocation includes substantial network-incentive, treasury and partner categories, so unlocks and circulating supply require continued monitoring.
• Reported partner reach should not be confused with verified active users, transaction demand or protocol revenue.

Risks and open questions

• The security and availability of cross-chain identity depend on bridge, oracle, relayer and verifier configurations that may differ by deployment.
• Credential privacy depends on correct circuit design, wallet security, issuer behavior and how receiving applications handle verification results.
• The documented validator ceiling and storage-provider model leave decentralization and operational resilience important questions for independent monitoring.
• The Foundation’s allocation table leaves the strategic-partner vesting schedule marked as to be confirmed.
• The project’s large addressable-user figures are promotional or estimated reach metrics, not independently verified active-user measurements.
• The reported 2024 token audit should be evaluated through its original scope, findings and remediation record rather than relied on as a general security assurance.