Skip to main content
As a Verifier, your role is to verify the authenticity of user credentials and ensure they meet your requirements. Verification is program-driven: a Verification Program configured in the Developer Dashboard centrally controls the proof type, whether a zero-knowledge proof is required, selective disclosure, and off-chain or on-chain mode. Your integration mainly passes a programId and optional disclosure parameters; the SDK handles credential discovery, consent, proof generation, and result handling.

Verification Flow

  1. Start verification — the verifier starts a session with a programId. The program defines what to check and how.
  2. Consent + discovery — the SDK requests the holder’s consent and loads the matching encrypted credential from DStorage.
  3. Proof generation — the holder decrypts the credential and generates a signature-based proof, including a zero-knowledge proof where the program requires one, disclosing only the requested claims.
  4. Verification — the proof is checked against the program’s settings off-chain by default, or recorded on-chain through the Universal Verifier when the program requires it.
  5. Result — on success the SDK returns a W3C Verifiable Presentation containing the disclosed claims and proof material.
Every verification attempt is recorded as a verification session — a server-side record of the result, mode, holder context, and usage data — giving you consistent reporting across integrations.

Verifier integration checklist

  1. Create or select a Verification Program in the Developer Dashboard (Verifier → Program).
  2. Configure the program:
    • Accepted proof type (BJJ_SIG_2021)
    • Requested claims and whether selective disclosure is required
    • Whether ZKP is required
    • Off-chain vs on-chain verification
    • The Issuer’s DID to constrain trusted issuers (optional)
  3. Publish the program and take note of the programId.
  4. Integrate the AIR Verifier SDK.
  5. Start verification with the programId.
  6. Handle outcomes: Compliant, Non-compliant, No matching credential, User declined consent, or proof/verification failure.
  7. On success, consume the returned Verifiable Presentation.
The dashboard link above uses Sandbox for development. For production launches, use the production Developer Dashboard. Moca Chain is on private Mainnet stage. Contact us for access and required $MOCA gas tokens before launching on production. See Production mainnet access.

Start verification

Generate a Partner JWT with scope=verify, then start verification with the SDK. Proof type, ZKP requirement, and off-chain / on-chain mode come from the program configuration, so your call stays minimal.

Input Parameters

Response

The function returns a Promise<CredentialVerificationResult>, a discriminated union on status.For non-compliant statuses ("Non-Compliant", "Pending", "Revoked", "Expired", "NotFound"):For compliant status ("Compliant"):
When compliance encryption (CAK) is enabled for the issuance program, the compliant result also includes a cakPrivateKey used to decrypt compliance data. See Selective Disclosure for how requested fields populate disclosedData.
Under the hood, the SDK loads the holder’s matching encrypted credential from DStorage, obtains consent, and generates the proof on the client side without exposing raw data to the verifier or to AIR. The proof is checked against the program’s settings — off-chain by default, or recorded on-chain when the program requires it. A successful result returns the compliant payload above, whose disclosedData is a W3C Verifiable Presentation–shaped object containing the disclosed claims and proof material.

Compliance encryption private key

When a result is "Compliant" and compliance encryption was enabled at issuance, the response includes a cakPrivateKey corresponding to the cakPublicKey returned during issuance. This lets verifiers decrypt regulated disclosure data or participate in threshold decryption, only after a successful verification.

Full CAK Verifier Guide

For handling user consent, receiving the private key, decrypting user data, and security best practices, see the dedicated CAK Verifier Guide.