> ## 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.

# Security Overview

> How Moca Network protects user identity, credentials, and data — split-trust architecture, on-chain anchoring, encryption, and zero-knowledge proofs.

Moca Network is an identity infrastructure platform. Security is foundational to every design decision — from how credentials are issued to how keys are managed and how data flows between parties.

## Trust model

AIR Kit separates issuer source data and signing authority from encrypted credential storage and holder-controlled disclosure:

| Party | What they hold | What they cannot do |
| - | - | - |
| **User (Holder)** | Private keys, consent authority, credential wallet | Cannot forge credentials or bypass schema rules |
| **Issuer** | Source data, issuer signing keys | Cannot decrypt holder-encrypted storage without the relevant key; retains access to its own source records |
| **Verifier** | Verification programs, approved claims, optional ZK proofs | Cannot access undisclosed claims without user consent |
| **Moca Chain** | Storage metadata, state records, optional on-chain verification proofs | Cannot reconstruct private keys or decrypt stored data |
| **dStorage** | Encrypted credential payloads | Cannot decrypt without the user-consented key |

## Security layers

### Zero-knowledge proofs

The Verification Program determines the requested claims, whether ZK proofs are required, and whether verification is off-chain or on-chain. Successful verification returns a Verifiable Presentation with user-approved claims and any required proof. A ZK proof can confirm a condition without disclosing the underlying value.

### MPC-based key management

User accounts are backed by multi-party computation (MPC). Private keys are never held in one place — shards are distributed so that no single party (including Moca) can reconstruct the key. Keys are only assembled in a secure execution environment at the moment of signing.

### On-chain anchoring

The issuer's signature makes the credential tamper-evident. Programs that require on-chain verification can submit proofs to Moca Chain; other programs verify off-chain. DStorage object metadata is distinct from these optional verification records.

### Encrypted storage

Raw source documents remain with the issuer. Encrypted credential payloads may be stored in DStorage, while users control decryption and disclosure. Credential payloads are encrypted by default. See [Privacy & Compliance](/technicals/architecture/privacy-and-compliance).

### Account abstraction

User wallets use smart accounts (ERC-4337 account abstraction) with paymaster-sponsored gas. Users interact with the chain without managing private keys or gas tokens directly.

## Further reading

<CardGroup cols={2}>
  <Card title="Credential security" icon="shield-check" href="/technicals/architecture/credential-security">
    How credentials are signed, encrypted, and verified with user-controlled disclosure.
  </Card>

  <Card title="Data privacy" icon="lock" href="/technicals/architecture/data-privacy">
    Where data lives, what is encrypted, and who can access it.
  </Card>

  <Card title="Security checklist" icon="list-check" href="/technicals/architecture/security-checklist">
    Integration best practices for partners.
  </Card>

  <Card title="Privacy & Compliance" icon="key" href="/technicals/architecture/privacy-and-compliance">
    Encryption, ZK proofs, and user consent.
  </Card>
</CardGroup>


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