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

# Credential Security

> How Moca Network credentials are issued, cryptographically anchored on-chain, and verified using zero-knowledge proofs without exposing personal data.

Verifiable credentials on Moca Network are designed to be tamper-evident, privacy-preserving, and portable across any verifier in the ecosystem.

## Issuance integrity

When a credential is issued:

1. The issuer signs the credential data with their DID (Decentralized Identifier).
2. A cryptographic proof of the credential is generated and submitted to Moca Chain.
3. The credential is written to on-chain storage. The `vcStatus` transitions from `WAIT_ONCHAIN` to `ONCHAIN` once confirmed.

The on-chain proof acts as a tamper seal. If the credential data is modified after issuance, any verification attempt will fail because the proof no longer matches.

## Zero-knowledge verification

By default, credential verification uses zero-knowledge proofs (ZKPs). This means:

* The verifier asks a question: "Does this user hold a valid credential matching schema X?"
* The user's device generates a ZK proof that answers "yes" or "no" without revealing the underlying data.
* The verifier receives the boolean result and the on-chain proof hash — nothing else.

No PII is transmitted during verification. The verifier cannot reconstruct the original credential data from the proof.

## Selective disclosure

ZK proofs can verify individual attributes without revealing the full credential. For example, a credential containing `age`, `country`, and `kycLevel` can prove that `kycLevel >= 2` without revealing the user's age or country.

Selective disclosure is defined at the schema and verification program level. See [Schema Design](/airkit/usage/credential/schema-overview) for configuration.

## Credential revocation

Issuers can revoke credentials at any time. Revocation is recorded on-chain and takes effect immediately — any subsequent verification against a revoked credential will fail.

When using [Issue on Behalf](/airkit/usage/credential/issue-on-behalf) with `onDuplicate: "revoke"`, the old credential is automatically revoked before the new one is issued.

## Regulated data access (CAK)

For industries where verifiers must access raw data (e.g. identity photos for KYC), the [Compliance Access Key (CAK)](/learn/advanced-topics/privacy-and-compliance) framework adds a consent-gated encryption layer. Data is encrypted at issuance and only decryptable by a verifier who has obtained explicit user consent.

## Credential storage

| Storage layer            | What is stored                      | Encrypted?                        |
| ------------------------ | ----------------------------------- | --------------------------------- |
| Moca Chain (on-chain)    | Credential proofs and state anchors | N/A — proofs are hashes, not data |
| dStorage (decentralized) | Full credential payload             | Yes, if CAK is enabled            |
| User device              | Private keys, session tokens        | Yes, managed by MPC shards        |

## Further reading

* [Privacy & Compliance (CAK)](/learn/advanced-topics/privacy-and-compliance) for the full encryption framework
* [zkTLS](/learn/advanced-topics/zktls) for the zero-knowledge transport layer
* [Schema Design](/airkit/usage/credential/schema-overview) for defining verifiable attributes