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

# Data Privacy

> Privacy-by-design in Moca Network — where user data lives, what is encrypted, who has access, and how data minimization is enforced across the stack.

Moca Network follows a privacy-by-design approach. User data is minimized at every layer, and access is gated by cryptographic controls and explicit user consent.

## Data minimization

The default AIR Kit integration stores the minimum data necessary:

| Data type | Stored by Moca? | Notes |
| - | - | - |
| User email | Yes (hashed identifier) | Used as the AIR Account identifier for cross-partner portability |
| Raw source documents | Remain with the issuer | Not shared with AIR or verifiers |
| Credential claims | Encrypted envelope in DStorage | Payloads are encrypted to the holder; AIR stores opaque ciphertext and metadata, never plaintext |
| Private keys | No | Keys are split via MPC; no single party holds a full key |
| Verification records | Off-chain by default | Recorded on-chain only when a program requires on-chain verification |

## Who can access what

### Standard flow (all credentials)

Every credential is signed by the issuer and encrypted to the holder before storage. Credential claims and metadata can still be personal data:

* **Issuers** know the data they put into the credential (they are the source of truth) and hold their own signing keys.
* **Verifiers** receive a Verifiable Presentation containing the claims requested by the program and approved by the user, plus any required proof. They never see undisclosed claim data.
* **AIR** stores encrypted credential objects and metadata as a blind facilitator. It cannot reconstruct credential content.
* **Users** hold the encrypted credential in their AIR Account and control when and to whom it is presented.

## Data residency

* **Encrypted credential payloads** are stored in decentralized storage (DStorage) on Moca Chain as opaque ciphertext.
* **On-chain data** includes DStorage object metadata and state records, replicated across validators. Verification proofs are recorded on-chain only when the Verification Program requires it.
* **Session tokens and MPC key shards** are stored on the user's device and in secure execution environments. They are not centrally stored.

## User control

Users can:

* **Revoke consent** — If a user previously authorized a verifier, they can deny future requests.
* **Export keys** — Users can export their wallet private key for portability.
* **Request account deletion** — Handle account records, encrypted payloads, metadata, and previously disclosed copies through the relevant retention and deletion processes. Account deletion or credential revocation does not erase every copy. On-chain records remain and may still be linkable to a user.

## Compliance considerations

Moca Network provides technical primitives (encryption, consent management, audit trails) that support compliance frameworks such as GDPR, CCPA, and industry-specific regulations. The [Security Checklist](/technicals/architecture/security-checklist) covers integration best practices for maintaining compliance.

<Warning>
  Moca Network provides infrastructure and tooling. Compliance responsibility ultimately lies with the issuer and verifier organizations. Consult legal counsel for your specific regulatory requirements.
</Warning>


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