# zkMe Protocol

Welcome to the zkMe Protocol Documentation Hub!

> Here, you will find all the information you need to learn about our company, our products, protocols & services, and our mission & values. Our Documentation Hub is designed to be user-friendly and informative. You can browse our library of documents, manuals, and guides to learn about our policies, procedures, and best practices. You can also search for specific topics or keywords to quickly find the information you need. By providing you with comprehensive and up-to-date information, we aim to empower you to make informed decisions and take effective actions. \
> \
> We encourage you to use our Documentation Hub as a starting point to learn more about zkMe Protocol and get started with an integration; our integration engineers are always available to answer any questions that go beyond what is currently documented here. Please do not hesitate to provide us with feedback on how we can improve it to better serve your needs; we value your suggestions.

{% hint style="success" %}
Ready to get started? \
Connect with zkMe today by sending an email to <contact@zk.me> and let's start talking!
{% endhint %}

***

{% hint style="warning" %}
**WIP**:  Note: The zkMe Protocol Documentation Hub is constantly being updated and may contain gaps that will be addressed in future revisions or outdated information that needs updating. Please do not hesitate to reach out to the zkMe team to clarify any details not covered by the documentation provided herein.
{% endhint %}

{% hint style="info" %}
**We aim to keep the Documentation Hub as up to date and detailed as possible. However, should you find any errors, outdated content, or simply be unable to locate the information you are looking for, please feel free to email us** **with the subject \[DOC HUB] to&#x20;**<mark style="color:blue;">**<contact@zk.me>**</mark>**.**
{% endhint %}


# Introduction

## *zkMe*

### *<mark style="color:green;">**The Identity & Open Finance Kernel for the Agent Economy**</mark>*

*<mark style="color:green;">**Enabling Autonomous Finance with Verifiable Trust.**</mark>*

***

## Who we are.

Founded in December 2022 and backed by the world's leading venture capital firms, zkMe Labs pioneers Self-Sovereign Identity solutions across various sectors. With the evolution of what we are building into zkMe Protocol, we empower users, institutions, and AI agents to securely manage and prove eligibility across a broad spectrum of applications. Originally focused on permissioned DeFi, zkMe now extends its secure, flexible compliance infrastructure to the Agent Economy, keeping data private while unlocking autonomous, permissionless finance.

zkMe builds the critical infrastructure layer between humans and autonomous AI agents. The future of finance is agentic: AI will manage cash flow, optimize yield, negotiate credit, and execute payments on behalf of humans. But this future cannot scale without a fundamental rethinking of how identity, secrets, and compliance are handled at the machine layer. zkMe solves this with infrastructure for **secrets management, dual underwriting, and payment initiation**, all powered by self-sovereign identity, zero-knowledge proofs, and session secrets.

***

## How it works.

zkMe is building a decentralized Identity infrastructure, bridging identity primitives through the [zkMe Protocol](/hub/how-built/modules). Leveraging the power of **Zero-Knowledge Proofs (ZKPs)**, zkMe enables **secure and private credential attestation and verification across ecosystems**.\
\
In contrast to most existing [Decentralized Identifier (DID)](https://en.wikipedia.org/wiki/Decentralized_identifier) or [Verifiable Credentials (VC)](https://en.wikipedia.org/wiki/Verifiable_credentials) approaches, Identity Protocol does not require centralized trusted Issuer entities on every ecosystem. Trusted Credentials are ubiquitous in traditional finance and the Internet, why not access and consume these onchain? Identity Oracles are thus the answer to the question:\
\ <mark style="color:green;">**Why reinvent the wheel when trusted credentials already exist?**</mark>

If a credential source is already trusted on another <mark style="color:purple;">Chain</mark>, on the <mark style="color:purple;">Internet</mark>, on a <mark style="color:purple;">Physical Device</mark>, or created by a <mark style="color:purple;">Trusted Issuer</mark>, zkMe's Identity Oracle **bridges that Credential fully trustlessly and programmatically** to any number of service providers without introducing new trust assumptions.

With zkMe, users maintain full control over their digital identities and disclose only what is necessary to authorized parties. In the Agent Economy, this same principle extends to AI agents: through the **zkKYA (Know Your Agent)** framework, agents receive verifiable credentials for **principal accountability**, **certified capabilities**, **declared intent**, **reputation history**, and **payment authorization**, enabling them to operate autonomously within **cryptographically-enforced boundaries**.

This enables a variety of [**Use Cases**](/hub/why/values), \
for the verification of a number of [**zkMe Credentials**](/hub/what/catalog), \
through the interaction of a number of [**zkMe Components**](/hub/how-works/architecture), \
powered by three complementary pillars:

<table><thead><tr><th width="118.494140625">Pillar</th><th width="245.83203125">Function</th><th>What it does</th></tr></thead><tbody><tr><td><strong>Secure</strong></td><td>Self-Sovereign Identity</td><td>Protects secrets via an encrypted zkVault with TEE execution, ensuring AI agents never hold plaintext credentials.</td></tr><tr><td><strong>Underwrite</strong></td><td>Trustless Credentials</td><td>Enables capital-efficient agents to instantly verify both their owner (UBO) and counterparties in a privacy-preserving way.</td></tr><tr><td><strong>Gate</strong></td><td>Enclaved Session Permission</td><td>Grants agents limited, revocable signing authority with built-in compliance checks before every transaction.</td></tr></tbody></table>

***

{% hint style="success" %}
Ready to build for the Agent Economy? <mark style="color:blue;">**Contact zkMe now:**</mark> [<mark style="color:blue;">**contact@zk.me**</mark>](mailto:contact@zk.me)
{% endhint %}

***


# Vision & Philosophy

## Vision & Mission

### + Vision

> *<mark style="color:green;">**A world where financial autonomy is not limited by security, knowledge, nor system boundaries. In the trustless world of tomorrow, Humans confidently entrust management of their financials to AI, and Agents transact with absolute, cryptographic trust.**</mark>*

### + Mission

> *<mark style="color:green;">**We build the leading infra for securing, verifying & bridging Identity for the Agent Economy. We empower AI Agents to handle firewalled secrets, instantly underwrite owners & counterparties, and effectively navigate an ever increasing complex economy.**</mark>*

## Design Philosophy

### Core Concept

zkMe provides a comprehensive privacy-preserving credential solution emphasizing zero-knowledge processing and selective disclosure. It implements Self-Sovereign Identities while maintaining regulatory compliance across finance, commerce, healthcare, government services, and the Agent Economy.

The platform prioritizes three foundational principles:

**Privacy-by-Design.** Personal data processes automatically on end devices or decentralized oracles, ensuring no unauthorized access and user control over information sharing with project-level permission revocation capabilities.

**Decentralization.** Trust determinations operate through decentralized node operator protocols, eliminating single-entity control while remaining party-agnostic across infrastructure roles.

**Transparency.** Open-source algorithms undergo regular audits, enabling credential cross-pollination across web3, web2, and real-life identity ecosystems.

These principles extend naturally to AI agents through the [**Secure**](/hub/how-built/id-infra)**,** [**Underwrite**](/hub/how-built/credential-sys)**,** and [**Gate**](/hub/how-built/agent-trust-gateway) pillars: agents receive self-sovereign identity credentials stored in an encrypted zkVault, their credentials compose with human credentials to form end-to-end trust chains, and agent operations comply with regulatory frameworks through cryptographically-enforced scope limits and principal accountability.

zkMe expands upon W3C Verifiable Credentials standards through:

* Replacing centralized issuers with open-source, trustless zero-knowledge verification algorithms
* Using Multi-Party Computation Oracles to bridge credentials across ecosystems
* Storing zero-knowledge proof verified presentations as Soulbound Tokens on-chain
* Decentralizing credential registries via anonymous proofs on distributed storage
* Extending identity infrastructure to AI agents through [zkKYA](/hub/what/zkkya) credentials, including Agent Principal, Agent Certification, Agent Intent, Agent Reputation, and Agent Payment Facilitation

<figure><img src="/files/GdNeeTVReK6eAXsaFqOw" alt=""><figcaption></figcaption></figure>

***

### Leading Design Considerations

#### **Compliance**

zkMe incorporates regulatory compliance with FATF's 2019 crypto KYC/AML recommendations, EU 6AML and TRF directives, emerging EU MiCA, US CLARITY Act, Stablecoin Compliance Requirements (SCR), the Agent Responsibility and Verification Act (ARVA), while adhering to W3C DIDs, VC, and VP standards. The system supports Crypto Travel Rule compliance and agent principal accountability, ensuring that the human or legal entity behind every agent action is always identifiable to regulators.

#### **Interoperability**

The system ensures credentials verified once function across any blockchain and any agent framework through a chain-agnostic and role-agnostic architecture independent of zkMe Technology Limited. Agent interoperability is achieved via MCP Server integration and the [Agent Trust Gateway](/hub/how-built/agent-trust-gateway), which translates credentials from any trusted issuer into a standardized format consumable by any service provider.

#### **User Experience**

Design priorities include:

* Conversion Rate optimization
* Self-Sovereignty maintenance
* Agent-native interfaces for programmatic credential management

#### **End-to-End Zero-Knowledge**

The protocol guarantees:

* No unilateral Personally Identifiable Information access
* No data sharing between parties
* No indirect identification mechanisms
* Verifiable end-to-end cryptographic integrity
* Agent secrets encrypted at rest with AES-256-GCM and accessible only within TEE enclaves

***

### High Level Process Flow

#### **Credential&#x20;**<mark style="color:green;">**Creation**</mark>

Holders present off-chain credentials to open-source verification algorithms running locally on mobile devices. The algorithm generates anonymized, tamper-proof Zero-Knowledge Proofs, sent to MPC node Oracles for consistency verification. Upon validation, a smart contract mints a credential proof Soulbound Token to the Holder's Self-Sovereign Identity Wallet.

For AI agents, the equivalent step is **Agent Registration**: agent developers register agents with a unique identifier, including model metadata and deployment context. The agent's identity is cryptographically bound to its principal's human or entity identity via an Agent Principal credential.

#### **Credential&#x20;**<mark style="color:green;">**Presentation**</mark>

When proving eligibility, Holders generate new ZKPs from their credential proof SBTs locally on their devices. They specify precise claims based on Verifier requirements. A ZKP circuit generates cryptographic proofs attesting to claim truthfulness without revealing additional personal information, embodying selective disclosure principles.

For agents, credential presentation is programmatic: when an agent requests access to a service or initiates a transaction, it generates a Zero-Knowledge Proof from its relevant credentials ([APC](/hub/what/zkkya/apc), [ACC](/hub/what/zkkya/acc), [AIC](/hub/what/zkkya/aic), [ARC](/hub/what/zkkya/arc), or [APF](/hub/what/zkkya/apf)) and submits it to the verifier via the Agent Trust Gateway. The agent proves specific claims, such as meeting a minimum reputation threshold or holding valid certification, without revealing the underlying data.

#### **Credential&#x20;**<mark style="color:green;">**Verification**</mark>

Holders submit generated ZKPs to Verifiers, who invoke smart contracts or APIs passing proofs as inputs. The cryptographic verification checks ZKP integrity and correctness, confirming only true/false claim validation while revealing nothing else about Holder identity, ensuring privacy-by-design protections.

For agents, verification occurs via the **8-step Session Secret Sharing flow**: the agent calls the Agent Trust Gateway, which checks scope and policy; the risk engine grades the action; the user approves on their phone via the SSI Wallet; the TEE signs a PASETO action token; the TEE decrypts credentials in the enclave; an isolated container executes on the target service; the result is returned and audit-logged to an immutable record.

#### **Credential&#x20;**<mark style="color:green;">**Attestation**</mark>

Holders delegate credential proofs to chosen blockchain ecosystems via signed delegation transactions from SSI-Wallets. A Delegate Smart Contract bridges the SBT onto the selected chain.

Holders access Verifier services by connecting wallets. Verifiers invoke either Verify smart contracts for one-time yes/no verification, or [**Certify**](/hub/how-built/id-infra/smart-contracts#zkme-verify-and-certify) smart contracts for maintaining auditable verification records enabling regulator action against bad actors. Certification requires additional Holder signature approval.

{% hint style="info" %}
***Note:** Steps 3.1.1–3.1.3 can be bypassed when Holders reuse previously verified credentials. The same reusability applies to agents: once registered and credentialed, agents present existing credentials without re-registration.*
{% endhint %}

<figure><img src="/files/tfiuvmw2ZaK3bwKtNcbW" alt=""><figcaption></figcaption></figure>


# Values & Use Cases

## Problems Solved by zkMe

As AI agents become autonomous actors in financial ecosystems, three fundamental problems emerge that existing infrastructure cannot solve:

* **The Data Security Crisis:** How do you protect secrets when agents are vulnerable to prompt injections and hallucinations? When an agent logs into a bank, it holds live credentials in its own context, where malicious inputs and memory leaks can silently exfiltrate them. $4.5B was lost to credential theft in 2025, and agent-related breaches are up 340% year-over-year.
* **The Underwriting Gap:** To be capital-efficient, an agent must instantly underwrite two entities: its owner, are they who they say they are, and the counterparty, are they a sanctioned entity or bad actor? Current systems cannot do both in a privacy-preserving way.
* **The Execution Fragmentation:** An agent needs to navigate thousands of payment rails such as ACH, SEPA, crypto, and stablecoins, each with its own licensing, authorization, and AML rules. There is no infrastructure for an AI agent to execute a stock trade, submit a tax form, or open a bank account on behalf of a user, with proper approval flows and an audit trail.

zkMe addresses all three with its three-pillar architecture: **Secure**, **Underwrite**, and **Gate**.

<details>

<summary>Identity Interoperability</summary>

One global Credential Data Market spanning all ecosystems, enabling seamless Credential verification and authorization across different blockchain ecosystems.

* **Unified Identity:** Holders maintain a single, coherent digital identity recognized and usable across all supported blockchain networks.
* **Self-Sovereign Control:** Provides Holders with greater control over their identity data and its sharing across various ecosystems and service providers.
* **Scalability:** Designed to accommodate a growing number of blockchain ecosystems and Credential Holders.
* **Developer-Friendly:** Provides tools and APIs for easy integration of identity services into dApps across various chains.
* **Seamless Interoperability:** Facilitates secure and efficient data exchange between users and various dApps across different ecosystems.
* **Agent Portability**: AI agents carry their principal's verified credentials across platforms and services, enabling a single delegation to unlock access everywhere, from DeFi protocols to traditional SaaS providers.

</details>

<details>

<summary>Identity Data Security</summary>

Individual Credential Data anonymization, encryption & strictly purpose-driven Credential Data Retrieval.

* **Enhanced Privacy:** Leverages zero-knowledge technology to enable identity verification without compromising personal data.
* **Enclaved Agent Execution**: Agent credentials are never exposed in plaintext. All sensitive operations, including decryption, signing, and verification, occur within hardware Trusted Execution Environments, eliminating the risk of prompt injection or memory-based credential theft.
* **Decentralized and Transparent Infrastructure:** Utilizes zkMe infrastructure to ensure secure, transparent, and censorship-resistant operations.
* **Reduced Friction:** Simplifies the user experience by eliminating the need for multiple identities across different blockchains.
* **Privacy-First Credential Issuance:** Verifies user data and issues cryptographic credentials using client-side ZKP technology, ensuring data integrity without compromising personal information.
* **Secure Data Verification:** Enables applications to verify user credentials without accessing or storing raw personal information, maintaining user privacy and reducing data liability.
* **Zero-Knowledge Privacy Protection:** Utilizes cutting-edge zero-knowledge technology to facilitate identity verification while keeping sensitive information confidential.

</details>

<details>

<summary>Holder-Centric Data Economy</summary>

Composable, smart contract based Credential verifications for all industries allows to create a thriving ecosystem that puts users at the center of the data economy. By providing a decentralized infrastructure for personal data management and monetization, zkMe enables the development of a wide range of user-centric applications and services. Developers can build privacy-preserving dapps with zkMe, offering innovative solutions for personal finance, health and wellness, social networking, and more. The network fosters collaboration between users, developers, and data consumers, creating a fair and transparent data economy where users are the primary beneficiaries. zkMe's user-centric approach ensures that the value derived from personal data is distributed equitably, empowering individuals and promoting a more inclusive data economy.

In the Agent Economy, this extends further: users can delegate data-sharing decisions to trusted AI agents that operate within cryptographically enforced boundaries, enabling autonomous participation in the data economy without sacrificing privacy or control.

</details>

***

## Value Propositions

{% columns %}
{% column width="33.33333333333333%" %}

### **For Users**

{% endcolumn %}

{% column width="66.66666666666667%" %}
*<mark style="color:green;">**The highest degree of privacy, control, and value creation in digital interactions.**</mark>*
{% endcolumn %}
{% endcolumns %}

<details>

<summary><strong>Self-Sovereign Identity</strong></summary>

Take control of your digital Identity while maintaining the highest degree of privacy.  You decide who has access to which of your anonymous credentials.

</details>

<details>

<summary><strong>Ultimate Privacy</strong></summary>

None of your Personally Identifiable Information (PII) is ever shared, processed, nor stored by anyone but yourself. Identity theft and misuse are not possible.

</details>

<details>

<summary><strong>Agent Delegation with Confidence</strong></summary>

Deploy personal AI agents to manage finances, subscriptions, and services on your behalf, knowing they operate within strict, revocable limits and never access your raw credentials.

</details>

{% columns %}
{% column width="33.33333333333333%" %}

### **For Businesses**

{% endcolumn %}

{% column width="66.66666666666667%" %}
*<mark style="color:green;">**Scalable and effective underwriting, risk management, and AML compliance.**</mark>*
{% endcolumn %}
{% endcolumns %}

<details>

<summary><strong>Decentralization &#x26; Disintermediation</strong></summary>

Empower your users to self-verify without the need of trust into a third party data processor or controller.

</details>

<details>

<summary><strong>Scalable &#x26; Affordable</strong></summary>

Scalable permissioning allows fine-grained access control to grow dynamically without compromising efficiency or security. Don't overspend on user verifications. Fully programmatic and data minimized data verification allow for the highest value to cost solution on the market.

</details>

<details>

<summary><strong>Agent-Ready Infrastructure</strong></summary>

Deploy AI agents that can securely handle user credentials, verify counterparties, and execute compliant transactions, all without exposing raw data. zkMe's TEE-based zkVault and OpenClaw Gateway provide the secrets management and policy enforcement layer that enterprise-grade agentic finance requires.

</details>

<details>

<summary><strong>Autonomous Underwriting</strong></summary>

Enable agents to instantly underwrite both the beneficial owner (UBO) and the counterparty in any transaction, using reusable, privacy-preserving credentials. Reduce capital inefficiency and trust assumptions in automated financial workflows.

</details>

<details>

<summary><strong>Institutional web3</strong></summary>

Unlock vast, compliant liquidity markets with ease.

</details>

<details>

<summary><strong>Reduced Onboarding Frictions</strong></summary>

Process all user verifications without any system breaks. Flutter and Javascript SDKs allow for a native verification user flow directly from your front end.

</details>

<details>

<summary><strong>Web3 Native Risk Management</strong></summary>

Implement risk management that does not compromise on decentralization or user privacy.

</details>

<details>

<summary><strong>GDPR Compliance Onchain</strong></summary>

Automatic GDPR compliance by not having to process nor store any private user data.&#x20;

</details>

<details>

<summary><strong>AML/KYC Compliance OnChain</strong></summary>

Comply with due diligence requirements without compromising on decentralization and user privacy by implementing FATF-compliant zero-knowledge KYC.

</details>

***

## Use Cases

{% hint style="success" %}
Please refer to zkMe Website for more details on Use Cases: [zk.me](https://zk.me/)
{% endhint %}

### zkMe for the Agent Economy

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Personal Tax Filing Agents</strong></td><td>Millions of individuals dread tax season and increasingly rely on AI agents to gather financial documents, calculate deductions, and file returns on their behalf. Tax authorities and accounting platforms require proof that the agent is authorized by a specific, verified taxpayer before accepting any submission. zkMe's Agent Principal Credential cryptographically binds the agent to its human owner, allowing it to file with full legal authority while the owner's personal details remain private and protected from unnecessary exposure.</td><td><a href="/pages/kcLeU6Y8fST2MxjpM2L4">/pages/kcLeU6Y8fST2MxjpM2L4</a></td></tr><tr><td><strong>E-Commerce Shopping Agents</strong></td><td>Consumers are adopting AI shopping agents that compare prices, detect deals, and make purchases across online marketplaces. Before granting an agent access to checkout flows and stored payment methods, platforms need assurance that the agent handles credentials securely and will not be exploited by fraudulent sellers. zkMe's Agent Certification Credential provides standardized, third-party proof that the agent has passed evaluations for data security, fraud resistance, and consumer protection, giving both platforms and shoppers confidence in its safety.</td><td><a href="/pages/aU7EFG6dwTqQf5HPXNjf">/pages/aU7EFG6dwTqQf5HPXNjf</a></td></tr><tr><td><strong>Personal Finance Optimization Agents</strong></td><td>Households use AI agents to reduce everyday expenses by monitoring subscriptions, switching utility providers, and negotiating better rates. Users need to trust that the agent will prioritize cost savings without canceling essential services or sharing personal usage data with third parties. zkMe's Agent Intent Credential cryptographically commits the agent to declared objectives and hard constraints, such as never canceling a service without explicit approval, ensuring the agent's behavior stays aligned with the user's priorities.</td><td><a href="/pages/1uk1PnUdULmTL0vAuegm">/pages/1uk1PnUdULmTL0vAuegm</a></td></tr><tr><td><strong>Freelance Hiring via Agent Marketplaces</strong></td><td>Businesses browsing agent marketplaces to find a reliable customer support agent face the challenge of distinguishing genuinely high-performing agents from those with inflated or fabricated reviews. zkMe's Agent Reputation Credential aggregates verified performance data, including response accuracy, uptime history, and Sybil-resistant user feedback, into a tamper-proof, multi-dimensional score. Hiring managers can compare agents on objective, manipulation-resistant metrics rather than unverified marketing claims.</td><td><a href="/pages/fYBMUqwQFLnmC4MBsUPP">/pages/fYBMUqwQFLnmC4MBsUPP</a></td></tr><tr><td><strong>Autonomous SaaS Subscription Management</strong></td><td>Growing startups delegate SaaS procurement and renewal to AI agents that manage dozens of cloud tools, from hosting to analytics to design software. Each vendor requires authenticated payment before activating or renewing a license. zkMe's Agent Payment Facilitation module enables the agent to settle invoices instantly via x402 stablecoin micropayments or traditional rails, all executed inside a hardware TEE enclave with strict spending limits, so the agent never touches raw payment credentials and every transaction is compliance-checked and audit-logged.</td><td><a href="/pages/gh7OvjebwGy5utxZSMfL">/pages/gh7OvjebwGy5utxZSMfL</a></td></tr></tbody></table>

### zkMe for Onchain KYC/AML Compliance

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>KYC on Stablecoin Secondary Trades</strong> </td><td>Stablecoin transfers could face strict scrutiny over AML, sanctions screening, and transaction monitoring. zkMe’s zkKYC links wallet compliance status directly to on-chain addresses, allowing issuers, payment processors, and service providers to automatically block high-risk wallets and approve verified ones. This keeps stablecoin transactions instant, borderless, and private, while meeting global regulatory requirements.</td><td><a href="/pages/Dk9O2hm0UWOdJxiDNBqf">/pages/Dk9O2hm0UWOdJxiDNBqf</a></td></tr><tr><td><strong>Interoperable RWA Tokens</strong></td><td>Real-world assets face a tangled web of regulations. zkMe cuts through the complexity, making them compliant on public blockchains. We mark wallets for their owners' compliance, enabling secure, hassle-free trading through existing DeFi infrastructure. Say goodbye to regulatory red tape and hello to smooth, compliant RWA trading.</td><td><a href="/pages/Dk9O2hm0UWOdJxiDNBqf">/pages/Dk9O2hm0UWOdJxiDNBqf</a></td></tr><tr><td><strong>Location-Gated Transaction Execution</strong></td><td>As part of KYC/AML requirements, some platforms might need to confirm a user’s residence jurisdiction before providing access to financial products. zkMe’s Proof-of-Address verifies a user’s residential address using zero-knowledge proofs, ensuring documents are valid, issued within 90 days, and compliant with jurisdictional rules, without exposing the plaintext address. This enables platforms to enforce residence-based requirements while keeping sensitive user information private.</td><td><a href="/pages/Dk9O2hm0UWOdJxiDNBqf">/pages/Dk9O2hm0UWOdJxiDNBqf</a></td></tr><tr><td><strong>Professional Investor Token Distribution</strong></td><td>Some jurisdictions, such as the US, require investors to meet specific net worth, income, or professional criteria before participating in certain offerings. zkMe’s Proof-of-Accredited-Investor verifies accredited investor status through zero-knowledge proofs, confirming eligibility without disclosing sensitive financial information. This approach supports compliant fundraising, private placements, and tokenized securities sales while ensuring that investors’ personal information remains secure and confidential.</td><td><a href="/pages/Dk9O2hm0UWOdJxiDNBqf">/pages/Dk9O2hm0UWOdJxiDNBqf</a></td></tr><tr><td><strong>Token Distribution</strong></td><td>Token launches and airdrops often face regulatory requirements around KYC/AML, jurisdiction restrictions and community standards. zkMe’s zkKYC verifies participant identity, jurisdiction, and other criteria through zero-knowledge proofs, ensuring only eligible wallets receive tokens without revealing personal data. This prevents multi-account abuse, supports fair allocation, and keeps the process compliant and transparent across jurisdictions.</td><td><a href="/pages/Dk9O2hm0UWOdJxiDNBqf">/pages/Dk9O2hm0UWOdJxiDNBqf</a></td></tr><tr><td><strong>Frictionless On/Off Ramp</strong></td><td>On/Off ramp providers must comply with strict AML and sanctions regulations when converting between fiat and digital assets. zkMe delivers end-to-end compliance by combining off-chain AML with on-chain AML through KYT. This ensures user identities are verified, transactions are screened in real time, and only compliant wallets can deposit or withdraw—while personal data remains private. The result is seamless, cross-border asset conversion with full regulatory alignment.</td><td><a href="/pages/Dk9O2hm0UWOdJxiDNBqf">/pages/Dk9O2hm0UWOdJxiDNBqf</a></td></tr><tr><td><strong>Age-Gated Access</strong></td><td>Many platforms need to restrict access based on age, from gaming and streaming to alcohol sales, gambling, and financial services. zkMe’s age verification uses zero-knowledge proofs to confirm whether a user meets the required threshold without revealing their exact birthdate or personal details. This enables businesses to meet regulatory requirements, reduce onboarding friction, and protect user privacy across all age-restricted services.</td><td><a href="/pages/Dk9O2hm0UWOdJxiDNBqf">/pages/Dk9O2hm0UWOdJxiDNBqf</a></td></tr></tbody></table>

### zkMe for Anti-Sybil Protection&#x20;

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Sybil-Resistant Governance</strong></td><td>Decentralized governance often suffers from vote manipulation by bots or users controlling multiple wallets. zkMe’s “one face, one DID” mechanism ensures that each voting participant is uniquely verified through privacy-preserving facial recognition. This guarantees that every vote comes from a distinct, real individual, making DAO governance outcomes more representative and secure.</td><td><a href="/pages/o0Tw6e9pDXbnvo2JjcrE">/pages/o0Tw6e9pDXbnvo2JjcrE</a></td></tr><tr><td><strong>Bot-Free Community Incentives</strong></td><td>Platforms can use zkMe to verify that rewards, badges, or engagement incentives go only to genuine members. By filtering out fake profiles and automated accounts, communities maintain healthy growth, prevent abuse of reward systems, and ensure fair distribution of benefits.</td><td><a href="/pages/o0Tw6e9pDXbnvo2JjcrE">/pages/o0Tw6e9pDXbnvo2JjcrE</a></td></tr><tr><td><strong>Authentic Event Participation</strong></td><td>Virtual and in-person events often suffer from duplicate registrations or ticket scalping. zkMe ensures each attendee has a unique DID, preventing the same person from claiming multiple tickets or benefits. Organizers can confidently manage capacity, distribute perks, and maintain a genuine attendee base.</td><td><a href="/pages/o0Tw6e9pDXbnvo2JjcrE">/pages/o0Tw6e9pDXbnvo2JjcrE</a></td></tr></tbody></table>

### zkMe for User Underwriting & Risk Management

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Exchange KYC Status Verification</strong></td><td>zkMe can verify a user’s KYC completion status across supported exchanges through zkTLS without revealing any personal information. Protocols and platforms can use this proof to grant access to trading features, token sales, or other KYC-gated services instantly. Verified status can be carried seamlessly across multiple platforms, helping businesses stay compliant while removing redundant verification steps.</td><td><a href="/pages/m6wrn5qan74AXgYyoSuS">/pages/m6wrn5qan74AXgYyoSuS</a></td></tr><tr><td><strong>Trusted Credit Profile</strong></td><td>Creditworthiness is essential for accessing loans, leases, and certain investments, but traditional checks expose sensitive financial data. zkMe verifies a user’s credit score band or creditworthiness status through zero-knowledge proofs, confirming eligibility without revealing exact scores or underlying records. Projects can assess risk, customize terms, and maintain compliance, all while safeguarding privacy and making onboarding faster.</td><td><a href="/pages/m6wrn5qan74AXgYyoSuS">/pages/m6wrn5qan74AXgYyoSuS</a></td></tr><tr><td><strong>Social-to-Chain Verification</strong></td><td>Campaigns and communities often face fake or automated accounts that drain rewards and distort engagement data. With zkMe, platforms can privately confirm Twitter account ownership using zero-knowledge proofs, no credentials exchanged, no personal data exposed. Verified social identities can then be tied directly to on-chain actions, making airdrops, gated access, and reward programs more accurate, fraud-resistant, and compliant.</td><td><a href="/pages/m6wrn5qan74AXgYyoSuS">/pages/m6wrn5qan74AXgYyoSuS</a></td></tr><tr><td><strong>Financial Capacity Attestation</strong></td><td>Some financial products, such as accredited investor offerings or high-value credit lines, require proof of bank-held assets. Using zero-knowledge proofs, zkMe verifies asset thresholds directly from supported banks without exposing account numbers, statements, or other sensitive details. Institutions can confirm eligibility in real time, accelerate onboarding, keep product access compliant, cut manual checks, and protect client privacy throughout the process.</td><td><a href="/pages/m6wrn5qan74AXgYyoSuS">/pages/m6wrn5qan74AXgYyoSuS</a></td></tr></tbody></table>

***

{% hint style="success" %} <mark style="color:green;">**MORE SUITES ARE COMING SOON**</mark>
{% endhint %}


# Roadmap

Pioneering the future of decentralized identity and privacy-preserving compliance.

## Strategic Direction

zkMe's strategic direction centers on three primary pillars:

* **Ecosystem Expansion**: The platform aims to integrate across multiple blockchain networks while strengthening its Identity Hub with improved campaign tools and cross-chain capabilities. With Agentic Open Finance, ecosystem expansion now includes agent framework interoperability via MCP Server integration and the Agent Trust Gateway, enabling agents to operate across platforms with portable, reusable credentials.
* **Credential Innovation**: Development efforts target broader compliance applications, including financial identity and healthcare verification, alongside enhanced developer resources and documentation improvements. A major new frontier is **zkKYA**, introducing agent credential types such as Agent Principal, Agent Reputation via ERC-8004, Agent Intent, and Agent Certification. This extends the credential model from humans to AI agents as first-class identity holders.
* **Institutional Scaling**: The initiative focuses on privacy-respecting compliance infrastructure designed for traditional financial and healthcare sectors, with emphasis on trust frameworks and strategic partnerships. For the Agent Economy, institutional scaling adds the zkVault for secure secret management within TEE enclaves, x402/AP2 payment facilitation for autonomous agent transactions, and compliance-aware execution infrastructure. zkMe is actively pursuing entry into regulated sandboxes in key financial hubs such as HKMA, CIMA, and BMA to create a compliant environment for agent-driven finance.

The organization's immediate priorities include expanding credential coverage to new industries and geographies, and strengthening regulatory alignment while maintaining user privacy. These efforts represent a deliberate evolution toward enterprise and agent adoption while preserving the decentralized identity model at the platform's foundation.

***

## What’s Next <a href="#whats-next" id="whats-next"></a>

zkMe's ongoing development focuses on:

* x402/AP2 payment facilitation for agent-initiated transactions
* Universal Facilitation with smart routing across any intent and any rail
* DeFi agent corridors for lending, trading, and yield optimization
* Agent marketplace with credential-based trust ranking and discovery


# Onboarding Checklist

{% hint style="info" %}
**Note:** 🗣️ Reach out to us at <mark style="color:blue;">**<contact@zk.me>**</mark> to get your project domain whitelisted asap.
{% endhint %}

{% stepper %}
{% step %}

#### Sign up for a zkMe dashboard account using a company email

* If you are implementing **zkKYC, KYT, zkOBS, or zkKYA**, please register for a **zkMe dashboard account** via [**this link**](https://dashboard.zk.me).
* If you are implementing **zkKYB**, please click [**this link**](https://kyb-dashboard.zk.me/signup) to get started.

{% hint style="info" %}
**Note:** The account is a Self-Sovereign Identity (SSI) that is tied to the email, please pick an email you will continue to use to manage the customer account from.
{% endhint %}
{% endstep %}

{% step %}

#### Accept the zkMe Terms & Conditions and the [App Privacy Policy](https://zk.me/app-privacy-policies)

{% endstep %}

{% step %}

#### Inform zkMe which [Credentials](/hub/what/catalog) you’d like to verify

Share your company email, the chain ecosystems you intend to support, the level of decentralization you want to support (pick from an [On-chain](/hub/start/onboarding/zkkyc-levels#on-chain-mint-default), or [Cross-chain](/hub/start/onboarding/zkkyc-levels#cross-chain) Verification), expected launch date, and anticipated traffic with zkMe in order to receive the required permissions.&#x20;
{% endstep %}

{% step %}

#### Once required permissions are assigned by zkMe, refer to the [Dashboard ](/hub/start/onboarding/dashboard) to access your API Key and configure your setup

{% endstep %}

{% step %}

#### Start to integrate, referring to the [Integration Checklist](/hub/start/onboarding/integration)

{% endstep %}
{% endstepper %}


# Decentralization Levels

## What decentralization levels of zkKYC does zkMe offer?

zkMe provides three levels of decentralization for zkKYC. The default level is [On-chain Mint](#on-chain-mint-default), please refer to the following description.

### On-chain Mint (Default)

Upon the initial connection of the asset wallet to a chain, it includes the creation of an SBT on the user's SSI wallet on both Polygon and the chain user's wallet connect to, setting data on the SBT, minting the SBT on the blockchain that the user's wallet is linked to, and authorizing the project using the SBT minted on the connected asset chain.

However, to accommodate potential different needs from our clients, we also offer the following another methods, which is called [Cross-chain](#cross-chain).

### Cross-chain

During the initial binding of the asset wallet to a chain, it includes creating an SBT on the user's SSI wallet on Polygon, setting data on the SBT, and obtaining user consent for authorization via a pop-up interface in widget. The user's authorization information is then transmitted to the project through zkMe's API.

***

## How do the three versions work?

After users complete the zkKYC process, then come to SBT minting and KYC status authorization stage.

### On-chain Mint (Default)&#x20;

**Interaction Instructions**

<figure><img src="/files/96vYsPPktOwX4djj6Isb" alt=""><figcaption></figcaption></figure>

**How does it work?**

* For the initial binding of the mainnet asset wallet, the following are carried out:
  * Creating SBT in the user's Polygon Mainnet SSI wallet.
  * Setting data for SBT in the user's Polygon Mainnet SSI wallet.
  * Minting SBT on the chain user's wallet connects to.
  * Setting data for the SBT in the connected wallet.
  * User authorizes the minted SBT to the project on the connected chain.<br>
* If the user is binding an asset wallet on the testnet, the following are conducted:
  * Minting SBT on the chain user's wallet connects to.
  * Setting data for SBT in the user's testnet asset wallet.
  * User authorizes the minted SBT to the project on the connected chain.

**Flow chart**

<figure><img src="/files/Q5XYervCk7wM3ndd6zaL" alt=""><figcaption></figcaption></figure>

### Cross-chain

#### Interaction Instructions

<figure><img src="/files/k43zRcStDR0GYZYEd9yN" alt=""><figcaption></figcaption></figure>

**How does it work?**

* For the initial binding of the mainnet asset wallet, the following are carried out:
  * Creating SBT in the user's Polygon Mainnet SSI wallet.
  * Setting data for SBT in the user's Polygon Mainnet SSI wallet.
  * User authorizes the permission of project side to compare their information
  * Project side can transmit information through zkMe's API<br>
* If the user is binding an asset wallet on the testnet, the following are conducted:
  * User authorizes the permission of project side to compare their information
  * Project side can transmit information through zkMe's API

**Flow chart**

<figure><img src="/files/3Jm5mrdyLdjwzdOskpny" alt=""><figcaption></figcaption></figure>

***

## Comparison of the two solutions

<table><thead><tr><th width="104"> </th><th width="128"> </th><th>On-chain Mint</th><th>Cross-chain</th></tr></thead><tbody><tr><td><strong>User Side</strong></td><td><strong>Binding Wallet with zkMe account</strong></td><td>Yes</td><td>Yes</td></tr><tr><td></td><td><strong>Where SBT(s) is minted</strong></td><td>Both Polygon and the chain user's wallet connect to</td><td>Only Polygon</td></tr><tr><td></td><td><strong>How a User Authorizes the KYC Status of A Project</strong><br><br></td><td>Mint SBT on the chain user's wallet connects to</td><td>Authorize via a pop-up window in the widget, where users decide whether to grant permission to a project</td></tr><tr><td><strong>Project Side</strong></td><td><strong>Configure Supported Networks in Dashboard</strong></td><td>Yes</td><td>No</td></tr><tr><td></td><td><strong>How to check the user's KYC status</strong></td><td>API and Smart Contract</td><td>API</td></tr></tbody></table>


# Dashboard Setup

This guide explains how to set up and access zkMe Dashboard for zkKYC, KYT, zkOBS, and zkKYA. It is intended for teams onboarding individual users or managing transaction-related compliance workflows.

{% hint style="info" %}
Looking for the zkKYB dashboard setup guide? Start here → [zkKYB Dashboard Setup](/hub/start/onboarding/dashboard/kyb)
{% endhint %}

{% stepper %}
{% step %}

### Start from the [zkMe Dashboard](https://dashboard.zk.me) Partner Login

Please enter your zkMe account and password to log in to the zkMe Dashboard.&#x20;

{% hint style="info" %}
If you don't have access to [zkMe Dashboard](https://dashboard.zk.me/) yet, \
please [sign up ](https://dashboard.zk.me/signup)and contact <mark style="color:blue;">**<contact@zk.me>**</mark> to obtain your permissions.
{% endhint %}

<figure><img src="/files/2TnDK4DyLzymUeA4ndr5" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Welcome to the zkMe Dashboard&#x20;

After successfully logging in, you will be directed to the User List page.

<figure><img src="/files/YvynZ8krt9scRmCgEXFl" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Whitelist Your Domain

Go to Integration -> Setting, please type in your domain and click "**Save**" to whitelist it.

<figure><img src="/files/Tps4craz7JGAvQMwuXW0" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Download Your Private Key

In the Configuration, you need to click "**Download JSON file**" to have access to your Private Key, which is crucial for subsequent decryption work. Please ensure it is safely kept in self-custody.

<figure><img src="/files/CieRbmcZqfOpLsqJLqex" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Generate Your API Key

Click **"Generate API Key"** to generate the key you'll use in the integration code.

<figure><img src="/files/olTIa2WNOidNyTLvNSBi" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**Note:** If your integration involves only [MeID](/hub/what/zkkyc/meid) or [KYT](/hub/what/kyt), Steps 1 through 5 are sufficient. Please skip Steps 6 through 8 and proceed to [Step 9](#step-9-all-set-time-to-start-implementing) directly for further implementation.
{% endhint %}
{% endstep %}

{% step %}

### Setup Your Eligibility Settings

In the zkKYC section of the Configuration, you can select the category you want to verify and click **"Create Program"** to enter the customization page.

<figure><img src="/files/4g13UAFdcYqnkGv9IRkU" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Check the Created Programs

After you finish customizing the requirement and save, your newly created program will appear in the list with the status "**Created**".

<figure><img src="/files/yRBpVsG52im2SgLEsYUa" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Activate the Program&#x20;

If you want to enable a created program, please click on the record and "**Apply program"**. Then, the status will change from "Created" to "**Apply**".

<figure><img src="/files/pAsFV0ccZCgHxDleqm52" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### All Set! Time to Start Implementing

When your status changes to "**Apply"**, you are ready to begin the integration process. Kindly refer to the [Integration Checklist](/hub/start/onboarding/integration) to start integrating zkMe’s solution with your project.

<figure><img src="/files/IzclRPxjeQvZb2p71j3a" alt=""><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}


# zkKYB Dashboard Setup

This guide explains how to set up and access the zkMe Dashboard for zkKYB. It is intended for teams onboarding business or institutional clients and managing corporate compliance workflows.

{% hint style="info" %}
Looking for dashboard setup for zkKYC, KYT, zkOBS, or zkKYA? Start here → [Dashboard Setup](/hub/start/onboarding/dashboard)
{% endhint %}

{% stepper %}
{% step %}

### Start from the [zkMe KYB Dashboard](https://kyb-dashboard.zk.me/) Partner Login

Please enter your zkMe account and password to log in to the zkMe Dashboard.&#x20;

{% hint style="info" %}
If you don't have access to [zkMe KYB Dashboard](https://kyb-dashboard.zk.me/) yet, \
please [sign up](https://kyb-dashboard.zk.me/signup) and contact <mark style="color:blue;">**<contact@zk.me>**</mark> to obtain your permissions.
{% endhint %}

<figure><img src="/files/2TnDK4DyLzymUeA4ndr5" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Welcome to the Dashboard&#x20;

After successfully logging in, you will be directed to the Company List page.

<figure><img src="/files/RmpMynOxRp4Gy8DsTYT3" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Whitelist Your Domain

Go to Integration, please type in your domain and click "**Save**" to whitelist it.

<figure><img src="/files/WPzrFJcIssWzv41IKOFj" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Generate Your API Key

Click **"Generate API Key"** to generate the key you'll use in the integration code.

<figure><img src="/files/eKRDcEcAV64FlasTzMSK" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Setup Your Eligibility Settings

In the section of Configuration, you can click **"Create KYB Program"** to enter the customization page.

<figure><img src="/files/98jttndfWtP53JmzAN6M" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Check the Created Program

After you finish customizing the requirement and save, your newly created program will appear in the list with the status "**Created**".

<figure><img src="/files/vELVWM30OFUYEAgHOrNf" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Activate the Program&#x20;

If you want to enable a created program, please click on the record and "**Apply program"**. Then, the status will change from "Created" to "**Apply**".

<figure><img src="/files/eoydP3j37L9wOFdkvqCE" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### All Set! Time to Start Implementing

When your status changes to "**Apply"**, you are ready to begin the integration process. Kindly refer to the [Integration Checklist](/hub/start/onboarding/integration) to start integrating zkMe’s solution with your project.

<figure><img src="/files/qC5mMJg9mdZTfqmvT09X" alt=""><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}


# Integration Checklist

{% hint style="info" %}
**Note:** If you haven’t checked the Onboarding Checklist yet, please visit [Onboarding Checklist](/hub/start/onboarding) before continuing,provides the setup foundation for the integration steps that follow.
{% endhint %}

{% stepper %}
{% step %}

### Integrate the zkMe SDK

To enable users to complete the verification flow and authorize sharing, start by integrating the zkMe SDK into your frontend.

* [**SDK**](/hub/start/onboarding/integration/js-sdk)**:** Integrate the zkMe SDK to enable the full verification flow and user authorization.\
  This step is **required** before querying any verification results.

> UI elements can be [customized](/hub/start/onboarding/integration/js-sdk/customize-ui) to match your dApp’s look and feel.
> {% endstep %}

{% step %}

### **Query User Verification Status**

{% hint style="info" %}
**Note:** This section only covers query methods. Before querying, ensure that **SDK Integration (Step 1)** has been completed so users can finish verification and authorize data sharing.\
\
Without it, API and Smart Contract methods will not return valid results.
{% endhint %}

After users finish their verification flow, use one of the following methods to retrieve their verification status:

* [**API**](/hub/start/onboarding/integration/api/verify-zkkyc)**:** Retrieve user verification results.
* [**Smart Contract**](/hub/start/onboarding/integration/smart-contract)**:** On-chain verification and proof validation. This method is only available when your Dashboard account is configured with an [On-chain Mint](https://docs.zk.me/hub/start/onboarding/zkkyc-levels) level.
  {% endstep %}

{% step %}

### Manage Users Ongoing

After a user has been onboarded, zkMe provides tools for ongoing user management, including tracking activity, re-verification when needed, and managing data usage in compliance with regulations.
{% endstep %}
{% endstepper %}

***

## Additional Capabilities

* [**KYT**](/hub/start/onboarding/integration/api/get-kyt)**:** Monitor wallet and transaction risk using zkMe’s KYT service, and complement your zkKYC checks with onchain risk signals.
* [**3rd Party Integration**](/hub/start/onboarding/integration/3rd-integration)**:** Set up event campaigns and manage user interactions through integrated campaign platforms. \
  \
  Contact us at <contact@zk.me> in order to set up an event campaign to target and incentivize the existing zkMe community to onboard onto your service.


# JavaScript SDK


# zkKYC - Know Your Customer

{% hint style="success" %}
This page covers the **compliance-related** features of [zkKYC](/hub/what/zkkyc). If you want to integrate MeID, please jump to [Proof-of-Personhood (MeID)](/hub/start/onboarding/integration/js-sdk/zkkyc/meid)for the MeID-specific guide.
{% endhint %}

## Use Case

To reduce the development cost for the project side, the project can use zkKYC capability by simply accessing the link. Users can complete full KYC verification directly on the web/H5, reducing user churn by minimizing the need to navigate to another page.

***

## **zkMe-Widget KYC Process**

**Step 1:** Enter the service authorization Widget page; the user confirms and goes to the next step

**Step 2:** E-mail verification login

**Step 3:** Verify the SBT to confirm that it is authenticated

**Step 4:** Depending on the KYC configuration of the project, determine whether the user needs to undergo different verification processes.

***

## Interaction Instructions

<figure><img src="/files/6xdIEildUPqaxTzCAZad" alt=""><figcaption></figcaption></figure>

***

## Integration via NPM

You can refer to [@zkmelabs/widget](https://www.npmjs.com/package/@zkmelabs/widget?activeTab=versions) and please make sure to use the latest version.

### Installation

```sh
pnpm add @zkmelabs/widget

# or
yarn add @zkmelabs/widget

# or
npm install @zkmelabs/widget
```

### Getting Started

#### **Step 1. Import styles**

```typescript
import '@zkmelabs/widget/dist/style.css'
```

#### **Step 2. Create a new `ZkMeWidget` instance**

{% tabs %}
{% tab title="Cross-chain" %}
{% code fullWidth="false" expandable="true" %}

```typescript
import { ZkMeWidget, type Provider } from '@zkmelabs/widget'

const provider: Provider = {
  async getAccessToken() {
    // -------------------------TODO-------------------------
    // Request a new token from your backend service and return it to the widget.
    // For the access token, see https://docs.zk.me/hub/start/onboarding/integration/js-sdk/zkkyc#access-token
    // ------------------------------------------------------
    return fetchNewToken()
  },

  async getUserAccounts() {
    // -------------------------TODO-------------------------
    // If your project is a Dapp,
    // you need to return the user's connected wallet address.
    const userConnectedAddress = await connect()
    return [userConnectedAddress ]

    // If not,
    // you should return the user's e-mail address, phone number or any other unique identifier.
    //
    // return ['email address']
    // or
    // return ['phone number']
    // or
    // return ['unique identifier']
    // ------------------------------------------------------
  },

}

const zkMeWidget = new ZkMeWidget(
  // -------------------------TODO-------------------------
  appId, // This parameter means the same thing as "mchNo"
  'YourDappName',
  '137', // chainId. No changes are needed here if the account is configured for cross-chain.
  provider,
  {
      lv: 'zkKYC'
      programNo: 'YourProgramNo' // You can find the Program No in the ‘Configuration’ section of your dashboard
      // For other options, please refer to the table below
  }
  // ------------------------------------------------------
)
```

{% endcode %}
{% endtab %}

{% tab title="On-chain Mint / On-chain Transactional " %}
{% code expandable="true" %}

```typescript
import { ZkMeWidget, type Provider } from '@zkmelabs/widget'

const provider: Provider = {
  async getAccessToken() {
    // -------------------------TODO-------------------------
    // Request a new token from your backend service and return it to the widget.
    // For the access token, see docs.zk.me/zkme-dochub/verify-with-zkme-protocol/integration-guide/javascript-sdk/zkkyc-compliance-suite#how-to-generate-an-access-token-with-api_key
    // ------------------------------------------------------
    return fetchNewToken()
  },

  async getUserAccounts() {
    // -------------------------TODO-------------------------
    // If your project is a Dapp,
    // you need to return the user's connected wallet address.
    const userConnectedAddress = await connect()
    return [userConnectedAddress]

    // If not,
    // you should return the user's e-mail address, phone number or any other unique identifier.
    //
    // return ['email address']
    // or
    // return ['phone number']
    // or
    // return ['unique identifier']
    // ------------------------------------------------------
  },

  // -------------------------TODO-------------------------
  // According to which blockchain your project is integrated with,
  // choose and implement the corresponding methods as shown below.

  // EVM
  async delegateTransaction(tx) {
    const txResponse = await signer.sendTransaction(tx)
    return txResponse.hash
  },

  // Cosmos
  async delegateCosmosTransaction(tx) {
    const txResponse = await signingCosmWasmClient.execute(
      tx.senderAddress,
      tx.contractAddress,
      tx.msg,
      'auto'
    )
    return txResponse.transactionHash
  },

  // Aptos
  async delegateAptosTransaction(tx) {
    const txResponse = await aptos.signAndSubmitTransaction(tx)
    return txResponse.hash
  },

  // TON
  async delegateTonTransaction(tx) {
    const { boc } = await tonConnectUI.sendTransaction({
      validUntil: Date.now() + 5 * 60 * 1000, // You can customize this value
      messages: [tx]
    })
    const { hash } = Cell.fromBase64(boc)
    return hash().toString('hex')
  },
  
  // Solana
  async delegateSolanaTransaction({ message }) {
    const tx = Transaction.populate(Message.from(bs58.decode(message))) 
    // Replace with your actual signer
    const txid = await signer.signAndSendTransaction(tx)
    return txid
  },

  // ...
  // See the Provider interface definition for more details on other chains.
  // ------------------------------------------------------
}


const zkMeWidget = new ZkMeWidget(
  // -------------------------TODO-------------------------
  appId, // This parameter means the same thing as "mchNo"
  'YourDappName',
  chainId, // 
  provider,
  {
      lv: 'zkKYC'
      programNo: 'YourProgramNo' // You can find the Program No in the ‘Configuration’ section of your dashboard
      // For other options, please refer to the table below
  }
  // ------------------------------------------------------
)
```

{% endcode %}
{% endtab %}
{% endtabs %}

{% hint style="info" %}
**NOTE:** The specific configuration for the "option" parameter is shown in the table below
{% endhint %}

<table><thead><tr><th width="195">Param</th><th width="164">Type</th><th>Description</th></tr></thead><tbody><tr><td>options.lv</td><td>VerificationLevel?</td><td><code>"zkKYC"</code> or <code>"MeID"</code>, default <code>"zkKYC"</code></td></tr><tr><td>options.programNo</td><td>string?</td><td><p>If you have activated multiple programs running in parallel, please pay attention to this setting:<br></p><p>The param can be found in <a href="https://dashboard.zk.me">Dashboard</a> and please make sure the program is enabled. The SDK will take the number of the first activated program as the default value if this parameter is not provided in the code.</p></td></tr><tr><td>options.theme</td><td>Theme?</td><td><code>"auto"</code>, <code>"light"</code> or <code>"dark"</code>, default <code>"auto"</code>. </td></tr><tr><td>options.locale</td><td>Language?</td><td><code>"en"</code> or <code>"zh-hk"</code>, default <code>"en"</code>.</td></tr></tbody></table>

#### **Step 3. Listen to the `kycFinished` widget events to detect when the user has completed the zkKYC process.**

```typescript
function handleFinished(results) {
  const { isGrant, associatedAccount } = results

  if (
    isGrant &&
    associatedAccount === userConnectedAddress.toLowerCase()
  ) {
    // -------------------------TODO-------------------------
    // Prompts the user that zkKYC verification has been completed
    // ------------------------------------------------------
  }
}

zkMeWidget.on('kycFinished', handleFinished)
```

#### **Step 4. Launch the zkMe widget and it will be displayed in the center of your webpage.**

```typescript
// This is the code to launch our widget on your page
button.addEventListener('click', () => {
  zkMeWidget.launch()
})
```

***

## Helper functions

### verifyKycWithZkMeServices()

Before launching the widget, you should check the zkKYC status of the user and launch the widget when the check result is `false`.

```typescript
import { verifyKycWithZkMeServices } from '@zkmelabs/widget'

// zkKYC
const { isGrant } = await verifyKycWithZkMeServices(
  appId,
  userAccount,
  // Optional configurations are detailed in the table below
  options
)
```

<table><thead><tr><th width="192">Param</th><th width="89">Type</th><th>Description</th></tr></thead><tbody><tr><td>appId</td><td>string</td><td>This parameter means the same thing as "mchNo"</td></tr><tr><td>userAccount</td><td>string</td><td>The <code>userAccount</code> info (such as wallet address, email, phone number, or unique identifier) must match the format of accounts returned by <code>provider.getUserAccounts</code>.</td></tr><tr><td>options.programNo</td><td>string?</td><td>If you have activated multiple programs running in parallel, please pay attention to this setting:<br><br>The param can be found in <a href="https://dashboard.zk.me">Dashboard</a> and please make sure the program is enabled. The SDK will take the number of the first activated program as the default value if this parameter is not provided in the code.</td></tr></tbody></table>

If the level of your Dashboard account is not Cross-Chain, then you can also query users' zkKYC status from zkMe Verify & Certify Smart Contract [here](https://github.com/zkMeLabs/zkme-sdk-js/tree/main/packages/verify-abi#readme).

## **How to Generate an Access Token with API\_KEY**

To use your API\_KEY to obtain an accessToken, you will need to make a specific HTTP request. Here's how you can do it:

#### a. **Endpoint**: Send a <mark style="color:orange;">`POST`</mark> request to the token exchange endpoint.

```powershell
POST https://nest-api.zk.me/api/token/get
```

{% hint style="info" %}
Please remember to modify the <mark style="color:blue;">`Content-Type`</mark> in the request header to <mark style="color:blue;">`application/json`</mark>. Failing to do so might result in a <mark style="color:red;">`Parameter Error`</mark> response.
{% endhint %}

#### b. **Request Body**:

<table><thead><tr><th width="193">Parameter Name</th><th width="136">Required</th><th width="150">Type</th><th>Desc</th></tr></thead><tbody><tr><td>apiKey</td><td>True</td><td>string</td><td>The API_KEY provided by zkMe.</td></tr><tr><td>appId</td><td>True</td><td>string</td><td>A unique identifier (mchNo) to DApp provided by zkMe.</td></tr><tr><td>apiModePermission</td><td>True</td><td>number</td><td>0 - email login (Only support email login)</td></tr><tr><td>lv</td><td>True</td><td>number</td><td>1 - zkKYC <br>2 - MeID</td></tr></tbody></table>

{% hint style="info" %} <mark style="color:orange;">`API_KEY`</mark>can be found in [the Configuration section](https://dashboard.zk.me/integration) of the Integration on the zkMe Dashboard.
{% endhint %}

#### c. **Response**

<details>

<summary><mark style="color:green;"><strong>Success</strong></mark></summary>

<pre class="language-json"><code class="lang-json">{
    "code": 80000000,
    "data": {
        "accessToken": "8641259808779c53de65c3698e42b402b112cfe3856202189c37eae9f0b23babbcc1429ea9adcb52283dca4dab024a640651f855d8c78c7bde308f721a6e0cb80d51dab7c775ebfe0ae74eb9ab02f503094a9b2a2e2aeabf70e03a0cac9773a93dba743ca0dc3fa4af77375351bc48f76515d72dbee3a8bd5c034e6ffb94bd97"
<strong>    },
</strong>    "msg": "success",
    "timestamp": 1691732474552
}
</code></pre>

</details>

<details>

<summary><mark style="color:red;"><strong>Exception (AppId and API_KEY not matched)</strong></mark></summary>

```json
{
    "code": 81000014,
    "data": null,
    "msg": "AppID and API Key do not match. Access token generation failed",
    "timestamp": 1691732568774
}
```

</details>

<details>

<summary><mark style="color:red;"><strong>Exception (Parameter Error)</strong></mark></summary>

```json
{
    "code": 80000002,
    "data": null,
    "msg": "parameter error",
    "timestamp": 1691732593484
}
```

</details>

<details>

<summary><mark style="color:red;"><strong>Exception (System Error)</strong></mark></summary>

```json
{
    "code": 80000001,
    "data": null,
    "msg": "system error",
    "timestamp": 1691732593484
}
```

</details>

***

## ZkMeWidget instance methods

<details>

<summary>launch()</summary>

Launch the zkMe widget and it will be displayed in the center of your webpage.

<pre class="language-typescript"><code class="lang-typescript"><strong>launch(): void
</strong></code></pre>

</details>

<details>

<summary>on()</summary>

Listen to zkMe widget events.

```typescript
on(event: 'kycFinished', callback: KycFinishedHook): void;
on(event: 'close', callback: () => void): void;
```

</details>

<details>

<summary>switchChain()</summary>

If your DApp integrates multiple chains, use this method to synchronize the new chain to the zkMe widget when the user switches chains in your DApp.

```typescript
switchChain(chainId: string): void
```

</details>

<details>

<summary>hide()</summary>

Hide the zkMe widget.

```typescript
hide(): void
```

</details>

<details>

<summary>destroy()</summary>

Remove the message event listener registered by the zkMe widget from the window and destroy the DOM node.

```typescript
destroy(): void
```

</details>

***

## Common Response & Exceptions

<details>

<summary><mark style="color:green;">Success</mark></summary>

If the user has passed the KYC verification and the user’s SBT could be accessed by your project, the following interface will be seen. Meanwhile, there will be a message with KYC results sent to your DApp.

<img src="/files/nk3z0wLSheTCuTfrHuJe" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">Camera Permission Denied Error</mark></summary>

The following screen will be displayed for possible issues such as the user denying browser camera access or not having a camera on the device.

<img src="/files/eCj3g5idjLltwYAf1hCn" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">OCR Scan Error</mark></summary>

The following screen will be displayed when an exception occurs during the OCR process.

<img src="/files/mORBETyxYW775uGpgHSz" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">Face Recognition Error</mark></summary>

The following screen will be displayed for possible problems such as eyes closed detected, art mask detected etc.

<img src="/files/zk5FVaIkHKicJ9VAQXut" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">Face Mismatch Error</mark></summary>

The following screen will be displayed when the face could not match the uploaded ID.

<img src="/files/Ws4HhD3eCkKb7ZYBdcqJ" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">Faceprint Mismatch Error</mark></summary>

The following screen will be displayed for the possible problem that the fully homomorphically encrypted faceprint does not match the one associated with this MeID.

<img src="/files/lYGtZWZinKlbf68mMDQ4" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">Faceprint Recognition Server Error</mark></summary>

The following screen will be displayed when something goes wrong on the faceprint recognition server.

<img src="/files/fHLzb77oDD24Z7YLsW3I" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">Unknown Error</mark></summary>

The following screen will be displayed when something goes wrong not listed above.

<img src="/files/A4vRjyFJ9y6eRdyrfByu" alt="" data-size="original">

</details>


# Proof-of-Personhood (MeID)

{% hint style="success" %}
his page covers the **Proof-of-Personhood** features of [MeID](/hub/what/zkkyc/meid). If you want to integrate zkKYC, please jump to [zkKYC - Know Your Customer](/hub/start/onboarding/integration/js-sdk/zkkyc) for the compliance-focused integration.
{% endhint %}

## Use Case

When you need to protect a website or application from automated attacks, you can use anti-bot mechanisms. These attacks can result in malicious behavior, such as spamming, data theft, or network disruption. Anti-bot technology is designed to identify and block these attacks to ensure that only real human users can access your website or application.

In this case, users are required to undergo facial liveliness detection to prove that they are real human users. This detection requires users to perform specific actions or expressions in front of a camera to prove that they are genuine humans and not automated programs. This technology can help prevent automated attacks and fraud, and increase the security and reliability of your website or application.

***

## **zkMe-Widget MeID Process**

**Step 1:** Enter the service authorization Widget page; the user confirms and goes to the next step

**Step 2:** E-mail verification login / Wallet address login

**Step 3:** Verify that the user has authorized MeID

**Step 4:** Based on the outcomes of the initiated query, a determination is made regarding whether to commence the authentication process for the specified user.

***

## Interaction Instructions

<figure><img src="/files/XCKLoUBgZxMlQ8wVZAWw" alt=""><figcaption></figcaption></figure>

***

## Integration via NPM

You can refer to [@zkmelabs/widget](https://www.npmjs.com/package/@zkmelabs/widget?activeTab=versions) and please make sure to use the latest version.

### Installation

```sh
pnpm add @zkmelabs/widget

# or
yarn add @zkmelabs/widget

# or
npm install @zkmelabs/widget
```

### Getting Started

#### **Step 1. Import styles**

```typescript
import '@zkmelabs/widget/dist/style.css'
```

#### **Step 2. Create a new `ZkMeWidget` instance**

{% tabs %}
{% tab title="Email Login Mode" %}
{% code expandable="true" %}

```typescript
import { ZkMeWidget, type Provider } from '@zkmelabs/widget'

const provider: Provider = {
  async getAccessToken() {
    // -------------------------TODO-------------------------
    // Request a new token from your backend service and return it to the widget.
    // For the access token, see https://docs.zk.me/hub/start/onboarding/integration/js-sdk/zkkyc/meid#access-token
    // ------------------------------------------------------
    return fetchNewToken()
  },

  async getUserAccounts() {
    // -------------------------TODO-------------------------
    // If your project is a Dapp,
    // you need to return the user's connected wallet address.
    const userConnectedAddress = await connect()
    return [userConnectedAddress]

    // If not,
    // you should return the user's e-mail address, phone number or any other unique identifier.
    //
    // return ['email address']
    // or
    // return ['phone number']
    // or
    // return ['unique identifier']
    // ------------------------------------------------------
  },

}

const zkMeWidget = new ZkMeWidget(
  // -------------------------TODO-------------------------
  appId, // This parameter means the same thing as "mchNo"
  'YourDappName',
  chainId,
  provider,
  {
      lv: 'MeID'
      // For other options, please refer to the table below
  }
  // ------------------------------------------------------
)
```

{% endcode %}
{% endtab %}

{% tab title="Wallet Login Mode" %}
{% code expandable="true" %}

```typescript
import { ZkMeWidget, type Provider } from '@zkmelabs/widget'

const provider: Provider = {
  async getAccessToken() {
    // -------------------------TODO-------------------------
    // Request a new token from your backend service and return it to the widget.
    // For the access token, see docs.zk.me/zkme-dochub/meid-anti-bot-suite/meid-integration-guide/sdk-integration#how-to-generate-an-access-token-with-api_key
    // ------------------------------------------------------
    return fetchNewToken()
  },

  async getUserAccounts() {
    // If your project is a Dapp,
    // you need to return the user's connected wallet address.
    const userConnectedAddress = await connect()
    return [userConnectedAddress]
  },

}

const zkMeWidget = new ZkMeWidget(
  // -------------------------TODO-------------------------
  appId, // This parameter means the same thing as "mchNo"
  'YourDappName',
  chainId,
  provider,
  {
      lv: 'MeID',
      mode: 'wallet',
      // Whether to verify the validity of the user's wallet. Default is false. 
      // If set to true, you need to implement the provider.signMessage method.
      checkAddress: true 
      // For other options, please refer to the table below
  }
  // ------------------------------------------------------
)
```

{% endcode %}
{% endtab %}
{% endtabs %}

{% hint style="info" %}
**NOTE:** The specific configuration for the "option" parameter is shown in the table below
{% endhint %}

<table><thead><tr><th width="196">Param</th><th width="164">Type</th><th>Description</th></tr></thead><tbody><tr><td>options.theme</td><td>Theme?</td><td><code>"auto"</code>, <code>"light"</code> or <code>"dark"</code>, default <code>"auto"</code>. </td></tr><tr><td>options.locale</td><td>Language?</td><td><code>"en"</code> or <code>"zh-hk"</code>, default <code>"en"</code>.</td></tr></tbody></table>

#### **Step 3. Listen to the `meidFinished` widget event to detect when the user has completed the MeID process**

```typescript
function handleFinished(results) {
  const { isGrant, associatedAccount } = results

  if (
    isGrant &&
    associatedAccount === userConnectedAddress.toLowerCase()
  ) {
    // Prompts the user that MeID verification has been completed
  }
}

zkMeWidget.on('meidFinished', handleFinished)
```

#### **Step 4. Launch the zkMe widget and it will be displayed in the center of your webpage**

```typescript
// This is the code to launch our widget on your page
button.addEventListener('click', () => {
  zkMeWidget.launch()
})
```

***

## Helper functions

### verifyMeidWithZkMeServices()

Before launching the widget, you should check the MeID status of the user and launch the widget when the check result is `false`.

```typescript
import { verifyMeidWithZkMeServices } from '@zkmelabs/widget'

// MeID
const { isGrant } = await verifyMeidWithZkMeServices(
  appId,
  userAccount
)
```

<table><thead><tr><th width="191">Param</th><th width="98">Type</th><th>Description</th></tr></thead><tbody><tr><td>appId</td><td>string</td><td>This parameter means the same thing as "mchNo"</td></tr><tr><td>userAccount</td><td>string</td><td>The <code>userAccount</code> info (such as wallet address, email, phone number, or unique identifier) must match the format of accounts returned by <code>provider.getUserAccounts</code>.</td></tr></tbody></table>

## **How to Generate an Access Token with API\_KEY**

To use your API\_KEY to obtain an accessToken, you will need to make a specific HTTP request. Here's how you can do it:

#### a. **Endpoint**: Send a <mark style="color:orange;">`POST`</mark> request to the token exchange endpoint.

```powershell
POST https://nest-api.zk.me/api/token/get
```

{% hint style="info" %}
Please remember to modify the <mark style="color:blue;">`Content-Type`</mark> in the request header to <mark style="color:blue;">`application/json`</mark>. Failing to do so might result in a <mark style="color:red;">`Parameter Error`</mark> response.
{% endhint %}

#### b. **Request Body**:

<table><thead><tr><th width="193">Parameter Name</th><th width="101">Required</th><th width="96">Type</th><th>Desc</th></tr></thead><tbody><tr><td>apiKey</td><td>True</td><td>string</td><td>The API_KEY provided by zkMe.</td></tr><tr><td>appId</td><td>True</td><td>string</td><td>A unique identifier (mchNo) to DApp provided by zkMe.</td></tr><tr><td>apiModePermission</td><td>True</td><td>number</td><td>0 - email login <br>1 - wallet address login</td></tr><tr><td>lv</td><td>True</td><td>number</td><td>The parameter must be passed and always be 2.</td></tr></tbody></table>

{% hint style="info" %} <mark style="color:orange;">`API_KEY`</mark>can be found in [the Configuration section](https://dashboard.zk.me/integration) of the Integration on the zkMe Dashboard.
{% endhint %}

#### c. **Response**

<details>

<summary><mark style="color:green;"><strong>Success</strong></mark></summary>

<pre class="language-json"><code class="lang-json">{
    "code": 80000000,
    "data": {
        "accessToken": "8641259808779c53de65c3698e42b402b112cfe3856202189c37eae9f0b23babbcc1429ea9adcb52283dca4dab024a640651f855d8c78c7bde308f721a6e0cb80d51dab7c775ebfe0ae74eb9ab02f503094a9b2a2e2aeabf70e03a0cac9773a93dba743ca0dc3fa4af77375351bc48f76515d72dbee3a8bd5c034e6ffb94bd97"
<strong>    },
</strong>    "msg": "success",
    "timestamp": 1691732474552
}
</code></pre>

</details>

<details>

<summary><mark style="color:red;"><strong>Exception (AppId and API_KEY not matched)</strong></mark></summary>

```json
{
    "code": 81000014,
    "data": null,
    "msg": "AppID and API Key do not match. Access token generation failed",
    "timestamp": 1691732568774
}
```

</details>

<details>

<summary><mark style="color:red;"><strong>Exception (Parameter Error)</strong></mark></summary>

```json
{
    "code": 80000002,
    "data": null,
    "msg": "parameter error",
    "timestamp": 1691732593484
}
```

</details>

<details>

<summary><mark style="color:red;"><strong>Exception (System Error)</strong></mark></summary>

```json
{
    "code": 80000001,
    "data": null,
    "msg": "system error",
    "timestamp": 1691732593484
}
```

</details>

***

## ZkMeWidget instance methods

<details>

<summary>launch()</summary>

Launch the zkMe widget and it will be displayed in the center of your webpage.

<pre class="language-typescript"><code class="lang-typescript"><strong>launch(): void
</strong></code></pre>

</details>

<details>

<summary>on()</summary>

Listen to zkMe widget events.

<pre class="language-typescript"><code class="lang-typescript"><strong>on(event: 'meidFinished', callback: MeidFinishedHook): void;
</strong>on(event: 'close', callback: () => void): void;
</code></pre>

</details>

<details>

<summary>hide()</summary>

Hide the zkMe widget.

```typescript
hide(): void
```

</details>

<details>

<summary>destroy()</summary>

Remove the message event listener registered by the zkMe widget from the window and destroy the DOM node.

```typescript
destroy(): void
```

</details>

***

## **Response & Exceptions**

<details>

<summary><mark style="color:green;">Success</mark></summary>

If the user has passed the liveness and uniqueness verification, the following interface will be seen.

**Note:**

The finished callback function will be fired after the interface is displayed.

<img src="/files/NYFmd4EiR6Z0m1eSF4wg" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">Camera Permission Denied Error</mark></summary>

The following screen will be displayed for possible issues such as the user denying browser camera access or not having a camera on the device.

<img src="/files/eCj3g5idjLltwYAf1hCn" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">Face Recognition Error</mark></summary>

The following screen will be displayed for possible problems such as eyes closed detected, art mask detected and etc.

<img src="/files/zk5FVaIkHKicJ9VAQXut" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">Existing Faceprint Error</mark></summary>

The following screen will be displayed for the possible problem that the user’s faceprint is similar to another user’s.

<img src="/files/7aXHjJZJiXJE7NLi0iWT" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">Faceprint Recognition Server Error</mark></summary>

The following screen will be displayed when something goes wrong on the faceprint recognition server.

<img src="/files/fHLzb77oDD24Z7YLsW3I" alt="" data-size="original">

</details>

<details>

<summary><mark style="color:red;">Unknown Error</mark></summary>

The following screen will be displayed when something goes wrong not listed above.

<img src="/files/oxOIlLz8IKwHCq9KME7E" alt="" data-size="original">

</details>


# zkKYB - Know Your Business

## Use Case

To reduce development costs, you can use the zkMe KYB Widget to handle the entire business verification process. Users can complete the full KYB verification directly on your web/H5 application, minimizing user churn by eliminating the need to navigate to another page.

***

## zkMe KYB Widget Process

The KYB verification flow consists of the following steps:

**Step 1**: Enter the service authorization Widget page; the user confirms and proceeds to the next step.

**Step 2**: Email verification login.

**Step 3**: Fill in company basic information.

**Step 4**: Fill in UBO (Ultimate Beneficial Owner) / SMO (Senior Managing Official) information.

**Step 5**: Trigger controller KYC/PoA verification for each controlling person.

**Step 6**: Upload corporate documents.

**Step 7**: Submit for review. The application status will then move to "Info Submitted" and await manual review by the zkMe compliance team.

***

## Integration via NPM

You can refer to [@zkmelabs/kyb-widget](https://www.npmjs.com/package/@zkmelabs/kyb-widget) and please make sure to use the latest version.

### Installation

```sh
pnpm add @zkmelabs/kyb-widget

# or
yarn add @zkmelabs/kyb-widget

# or
npm install @zkmelabs/kyb-widget
```

### Getting Started

#### **Step 1. Import styles**

```typescript
import '@zkmelabs/kyb-widget/dist/style.css'
```

#### **Step 2. Create a new** `ZkMeKybWidget` **instance**

{% code expandable="true" %}

```typescript
import { ZkMeKybWidget, type Provider } from '@zkmelabs/kyb-widget'

const provider: Provider = {
  async getAccessToken() {
    // -------------------------TODO-------------------------
    // Request a new token from your backend service and return it to the widget.
    // For the access token, see https://docs.zk.me/hub/start/onboarding/integration/js-sdk/zkkyb#access-token
    // ------------------------------------------------------
    return fetchNewToken()
  },

  async getExternalID() {
    // -------------------------TODO-------------------------
    // `ExternalID` represents the unique identifier of this user in your system.
    // Typical examples include a corporate e-mail address, phone number,
    // or an internal user ID. Use the same identifier consistently
    // whenever you query or verify this user's KYB status.
    // ------------------------------------------------------
    return [externalID]
  },

}

const zkMeKybWidget = new ZkMeKybWidget(
  // -------------------------TODO-------------------------
  appId, // This parameter means the same thing as "mchNo"
  'YourDappName',
  provider,
  {
      programNo: 'YourProgramNo' // You can find the Program No in the ‘Configuration’ section of your KYB dashboard
      // For other options, please refer to the table below
  }
  // ------------------------------------------------------
)
```

{% endcode %}

{% hint style="info" %}
**NOTE:** The specific configuration for the "option" parameter is shown in the table below
{% endhint %}

<table><thead><tr><th width="195">Param</th><th width="164">Type</th><th>Description</th></tr></thead><tbody><tr><td>options.programNo</td><td>string</td><td><p>If you have activated multiple programs running in parallel, please pay attention to this setting:<br></p><p>The param can be found in Dashboard and please make sure the program is enabled. The SDK will take the number of the first activated program as the default value if this parameter is not provided in the code.</p></td></tr></tbody></table>

#### **Step 3. Listen to the `kybFinished` widget events to detect when the user has completed the zkKYB process.**

<pre class="language-typescript"><code class="lang-typescript">function handleKybFinished(results) {
  const { status, externalID, zkMeAccount, programNo } = results

  if (status === 5 &#x26;&#x26; externalID === provider.getExternalID().toLowerCase()) {
    // -------------------------TODO-------------------------
    // The user has successfully completed zkKYB verification.
    // Prompt the user that verification has been completed.
    // ------------------------------------------------------
    console.log(`KYB verification completed for ${externalID}`)
  }
}

<strong>zkMeWidget.on('kybFinished', handleKybFinished)
</strong></code></pre>

**Event Callback Parameters**

The `kybFinished` event callback receives a `results` object with the following properties:

<table><thead><tr><th width="186">Name</th><th width="83">Type</th><th>Description</th></tr></thead><tbody><tr><td>status</td><td>int</td><td><p>Indicates the current verification status of the KYB process.</p><p></p><p>Status codes are defined as follows:</p><ul><li><code>1</code> – Verification Started</li><li><code>2</code> – Info Submitted</li><li><code>3</code> – Under Review</li><li><code>4</code> – Resubmission Required</li><li><code>5</code> – Verification Passed</li><li><code>6</code> – Verification Failed</li></ul></td></tr><tr><td>externalID</td><td>string</td><td>The entity identifier from your system, echoed back by the SDK. This is the same value you returned as <code>externalID</code> in the <code>getExternalID()</code> function (for example, a corporate email address, phone number, or an internal user ID).</td></tr><tr><td>zkMeAccount</td><td>string</td><td>The zkMe internal account identifier.</td></tr></tbody></table>

#### **Step 4. Launch the zkMe KYB widget and it will be displayed in the center of your webpage.**

```typescript
// This is the code to launch our widget on your page
button.addEventListener('click', () => {
  zkMeKybWidget.launch()
})
```

***

## Helper functions

### verifyKybWithZkMeServices()

Before launching the widget, you should check the zkKYB status of the user and launch the widget when the check result is `false`.

{% tabs %}
{% tab title="Function" %}

```typescript
import { verifyKybWithZkMeServices } from '@zkmelabs/kyb-widget'

// zkKYB
const { status, statusDesc } = await verifyKybWithZkMeServices(
  appId, // Your unique App ID (mchNo)
  externalID, // The user's unique identifier (e.g., corporate email)
  accessToken, // The access token obtained from https://docs.zk.me/hub/start/onboarding/integration/js-sdk/zkkyb#access-token
  options // Optional configurations are detailed in the table below
)
```

<table><thead><tr><th width="192">Name</th><th width="89">Type</th><th>Description</th></tr></thead><tbody><tr><td>appId</td><td>string</td><td>This parameter means the same thing as "mchNo"</td></tr><tr><td>externalID</td><td>string</td><td>The unique identifier provided by you to reference the KYB entity to be verified. This should match the <code>getExternalID()</code> passed by <code>provider.getExternalID</code>.</td></tr><tr><td>accessToken</td><td>string</td><td>The access token obtained from <a data-mention href="#how-to-generate-an-access-token-with-api_key">#how-to-generate-an-access-token-with-api_key</a></td></tr><tr><td>options.programNo</td><td>string?</td><td>If you have activated multiple programs running in parallel, please pay attention to this setting:<br><br>The param can be found in Dashboard and please make sure the program is enabled. The SDK will take the number of the first activated program as the default value if this parameter is not provided in the code.</td></tr></tbody></table>
{% endtab %}

{% tab title="Return" %}

#### **Return Value**

The function returns an object with the following property:

<table><thead><tr><th width="184">Property</th><th width="96">Type</th><th>Description</th></tr></thead><tbody><tr><td>status</td><td>int</td><td>The current verification status as an integer. See the status codes table below.</td></tr><tr><td>statusDesc</td><td>string</td><td>A human-readable description of the current verification status.</td></tr></tbody></table>

**Status Codes Explanation**

<table><thead><tr><th width="128">Status Code</th><th width="203">Status Name</th><th>Description</th></tr></thead><tbody><tr><td><code>1</code></td><td>Verification Started</td><td>The KYB verification process has been initiated.</td></tr><tr><td><code>2</code></td><td>Info Submitted</td><td>The user has completed and submitted their information.</td></tr><tr><td><code>3</code></td><td>Under Review</td><td>The submitted information is being reviewed by the compliance team.</td></tr><tr><td><code>4</code></td><td>Resubmission Required</td><td>Further information or clarification is needed.</td></tr><tr><td><code>5</code></td><td>Verification Passed</td><td>The KYB verification was successful.</td></tr><tr><td><code>6</code></td><td>Verification Failed</td><td>The KYB verification was unsuccessful.</td></tr></tbody></table>
{% endtab %}
{% endtabs %}

***

## **How to Generate an Access Token with API\_KEY** <a href="#access-token" id="access-token"></a>

To use your API\_KEY to obtain an accessToken, you will need to make a specific HTTP request. Here's how you can do it:

{% hint style="info" %}
**NOTE:** The generated accessToken is valid for **30 minutes** and will expire automatically after that.
{% endhint %}

{% tabs %}
{% tab title="Endpoint" %}

```ruby
POST https://agw.zk.me/kybpopup/api/generate-access-token
```

{% hint style="info" %}
Please remember to modify the <mark style="color:blue;">`Content-Type`</mark> in the request header to <mark style="color:blue;">`application/json`</mark>. Failing to do so might result in a <mark style="color:red;">`Parameter Error`</mark> response.
{% endhint %}
{% endtab %}

{% tab title="Request" %}

<table><thead><tr><th width="111.2421875">Name</th><th width="81.3359375">Required</th><th width="76.484375">Type</th><th>Desc</th></tr></thead><tbody><tr><td>apiKey</td><td>True</td><td>string</td><td>The API_KEY provided by zkMe.</td></tr><tr><td>appId</td><td>True</td><td>string</td><td>A unique identifier (mchNo) to DApp provided by zkMe.</td></tr></tbody></table>

{% hint style="info" %} <mark style="color:orange;">`API_KEY`</mark>can be found in [the Configuration section](https://dashboard.zk.me/integration) of the Integration on the zkMe Dashboard.
{% endhint %}
{% endtab %}

{% tab title="Response" %}

<details>

<summary><mark style="color:green;"><strong>Success</strong></mark></summary>

```json
{
    "code": 80000000,
    "data": {
        "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.xxxxxxx",
        "expiresIn": 1800
    },
    "msg": "success",
    "timestamp": 1691732474552
}
```

</details>

<details>

<summary><mark style="color:red;"><strong>Exception (AppId and API_KEY not matched)</strong></mark></summary>

```json
{
    "code": 81000014,
    "data": null,
    "msg": "AppID and API Key do not match. Access token generation failed",
    "timestamp": 1691732568774
}
```

</details>

<details>

<summary><mark style="color:red;"><strong>Exception (Parameter Error)</strong></mark></summary>

```json
{
    "code": 80000002,
    "data": null,
    "msg": "parameter error",
    "timestamp": 1691732593484
}
```

</details>
{% endtab %}
{% endtabs %}

***

## ZkMeKybWidget instance methods

<details>

<summary>launch()</summary>

Launch the zkMe KYB widget and it will be displayed in the center of your webpage.

<pre class="language-typescript"><code class="lang-typescript"><strong>launch(): void
</strong></code></pre>

</details>

<details>

<summary>on()</summary>

Listen to zkMe KYB widget events.

```typescript
on(event: 'kybFinished', callback: KybFinishedHook): void;
on(event: 'close', callback: () => void): void;
```

</details>

<details>

<summary>hide()</summary>

Hide the zkMe widget.

```typescript
hide(): void
```

</details>

<details>

<summary>destroy()</summary>

Remove the message event listener registered by the zkMe widget from the window and destroy the DOM node.

```typescript
destroy(): void
```

</details>

***


# Customize Widget UI

While our default design style aims to meet a variety of needs, specific projects may require a more tailored approach. Therefore, zkMe expanded the Widget customization features.

In our dashboard, you now have the ability to alter the zkMe Widget style, including font color, background color, and more. This provides you with the flexibility to adapt the zkMe Widget to fit your project needs or personal preferences effectively.

We will now guide you through the utilization of this feature in detail.

<figure><img src="/files/vsC7SRPIMYgYq5CXeKg0" alt=""><figcaption></figcaption></figure>

On the left, you'll find our custom editing area. On the right, we display real-time previews, showcasing how the Widget will appear on both PC Browsers and Mobile Devices by clicking the toggle button on the top.

### Color Mode

<div align="left"><figure><img src="/files/kHRBJLrpm9gyj1soNysw" alt=""><figcaption></figcaption></figure></div>

As it stands, the zkMe Widget's default color mode aligns with the system settings. This means that the widget's background color, icon background color, and font color adapt to the display mode on the user's device. However, selecting either `Light mode` or `Dark mode` overrides this functionality, meaning the color style will then remain constant, regardless of changes to the user's system settings.

<figure><img src="/files/GJ6GKUyXt0HfdZRHxKoi" alt=""><figcaption><p>Light Mode (Default theme color)</p></figcaption></figure>

<figure><img src="/files/Yx3jeG3GaplEUj2JjSfP" alt=""><figcaption><p>Dark Mode (Default theme color)</p></figcaption></figure>

### Theme Color

We provide 16 distinct color choices, along with a color palette option in our editor, to ensure a perfect match with your project's theme.

<div align="left"><figure><img src="/files/IY3IPUSuFZlQrhwomnfj" alt=""><figcaption></figcaption></figure></div>

The zkMe Widget will use the following color values when no theme color is set:

<div align="left"><figure><img src="/files/BCVlVlyTx69lo1rIdPe1" alt=""><figcaption></figcaption></figure></div>

{% hint style="info" %}
When a color from the palette is chosen, it's designated as -vt-c-primary-1. The remaining two colors are determined using [Ant Design](https://ant.design/docs/spec/colors)'s palette tool. If the way these color values are calculated doesn't quite meet your needs, feel free to adjust them by adding your own CSS.
{% endhint %}

### Advance Setting

<div align="left"><figure><img src="/files/nVZTVpRxKn6QNJbKfLhz" alt=""><figcaption></figcaption></figure></div>

This textarea lets you insert your own CSS to customize the zkMe Widget. If you adjust the color here, it'll take precedence over the theme color selector. We've implemented a few limitations on the custom CSS uploads; actions such as adding pseudo-elements, concealing elements in the widget, or altering the image source of background and icons are not allowed.

{% hint style="info" %}
To pinpoint and adjust the style of elements within a widget more effectively, you can inspect the specific elements using your browser. Subsequently, you can make alterations based on their class names.
{% endhint %}

## Examples

Here are some straightforward examples to assist you in navigating the Advanced Settings.

### Background Color

To modify the background color of the zkMe Widget to a solid color other than black or white, you may apply the subsequent CSS.

```css
:root {
  --color-background: pink;
  --vt-c-white-bg: pink;
}
```

<figure><img src="/files/J7mldUCMsCdLXGDei7tM" alt=""><figcaption></figcaption></figure>

To switch the background color to a gradient, we suggest updating the background of the given class name and adjusting the color attributes `--color-background` and `--vt-c-white-bg`.

```css
:root {
  --color-background: transparent;
  --vt-c-white-bg: linear-gradient(0deg, rgba(34,193,195,1) 0%, rgba(253,187,45,1) 100%);
}

.sty1-cell {
  background: linear-gradient(0deg, rgba(34,193,195,1) 0%, rgba(253,187,45,1) 100%);
}
```

<figure><img src="/files/jO0v0jPA57XTKH91klNy" alt=""><figcaption></figcaption></figure>

### Button Style

Most of the buttons within the zkMe Widget utilize the el-button class name. This allows you to easily style the Widget's buttons using this class name.

<pre class="language-css"><code class="lang-css"><strong>.el-button {
</strong>  background: linear-gradient(90deg, #FFC658 0.27%, #F712A9 100.27%);
  border: none;
}
</code></pre>

<figure><img src="/files/iPndTIo81t4X76O8v7yX" alt=""><figcaption></figcaption></figure>

### Font Color

To adjust the font color in zkMe Widget, you can generally do so by altering the color attribute of the relevant preset.

```css
:root {
  --color-text-9: #3974c2;
  --color-text-6: 57, 116, 194;
  --color-text-7: #887272;
}
```

<figure><img src="/files/A1MrQhmqRxsLBEI6VCba" alt=""><figcaption></figcaption></figure>


# Mobile SDK


# zkOBS - Open Banking Services

## Use Case

This guide provides detailed instructions on how to integrate zkMe’s zkTLS SDK into your Flutter mobile application for secure Open Banking Services (zkOBS) verification. Through Platform Channels, your Flutter app can seamlessly interact with the native zkTLS SDK on Android and iOS platforms, enabling user data authorization and verification without redirection to external browsers or third-party applications.

This integration approach aims to reduce user friction and drop-off while ensuring sensitive data is never exposed to the app. Users generate privacy-preserving cryptographic proofs, making it an ideal solution for mobile-first products that require secure verification with a single cross-platform Flutter codebase.

***

## Requirements & Compatibility

Before starting the integration, ensure your development environment meets the following minimum requirements:&#x20;

<table><thead><tr><th width="156.1875">Platform</th><th>Minimum Supported Version</th><th>Target/Distribution</th></tr></thead><tbody><tr><td><strong>Android</strong></td><td>Android 7.0 (API 24)</td><td>Android 14 (API 34)</td></tr><tr><td><strong>iOS</strong></td><td>iOS 13.0</td><td>CocoaPods</td></tr></tbody></table>

The SDK is provided as native libraries. It is compatible with all **stable Flutter releases** that support standard Platform Channels. No additional Flutter-side dependencies are required beyond the services library.

***

## Integration Workflow Overview

Integrating the SDK requires platform-specific native integration for Android and iOS:

* [**Android Native Integration**](#android-native-integration)**:** Configure your Android project to include the SDK and handle calls from Flutter to start the verification process.
* [**iOS Native Integration**](#ios-native-integration)**:** Configure your iOS project to include the SDK and invoke the native zkTLS verification flow from your view controller.

***

## Android Native Integration

This section details how to integrate the zkTLS SDK into the Android portion of your Flutter project and implement the Platform Channel handler to respond to calls from Dart.

### Step 1. Add Maven Repository

Add a private Maven repository in `settings.gradle.kts` (or `settings.gradle`) in the project `root` directory.

{% tabs %}
{% tab title="Kotlin" %}
{% code expandable="true" %}

```kotlin
// settings.gradle.kts
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()

        maven {
            url = uri("https://maven.pkg.github.com/zkMeLabs/selvage-verifier-android-sdk")
            credentials {
                username = "GITHUB_OWNER"
                password = "GITHUB_TOKEN"
            }
        }

        // Official Flutter Engine Repository
        maven {
            url = uri("https://storage.googleapis.com/download.flutter.io")
        }
    }
}
```

{% endcode %}
{% endtab %}

{% tab title="Groovy" %}
{% code expandable="true" %}

```groovy
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()

        maven {
            url = uri('https://maven.pkg.github.com/zkMeLabs/selvage-verifier-android-sdk')
            credentials {
                username = 'zktls-selvage'
                password = '<YOUR_GITHUB_TOKEN>'
            }
        }
        
        // Official Flutter Engine Repository
        maven {
            url = uri('https://storage.googleapis.com/download.flutter.io')
        }
    }
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

### Step 2. Add Dependencies

Add the SDK dependency in the `build.gradle.kts` (or `build.gradle`) file of your `app` module.

{% tabs %}
{% tab title="Kotlin" %}

```kotlin
// build.gradle.kts
dependencies {
    implementation("com.zkme.selvage.verifier:selvage-verifier-sdk:1.0.0")
}
```

{% endtab %}

{% tab title="Groovy" %}

```groovy
// build.gradle
dependencies {
    implementation 'com.zkme.selvage.verifier:selvage-verifier-sdk:1.0.0'
}
```

{% endtab %}
{% endtabs %}

{% hint style="info" %}
Note: Click the **Sync Now** button in Android Studio and wait for the dependency download to complete.
{% endhint %}

### Step 3. Handle Flutter Calls and Start Verification

To start the verification process on Android when triggered from Flutter, add the following code to your `MainActivity`. This code invokes the native `SelvageSdk.startVerification()` API and handles verification callbacks, including success, error, and cancellation.

{% tabs %}
{% tab title="Kotlin" %}
{% code expandable="true" %}

```kotlin
import com.zkme.selvage.verifier.SelvageSdk
import com.zkme.selvage.verifier.SelvageVerificationResult
import com.zkme.selvage.verifier.SelvageVerificationError

class MainActivity : AppCompatActivity() {
    
    private fun startVerification() {
        SelvageSdk.startVerification(
            context = this,
            requestId = "your-request-id",
            appId = "your-app-id",          
            apiKey = "your-api-key",       
            providerId = "your-provider-id",
            callback = object : SelvageSdk.Callback {
                override fun onSuccess(result: SelvageVerificationResult) {
                    // Verification successful
                    Log.d("Selvage", "Verification Successful")
                    Log.d("Selvage", "Session ID: ${result.sessionId}")
                    Log.d("Selvage", "Proofs JSON: ${result.proofsJson}")
                    
                    // Send proofsJson to your backend for verification
                }
                
                override fun onError(error: SelvageVerificationError) {
                    // Verification failed
                    Log.e("Selvage", "Verification Failed: ${error.code} - ${error.message}")
                    Toast.makeText(this@MainActivity, 
                        "Verification Failed: ${error.message}", 
                        Toast.LENGTH_SHORT).show()
                }
                
                override fun onCancelled() {
                    // User canceled verification
                    Log.d("Selvage", "User cancels verification")
                    Toast.makeText(this@MainActivity, 
                        "User cancels verification", 
                        Toast.LENGTH_SHORT).show()
                }
            }
        )
    }
}
```

{% endcode %}
{% endtab %}

{% tab title="Java" %}
{% code expandable="true" %}

```java
import com.zkme.selvage.verifier.SelvageSdk;
import com.zkme.selvage.verifier.SelvageVerificationResult;
import com.zkme.selvage.verifier.SelvageVerificationError;

public class MainActivity extends AppCompatActivity {
    
    private void startVerification() {
        SelvageSdk.INSTANCE.startVerification(
            this,
            "your-request-id",
            "your-app-id",
            "your-api-key",
            "your-provider-id",
            new SelvageSdk.Callback() {
                @Overridepublic void onSuccess(@NonNull SelvageVerificationResult result) {
                    Log.d("Selvage", "Verification Successful: " + result.getSessionId());
                    Log.d("Selvage", "Proofs: " + result.getProofsJson());
                }
                
                @Overridepublic void onError(@NonNull SelvageVerificationError error) {
                    Log.e("Selvage", "Verification Failed: " + error.getCode() + " - " + error.getMessage());
                }
                
                @Overridepublic void onCancelled() {
                    Log.d("Selvage", "User cancels verification");
                }
            }
        );
    }
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

### API Reference

<details>

<summary><code>SelvageSdk</code></summary>

The main entry class of the SDK, providing verification-related methods.

**Method:** `startVerification`

**Parameters:**

<table><thead><tr><th width="143.90625">Name</th><th width="200.91015625">Type</th><th>Description</th></tr></thead><tbody><tr><td><code>context</code></td><td>Context</td><td>Android context, typically an <code>Activity</code>.</td></tr><tr><td><code>requestId</code></td><td>String</td><td>Unique identifier for this verification request.</td></tr><tr><td><code>appId</code></td><td>String</td><td>App ID</td></tr><tr><td><code>apiKey</code></td><td>String</td><td>API key</td></tr><tr><td><code>providerId</code></td><td>String</td><td>Provider identifier for the verification flow.</td></tr><tr><td><code>callback</code></td><td>SelvageSdk.Callback</td><td>Callback used to receive verification results.</td></tr></tbody></table>

**Return Value:** None.

</details>

<details>

<summary><code>SelvageSdk.Callback</code></summary>

Verification result callback interface.

**Methods:**

**`onSuccess(result: SelvageVerificationResult)`**: Called when the verification flow completes successfully.

* **Parameters:** `result: SelvageVerificationResult` : Result object delivered on successful verification.

***

**`onError(error: SelvageVerificationError)`**: Called when the verification flow fails.

* **Parameters:** `error: SelvageVerificationError`: Error object describing the failure.

***

**`onCancelled()`**: Called when the user cancels the verification flow.

* **Parameters:** None.

</details>

<details>

<summary><code>SelvageVerificationResult</code></summary>

Result object delivered via `SelvageSdk.Callback.onSuccess` when the verification flow completes successfully.

***

**Properties:**

| Property     | Type   | Description                |
| ------------ | ------ | -------------------------- |
| `sessionId`  | String | Session ID                 |
| `proofsJson` | String | Proof data in JSON format. |

***

**Example: Handling a successful verification result**

```kotlin
override fun onSuccess(result: SelvageVerificationResult) {
    val sessionId = result.sessionId
    val proofs = result.proofsJson
    // Send proofs to the backend for verification
    sendToBackend(sessionId, proofs)
}
```

</details>

***

## iOS Native Integration

### Step 1. `Podfile` Integration

Add the following to your `Podfile`:

```bash
source '<https://github.com/zkMeLabs/zktls-specs.git>'
source '<https://cdn.cocoapods.org/>'

platform :ios, '13.0'
use_frameworks! :linkage => :static

target 'YourApp' do
  pod 'SelvageVerifierSDK', '1.0.0'
end
```

### Step 2. Initial Setup

```bash
# 1. Add the private source to the local repository
pod repo add zktls-specs <https://github.com/zkMeLabs/zktls-specs.git >

# 2. Update the source
pod repo update zktls-specs

# 3. Install Pods
pod install
```

### Step 3. iOS Configuration

#### 3.1 Info.plist

Ensure the following network security configuration is included in your `Info.plist`:

```xml
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>
```

#### 3.2 Build Settings

In your Xcode project’s **Build Settings**, configure the following:

| Setting                            | Value                   | Description                                      |
| ---------------------------------- | ----------------------- | ------------------------------------------------ |
| **Enable Bitcode**                 | No                      | Flutter does not support Bitcode.                |
| **Build Active Architecture Only** | Debug: Yes, Release: No | Ensure Release builds include all architectures. |
| **Excluded Architectures (Debug)** | i386                    | Exclude 32-bit emulator architectures.           |

### Step 4. Start Verification on iOS

{% tabs %}
{% tab title="Swift" %}
{% code expandable="true" %}

```swift
import UIKit
import SelvageVerifierSDK

class ViewController: UIViewController {
    
    @IBAction func startVerificationTapped(_ sender: UIButton) {
        startVerification()
    }
    
    private func startVerification() {
        SelvageSdk.startVerification(
            presenter: self,                  // Optional; if not provided, the currently displayed ViewController will be automatically located
            appId: "your-app-id",           
            apiKey: "your-api-key",         
            providerId: "your-provider-id"
        ) { [weak self] result in
            // The callback is executed on the main thread
            switch result {
            case .success(let verificationResult):
                // Verification successful
                print("Verification Successful")
                print("Session ID: \(verificationResult.sessionId)")
                print("Proofs JSON: \(verificationResult.proofsJson)")
                
                // Send proofsJson to the backend for verification
                self?.sendProofsToBackend(verificationResult.proofsJson)
                
            case .failure(let error):
                // Verification failed or canceled
                print("Verification Failed: \(error.localizedDescription)")
                self?.handleVerificationError(error)
            }
        }
    }
    
    private func sendProofsToBackend(_ proofsJson: String) {
        // Implement your backend verification logic
    }
    
    private func handleVerificationError(_ error: Error) {
    }
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

### API Reference

<details>

<summary><code>SelvageSdk</code></summary>

The main entry class of the SDK, providing static methods.

**Method:** `startVerificationWithAuth`

**Parameters:**

<table><thead><tr><th width="110.2935791015625">Name</th><th width="160.6097412109375">Type</th><th>Description</th></tr></thead><tbody><tr><td><code>presenter</code></td><td>UIViewController?</td><td>The view controller used to present the verification interface. If <code>nil</code>, the SDK automatically locates the currently displayed view controller.</td></tr><tr><td><code>appId</code></td><td>String</td><td>Application ID issued by zkTLS.</td></tr><tr><td><code>apiKey</code></td><td>String</td><td>API key associated with your application.</td></tr><tr><td><code>providerId</code></td><td>String</td><td>Provider identifier for the verification flow.</td></tr><tr><td><code>callback</code></td><td>Callback</td><td>Callback interface used to receive verification results.</td></tr></tbody></table>

**Return Value:** None.

</details>

<details>

<summary><code>VerificationResult</code></summary>

Result object delivered via the verification success callback when the verification flow completes successfully.

**Properties:**

| Property     | Type   | Description                                                                                    |
| ------------ | ------ | ---------------------------------------------------------------------------------------------- |
| `sessionId`  | String | Unique identifier of the verification session.                                                 |
| `proofsJson` | String | Proof payload in JSON format. This value should be submitted to your backend for verification. |

**Example: Handling a successful verification result**

```swift
case .success(let result):
    print("Session ID: \(result.sessionId)")
    print("Proofs JSON: \(result.proofsJson)")

    // Parse proofs JSON if needed
    if let data = result.proofsJson.data(using: .utf8),
       let json = try? JSONSerialization.jsonObject(with: data) as? [[String: Any]] {
        print("Parsed proofs array: \(json)")
    }
```

</details>

<details>

<summary><code>VerificationError</code></summary>

Error type delivered via the verification failure callback when the verification flow fails. This error object describes the reason why the verification did not complete successfully.

***

**Error Cases:**

* `invalidArguments(message)`\
  Indicates that one or more required arguments are missing or invalid.
* `sdkBusy`\
  Indicates that the SDK is currently processing another verification request.
* `verificationFailed(message, _, type)`\
  Indicates that the verification process completed but did not meet the required verification criteria.
* `flutterChannelError(code, message, _)`\
  Indicates an internal error occurred while communicating with the Flutter platform channel.

***

**Example: Handling a verification failure**

```swift
case .failure(let error):
    if let sdkError = error as? SelvageSdk.VerificationError {
        switch sdkError {

        case .invalidArguments(let message):
            // Handle invalid or missing arguments

        case .sdkBusy:
            // Handle SDK busy state

        case .verificationFailed(let message, _, let type):
            // Handle verification failure

        case .flutterChannelError(let code, let message, _):
            // Handle Flutter channel communication error

        default:
            // Handle other errors
        }
    }
```

</details>

***

## FAQs

This section collects common questions and their solutions that developers may encounter while using the SDK.

<details>

<summary>How to handle network disconnection?</summary>

The SDK will throw a `zkTlsException` upon network disconnection. Developers should catch this exception at the application layer and prompt the user to check their network connection or retry later.

</details>

<details>

<summary>Why did my data collection request fail?</summary>

Please check the following: Is the API Key correct? Is the zkTLS backend service address reachable? Is the Provider Schema valid? Is the target URL accessible? Detailed error messages can be obtained by enabling SDK logging.

</details>

<details>

<summary>Does the SDK support data collection from all websites?</summary>

The zkTLS protocol theoretically supports all TLS-based HTTPS websites. However, the specific data extraction capability depends on the definition of the Provider Schema and the website structure. For complex websites or those with dynamic content, customized Provider Schemas may be required. It is recommended to thoroughly test target websites before integration.

</details>


# zkMe API

The section describes the zkMe OpenAPI, which is also known as zkMe API. Its subpages focus on retrieving zkKYC (Know Your Customer) and KYT (Know Your Transaction) results via API sepcifically.

## **Getting Started**

Before calling any zkMe API endpoints, please make sure you have created an account on the [zkMe Dashboard](https://dashboard.zk.me/) and completed the initial setup.

You can follow the [Onboarding Checklist](/hub/start/onboarding) to obtain your required parameters, including:

* **mchNo (AppID)**
* **apiKey (API Key)**

These values are needed to authenticate your API requests.

## Choose What You Want to Integrate <a href="#rate-limits" id="rate-limits"></a>

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td><h4><strong>Need Individual compliance verification?</strong></h4></td><td>Use <strong>zkKYC</strong> to check a user’s verification status and confirm whether they meet your requirements.</td><td>👉 <a href="/pages/roYBsMVUPzDJqFZN2ZKc">Continue with the zkKYC API guide.</a></td></tr><tr><td><h4>Need transaction risk insights?</h4></td><td>Use <strong>KYT</strong> to screen wallet addresses and transactions, detect risk signals, and enhance your compliance workflow.</td><td>👉 <a href="/pages/swjtR0iTut6RiU1fefPV">Continue with the KYT API guide.</a></td></tr><tr><td><h4><strong>Need business compliance verification?</strong></h4></td><td>Use <strong>zkKYB</strong> to verify companies and business entities and confirm whether they meet your compliance requirements.</td><td>👉 <a href="/pages/gPvM3zdw6uUYm1W7HWFj">Continue with the zkKYB API guide.</a></td></tr></tbody></table>

## Rate Limits <a href="#rate-limits" id="rate-limits"></a>

| Plan     | Rate Limit             |
| -------- | ---------------------- |
| Standard | 10 call / second / key |


# Verify zkKYC Status

{% hint style="info" %}
Before making any API requests, please refer to the [zkMe API](/hub/start/onboarding/integration/api#getting-started) section on the [zkMe API](/hub/start/onboarding/integration/api) page to obtain the necessary API access parameters.
{% endhint %}

## Get Users List <a href="#get-users-list" id="get-users-list"></a>

Returns a list of users who initiated the verification flow under a dashboard account.

{% tabs %}
{% tab title="Endpoint" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/kyc/getUsersList
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
{
  "mchNo": "YourAppID" ,
  "apiKey": "YourApiKey",
  "programNo": "YourProgramNo",
  "page": 1,
}
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="206">Name</th><th width="155">Type</th><th>Description</th></tr></thead><tbody><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a>.</td></tr><tr><td>apiKey</td><td>string</td><td>Your API Key.</td></tr><tr><td>programNo</td><td>string</td><td>Same as the programNo you pass for the SDK integration. </td></tr><tr><td>page</td><td>integer</td><td>Returns users in blocks of 50 (page 1 = 1–50, page 2 = 51–100, etc.). If fewer users exist, all are returned.</td></tr></tbody></table>
{% endtab %}

{% tab title="Response" %}

#### Sample Response <a href="#sample-response" id="sample-response"></a>

```json
{
  "code": ...,
  "data": {
    "total": ...,
    "totalPage": ...,
    "users": [
      {
        "clientUserIdentifier": [
          {
            "blockchainId": ...,
            "network": "...",
            "tokenId": "...",
            "userId": ...,
            "walletAddress": "..."
          }
        ],
        "completedTimeUnix": "...",
        "ssiWallet": "...",
        "status": "...",
        "zkmeAccount": "...",
        "zkmeId": "..."
      },
    ]
  },
  "msg": "...",
  "timestamp": ...
}
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

| Name      | Type   | Description                                             |
| --------- | ------ | ------------------------------------------------------- |
| code      | number | Business status code, e.g. `80000000` indicates success |
| msg       | string | Message describing the result                           |
| timestamp | number | Response timestamp in Unix milliseconds                 |
| data      | object | Main data object (see **`data` Object** below)          |

***

**`data` Object**

| Name      | Type           | Description                                   |
| --------- | -------------- | --------------------------------------------- |
| total     | number         | Total number of users matched                 |
| totalPage | number         | Total number of pages                         |
| users     | array\<object> | List of user objects (see **`users` Object**) |

***

**`users` Object**

<table><thead><tr><th width="182.548828125">Name</th><th width="128.3125">Type</th><th>Description</th></tr></thead><tbody><tr><td>clientUserIdentifier</td><td>array&#x3C;object></td><td>Identifiers linked to this user (see <strong><code>clientUserIdentifier</code> Object</strong>)</td></tr><tr><td>completedTimeUnix</td><td>string</td><td>Completion time (Unix milliseconds, as string)</td></tr><tr><td>ssiWallet</td><td>string</td><td>zkMe SSI wallet address bound to the user.</td></tr><tr><td>status</td><td>string</td><td><p>Current KYC/verification status. Possible values include:</p><ul><li>Verification Started</li><li>OCR Passed</li><li>Liveness Checked</li><li>ZKP Generated</li><li>SBT Minted</li><li><p>OnChain Minted</p><ul><li>Note: Only applicable to <a href="/pages/OUIXBnh5tvUU4oUY9vs5#on-chain-mint-default">On-chain Mint</a> </li></ul></li><li>KYC Passed</li><li>Verification Failed</li></ul></td></tr><tr><td>zkmeAccount</td><td>string</td><td>The email address used to log in to zkMe.</td></tr><tr><td>zkmeId</td><td>string</td><td>Unique zkMe user ID</td></tr></tbody></table>

{% hint style="info" %}
**Note:** <kbd>`clientUserIdentifier`</kbd> will be empty if the user’s `status` has not yet reached `KYC_PASSED`.
{% endhint %}

***

**`clientUserIdentifier` Object**

<table><thead><tr><th width="129.77734375">Name</th><th width="100">Type</th><th>Description</th></tr></thead><tbody><tr><td>blockchainId</td><td>number</td><td>Chain ID</td></tr><tr><td>network</td><td>string</td><td>Chain name </td></tr><tr><td>tokenId</td><td>string</td><td>The ID of the Soulbound Token (SBT) minted for the user on the chain.</td></tr><tr><td>walletAddress</td><td>string</td><td>User’s wallet address from the client system.</td></tr><tr><td>userId</td><td>string</td><td>User’s email address, or another non-wallet unique identifier from the client system.</td></tr></tbody></table>

{% hint style="info" %}
**Note:**&#x20;

The returned fields are returned is determined by the configured [**decentralization level**](/hub/start/onboarding/zkkyc-levels)**:**&#x20;

* For [On-chain Mint](/hub/start/onboarding/zkkyc-levels#on-chain-mint-default) integrations, the fields `blockchainId`, `network`, `tokenId`, and `walletAddress` are returned. `userId` is not returned.
* For [Cross-chain](/hub/start/onboarding/zkkyc-levels#cross-chain) integrations, only `userId`  is returned.
  {% endhint %}

***

{% endtab %}
{% endtabs %}

## Get Users KYC Result Overview  <a href="#get-get-users-kyc-result-overview" id="get-get-users-kyc-result-overview"></a>

Returns the verification status of the user for the following credentials: [Proof-of-Citizenship (PoC)](/hub/what/zkkyc/zkpoc), [Proof-of-Location (PoL)](/hub/what/zkkyc/zkpol), and [AML Check (zkAML)](/hub/what/zkkyc/amlme).&#x20;

{% tabs %}
{% tab title="Endpoint" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/queryKycInfoByAddress
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
{
  "mchNo": "YourAppID" ,
  "apiKey": "YourApiKey",
  "programNo": "YourProgramNo",
  "account": "walletAddress", // or email, or other unique identifiers
  "chainId": "YourChainID"
}
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="206">Name</th><th width="155">Type</th><th>Description</th></tr></thead><tbody><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a>.</td></tr><tr><td>apiKey</td><td>string</td><td>Your API Key.</td></tr><tr><td>programNo</td><td>string</td><td>Same as the programNo you pass for the SDK integration. </td></tr><tr><td>account</td><td>string</td><td>User's wallet address (recommended), email address, or other unique identifier</td></tr><tr><td>chainId</td><td>string</td><td>Same as the param chainId you pass for the SDK integration. </td></tr></tbody></table>

#### Supported Chain List

{% tabs %}
{% tab title="Mainnet" %}

| Chain Name      | zkMe Chain ID |
| --------------- | ------------- |
| Aptos           | aptos-1       |
| Arbitrum        | 42161         |
| Base            | 8453          |
| BNB Smart Chain | 56            |
| BounceBit       | 6001          |
| Ethereum        | 1             |
| Kaia            | 8217          |
| Manta           | 169           |
| Neutron         | neutron-1     |
| Polygon         | 137           |
| Ronin           | 2020          |
| Solana          | solana        |
| TON             | ton           |
| {% endtab %}    |               |

{% tab title="Testnet" %}

| Chain Name                | zkMe Chain ID |
| ------------------------- | ------------- |
| Aptos Testnet             | aptos-2       |
| Plume Testnet             | 98864         |
| Scroll Sepolia Testnet    | 534351        |
| Sei Testnet               | atlantic-2    |
| ZetaChain Athens3 Testnet | 7001          |
| {% endtab %}              |               |
| {% endtabs %}             |               |
| {% endtab %}              |               |

{% tab title="Response" %}

#### Sample Response <a href="#sample-response" id="sample-response"></a>

```json
{
  "zkme_id":"...",
  "kycStatus":"...",
  "kycCompleteTimeUnix":"...", 
  "ssiAddress":"...",
  "verifierValues":{
    "sanction":...,
    "age":...,
    "citizenship":...,
    "location":...,
    "unique":...,
  },
}
```

#### Fields Explanation <a href="#fields" id="fields"></a>

<table><thead><tr><th width="218">Name</th><th width="96">Type</th><th>Description</th></tr></thead><tbody><tr><td>zkme_id</td><td>string</td><td>Return the zkMe id corresponding to the zkMe account linked to the provided address.</td></tr><tr><td>kycStatus</td><td>string</td><td><p>Return users' KYC status, including 8-9 stages: </p><ul><li>Not Started</li><li>Verification Started</li><li>OCR Passed</li><li>Liveness Checked</li><li>ZKP Generated</li><li>SBT Minted</li><li><p>OnChain Minted</p><ul><li>Note: Only applicable to <a href="/pages/OUIXBnh5tvUU4oUY9vs5#on-chain-mint-default">On-chain Mint</a> </li></ul></li><li>KYC Passed</li><li>Verification Failed</li></ul></td></tr><tr><td>kycCompleteTimeUnix</td><td>string</td><td>Unix timestamp of the mint time of SBT minting in SSI wallet.</td></tr><tr><td>ssiAddress</td><td>string</td><td>User's SSI wallet address.</td></tr><tr><td>verifierValues</td><td>object</td><td>List of verifierValues objects (see <strong><code>verifierValues</code> Object</strong>)</td></tr></tbody></table>

***

**`verifierValues` Object**

<table><thead><tr><th width="218">Name</th><th width="96">Type</th><th>Description</th></tr></thead><tbody><tr><td>sanction</td><td>bool</td><td><p>Return the user's AML Screening verification result with the following output:</p><ul><li>If the user passes, return <code>true</code>.</li><li>If the user fails, return <code>false</code>.</li><li>If the AML Screening verification is not configured for the program, return <code>null</code>.</li></ul></td></tr><tr><td>age</td><td>bool</td><td><p>Return the user's age verification result with the following output:</p><ul><li>If the user passes, return <code>true</code>.</li><li>If the user fails, return <code>false</code>.</li><li>If the Proof of Citizenship is not configured for this program, return <code>null</code>.</li></ul></td></tr><tr><td>citizenship</td><td>bool</td><td><p>Return the user's citizenship verification result with the following output:</p><ul><li>If the user passes, return <code>true</code>.</li><li>If the user fails, return <code>false</code>.</li><li>If the Proof of Citizenship is not configured for the program, return <code>null</code>.</li></ul></td></tr><tr><td>location</td><td>bool</td><td><p>Return the user's location verification result with the following output:</p><ul><li>If the user passes, return <code>true</code>.</li><li>If the user fails, return <code>false</code>.</li><li>If the Proof of Location is not configured for the program, return <code>null</code>.</li></ul></td></tr><tr><td>unique</td><td>bool</td><td><p>Return the user's ID-based uniqueness verification result with the following output:</p><ul><li>If the user passes, return <code>true</code>.</li><li>If the user fails, return <code>false</code>.</li><li>If the Uniqueness Check is not configured for the program, return <code>null</code>.</li></ul></td></tr></tbody></table>
{% endtab %}
{% endtabs %}

## Get Users Address Proof Result Overview

Returns the verification status of the user for the following credentials: [Proof-of-Address (PoA)](/hub/what/zkkyc/zkpoa).&#x20;

{% tabs %}
{% tab title="Endpoint" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/queryPoAInfoByAddress 
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
{
  "mchNo": "YourAppID" ,
  "apiKey": "YourApiKey",
  "programNo": "YourProgramNo",
  "account": "walletAddress", // or email, or other unique identifiers
}
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="206">Name</th><th width="155">Type</th><th>Description</th></tr></thead><tbody><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a>.</td></tr><tr><td>apiKey</td><td>string</td><td>Your API Key.</td></tr><tr><td>programNo</td><td>string</td><td>Same as the programNo you pass for the SDK integration. </td></tr><tr><td>account</td><td>string</td><td>User's wallet address (recommended), email address, or other unique identifier</td></tr></tbody></table>
{% endtab %}

{% tab title="Response" %}

#### Sample Response <a href="#sample-response" id="sample-response"></a>

```json
{
    "code": ...,
    "data": [
        {
            "completedTimeUnix": "...",
            "ssiAddress": "...",
            "status": "...",
            "verifierValues": {
                "countryRegion": ...
            },
            "zkmeId": "..."
        }
    ],
    "msg": "...",
    "timestamp": ...
}
```

#### Fields Explanation <a href="#fields" id="fields"></a>

| Name      | Type   | Description                                             |
| --------- | ------ | ------------------------------------------------------- |
| code      | number | Business status code, e.g. `80000000` indicates success |
| msg       | string | Message describing the result                           |
| timestamp | number | Response timestamp in Unix milliseconds                 |
| data      | object | Main data object (see **`data` Object** below)          |

***

**`data` Object**

<table><thead><tr><th width="218">Name</th><th width="96">Type</th><th>Description</th></tr></thead><tbody><tr><td>completedTimeUnix</td><td>string</td><td>Unix timestamp of the mint time of SBT minting in SSI wallet.</td></tr><tr><td>ssiAddress</td><td>string</td><td>User's SSI wallet address.</td></tr><tr><td>status</td><td>string</td><td><p>Return users' KYC status, including 7 stages: </p><ul><li>Not Started</li><li>Verification Started</li><li>OCR Passed</li><li>ZKP Generated</li><li>SBT Minted</li><li>Verification Passed</li><li>Verification Failed</li></ul></td></tr><tr><td>zkme_id</td><td>string</td><td>Return the zkMe id corresponding to the zkMe account linked to the provided address.</td></tr><tr><td>verifierValues</td><td>object</td><td>List of verifierValues objects (see <strong><code>verifierValues</code> Object</strong>)</td></tr></tbody></table>

***

**`verifierValues` Object**

<table><thead><tr><th width="218">Name</th><th width="96">Type</th><th>Description</th></tr></thead><tbody><tr><td>countryRegion</td><td>bool</td><td><p>Return the user's Address verification result with the following output:</p><ul><li>If the user passes, return <code>true</code>.</li><li>If the user fails, return <code>false</code>.</li><li>If the AML Screening verification is not configured for the program, return <code>null</code>.</li></ul></td></tr></tbody></table>
{% endtab %}
{% endtabs %}


# Get KYT Results

{% hint style="info" %}
Before making any API requests, please refer to the [zkMe API](/hub/start/onboarding/integration/api#getting-started) section on the [zkMe API](/hub/start/onboarding/integration/api) page to obtain the necessary API access parameters.
{% endhint %}

## Get API Status

{% tabs %}
{% tab title="URL" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/kyt/status
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
  {
    "apiKey": "YourApiKey",
    "mchNo": "YourMchNo"
  }
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="116">Name</th><th width="83.732421875">Type</th><th>Description</th></tr></thead><tbody><tr><td>apiKey</td><td>string</td><td>Your API key</td></tr><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a></td></tr></tbody></table>
{% endtab %}

{% tab title="Response" %}

#### Sample Response <a href="#sample-response" id="sample-response"></a>

```json
{
  "code": 200,
  "message": "success",
  "data": {
    "support_api": [
      "status",
      "address_labels",
      "address_overview",
      "risk_score",
      "transactions_investigation",
    ],
    "support_coin": [
      "ETH", 
      "USDT-ERC20", 
      "USDC-ERC20", 
      "USDT-TRC20", 
      "WETH-ERC20", 
      "BNB-ERC20", 
      "UNI-ERC20", 
      "BUSD-ERC20", 
      "DAI-ERC20", 
      "GRT-ERC20", 
      "ENS-ERC20", 
      "UST-ERC20", 
      "BNB", 
      "renBTC-ERC20", 
      "WBTC-ERC20", 
      "TUSD-ERC20", 
      "SHIB-ERC20", 
      "LINK-ERC20", 
      "BAT-ERC20", 
      "CRO-ERC20", 
      "SUSHI-ERC20", 
      "stETH-ERC20", 
      "CRV-ERC20", 
      "CVX-ERC20", 
      "cvxCRV-ERC20", 
      "3Crv-ERC20", 
      "LOOKS-ERC20", 
      "USDC-TRC20",
      "IOTX-ERC20",
      "IOTX",
      "BUSD-BEP20", 
      "USDT-BEP20", 
      "WBNB-BEP20", 
      "ETH-BEP20", 
      "BTCB-BEP20",
      "DOGE-BEP20", 
      "USDC-BEP20", 
      "SHIB-BEP20", 
      "UST-BEP20",
      "MATIC-Polygon", 
      "WMATIC-Polygon", 
      "WETH-Polygon", 
      "USDC-Polygon", 
      "USDT-Polygon", 
      "DAI-Polygon",
      "WBTC-Polygon",
      "AAVE-Polygon", 
      "LINK-Polygon", 
      "UNI-Polygon", 
      "UST-Polygon", 
      "SUSHI-Polygon",
      "AVAX-Avalanche",
      "WAVAX-Avalanche",
      "BTC.b-Avalanche",
      "USDT-Avalanche",
      "USDT.e-Avalanche",
      "USDC-Avalanche",
      "USDC.e-Avalanche",
      "WETH.e-Avalanche",
      "DAI.e-Avalanche",
      "WBTC.e-Avalanche",
      "ETH-Arbitrum",
      "USDT-Arbitrum",
      "USDC-Arbitrum",
      "USDC.e-Arbitrum",
      "WETH-Arbitrum",
      "DAI-Arbitrum",
      "WBTC-Arbitrum",
      "LINK-Arbitrum",
      "GMX-Arbitrum",
      "sbfGMX-Arbitrum",
      "STG-Arbitrum",
      "MAGIC-Arbitrum",
      "BTC",
      "Cake-BEP20",
      "DAI-BEP20",
      "APE-ERC20",
      "ETH-Optimism",
      "USDT-Optimism",
      "USDC-Optimism",
      "OP-Optimism",
      "DAI-Optimism",
      "WBTC-Optimism",
      "WETH-Optimism",
      "SNX-Optimism",
      "sUSD-Optimism",
      "VELO-Optimism",
      "PYUSD-ERC20",
      "ETH-Base",
      "TRX",
      "MEME-ERC20",
      "ETH-zkSync",
      "USDC.e-Polygon",
      "BTC-Merlin",
      "BCH-BEP20",
      "USDC-Base",
      "USDbC-Base",
      "WETH-Base",
      "DEGEN-Base",
      "DAI-Base",
      "cbETH-Base"
      "ZK-zkSync",
      "WLD-Optimism",
      "TON",
      "ZK-zkSync",
      "WLD-Optimism",
      "USDT-TON",
      "SOL",
      "USDT-Solana",
      "USDC-Solana",
      "LTC",
      "DOGE",
      "BCH",
      "Bonk-Solana",
      "JUP-Solana",
      "RAY-Solana",
      "PYTH-Solana",
      "W-Solana"
    ]
  }
}
```

{% endtab %}
{% endtabs %}

## Get Address Labels <a href="#get-address-labels" id="get-address-labels"></a>

Returns a list of labels for a given address.

{% tabs %}
{% tab title="URL" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/kyt/address/labels
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
  {
    "apiKey": "YourApiKey",
    "mchNo": "YourMchNo",
    "coin": "ETH",
    "address": "{address}"
  }
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="116">Name</th><th width="83.732421875">Type</th><th>Description</th></tr></thead><tbody><tr><td>apiKey</td><td>string</td><td>Your API key</td></tr><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a></td></tr><tr><td>coin</td><td>string</td><td>The coin to check for address labels, all optional values can be found <a href="/pages/AUH5BJBXFZqYjMuYlSBo">here</a></td></tr><tr><td>address</td><td>string</td><td>The address to check for address labels</td></tr></tbody></table>
{% endtab %}

{% tab title="Response" %}

#### Sample response <a href="#sample-response" id="sample-response"></a>

```json
{
  "code": 200,
  "message": "success",
  "data": {
    "label_list": ["Binance", "hot"],
    "label_type": "exchange"
  }
}
```

{% endtab %}
{% endtabs %}

## Get Address Actions <a href="#get-address-actions" id="get-address-actions"></a>

Returns the transaction action analysis results for a given address.

{% tabs %}
{% tab title="URL" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/kyt/v1/address/actions
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
  {
    "apiKey": "YourApiKey",
    "mchNo": "YourMchNo",
    "coin": "ETH",
    "address": "{address}"
  }
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="128">Name</th><th width="120">Type</th><th width="363">Description</th></tr></thead><tbody><tr><td>apiKey</td><td>string</td><td>Your API key</td></tr><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a></td></tr><tr><td>coin</td><td>string</td><td>The coin to check for address overview, all optional values can be found <a href="/pages/AUH5BJBXFZqYjMuYlSBo">here</a></td></tr><tr><td>address</td><td>string</td><td>The address to check for overview datas</td></tr></tbody></table>
{% endtab %}

{% tab title="Response" %}

#### Sample response <a href="#sample-response" id="sample-response"></a>

```json
{
  "code": 200,
  "message": "success",
  "data": {
    "received_txs": [
      {
        "action": "DEX",
        "count": 7,
        "proportion": 70
      },
      {
        "action": "Mixer",
        "count": 1,
        "proportion": 10
      },
      {
        "action": "Exchange",
        "count": 1,
        "proportion": 10
      },
      {
        "action": "Swap",
        "count": 1,
        "proportion": 10
      }
    ],
    "spent_txs": [
      {
        "action": "Exchange",
        "count": 15,
        "proportion": 57.69
      },
      {
        "action": "DEX",
        "count": 2,
        "proportion": 7.69
      },
      {
        "action": "Transfer",
        "count": 9,
        "proportion": 34.62
      }
    ]
  }
}
```

#### Fields <a href="#fields" id="fields"></a>

<table><thead><tr><th width="145">Name</th><th width="90">Type</th><th>Description</th></tr></thead><tbody><tr><td>received_txs</td><td>list</td><td>The analysis result of the incoming transaction of the target address.</td></tr><tr><td>spent_txs</td><td>list</td><td>The analysis result of the outgoing transaction of the target address.</td></tr></tbody></table>

The API response data is suitable for display in a pie chart, as shown in the following figure.

<figure><img src="/files/I0X7qeTln9OFWx36N0jr" alt=""><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

## Get Address Counterparty  <a href="#get-address-counterparty" id="get-address-counterparty"></a>

Returns the counterparty analysis results for a given address.&#x20;

{% tabs %}
{% tab title="URL" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/kyt/address/counterparty
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
  {
    "apiKey": "YourApiKey",
    "mchNo": "YourMchNo",
    "coin": "ETH",
    "address": "{address}"
  }
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="128">Name</th><th width="120">Type</th><th width="363">Description</th></tr></thead><tbody><tr><td>apiKey</td><td>string</td><td>Your API key</td></tr><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a></td></tr><tr><td>coin</td><td>string</td><td>The coin to check for address overview, all optional values can be found <a href="/pages/AUH5BJBXFZqYjMuYlSBo">here</a></td></tr><tr><td>address</td><td>string</td><td>The address to check for overview datas</td></tr></tbody></table>
{% endtab %}

{% tab title="Response" %}

#### Sample Response <a href="#sample-response" id="sample-response"></a>

{% code fullWidth="false" %}

```json
{
  "code": 200,
  "message": "success",
  "data": [
    {
      "amount": 4150484.508,
      "name": "Uniswap",
      "percent": 49.7
    },
    {
      "amount": 2168062.159,
      "name": "Multichain",
      "percent": 25.961
    },
    {
      "amount": 2024879.354,
      "name": "Tornado.Cash",
      "percent": 24.247
    },
    {
      "amount": 4541.034,
      "name": "Unknown",
      "percent": 0.054
    },
    {
      "amount": 1923.578,
      "name": "SushiSwap",
      "percent": 0.023
    },
    {
      "amount": 972.055,
      "name": "sideshift.ai",
      "percent": 0.012
    },
    {
      "amount": 244.696,
      "name": "Binance",
      "percent": 0.003
    }
  ]
}
```

{% endcode %}

The API response data is suitable for display in a pie chart, as shown in the following figure.

<figure><img src="/files/xCssx06hU5wewbBsZMff" alt=""><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

## Get Address Overview <a href="#get-address-overview" id="get-address-overview"></a>

Returns the balance and statistics for a given address.&#x20;

{% tabs %}
{% tab title="URL" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/kyt/address/overview
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
  {
    "apiKey": "YourApiKey",
    "mchNo": "YourMchNo",
    "coin": "ETH",
    "address": "{address}"
  }
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="111">Name</th><th width="86">Type</th><th>Description</th></tr></thead><tbody><tr><td>apiKey</td><td>string</td><td>Your API key</td></tr><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a></td></tr><tr><td>coin</td><td>string</td><td>The coin to check for address overview, all optional values can be found <a href="/pages/AUH5BJBXFZqYjMuYlSBo">here</a></td></tr><tr><td>address</td><td>string</td><td>The address to check for overview datas</td></tr></tbody></table>
{% endtab %}

{% tab title="Response" %}

#### Sample response <a href="#sample-response" id="sample-response"></a>

```json
{
  "code": 200,
  "message": "success",
  "data": {
    "balance": 49.8305, 
    "txs_count": 1231, 
    "first_seen": 1441800674,
    "last_seen": 1670971955,
    "total_received": 916204.8697, 
    "total_spent": 916151.0499, 
    "received_txs_count": 1018, 
    "spent_txs_count": 213
  }
}
```

#### Fields <a href="#fields" id="fields"></a>

<table><thead><tr><th width="190">Name</th><th width="92">Type</th><th>Description</th></tr></thead><tbody><tr><td>balance</td><td>float(4)</td><td>The balance of the query address</td></tr><tr><td>txs_count</td><td>int</td><td>Total number of transactions of the query address</td></tr><tr><td>first_seen</td><td>int</td><td>The first transaction time of the query address, in unix timestamp format</td></tr><tr><td>last_seen</td><td>int</td><td>The last transaction time of the query address, in unix timestamp format</td></tr><tr><td>total_received</td><td>float(4)</td><td>The total received amount of the query address</td></tr><tr><td>total_spent</td><td>float(4)</td><td>The total spent amount of the query address</td></tr><tr><td>received_txs_count</td><td>int</td><td>Total number of incoming transactions of the query address</td></tr><tr><td>spent_txs_count</td><td>int</td><td>Total number of outgoing transactions of the query address</td></tr></tbody></table>
{% endtab %}
{% endtabs %}

## Get Address Profile <a href="#get-address-profile" id="get-address-profile"></a>

This API endpoint allows users to easily track which platforms an address has interacted with, such as exchanges, mixers, DeFi protocols, and NFT platforms. It also identifies any associated malicious events and provides additional information about the address, including used wallets, ENS names, and linked Twitter profiles.

{% tabs %}
{% tab title="URL" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/kyt/v1/address/profile
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
  {
    "apiKey": "YourApiKey",
    "mchNo": "YourMchNo",
    "coin": "ETH",
    "address": "{address}"
  }
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="128">Name</th><th width="120">Type</th><th width="363">Description</th></tr></thead><tbody><tr><td>apiKey</td><td>string</td><td>Your API key</td></tr><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a></td></tr><tr><td>coin</td><td>string</td><td>The coin to check for address overview, all optional values can be found <a href="/pages/AUH5BJBXFZqYjMuYlSBo">here</a></td></tr><tr><td>address</td><td>string</td><td>The address to check for overview datas</td></tr></tbody></table>
{% endtab %}

{% tab title="Response" %}

#### Sample response <a href="#sample-response" id="sample-response"></a>

```json
{
    "success": true, 
    "msg": "", 
    "data": {
        "first_address": "sideshift.ai", 
        "use_platform": {
            "exchange": {
                "count": 1, 
                "exchange_list": [
                    "Binance"
                ]
            }, 
            "dex": {
                "count": 3, 
                "dex_list": [
                    "Uniswap", 
                    "SushiSwap", 
                    "Multichain"
                ]
            }, 
            "mixer": {
                "count": 2, 
                "mixer_list": [
                    "Tornado.Cash", 
                    "sideshift.ai"
                ]
            }, 
            "nft": {
                "count": 0, 
                "nft_list": [ ]
            }
        }, 
        "malicious_event": {
            "phishing": {
                "count": 0, 
                "phishing_list": [ ]
            }, 
            "ransom": {
                "count": 0, 
                "ransom_list": [ ]
            }, 
            "stealing": {
                "count": 5, 
                "stealing_list": [
                    "MMFinance Exploiter"
                ]
            }, 
            "laundering": {
                "count": 0, 
                "laundering_list": [ ]
            }
        }, 
        "relation_info": {
            "wallet": {
                "count": 0, 
                "wallet_list": [ ]
            }, 
            "ens": {
                "count": 2, 
                "ens_list": [
                    "destruction.eth", 
                    "poma.eth"
                ]
            }, 
            "twitter": {
                "count": 1, 
                "twitter_list": [
                    " @destructioneth"
                ]
            }
        }
    }
}
```

#### Fields <a href="#fields" id="fields"></a>

<table><thead><tr><th width="190">Name</th><th width="92">Type</th><th>Description</th></tr></thead><tbody><tr><td>first_address</td><td>string</td><td>The source wallet address of the gas fee, or the label of the source address.</td></tr><tr><td>use_platform</td><td>dict</td><td>Includes four fields: <code>exchange</code>, <code>dex</code>, <code>mixer</code>, <code>nft</code>.</td></tr><tr><td>malicious_event</td><td>dict</td><td>Includes three fields: <code>phishing</code>, <code>ransom</code>, <code>stealing</code>, <code>laundering</code>.</td></tr><tr><td>relation_info</td><td>dict</td><td>Includes three fields: <code>wallet</code>, <code>ens</code>, <code>twitter</code>.</td></tr></tbody></table>
{% endtab %}
{% endtabs %}

## Get Risk Score <a href="#get-risk-score" id="get-risk-score"></a>

Returns the risk score, risk detail list for a given address or transaction hash.

{% tabs %}
{% tab title="URL" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/kyt/risk/score
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
  {
    "apiKey": "YourApiKey",
    "mchNo": "YourMchNo",
    "coin": "ETH",
    "address": "{address}",
    "txid": "{txn hash (optional)}"
  }
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="112">Name</th><th width="82">Type</th><th>Description</th></tr></thead><tbody><tr><td>apiKey</td><td>string</td><td>Your API key</td></tr><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a></td></tr><tr><td>coin</td><td>string</td><td>The coin to check for risk score, all optional values can be found <a href="/pages/AUH5BJBXFZqYjMuYlSBo">here</a></td></tr><tr><td>address</td><td>string</td><td>The address to check for risk score, one of address and txid must be passed.</td></tr><tr><td>txid</td><td>string</td><td>The address to check for risk score, one of address and txid must be passed. If you are unsure of its value, please ignore it directly and do not pass any non-existent or fictional values.</td></tr></tbody></table>
{% endtab %}

{% tab title="Response" %}

#### Sample response  <a href="#sample-response" id="sample-response"></a>

```json
{
  "code": 200,
  "message": "success",
  "data": {
    "score": 3,
    "hacking_event": "",
    "detail_list": [
      "Interact With Malicious Address",
      "Interact With High-risk Tag Address",
      "Interact With Medium-risk Tag Addresses"
    ],
    "risk_level": "Low",
    "risk_detail": [
      {
        "label": "Tornado.Cash: Router",
        "type": "high_risk",
        "volume": 1338984,
        "address": "0xd90e2f925da726b50c4ed8d0fb90ad053324f31b",
        "percent": 0.453
      },
      {
        "label": "Tornado.Cash: L1 Helper",
        "type": "high_risk",
        "volume": 1859.7,
        "address": "0xca0840578f57fe71599d29375e16783424023357",
        "percent": 0.001
      },
      {
        "label": "Tornado.Cash: Proxy",
        "type": "high_risk",
        "volume": 1487760,
        "address": "0x722122df12d4e14e13ac3b6895a86e84145b6967",
        "percent": 0.503
      },
      {
        "label": "Tornado.Cash: 10 ETH",
        "type": "high_risk",
        "volume": 167204.511,
        "address": "0x910cbd523d972eb0a6f4cae4618ad62622b39dbf",
        "percent": 0.057
      },
      {
        "label": "HitBTC",
        "type": "medium_risk",
        "volume": 76090.41,
        "address": "0x9c67e141c0472115aa1b98bd0088418be68fd249",
        "percent": 0.026
      }
    ]
  }
}
```

#### Fields <a href="#fields" id="fields"></a>

<table><thead><tr><th width="160">Name</th><th width="93">Type</th><th>Description</th></tr></thead><tbody><tr><td>score</td><td>int</td><td>Risk Score for the query address, range: 3 ~ 100</td></tr><tr><td>hacking_event</td><td>string</td><td>Related security event/incident name for the query address</td></tr><tr><td>detail_list</td><td>string[]</td><td>Risk description for the query address</td></tr><tr><td>risk_level</td><td>string</td><td>Risk level, <a href="#risk-level-guide">Low / Moderate / High / Severe</a></td></tr><tr><td>risk_detail</td><td>object[]</td><td>Data for the risk score calculation process</td></tr></tbody></table>

#### Risk Descriptions for `detail_list` <a href="#risk-descriptions-for-detail_list" id="risk-descriptions-for-detail_list"></a>

<table><thead><tr><th width="223">Risk Item</th><th>Risk Item</th></tr></thead><tbody><tr><td>Malicious Address</td><td>Address directly involved in malicious events, Example: DeFi protocol exploiters, centralized exchange hackers, sanctioned addresses, etc.</td></tr><tr><td>Suspected Malicious Address</td><td>Address associated with malicious events</td></tr><tr><td>High-risk Tag Address</td><td>High-risk entity address, Example: Mixers, some nested exchanges, etc.</td></tr><tr><td>Medium-risk Tag Address</td><td>High-risk entity address, Example: Mixers, some nested exchanges, etc.</td></tr><tr><td>Mixer</td><td>Mixer entity address, Example: Tornado Cash, etc.</td></tr><tr><td>Risk Exchange</td><td>Exchanges that do not require KYC</td></tr><tr><td>Gambling</td><td>Gambling entity address</td></tr><tr><td>Involved Theft Activity</td><td>Address involved in theft events</td></tr><tr><td>Involved Ransom Activity</td><td>Address involved in ransom events</td></tr><tr><td>Involved Phishing Activity</td><td>Address involved in phishing events</td></tr><tr><td>Interact With Malicious Address</td><td>Interactions with malicious address</td></tr><tr><td>Interact With Suspected Malicious Address</td><td>Interactions with suspected malicious address</td></tr><tr><td>Interact With High-risk Tag Address</td><td>Interactions with high-risk address</td></tr><tr><td>Interact With Medium-risk Tag Addresses</td><td>Interactions with medium-risk address</td></tr></tbody></table>

#### Risk Level Guide <a href="#risk-level-guide" id="risk-level-guide"></a>

<table><thead><tr><th width="126">Risk Level</th><th width="113">Risk Score</th><th>Suggested Operations</th></tr></thead><tbody><tr><td>Severe</td><td>91 ~ 100</td><td>Prohit withdrawals &#x26; trade, and report address immediately</td></tr><tr><td>High</td><td>71 ~ 90</td><td>Maintain high level surveillance, and analyze via zkMe OpenAPI to conduct transaction analysis</td></tr><tr><td>Moderate</td><td>31 ~ 70</td><td>Moderate supervision required</td></tr><tr><td>Low</td><td>0 ~ 30</td><td>Minimal supervision required</td></tr></tbody></table>
{% endtab %}
{% endtabs %}

## Get Transactions Investigation <a href="#get-transactions-investigation" id="get-transactions-investigation"></a>

{% tabs %}
{% tab title="URL" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/kyt/transactions/investigation
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
  {
    "apiKey": "YourApiKey",
    "mchNo": "YourMchNo",
    "coin": "ETH",
    "address": "{address}",
    "start_timestamp": 0,
    "end_timestamp": 1710000000,
    "type": "all",
    "page": 1
  }
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="181">Name</th><th width="78">Type</th><th>Description</th></tr></thead><tbody><tr><td>apiKey</td><td>string</td><td>Your API key</td></tr><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a></td></tr><tr><td>coin</td><td>string</td><td>The coin to check for transaction investigation, all optional values can be found <a href="/pages/AUH5BJBXFZqYjMuYlSBo">here</a></td></tr><tr><td>address</td><td>string</td><td>The address to check for transaction investigation</td></tr><tr><td>start_timestamp</td><td>int</td><td>The start timestamp to check for transaction investigation<br>(optional, default is 0)</td></tr><tr><td>end_timestamp</td><td>int</td><td>The end timestamp to check for transaction investigation<br>(optional, default is current timestamp)</td></tr><tr><td>type</td><td>string</td><td>The type to check for transaction investigation<br>(optional value “in”, “out” and “all”, default is “all”)</td></tr><tr><td>page</td><td>int</td><td>Page number<br>(optional, default is 1)</td></tr></tbody></table>
{% endtab %}

{% tab title="Response" %}

#### Sample Response

```json
  "code": 200,
  "message": "success",
  "data": {
    "in": [
      {
        "address": "0xcdd37ada79f589c15bd4f8fd2083dc88e34a2af2",
        "amount": 0.3615,
        "label": "sideshift.ai",
        "tx_hash_list": [
          "0x5cc3de8969e2642f6562fe3c0d32f0136a046e53f95ca1f40fe0b7e069f6646c"
        ],
        "type": 3
      },
      {
        "address": "0x68b3465833fb72a70ecdf485e0e4c7bd8665fc45",
        "amount": 735.5724,
        "label": "Uniswap V3: Router 2",
        "tx_hash_list": [
          "0x127fcdb6f30228045d07525940b628e9d1c2d343d4d2d79a41f078eecf67d869",
          "0x7f14257482969941aaa6fef9b27bbd48cae828c5df7c6246c8b2d9f7cfa8acbe",
          "0x5e6cad442ee522055512514616cb9465f551d81096c09b183175609db177e8da",
          "0x87032b673fa3264e491e6770209a2457ae4d765c0f504d87b4467e7e907fafaa",
          "0x33cdf3daee948390200254e8a0a0580a6b12ca813f45788c359bd389ed3bcce0",
          "0xac1139c366727e434de7ae3334d5acb95d2f0dcf3bfc43544dd768491e2e2890",
          "0x24952d8c3ec6dbf4c468518e9ff67f9d97ac9963ceb71ecab9ff58014a914ec8"
        ],
        "type": 3
      },
      {
        "address": "0xd9e1ce17f2641f24ae83637ab66a2cca9c378b9f",
        "amount": 0.4158,
        "label": "SushiSwap: Router",
        "tx_hash_list": [
          "0xcbb552f4929b9ab891884189be2d885468de774d7644b53c54c21ef810b4a01d"
        ],
        "type": 3
      },
      {
        "address": "0xb3065fe2125c413e973829108f23e872e1db9a6b",
        "amount": 0.0098,
        "label": "Malicious address, Theft, MMFinance Exploiter",
        "tx_hash_list": [
          "0x24dcf60c17a2c068549e3cfcfce8e131ff65ec0ef414218feb2c2b198b3a6280"
        ],
        "type": 2
      },
      {
        "address": "0x910cbd523d972eb0a6f4cae4618ad62622b39dbf",
        "amount": 9.9364,
        "label": "Tornado.Cash: 10 ETH",
        "tx_hash_list": [
          "0x113be3df8e1e95cacd51d57ad1022fb7181bd19650648a346c29c540801a45a0"
        ],
        "type": 3
      }
    ],
    "out": [
      {
        "address": "0xd90e2f925da726b50c4ed8d0fb90ad053324f31b",
        "amount": 743,
        "label": "Tornado.Cash: Router",
        "tx_hash_list": [
          "0x48c2601bcb2f3cc5a4b047d0151322d74b525c79fc68a052ba6e7faf1231017c",
          "0x7e87c61d423a3ea98937c16e4519069410212b16b6614daa9a84110a7422a12a",
          "0x9b8b6c6a141476fd7727a3e89fab94bd14638149430cb2512d7f0c6e731ab4ad",
          "0x6cba946ea79e77592a5a2dda2cd2a0806f568fae4f5f129624a621c7b36b8698",
          "0x8c558551d9b56e5643235d9dfe3865ce78b77630f789b1b7b02f7927ffd4b5b6",
          "0x5a2a96e722ce113fd22a919b08f51b2d49ab7b90784c2b11386380093e6c4d99",
          "0xaec81680d2bb4c8dbfbf150edb92abb618ef345c3325e62c0472b14f84e3a4ae",
          "0xf1b495be2beb828b88d6b60afd613bc9c7eadd9a7b51b98f03d48809f1136bfb",
          "0xefe8a14dfca2394b5ef914e9e0c3f83a07c83dc4eaf3187769384744d746cdf3",
          "0x0e4be586fe14b3aa2585fe3af0fa69cc5f3092c11d1e398987df46b28daa7ab3",
          "0xb2c5dcb6c2af88b2d139c575f7e575e8fd70bc225de72c99a142c9540a406635",
          "0x979711c7760844ca0cc5c04436676e12c0c3d9d8f4abe429fa2b5b8b21c685dc",
          "0x91cca8652cd00559fd0ff63557a967a14c13507d90e35acb4e71d8aed9fa65b8",
          "0x2acf21485518c305d40da718a415519c8c4fecf43323f45a2a945f400083d9fe"
        ],
        "type": 3
      },
      {
        "address": "0x7e46480d8e28c1d6c55be1b782084dd2c902f99f",
        "amount": 0.0845,
        "label": "Suspected malicious address, Theft",
        "tx_hash_list": [
          "0xf3ba8038e1e22017a91efa5d87685891b90f081a1da4f5098c8c7c8d97519e85"
        ],
        "type": 2
      },
      {
        "address": "0x259838b05d61717e37fc7b6bf0758d25644ee930",
        "amount": 0.0795,
        "label": "binance",
        "tx_hash_list": [
          "0xaa5eccb2fa452770e5a4026d8b335c8a292e7166832116c3e6494c384dc3ec87"
        ],
        "type": 3
      },
      {
        "address": "0xf8dfe4da86f8e73fec7383784f96752255d50fdc",
        "amount": 0.0428,
        "label": "Suspected malicious address, Theft",
        "tx_hash_list": [
          "0x5e58958244228e3954550f5dea9065b1622a29ad77821e4a1a669a01fd3e60b0"
        ],
        "type": 2
      },
      {
        "address": "0x68b3465833fb72a70ecdf485e0e4c7bd8665fc45",
        "amount": 0.65,
        "label": "Uniswap V3: Router 2",
        "tx_hash_list": [
          "0x1854e70f60ca81ada0d842242cfc34fbb2a107e825389cb24485733d1a3bda5c",
          "0xf620d29dd717035ed94e6c325b28d5ed2ac173022a0577463a9c9d4c1ce1a10a"
        ],
        "type": 3
      },
      {
        "address": "0xd32998321e43fcdb0482101a7aed9496813e06d0",
        "amount": 1.4668,
        "label": "Suspected malicious address, Theft",
        "tx_hash_list": [
          "0x2e565664bb8b29a3930207a2df2f46045c4c0eba8882c8b57cab67c35437992b",
          "0xf4b19bde3035c0a1a4bef62132b8c1f1577b3910d32718bad9e5261f60194833",
          "0x6a939a4dbf30a1f291e4fa9ba010294226acdad7a4fd8a6010b94ca1694515f4",
          "0x8eba59c2632d55a99324b2a2d218dba64b40e6a2ed32f0aac75c29f53203dfcd",
          "0x264e5295660cc469165cb26de5e6ac2257e9f15920c6d0d5ddb8a0ca4d15a45a",
          "0xad604f2e3ba83c4dadc540919ad86077cf8d589f08f70ab1482144a5f5bb46ef"
        ],
        "type": 2
      }
    ],
    "page": 1,
    "total_pages": 1,
    "transactions_on_page": 36
  }
}
```

#### Response Data Parameters <a href="#response-data-parameters" id="response-data-parameters"></a>

<table><thead><tr><th width="214">Name</th><th width="75">Type</th><th>Description</th></tr></thead><tbody><tr><td>in</td><td>list</td><td>The transfer-in transaction list of the querying address</td></tr><tr><td>out</td><td>list</td><td>The transfer-out transaction list of the querying address</td></tr><tr><td>page</td><td>int</td><td>The current page number </td></tr><tr><td>total_pages</td><td>int</td><td>The total page number</td></tr><tr><td>transactions_on_page</td><td>int</td><td>The number of transactions investigated on the current page<br>(maximum is 1000)</td></tr></tbody></table>

#### Response Data Unit Parameters  <a href="#response-data-unit-parameters" id="response-data-unit-parameters"></a>

<table><thead><tr><th width="138">Name</th><th width="91">Type</th><th>Description</th></tr></thead><tbody><tr><td>address</td><td>string</td><td>The transfer-in transaction list of the querying address</td></tr><tr><td>amount</td><td>float(4)</td><td>total transfer amount</td></tr><tr><td>label       </td><td>string</td><td>Address label detail</td></tr><tr><td>tx_hash_list </td><td>list</td><td>Transfer transaction hash list</td></tr><tr><td>type</td><td>int</td><td>1: EOA address / bitcoin address;<br>2: malicious address;<br>3: entity label address;<br>4: contract address</td></tr></tbody></table>
{% endtab %}
{% endtabs %}


# Verify zkOBS Status

{% hint style="info" %}
Before making any API requests, please refer to the [zkMe API](/hub/start/onboarding/integration/api#getting-started) section on the [zkMe API](/hub/start/onboarding/integration/api) page to obtain the necessary API access parameters.
{% endhint %}

## Get Users Accredited Investor Status Overview

Returns the verification status of the user for the following credential: [Proof-of-Accredited-Investor (PAI)](/hub/what/zkobs/zkpoai).&#x20;

{% tabs %}
{% tab title="Endpoint" %}

```ruby
POST https://agw.zk.me/zkseradmin/openapi/queryKycInfoByAddressForPoa
```

{% endtab %}

{% tab title="Request" %}

#### Request Body <a href="#parameters" id="parameters"></a>

```json
{
  "mchNo": "YourAppID" ,
  "apiKey": "YourApiKey",
  "programNo": "YourProgramNo", 
  "account": "walletAddress", // or email, or other unique identifiers
  "chainId": "YourChainID"
}
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="206">Name</th><th width="155">Type</th><th>Description</th></tr></thead><tbody><tr><td>mchNo</td><td>string</td><td>Same as AppID in the <a href="https://dashboard.zk.me/integration">Dashboard</a>.</td></tr><tr><td>apiKey</td><td>string</td><td>Your API Key.</td></tr><tr><td>programNo</td><td>string</td><td>Same as the programNo you pass for the SDK integration. </td></tr><tr><td>account</td><td>string</td><td>User's wallet address (recommended), email address, or other unique identifier</td></tr><tr><td>chainId</td><td>string</td><td><p>Same as the param chainId you pass for the SDK integration.</p><p></p><p>Currently supports Polygon (137) and Base (8453).</p></td></tr></tbody></table>

#### Supported Chain List

{% tabs %}
{% tab title="Mainnet" %}

| Chain Name      | zkMe Chain ID |
| --------------- | ------------- |
| Aptos           | aptos-1       |
| Arbitrum        | 42161         |
| Base            | 8453          |
| BNB Smart Chain | 56            |
| BounceBit       | 6001          |
| Ethereum        | 1             |
| Kaia            | 8217          |
| Manta           | 169           |
| Neutron         | neutron-1     |
| Polygon         | 137           |
| Ronin           | 2020          |
| Solana          | solana        |
| TON             | ton           |
| {% endtab %}    |               |

{% tab title="Testnet" %}

| Chain Name                | zkMe Chain ID |
| ------------------------- | ------------- |
| Aptos Testnet             | aptos-2       |
| Plume Testnet             | 98864         |
| Scroll Sepolia Testnet    | 534351        |
| Sei Testnet               | atlantic-2    |
| ZetaChain Athens3 Testnet | 7001          |
| {% endtab %}              |               |
| {% endtabs %}             |               |
| {% endtab %}              |               |

{% tab title="Response" %}
**Sample Response**

```json
{
  "poaiCompletedTimeUnix":"...",
  "poaiStatus":"...",
  "ssiAddress":"...",
  "zkmeId":"...",
}
```

#### Fields Explanation <a href="#fields" id="fields"></a>

<table><thead><tr><th width="218">Name</th><th width="96">Type</th><th>Description</th></tr></thead><tbody><tr><td>poaiCompletedTimeUnix</td><td>string</td><td>Unix timestamp of the mint time of user completed the share data process and minted a SBT in SSI wallet.</td></tr><tr><td>poaiStatus</td><td>string</td><td><p>Return users' zkPoAI status, including 6 stages:</p><ul><li>Verification Started</li><li>Data Retrieved</li><li>ZKP Generated</li><li>SBT Minted</li><li><p>OnChain Minted</p><ul><li>Note: Only applicable to <a href="/pages/OUIXBnh5tvUU4oUY9vs5#on-chain-mint-default">On-chain Mint</a> and <a href="/pages/OUIXBnh5tvUU4oUY9vs5#on-chain-transactional">On-chain Transactional</a></li></ul></li><li>PoAI Passed (or PoAI Failed)</li></ul></td></tr><tr><td>ssiAddress</td><td>string</td><td>User's SSI wallet address</td></tr><tr><td>zkmeId</td><td>string</td><td>Return the zkMe id corresponding to the zkMe account linked to the provided address.</td></tr></tbody></table>
{% endtab %}
{% endtabs %}


# Verify zkKYB Status

## Get Entity KYB Result Overview  <a href="#get-get-users-kyc-result-overview" id="get-get-users-kyc-result-overview"></a>

Returns the verification status of the user for the following credential: [zkKYB - Know Your Business](/hub/what/zkkyb)

{% tabs %}
{% tab title="Endpoint" %}

```ruby
POST https://agw.zk.me/kybpopup/api/kyb/getBusinessStatus
```

{% endtab %}

{% tab title="Request" %}

#### **Request Body**

```json
{
  "mchNo": "YourAppID" ,
  "accessToken": "YourAccessToken", 
  // Same as the access token obtained during SDK integration.
  // See: https://docs.zk.me/hub/start/onboarding/integration/js-sdk/zkkyb#access-token
  "programNo": "YourProgramNo",
  "externalID": "UID" // identifier for the KYB entity defined by you (e.g. company name, walletAddress, or email)
}
```

#### Fields Explanation <a href="#parameters" id="parameters"></a>

<table><thead><tr><th width="154">Name</th><th width="102">Type</th><th>Description</th></tr></thead><tbody><tr><td>mchNo</td><td>string</td><td>Same as AppID.</td></tr><tr><td>accessToken</td><td>string</td><td>The same access token obtained during SDK integration. Used to authenticate subsequent API requests. Valid for 30 minutes.</td></tr><tr><td>programNo</td><td>string</td><td>Same as the programNo you pass for the <a href="/pages/60A8hwAJn7vAfwJMoQkj">SDK</a>  integration.</td></tr><tr><td>externalID</td><td>string</td><td>The unique identifier provided by you to reference the KYB entity to be verified. This should match the <code>getExternalID()</code> passed during <a href="/pages/60A8hwAJn7vAfwJMoQkj">SDK</a> integration.</td></tr></tbody></table>
{% endtab %}

{% tab title="Response" %}

#### Sample Response <a href="#sample-response" id="sample-response"></a>

```json
{
  "code": ...,
  "msg": "...",
  "data": {
    "statusCode": ...,
    "statusDesc": "..."
  },
  "timestamp": ...
}
```

#### Fields Explanation <a href="#fields" id="fields"></a>

<table><thead><tr><th width="162">Name</th><th width="162">Type</th><th>Description</th></tr></thead><tbody><tr><td>code</td><td>number</td><td>Response code. <code>80000000</code> indicates success.</td></tr><tr><td>msg</td><td>string</td><td>Response message.</td></tr><tr><td>data</td><td>object</td><td>List of verifierValues objects (see <strong><code>data</code> Object</strong>)</td></tr><tr><td>timestamp</td><td>number</td><td>Response timestamp in milliseconds.</td></tr></tbody></table>

***

**`data` Object**

<table><thead><tr><th width="218">Name</th><th width="96">Type</th><th>Description</th></tr></thead><tbody><tr><td>statusCode</td><td>number</td><td><p>Indicates the current verification status of the KYB process.</p><p></p><p>Status codes are defined as follows:</p><ul><li><code>1</code> – Verification Started</li><li><code>2</code> – Info Submitted</li><li><code>3</code> – Under Review</li><li><code>4</code> – Resubmission Required</li><li><code>5</code> – Verification Passed</li><li><code>6</code> – Verification Failed</li></ul></td></tr><tr><td>statusDesc</td><td>string</td><td>A readable description of the current verification stage, derived from <code>statusCode</code>.</td></tr></tbody></table>
{% endtab %}
{% endtabs %}


# Smart Contract

The smart contract (***ZKMEVerifyUpgradeable***) is used for eligibility checks. The `verify` function provides yes/no answers to a list of predetermined eligibility questions for each credential verified. The `hasApproved` function provides information on whether the user has authorized the SBT.

## View Methods <a href="#view-methods" id="view-methods"></a>

### hasApproved()

This method verifies both that the user has authorized their SBT and that the user meets the project's KYC requirements. \
\
According to our design logic, users can only authorize their SBT to a project if their KYC meets the specified requirements. Therefore, a successfully authorized user, indicated by `hasApproved()` returning true, is one who meets your KYC settings.

```solidity
function hasApproved(
    address cooperator, 
    address user
) public view returns (bool)
```

### Parameters

<table><thead><tr><th width="189">Name</th><th width="154">Type</th><th width="142">Required</th><th>Description</th></tr></thead><tbody><tr><td>cooperator</td><td>address</td><td>Yes</td><td>Account address of Program</td></tr><tr><td>user</td><td>address</td><td>Yes</td><td>User's wallet address</td></tr></tbody></table>

{% hint style="info" %}
**Note:** You can obtain the `cooperator` address after completing the "Create Program" step on the [zkMe Dashboard](/hub/start/onboarding/dashboard).
{% endhint %}

<figure><img src="/files/HHTAitiFouPE9NTwBKjc" alt=""><figcaption></figcaption></figure>

***

## **Resources**

### Smart Contract Address

Please check [zkMe Smart Contracts](/hub/how-built/id-infra/smart-contracts).

### ABI

You can download the following file or install it from [npm](https://www.npmjs.com/package/@zkmelabs/verify-abi).

{% file src="/files/QZeTYHW6o68od7630R2E" %}


# 3rd Party Integrations


# QuestN

This page describes how to use zkMe's anti-sybil verifications on the QuestN platform.

## Creating your MeID Anti-Sybil Campaign

1. Navigate to your **Community - Quest** or [**https://business.questn.com/quest**](https://business.questn.com/quest) first, then click on "**Create a quest**".

<figure><img src="/files/SlQOeHFLANRNodXGi8uG" alt=""><figcaption></figcaption></figure>

### Quest Info

1. Complete the necessary information.
   1. **Title:** Enter a catchy and attention-grabbing title for your campaign.
   2. **Description:** Write a detailed description including an introduction to your NFT collection and the credentials users need to fulfill to participate in the campaign.
   3. **Schedule:** Set the registration period during which users can fulfill the requirements and participate.
2. **Click "Save Settings" to continue.**

<figure><img src="/files/hgkPxtpwGSC1geYgAfu1" alt=""><figcaption></figcaption></figure>

### Entries **Setting**

**I.**     Select the **Anti-Sybil template** for setting up the requirements.

1. Choose **Anti-Sybil** template from the **Recommend / Custom-Made** column. *This entry ensures that all participants are real and unique individuals. Users will be required to do facial scanning with mobile phones.*

<figure><img src="/files/pBupIf6RzappZEkkKslh" alt=""><figcaption></figcaption></figure>

2. Place a check mark next to the "**Pase zkMe anti-bot/sybil verification**" to add this template to your quest.

<figure><img src="/files/JWA2MNLxPVwbq2SVJY4G" alt=""><figcaption></figcaption></figure>

3. When the box below appears, the template has been added successfully to your quest.

<figure><img src="/files/50OmrG6LFunTgqV61F0I" alt=""><figcaption></figcaption></figure>

**II.    Add other available templates that you want to include in your quest.**

**III.   Click "Save Settings" to continue.**

### Eligibility & Reward Setting

1. Set the eligibility criteria for participating in your quest (specify who can take part in your quest).
2. Set up the Reward and **Release** your quest.

<figure><img src="/files/745Hm6w64ZxqXQiMUsaG" alt=""><figcaption></figcaption></figure>


# TaskOn

{% hint style="success" %}
COMING SOON
{% endhint %}


# Best Practices

<details>

<summary>Compliance Suite</summary>

## Tips

When integrating with a zkMe SDK, it is important to follow these tips:

* Ensure that you are using the **latest version** of the SDK to take advantage of new features and bug fixes.
* Follow the **integration instructions** provided in the SDK documentation carefully.
* **Test** your integration thoroughly before deploying it to production.
* Optimize performance by following the SDK's **recommendations and guidelines**.

## Github Example Code

<https://github.com/zkMeLabs/widget-demo>

</details>

<details>

<summary>Anti-bot / Anti-sybil Suite</summary>

## Tips

When integrating with a zkMe SDK, it is important to follow these tips:

* Ensure that you are using the **latest version** of the SDK to take advantage of new features and bug fixes.
* Follow the **integration instructions** provided in the SDK documentation carefully.
* **Test** your integration thoroughly before deploying it to production.
* Optimize performance by following the SDK's **recommendations and guidelines**.

## Github Example Code

<https://github.com/zkMeLabs/widget-demo>

</details>

<details>

<summary>Profiling Suite</summary>

<mark style="color:green;">**✅ COMING SOON**</mark>

</details>


# Architecture Overview

zkMe Protocol is a decentralized, permissionless, and composable zk-Identity Layer designed to unify, standardize, and process digital identities across all ecosystems, spanning all chains and Web2 environments. It leverages a combination of Zero-Knowledge Proofs (ZKP), Fully Homomorphic Encryption (FHE), Multi-Party Computation (MPC), and zkTLS technologies to enable truly universal, secure, and versatile verification, management, and monetization of credential data.

As zkMe evolves into the Identity and Open Finance Kernel for the Agent Economy, its architecture is organized around three core pillars: **Secure**, **Underwrite**, and **Gate**, powering secrets management, trustless credential verification, and enclaved session permissions respectively.

***

## The Three Pillars

### Secure: Protect Data

The **Secure** pillar provides the foundational infrastructure for protecting user and agent data. It encompasses Self-Sovereign Identity (SSI), the zkMe DID Method, the encrypted zkVault, Fully Homomorphic Encryption (FHE), zkPassport, zkTLS, and the on-chain Smart Contracts. Together, these components ensure that sensitive data never leaves the user’s control and that all cryptographic operations occur in privacy-preserving environments.

For AI agents, the Secure pillar means that secrets (API keys, payment credentials, private keys) are stored in an AES-256-GCM encrypted zkVault and are only ever decrypted inside hardware Trusted Execution Environments (Intel SGX / AMD SEV). The agent itself never holds plaintext credentials in its own memory.

### Underwrite: Verify Data

The **Underwrite** pillar transforms raw data into trustless, verifiable credentials. The [Credential System](/hub/how-built/credential-sys) is the core of this pillar, providing the issuance, verification, and lifecycle management infrastructure for all zkMe credentials. It supports [Selective Disclosure](/hub/how-built/credential-sys/selective-disclosure), [Reusable Credentials](/hub/how-built/credential-sys/reusable-credentials), and [Agent-Ready Credentials](/hub/how-built/credential-sys/agent-ready-credentials).

### Gate: Agent Execution

The **Gate** pillar enables AI agents to act on verified credentials through the [Agent Trust Gateway](/hub/how-built/agent-trust-gateway). The gateway evaluates agent credentials in real time, enforces policy decisions at the session level, and executes sensitive operations inside TEE enclaves. It supports the [8-step Agent Session Flow](/hub/how-built/agent-trust-gateway/agent-session-flow), [MCP Server integration](/hub/how-built/agent-trust-gateway/supported-protocols), OAuth2/PKCE authentication, PASETO v4 token signing, and immutable audit logging.

***

## Component Map

### Secure Pillar: [Identity Infrastructure Stack](/hub/how-built/id-infra)

<table><thead><tr><th width="139.123046875">Component</th><th width="286.58203125">What It Does</th><th width="203.87890625">Key Technology</th><th>Learn More</th></tr></thead><tbody><tr><td><strong>zkMe Identity Chain</strong></td><td>Purpose-built L1 for identity settlement and credential state anchoring</td><td>CometBFT PoS, EVMOS EVM, Decentralized Storage Providers</td><td><a href="/pages/PJXVg6WY3BJmBfUHiv0R">Identity Chain →</a></td></tr><tr><td><strong>Self-Sovereign Identity</strong></td><td>Defines the trust model and role relationships (Credential Issuer, ZKP Issuer, Holder, Verifier, Regulator). Provides the SSI Wallet (zkMe App) for credential custody and on-device ZKP generation.</td><td>W3C VC, MPC key management, OCR, facial recognition</td><td><a href="/pages/o5SSNX9sDYwphgFAcwh6">SSI →</a></td></tr><tr><td><strong>DID Method</strong></td><td>On-chain registry for <code>did:zkme</code> decentralized identifiers. Enables creation, resolution, update, and deletion of DIDs linked to EVM addresses.</td><td><code>did:zkme</code> specification, Solidity smart contract</td><td><a href="/pages/LML1W5eTUQFeh1LmmkzZ">DID Method →</a></td></tr><tr><td><strong>zkVault</strong></td><td>Encrypted secrets storage combining TEE-based key hierarchy with threshold encryption. For agents, secrets are decrypted only inside hardware enclaves. For regulatory compliance, threshold encryption ensures no single party can access raw data alone.</td><td>AES-256-GCM, EC-ElGamal threshold encryption, TEE (Intel SGX / AMD SEV), Shamir’s Secret Sharing, IPFS</td><td><a href="/pages/m4fOGTqZi9hQL5OxAiMy">zkVault →</a></td></tr><tr><td><strong>FHE</strong></td><td>Fully Homomorphic Encryption enabling computation on encrypted facial feature vectors. Powers the Face-to-DID creation process where biometric data is never exposed in plaintext.</td><td>CKKS scheme (Cheon-Kim-Kim-Song)</td><td><a href="/pages/f35ffdG0aa8TTzBKrzoA">FHE →</a></td></tr><tr><td><strong>zkPassport</strong></td><td>Privacy-preserving ePassport verification. Reads NFC chip data, performs Active Authentication, and generates ZKPs from ICAO 9303 passport data without exposing the raw document.</td><td>NFC, ICAO 9303, Active Authentication, zk-SNARKs</td><td><a href="/pages/ZLerOKZiiLOaghojUycc">zkPassport →</a></td></tr><tr><td><strong>zkTLS</strong></td><td>Bridges Web2 data sources (bank accounts, credit scores, government portals) by generating zero-knowledge proofs from standard HTTPS sessions. Enables trustless attestation of off-chain data.</td><td>TLS 1.2/1.3, MPC-based session splitting, zk-SNARKs</td><td><a href="/pages/MPIrpl18CtFcUr3n3dl3">zkTLS →</a></td></tr><tr><td><strong>Smart Contracts</strong></td><td>On-chain contract suite managing credential state (Merkle roots, revocation), cross-chain relay, and the Mint/Delegate/Verify/Certify lifecycle. Deployed across all supported chains.</td><td>Solidity, SBT, cross-chain relay</td><td><a href="/pages/ntNN2rwFAnwNtrVd2Z6w">Smart Contracts →</a></td></tr></tbody></table>

### Underwrite Pillar: [Credential System Stack](/hub/how-built/credential-sys)

<table><thead><tr><th width="129.22265625">Component</th><th width="289.484375">What It Does</th><th width="169.05078125">Key Technology</th><th>Learn More</th></tr></thead><tbody><tr><td><strong>Core Concepts</strong></td><td>System architecture (4-layer model), credential data model (W3C VC, JSON-LD), Claim Tree and Merkle commitment model, complete credential lifecycle (issuance, verification, revocation, expiration), and cryptographic assumptions.</td><td>W3C VC, Sparse Merkle Tree, Poseidon hash, Baby JubJub curve</td><td><a href="/pages/W65KJZ9MjLTqFBYJjz4k">Core Concepts →</a></td></tr><tr><td><strong>Selective Disclosure</strong></td><td>Fine-grained privacy control allowing Holders to reveal only specific credential fields. Supports 14 query operators including range matching, set membership, and field extraction. Gas-optimized on-chain verification via circuitQueryHash compression.</td><td>ZK Query Language, SD operator, circuitQueryHash</td><td><a href="/pages/d6tRIsT26ysfJWhHvUkI">Selective Disclosure →</a></td></tr><tr><td><strong>Multi-Credential Proofs &#x26; Delegation</strong></td><td>Batch verification of up to 10 queries across multiple credentials in a single proof. Cross-chain identity portability via Delegated Proofs bound to secondary addresses or AI agent DIDs.</td><td>LinkedMultiQuery10, Delegate SC, Soulbound Token</td><td><a href="/pages/lqy5IoZwUUh5MOPIYBGN">Multi-Credential Proofs &#x26; Delegation →</a></td></tr><tr><td><strong>Anti-Sybil Mechanisms</strong></td><td>Nullifier-based uniqueness enforcement for "one person, one action" guarantees. Unified authentication supporting both BabyJubJub keys and standard Ethereum wallet signatures. Unified SIG/MTP circuit.</td><td>Nullifier, unified authentication, Groth16 zk-SNARK</td><td><a href="/pages/T4yM5WNiPJULaV1LsRAU">Anti-Sybil Mechanisms →</a></td></tr><tr><td><strong>Reusable Credentials</strong></td><td>“Verify Once, Prove Anywhere” paradigm. Cross-chain credential portability via Delegate smart contracts. Context-specific proof generation prevents replay.</td><td>Delegate SC, cross-chain relay, nonce-bound proofs</td><td><a href="/pages/oBuvDcDDLHpY44jpgyUf">Reusable Credentials →</a></td></tr><tr><td><strong>Agent-Ready Credentials</strong></td><td>Credentials optimized for AI agent consumption. Cryptographic delegation protocol, machine-readable JSON-LD schemas for LLM parsing, and automated proof generation.</td><td>Constrained proxy credentials, JSON-LD, Agent Trust Gateway</td><td><a href="/pages/nBMLaHWcG5quqLsTZ7jG">Agent-Ready Credentials →</a></td></tr></tbody></table>

### Gate Pillar: [Agent Trust Gateway Stack](/hub/how-built/agent-trust-gateway)

<table><thead><tr><th width="124.78125">Component</th><th width="297">What It Does</th><th width="177.82421875">Key Technology</th><th>Learn More</th></tr></thead><tbody><tr><td><strong>Gateway Overview</strong></td><td>Authorization and policy enforcement layer for AI agents. TEE Enclave for confidential execution, Policy Engine for user-defined constraints, Credential Verifier for on-chain validation, Protocol Adapters for ecosystem integration.</td><td>TEE (Intel SGX / AMD SEV), Remote Attestation</td><td><a href="/pages/0woRBBo2YnaWzOzO8P4z">Gateway Overview →</a></td></tr><tr><td><strong>Agent Session Flow</strong></td><td>The complete 8-step session lifecycle: Initiation → TEE Ingress → Credential Verification → Policy Evaluation → Human-in-the-Loop → Context Provisioning → Execution Proxy → Audit Logging.</td><td>PASETO v4, OAuth2/PKCE, append-only audit ledger</td><td><a href="/pages/J1wX5oMRHA6tgswBDLHk">Session Flow →</a></td></tr><tr><td><strong>Supported Protocols</strong></td><td>Native adapters for MCP (AI agent communication), APF/x402 (agent payments), W3C VC/DID, ERC-8004 (agent reputation), OIDC4VP (Web2 bridge), zkTLS, and PASETO.</td><td>MCP, x402, ERC-8004, OIDC4VP, PASETO</td><td><a href="/pages/ILcCUPggXSlTCoqHd5hU">Protocols →</a></td></tr></tbody></table>

***

## Integration Tools

For developers integrating with zkMe, the following tools provide the primary interfaces. Detailed documentation is available in the Getting Started section.

<table><thead><tr><th width="176.66015625">Tool</th><th width="414.609375">Description</th><th>Documentation</th></tr></thead><tbody><tr><td><strong>zkMe Widget / SDK</strong></td><td>JavaScript SDK for embedding credential verification into web applications. Desktop browser component with mobile QR code support.</td><td><a href="/pages/HmI3NcewisUG6cFLJfKF">JS SDK →</a></td></tr><tr><td><strong>Mobile SDK</strong></td><td>Native mobile SDK for iOS and Android integration.</td><td><a href="/pages/J9ZYF1n4LInw2fjE37bS">Mobile SDK →</a></td></tr><tr><td><strong>zkMe Dashboard</strong></td><td>Management interface for Verifiers to configure verification profiles, define eligibility rules, and access analytics.</td><td><a href="/pages/Y11BD2EPmGOjk1nIPflZ">Dashboard →</a></td></tr><tr><td><strong>zkMe API</strong></td><td>RESTful API for programmatic access to KYC and KYT verification, user management, risk assessment, and transaction analysis.</td><td><a href="/pages/RNWJoxfT8FefhmffencP">API Reference →</a></td></tr></tbody></table>

***

## High-Level User Stories

See the dedicated [**High-Level User Stories**](/hub/how-works/architecture/user-stories) page for detailed narratives covering the Holder, the Agent, the Verifier, the Regulator, and the Credential Issuer.

## Supported Chains

See the dedicated [**Supported Chains**](/hub/what/kyt/support-scope) page for the full list of blockchain networks where zkMe smart contracts are deployed and configurable via the dashboard.


# High Level User Stories

This chapter presents a high-level solution overview of the zkMe Network through long-form User Stories for the following zkMe Protocol Stakeholders:

## The Holder (End User and Agent Principal)

The Holder wants to leverage owned off-chain and cross-chain Credentials (e.g., a government-issued ID card) to access permissioned or access-controlled services (e.g., permissioned yield pools) across any ecosystem. In the Agent Economy, the Holder also acts as the [Agent Principal](/hub/how-built/credential-sys/agent-ready-credentials), delegating bounded authority to AI agents via the [zkMe Vault](/hub/how-built/id-infra/zkvault).

The Holder’s primary goal is to reveal as little Personally Identifiable Information (PII) as possible and remain anonymous to prevent any party, including Issuers, Verifiers, Regulators, or any uninvolved third party, from benefiting from or abusing the link between their identity and their public service consumption patterns. When deploying agents, the Holder’s goal extends to ensuring their agents can execute tasks autonomously without exposing the Holder’s raw credentials or exceeding delegated limits.

**Holder Priorities:**

<table><thead><tr><th width="98.724609375">Priority</th><th width="237.18359375">Metric</th><th>Description</th></tr></thead><tbody><tr><td>1</td><td>Low PII Data Sharing</td><td>Minimize the amount of personal data shared during verification.</td></tr><tr><td>2</td><td>Low Time to Service</td><td>Reduce the average time it takes to onboard to a new permissioned service.</td></tr><tr><td>3</td><td>Granular Delegation Control</td><td>Ability to set, monitor, and instantly revoke specific spending limits and permissions for delegated AI agents.</td></tr></tbody></table>

### Example Scenario

Alice holds a government-issued passport credential and wants her AI trading agent to participate in a permissioned DeFi yield pool that requires proof of non-US residency. Rather than sharing her passport with the agent or the protocol, Alice authorizes a time-limited, scope-restricted delegation through her [SSI Wallet](/hub/how-built/id-infra/ssi). The agent can prove Alice’s eligibility to the pool’s smart contract via a [zero-knowledge proof](/hub/how-built/credential-sys), without ever seeing her passport data, her nationality, or any other personal detail beyond the boolean result “eligible: true.”

## The Agent (Autonomous Actor)

The Agent is an autonomous AI system that operates on behalf of a human or legal entity principal. It needs to prove its identity, intent, capabilities, and authorization to access services, execute transactions, and interact with other agents or platforms.

The Agent’s primary goal is to act within its delegated authority while maintaining cryptographic proof of accountability to its principal (via the [Agent Principal Credential](/hub/how-built/credential-sys/agent-ready-credentials)), without ever holding the principal’s raw secrets, API keys, or PII in its own memory.

Agent Priorities:

<table><thead><tr><th width="99.0703125">Priority</th><th width="242.6484375">Metric</th><th>Description</th></tr></thead><tbody><tr><td>1</td><td>Zero Credential Exposure</td><td>Execute transactions and API calls without ever holding raw secrets or private keys in memory, relying on <a href="/pages/m4fOGTqZi9hQL5OxAiMy">TEE</a> enclaves instead.</td></tr><tr><td>2</td><td>Low Latency to Authorization</td><td>Minimize the time between intent formulation and compliant execution across diverse payment rails (e.g., <a href="/pages/ILcCUPggXSlTCoqHd5hU">x402, AP2</a>).</td></tr><tr><td>3</td><td>High Interoperability</td><td>Present verifiable credentials  (<a href="/pages/kcLeU6Y8fST2MxjpM2L4">APC</a>, <a href="/pages/aU7EFG6dwTqQf5HPXNjf">ACC</a>, <a href="/pages/1uk1PnUdULmTL0vAuegm">AIC</a>, <a href="/pages/fYBMUqwQFLnmC4MBsUPP">ARC</a>) seamlessly across diverse platforms, chains, and jurisdictions.</td></tr></tbody></table>

### Example Scenario

A SaaS procurement agent is authorized by a startup’s CFO to evaluate and purchase software subscriptions up to $500/month. When a vendor’s API responds with a 402 Payment Required status, the agent routes the payment through the [Agent Trust Gateway](/hub/how-built/agent-trust-gateway). The Gateway verifies the agent’s payment credential (a delegated allowance from the CFO), confirms the amount is within the authorized spending limit, and facilitates the stablecoin transaction inside a TEE enclave. The vendor receives payment confirmation alongside a verifiable proof that the agent is authorized by a real, KYC-verified entity, all without the agent ever accessing the CFO’s private keys or bank account details.

## The Verifier (Service Provider)

The Verifier needs to perform user due diligence before onboarding a user to fulfill internal business needs (e.g., targeted service provision), reduce fraud (e.g., remove bots and duplicate accounts), manage jurisdictional restrictions (e.g., block services to residents of certain countries), or fulfill compliance requirements (e.g., enhanced customer due diligence).

In the Agent Economy, the Verifier must also perform [Agent Due Diligence (zkKYA)](/hub/what/zkkya). They need to verify an incoming agent’s accountability ([APC](/hub/what/zkkya/apc)), safety certification ([ACC](/hub/what/zkkya/acc)), declared intent ([AIC](/hub/what/zkkya/aic)), and historical reputation ([ARC](/hub/what/zkkya/arc)) before granting it access to APIs, financial rails, or platform resources. The Verifier requires a solution that is fully decentralized, cost-effective, and secure against data misuse to comply with global data privacy regulations like GDPR.

**Verifier Priorities:**

<table><thead><tr><th width="100.283203125">Priority</th><th width="164.375">Metric</th><th>Description</th></tr></thead><tbody><tr><td>1</td><td>High Retention Rate</td><td>The proportion of users (and agents) who complete the verification process without dropping off.</td></tr><tr><td>2</td><td>Low Crossover Error Rate</td><td>The combined error rate of false-positive and false-negative user/agent verifications.</td></tr><tr><td>3</td><td>Low Fees per Verification</td><td>The cost-effectiveness of the verification service.</td></tr><tr><td>4</td><td>Instant Agent Underwriting</td><td>The ability to instantly verify an agent’s UBO compliance status and reputation score before authorizing a transaction.</td></tr></tbody></table>

### Example Scenario

A decentralized exchange receives a trade request from an AI agent it has never seen before. Before executing the trade, the exchange’s smart contract challenges the agent for three proofs:&#x20;

1. an [Agent Principal Credential](/hub/what/zkkya/apc) proving the agent is accountable to a KYC-verified human,
2. an Agent Safety Credential confirming the agent has passed a recognized safety audit, and&#x20;
3. a [nullifier](/hub/how-built/credential-sys/anti-sybil-mech) proving this is not a duplicate Sybil identity.&#x20;

The agent constructs all three proofs automatically via the [Agent Trust Gateway](/hub/how-built/agent-trust-gateway) and submits them alongside the trade transaction. The exchange verifies the proofs on-chain in a single transaction, grants access, and executes the trade, all within seconds and without any human intervention on either side.

## The Regulator

The Regulator aims to protect Holders within its jurisdiction from accessing unregistered financial services to shield them from non-transparent risks. In the context of autonomous finance, the Regulator seeks to ensure that machine-to-machine transactions do not become a black box for money laundering or market manipulation.

The Regulator requires the ability to recover the real identity of a Holder, or the Ultimate Beneficial Owner (UBO) behind an autonomous AI agent, in case formal bad actor proceedings are initiated against them. They rely on [immutable audit trails](/hub/how-built/agent-trust-gateway/agent-session-flow) and cryptographic bindings (like the [APC](/hub/what/zkkya/apc)) to maintain market integrity.

**Regulator Priorities:**

<table><thead><tr><th width="97.458984375">Priority</th><th width="157.427734375">Metric</th><th>Description</th></tr></thead><tbody><tr><td>1</td><td>UBO Traceability</td><td>The ability to recover the real identity behind any wallet or agent when formal legal proceedings are initiated, via the cryptographic binding in the <a href="/pages/kcLeU6Y8fST2MxjpM2L4">Agent Principal Credential</a>.</td></tr><tr><td>2</td><td>Immutable Audit Trail</td><td>Tamper-proof, cryptographically anchored records of all verification events, agent authorizations, and delegation changes.</td></tr><tr><td>3</td><td>Jurisdictional Enforcement</td><td>The ability to enforce geographic and regulatory restrictions on service access without relying on centralized gatekeepers or mass surveillance.</td></tr></tbody></table>

### Example Scenario

A financial regulator receives a suspicious activity report involving a series of high-frequency trades executed by an AI agent across multiple DeFi protocols. Using the [immutable audit trail](/hub/how-built/agent-trust-gateway/agent-session-flow) recorded on-chain, the regulator traces the agent’s [Agent Principal Credential](/hub/what/zkkya/apc) back to its UBO. The APC’s cryptographic binding, combined with the zkMe [FHE-protected biometric anchor](/hub/how-built/id-infra/fhe), allows the regulator to initiate a formal identity recovery process through the appropriate legal channel, without compromising the privacy of any uninvolved users in the system.

## The Credential Issuer

The Credential Issuer is responsible for generating and distributing verifiable credentials to Holders and Agents. It represents the starting point of the [credential lifecycle](/hub/how-built/credential-sys) within the zkMe Protocol. In the Agent Economy, Issuers expand beyond traditional KYC providers to include third-party AI auditors, reputation scoring oracles, and intent verification networks.

A Credential Issuer can operate in two models:

<table><thead><tr><th width="197.388671875">Issuer Model</th><th>Description</th></tr></thead><tbody><tr><td>Centralized Issuer</td><td>A trusted entity (e.g., a government agency, financial institution, or accredited AI safety auditor) that directly issues Credentials recognized as reliable and compliant.</td></tr><tr><td>Decentralized Issuer</td><td>A programmatic bridge to an external trusted entity that is not natively part of the zkMe Protocol, enabling automatic Credential issuance without a new centralized intermediary (e.g., aggregating on-chain agent behavior into an <a href="/pages/fYBMUqwQFLnmC4MBsUPP">ARC score</a>).</td></tr></tbody></table>

**Issuer Priorities:**

<table><thead><tr><th width="107.9296875">Priority</th><th width="172.876953125">Metric</th><th>Description</th></tr></thead><tbody><tr><td>1</td><td>Credential Integrity</td><td>Ensure every issued credential is cryptographically tamper-proof and bound to a verified identity or audited agent.</td></tr><tr><td>2</td><td>Data Minimization</td><td>Issue credentials containing only the minimum attributes required for downstream verification, reducing liability in case of breach.</td></tr><tr><td>3</td><td>Revocation Responsiveness</td><td>The ability to instantly revoke compromised or fraudulent credentials, propagating revocation across all delegate copies and chains.</td></tr></tbody></table>

#### Example Scenario

An AI safety auditing firm completes a behavioral assessment of a new trading agent. The firm acts as a Decentralized Issuer, generating an [Agent Capability Credential (ACC)](/hub/what/zkkya/acc) that attests to the agent’s safety score, tested failure modes, and maximum recommended transaction limits. The credential is signed with the firm’s [BabyJubJub key](/hub/how-built/credential-sys/anti-sybil-mech) and anchored to the on-chain [State Contract](/hub/how-built/id-infra/smart-contracts). If the agent later exhibits anomalous behavior and the firm revokes the ACC, every Verifier that checks the agent’s credential will immediately see the revocation reflected in the [State Contract](/hub/how-built/id-infra/smart-contracts), preventing the agent from accessing any further permissioned services.

### Stakeholder Interaction Summary

The five stakeholders form an interconnected trust network. The following table summarizes the primary interactions between each pair:

<table><thead><tr><th width="181.333984375">Interaction</th><th>Description</th></tr></thead><tbody><tr><td>Holder to Agent</td><td>The Holder delegates bounded authority to the Agent via the <a href="/pages/m4fOGTqZi9hQL5OxAiMy">zkMe Vault</a>, specifying scope, spending limits, and TTL. The Agent operates autonomously within these constraints.</td></tr><tr><td>Holder to Verifier</td><td>The Holder (or their Agent) presents zero-knowledge proofs to the Verifier to gain access to permissioned services. The Verifier learns only the boolean verification result.</td></tr><tr><td>Agent to Verifier</td><td>The Agent presents its credential stack (<a href="/pages/kcLeU6Y8fST2MxjpM2L4">APC</a>, <a href="/pages/aU7EFG6dwTqQf5HPXNjf">ACC</a>, <a href="/pages/1uk1PnUdULmTL0vAuegm">AIC</a>, <a href="/pages/fYBMUqwQFLnmC4MBsUPP">ARC</a>) to the Verifier for <a href="/pages/uH80jrqhmNT5hBniWx7q">Agent Due Diligence</a>. The Verifier evaluates the proofs and grants or denies access in real time.</td></tr><tr><td>Verifier to Regulator</td><td>The Verifier maintains on-chain audit trails that the Regulator can query. In formal proceedings, the Regulator can initiate UBO recovery via the <a href="/pages/kcLeU6Y8fST2MxjpM2L4">APC</a>'s cryptographic binding.</td></tr><tr><td>Credential Issuer to Holder/Agent</td><td>The Issuer generates and distributes verifiable credentials. For Holders, this includes identity credentials (zkKYC). For Agents, this includes capability, safety, and reputation credentials.</td></tr><tr><td>Credential Issuer to Verifier</td><td>The Issuer’s on-chain <a href="/pages/ntNN2rwFAnwNtrVd2Z6w">State Contract </a>serves as the trust anchor. Verifiers check credential validity, non-revocation, and issuer authority against this contract during proof verification.</td></tr></tbody></table>

The Issuer’s critical role is to ensure that issued Credentials are cryptographically secure, privacy-preserving, and verifiable while adhering to data minimization principles.


# zkMe Supported Chains

{% hint style="success" %}
If you don't see your required chain listed here, please feel free to contact us at <mark style="color:blue;">**<contact@zk.me>**</mark> to submit your request to add support for an additional mainnet.
{% endhint %}

<table data-view="cards" data-full-width="false"><thead><tr><th></th><th data-hidden data-type="checkbox">Mainnet</th><th data-hidden data-type="checkbox">Testnet</th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td>Aptos</td><td>true</td><td>true</td><td><a href="/files/VYT9kgGFXJJDPJRDmXoh">/files/VYT9kgGFXJJDPJRDmXoh</a></td></tr><tr><td>Arbitrum One</td><td>true</td><td>true</td><td><a href="/files/BzsyJUNRDXpFX367ulGk">/files/BzsyJUNRDXpFX367ulGk</a></td></tr><tr><td>Base</td><td>true</td><td>false</td><td><a href="/files/LRc9Coq3KUKZvfZ47nwp">/files/LRc9Coq3KUKZvfZ47nwp</a></td></tr><tr><td>BNB Smart Chain</td><td>true</td><td>false</td><td><a href="/files/N2sEyHeBohhZI3cjUsBj">/files/N2sEyHeBohhZI3cjUsBj</a></td></tr><tr><td>BounceBit</td><td>false</td><td>false</td><td><a href="/files/KbPj39nRxZjCG7HrE0jI">/files/KbPj39nRxZjCG7HrE0jI</a></td></tr><tr><td>Ethereum</td><td>true</td><td>false</td><td><a href="/files/IJ5beaVDImAtk8FPXaFo">/files/IJ5beaVDImAtk8FPXaFo</a></td></tr><tr><td>Kaia</td><td>false</td><td>false</td><td><a href="/files/8ZyzDpRwMXl5089cxmI3">/files/8ZyzDpRwMXl5089cxmI3</a></td></tr><tr><td>Manta Network</td><td>true</td><td>false</td><td><a href="/files/SnO5wcSJGPcSNJI5bckH">/files/SnO5wcSJGPcSNJI5bckH</a></td></tr><tr><td>Neutron</td><td>true</td><td>true</td><td><a href="/files/XsYEH4nSyPiYRRblX2o5">/files/XsYEH4nSyPiYRRblX2o5</a></td></tr><tr><td>Polygon</td><td>true</td><td>false</td><td><a href="/files/Gk5nIy4lYW2LkWVC6Ph7">/files/Gk5nIy4lYW2LkWVC6Ph7</a></td></tr><tr><td>Ronin</td><td>false</td><td>false</td><td><a href="/files/YBwlx7hnl8ruOstGIGpc">/files/YBwlx7hnl8ruOstGIGpc</a></td></tr><tr><td>Solana</td><td>false</td><td>false</td><td><a href="/files/gXBvVgzXDQnz7msJqmbd">/files/gXBvVgzXDQnz7msJqmbd</a></td></tr><tr><td>The Open Network (TON)</td><td>false</td><td>false</td><td><a href="/files/MC3F7fqdh29SxjLFgSuT">/files/MC3F7fqdh29SxjLFgSuT</a></td></tr><tr><td>X Layer</td><td>false</td><td>false</td><td><a href="/files/ugwJyosZabbwsTj2ITeE">/files/ugwJyosZabbwsTj2ITeE</a></td></tr><tr><td><strong>Stay tuned for more chains...</strong></td><td>false</td><td>false</td><td></td></tr></tbody></table>

{% hint style="info" %}
**NOTE:** The chains listed are supported for configuration on our dashboard now. We have also deployed smart contracts on additional chains, which are in the pipeline to be added to the dashboard. For a complete list of all the chains we currently deploy, please refer to [zkMe Smart Contracts](/hub/how-built/id-infra/smart-contracts).
{% endhint %}


# Try It Out - Demos

## Dive into our solution&#x20;

Start your journey and experience its features firsthand.

{% hint style="info" %}
**Note:** This demo showcases [Proof-of-Citizenship (zkPoC)](/hub/what/zkkyc/zkpoc), one flagship feature among zkMe Protocols, giving you a full spectrum experience of what we offer.
{% endhint %}

{% embed url="<https://testwidget.zk.me/>" %}

## Master it in minutes&#x20;

Watch the how-to video to get started quickly.

{% embed url="<https://www.youtube.com/watch?v=r15F4s7HJJU>" %}


# Underlying Modules

The zkMe Protocol is built on a modular architecture organized around three functional pillars: **Secure, Underwrite,** and **Gate.** Each pillar addresses a distinct stage of the identity and trust lifecycle, from protecting raw data to issuing verifiable credentials to authorizing agent execution.

This page provides a high-level map of all underlying modules and their relationships. For a narrative overview of how these pillars work together, see the [Architecture Overview](/hub/how-works/architecture).

<figure><img src="/files/mKsSqiLHbwynQAaN32CL" alt=""><figcaption><p>zkMe Architecture v2</p></figcaption></figure>

{% hint style="info" %}
**Note:** This diagram reflects a legacy architecture. An updated version incorporating the latest setup is in progress.
{% endhint %}

***

## Identity Infrastructure

The Identity Infrastructure modules provide the foundational cryptographic and storage layer that protects user data throughout its entire lifecycle. These modules ensure that sensitive information never leaves the user's control and that all operations occur in privacy-preserving environments.

<table><thead><tr><th width="270.71875">Module</th><th>Description</th></tr></thead><tbody><tr><td><a data-mention href="/pages/PJXVg6WY3BJmBfUHiv0R">/pages/PJXVg6WY3BJmBfUHiv0R</a></td><td>Purpose-built Layer 1 EVM-compatible blockchain (CometBFT PoS + EVMOS) serving as the settlement and persistence foundation for all identity operations. Provides instant finality, sub-second block times, and a Decentralized Storage Provider network optimized for credential payloads.</td></tr><tr><td><a data-mention href="/pages/o5SSNX9sDYwphgFAcwh6">/pages/o5SSNX9sDYwphgFAcwh6</a></td><td>The SSI model underpinning zkMe, including the evolved role definitions (Credential Issuer, ZKP Issuer, Holder, Verifier, Regulator), the zkMe SBT, and the zkMe App (MPC-based SSI wallet).</td></tr><tr><td><a data-mention href="/pages/LML1W5eTUQFeh1LmmkzZ">/pages/LML1W5eTUQFeh1LmmkzZ</a></td><td>The <code>did:zkme</code> specification, on-chain DID Registry smart contract, CRUD operations, and DID Document resolution.</td></tr><tr><td><a data-mention href="/pages/m4fOGTqZi9hQL5OxAiMy">/pages/m4fOGTqZi9hQL5OxAiMy</a></td><td>Encrypted secrets management combining TEE-based key hierarchy with threshold encryption (EC-ElGamal), decentralized credential storage on IPFS, and the data recovery procedure for regulatory compliance.</td></tr><tr><td><a data-mention href="/pages/f35ffdG0aa8TTzBKrzoA">/pages/f35ffdG0aa8TTzBKrzoA</a></td><td>Fully Homomorphic Encryption using the CKKS scheme, enabling computation on encrypted facial feature vectors for privacy-preserving DID creation (Face-to-DID).</td></tr><tr><td><a data-mention href="/pages/ZLerOKZiiLOaghojUycc">/pages/ZLerOKZiiLOaghojUycc</a></td><td>Privacy-preserving ePassport verification using NFC chip reading, Active Authentication, and zero-knowledge proof generation from ICAO 9303 data.</td></tr><tr><td><a data-mention href="/pages/MPIrpl18CtFcUr3n3dl3">/pages/MPIrpl18CtFcUr3n3dl3</a></td><td>Zero-Knowledge Transport Layer Security for trustless extraction and attestation of Web2 data (bank accounts, credit scores, government records) without exposing raw session content.</td></tr><tr><td><a data-mention href="/pages/ntNN2rwFAnwNtrVd2Z6w">/pages/ntNN2rwFAnwNtrVd2Z6w</a></td><td>On-chain contract suite including zkMe Mint, Delegate, Verify &#x26; Certify contracts, with deployment addresses across all supported chains.</td></tr></tbody></table>

***

## Credential System

The Credential System is the core issuance and verification infrastructure for all zkMe credentials. It transforms raw identity data into trustless, privacy-preserving, and reusable verifiable credentials anchored on-chain.

<table><thead><tr><th width="244.6328125">Module</th><th>Description</th></tr></thead><tbody><tr><td><a data-mention href="/pages/W65KJZ9MjLTqFBYJjz4k">/pages/W65KJZ9MjLTqFBYJjz4k</a></td><td>System overview, design goals, the Issuer-Holder-Verifier trust triangle, system architecture (4-layer model), credential data model (W3C VC), Claim Tree and commitment model, full credential lifecycle (issuance, verification, revocation, expiration), and cryptographic assumptions.</td></tr><tr><td><a data-mention href="/pages/d6tRIsT26ysfJWhHvUkI">/pages/d6tRIsT26ysfJWhHvUkI</a></td><td>Fine-grained privacy control allowing Holders to reveal only specific credential fields via the SD operator. Supports 14 query operators for range matching, set membership, and field extraction. Gas-optimized on-chain verification via circuitQueryHash compression.</td></tr><tr><td><a data-mention href="/pages/lqy5IoZwUUh5MOPIYBGN">/pages/lqy5IoZwUUh5MOPIYBGN</a></td><td>Batch verification of up to 10 queries across multiple credentials in a single proof (LinkedMultiQuery10). Cross-chain identity portability via Delegated Proofs bound to secondary addresses or AI agent DIDs.</td></tr><tr><td><a data-mention href="/pages/T4yM5WNiPJULaV1LsRAU">/pages/T4yM5WNiPJULaV1LsRAU</a></td><td>Nullifier-based uniqueness enforcement for "one person, one action" guarantees. Unified authentication supporting both BabyJubJub keys and standard Ethereum wallet signatures. Unified SIG/MTP circuit.</td></tr><tr><td><a data-mention href="/pages/oBuvDcDDLHpY44jpgyUf">/pages/oBuvDcDDLHpY44jpgyUf</a></td><td>The "Verify Once, Prove Anywhere" paradigm, cross-chain credential portability via Delegate smart contracts, and lifecycle management for reusable credentials.</td></tr><tr><td><a data-mention href="/pages/nBMLaHWcG5quqLsTZ7jG">/pages/nBMLaHWcG5quqLsTZ7jG</a></td><td>Credentials optimized for AI agent consumption, featuring cryptographic delegation, machine-readable schemas, and automated proof generation.</td></tr></tbody></table>

***

## Agent Trust Gateway

The Agent Trust Gateway is the authorization and policy enforcement layer for AI agents. It mediates all interactions between autonomous agents and external resources, ensuring that every agent action is backed by a verified human identity, constrained by user-defined policies, and executed inside a hardware-secured enclave.

<table><thead><tr><th width="228.61328125">Module</th><th>Description</th></tr></thead><tbody><tr><td><a data-mention href="/pages/0woRBBo2YnaWzOzO8P4z">/pages/0woRBBo2YnaWzOzO8P4z</a></td><td>Core positioning, architectural components (TEE Enclave, Policy Engine, Credential Verifier, Protocol Adapters), and the high-level trust flow.</td></tr><tr><td><a data-mention href="/pages/J1wX5oMRHA6tgswBDLHk">/pages/J1wX5oMRHA6tgswBDLHk</a></td><td>The complete 8-step session lifecycle from initiation through TEE ingress, credential verification, policy evaluation, optional human-in-the-loop authorization, context provisioning, execution proxying, to audit logging.</td></tr><tr><td><a data-mention href="/pages/ILcCUPggXSlTCoqHd5hU">/pages/ILcCUPggXSlTCoqHd5hU</a></td><td>Native protocol adapters including MCP, APF/x402, W3C VC/DID, ERC-8004, OIDC4VP, zkTLS, and PASETO.</td></tr></tbody></table>

***

## Client-Side Tools

The following tools provide user-facing interfaces for interacting with the zkMe Protocol. For integration guides and SDK documentation, see the Getting Started section.

<table><thead><tr><th width="204.8828125">Tool</th><th>Description</th></tr></thead><tbody><tr><td><a href="https://app.zk.me/">zkMe App</a></td><td>The MPC-based SSI wallet for mobile credential management, featuring OCR document scanning, facial recognition, ZKP generation, and SBT minting. </td></tr><tr><td><a href="/pages/uM38jWO7esNbmysVnRHn">zkMe SDK</a></td><td>JavaScript SDK for embedding credential verification into web applications.</td></tr><tr><td><a href="https://dashboard.zk.me">zkMe Dashboard</a></td><td>Management interface for Verifiers to configure verification profiles, define business eligibility rules, and access analytics. </td></tr><tr><td><a href="/pages/RNWJoxfT8FefhmffencP">zkMe API</a></td><td>RESTful API for programmatic access to KYC and KYT verification services. </td></tr></tbody></table>

***

## **Available as Independent Services**

The technology stack behind the zkMe Protocol is commercially available for external organizations to license, deploy, and operate independently. Customers can acquire any single module, any combination across pillars, or a complete pillar as a turnkey technology product.

<table><thead><tr><th width="191.88671875">Pillar</th><th>Commercially Available Technology</th></tr></thead><tbody><tr><td><strong>Identity Infrastructure</strong></td><td>8 modules available for independent licensing. See <a href="/pages/1CAXSjcjAgs34CGjSf5k#commercially-available-technology">Identity Infrastructure: Available as Independent Services</a> for the full catalog and acquisition models.</td></tr><tr><td><strong>Credential System</strong></td><td>6 capabilities available for independent licensing. See <a href="/pages/VocXj0Kcynl2ks1gIbyk#commercially-available-technology">Credential System: Available as Independent Services</a> for the full catalog and acquisition models.</td></tr><tr><td><strong>Agent Trust Gateway</strong></td><td>7 capabilities available for independent licensing. See <a href="/pages/0woRBBo2YnaWzOzO8P4z#commercially-available-technology">Agent Trust Gateway: Available as Independent Services</a> for the full catalog and acquisition models.</td></tr></tbody></table>

{% hint style="success" %}
All modules support flexible engagement models including technology licensing for self-hosted deployment, managed service with pay-as-you-go or committed-use pricing, and full white-label solutions. Contact the zkMe team at <contact@zk.me>.
{% endhint %}


# Identity Infrastructure Stack

Identity Infrastructure Stack is the foundational layer of the zkMe Protocol. It provides the cryptographic primitives, secure storage mechanisms, and on-chain anchoring systems that ensure user data remains under the user’s exclusive control throughout its entire lifecycle. Every credential issued, every proof generated, and every agent interaction authorized by zkMe ultimately depends on the guarantees provided by these modules.

The design philosophy of this layer follows a strict **privacy-by-default** principle: raw personal data is never transmitted to any third party. Instead, data is processed locally on the user’s device, encrypted at rest using threshold cryptography, and represented on-chain only as zero-knowledge proofs or cryptographic commitments. Even in regulatory scenarios requiring data recovery, no single party can access the underlying information alone.

***

## How the Modules Fit Together

The Identity Infrastructure modules form a layered stack, each building on the capabilities of the layer below:

1. **Chain Layer.** The [zkMe Identity Chain](/hub/how-built/id-infra/zkme-identity-chain) provides the settlement and persistence foundation for the entire stack. All identity smart contracts are deployed on this chain, all credential state commitments are anchored here, and the Decentralized Storage Provider network manages encrypted credential data persistence. The chain's instant finality and dedicated block space ensure that identity operations are never delayed by unrelated network congestion.
2. **Identity Foundation.** [Self-Sovereign Identity (SSI)](/hub/how-built/id-infra/ssi) defines the trust model and role relationships (Issuer, Holder, Verifier, Regulator). The [DID Method](/hub/how-built/id-infra/did-method) provides each participant with a globally unique, on-chain resolvable decentralized identifier (`did:zkme`).
3. **Data Protection.** [zkVault](/hub/how-built/id-infra/zkvault) provides encrypted secrets storage using a combination of TEE-based key hierarchy and threshold encryption (EC-ElGamal). For AI agents, secrets are decrypted only inside hardware enclaves. [FHE](/hub/how-built/id-infra/fhe) enables computation on encrypted data, specifically facial feature vectors, allowing privacy-preserving DID creation without ever exposing biometric data in plaintext.
4. **Data Acquisition.** [zkPassport](/hub/how-built/id-infra/zkpassport) extracts and attests identity data from government-issued ePassports via NFC chip reading and Active Authentication. [zkTLS](/hub/how-built/id-infra/zktls) bridges Web2 data sources (bank accounts, credit scores, government portals) by generating zero-knowledge proofs from standard HTTPS sessions.
5. **On-Chain Anchoring.** [Smart Contracts](/hub/how-built/id-infra/smart-contracts) provide the immutable trust anchor, managing credential state (Merkle roots, revocation status), cross-chain relay, and the Mint/Delegate/Verify contract suite deployed across all supported chains.

***

## Module Index

<table><thead><tr><th width="232.423828125">Module</th><th width="275.837890625">What It Does</th><th>Key Technology</th></tr></thead><tbody><tr><td><a data-mention href="/pages/PJXVg6WY3BJmBfUHiv0R">/pages/PJXVg6WY3BJmBfUHiv0R</a></td><td>Settlement and persistence layer for all identity operations</td><td>CometBFT PoS, EVM (EVMOS), Decentralized Storage Providers</td></tr><tr><td><a data-mention href="/pages/o5SSNX9sDYwphgFAcwh6">/pages/o5SSNX9sDYwphgFAcwh6</a></td><td>Defines the identity model and trust roles</td><td>W3C SSI, Verifiable Credentials</td></tr><tr><td><a data-mention href="/pages/LML1W5eTUQFeh1LmmkzZ">/pages/LML1W5eTUQFeh1LmmkzZ</a></td><td>On-chain decentralized identifier registry</td><td><code>did:zkme</code> specification, EVM smart contract</td></tr><tr><td><a data-mention href="/pages/m4fOGTqZi9hQL5OxAiMy">/pages/m4fOGTqZi9hQL5OxAiMy</a></td><td>Encrypted secrets storage and data recovery</td><td>Threshold encryption (EC-ElGamal), TEE, IPFS</td></tr><tr><td><a data-mention href="/pages/f35ffdG0aa8TTzBKrzoA">/pages/f35ffdG0aa8TTzBKrzoA</a></td><td>Computation on encrypted biometric data</td><td>CKKS fully homomorphic encryption</td></tr><tr><td><a data-mention href="/pages/ZLerOKZiiLOaghojUycc">/pages/ZLerOKZiiLOaghojUycc</a></td><td>ePassport verification and attestation</td><td>NFC, ICAO 9303, Active Authentication, ZKP</td></tr><tr><td><a data-mention href="/pages/MPIrpl18CtFcUr3n3dl3">/pages/MPIrpl18CtFcUr3n3dl3</a></td><td>Web2 data bridging with privacy</td><td>TLS 1.2/1.3, zk-SNARKs</td></tr><tr><td><a data-mention href="/pages/ntNN2rwFAnwNtrVd2Z6w">/pages/ntNN2rwFAnwNtrVd2Z6w</a></td><td>On-chain state management and verification</td><td>Solidity, cross-chain relay, SBT</td></tr></tbody></table>

***

## Recommended Reading Order

For readers new to the zkMe Protocol, we recommend reading the Identity Infrastructure modules in the following order:

1. Start with **zkMe Identity Chain** to understand the blockchain foundation that all other modules depend on.
2. Start with **SSI** to understand the trust model and role definitions.
3. Read **DID Method** to understand how identities are represented on-chain.
4. Read **zkVault** to understand how sensitive data is stored and protected.
5. Read **FHE** to understand how biometric data is processed without exposure.
6. Read **zkPassport** and **zkTLS** to understand how identity data is acquired from real-world sources.
7. Read **Smart Contracts** to understand the on-chain verification and state management layer.

For readers primarily interested in building on zkMe, you may want to start with the [Credential System](/hub/how-built/credential-sys) and [Agent Trust Gateway](/hub/how-built/agent-trust-gateway) modules, which consume the guarantees provided by this infrastructure layer.

***

## Available as Independent Services

The Identity Infrastructure Stack is available for licensing and deployment by external organizations. Customers can acquire any module independently or license the full stack to build and operate their own identity infrastructure using zkMe's chain layer, cryptographic primitives, and on-chain anchoring systems.

<table><thead><tr><th width="195.8359375">Module</th><th>Acquisition Model</th></tr></thead><tbody><tr><td>zkMe Identity Chain</td><td>License the chain stack (CometBFT + EVMOS + DSP network) for sovereign deployment, or deploy on the shared zkMe mainnet</td></tr><tr><td>SSI Framework</td><td>License the SSI model, role definitions, and MPC wallet infrastructure</td></tr><tr><td>DID Infrastructure</td><td>License the did:zkme registry contracts and resolution service</td></tr><tr><td>zkVault</td><td>License the encryption stack (TEE key hierarchy + EC-ElGamal threshold encryption + IPFS storage layer)</td></tr><tr><td>FHE Engine</td><td>License the CKKS homomorphic encryption compute engine</td></tr><tr><td>zkPassport</td><td>License the NFC reader SDK, Active Authentication module, and ZKP generation pipeline</td></tr><tr><td>zkTLS</td><td>License the TLS session proof generation stack</td></tr><tr><td>Smart Contracts Suite</td><td>License the Mint/Delegate/Verify/Certify contract suite for deployment on any EVM chain</td></tr></tbody></table>

{% hint style="success" %}
All modules support flexible engagement models including technology licensing for self-hosted deployment, managed service with pay-as-you-go or committed-use pricing, and full white-label solutions. Contact the zkMe team at <contact@zk.me>.
{% endhint %}


# zkMe Identity Chain

The zkMe Identity Chain is a Layer 1 EVM-compatible blockchain purpose-built for decentralized identity. It serves as the single source of truth for all identity data within the zkMe Protocol, housing credential smart contracts, anchoring [DID registries](/hub/how-built/id-infra/did-method), and managing a decentralized storage network where encrypted credentials are persisted. Every proof generated by the [Credential System](/hub/how-built/credential-sys), every DID registered by a Holder or Agent, and every verification event recorded by a Verifier ultimately settles on this chain.

In the Agent Economy, the Identity Chain plays a particularly critical role. AI agents require a tamper-proof, always-available identity layer that can process high-frequency verification requests with low latency. Traditional general-purpose blockchains introduce unpredictable gas costs and confirmation delays that are incompatible with real-time agent interactions. The zkMe Identity Chain addresses this by providing instant finality, sub-second block times, and a purpose-built storage layer optimized for identity payloads.

## Why a Dedicated Identity Chain

General-purpose blockchains are designed to serve a broad range of applications, from DeFi to gaming to NFTs. This generality comes at a cost: identity workloads must compete with unrelated transactions for block space, gas prices fluctuate based on network congestion from other applications, and storage models are optimized for financial state rather than credential data.

The zkMe Identity Chain eliminates these trade-offs by dedicating the entire chain to identity operations. The following table summarizes the key advantages:

<table><thead><tr><th width="206.208984375">Dimension</th><th>General-Purpose Chain</th><th>zkMe Identity Chain</th></tr></thead><tbody><tr><td>Block space contention</td><td>Identity transactions compete with DeFi, NFT, gaming traffic</td><td>100% of block space reserved for identity operations</td></tr><tr><td>Gas price predictability</td><td>Volatile, driven by unrelated demand spikes</td><td>Stable, driven only by identity workload</td></tr><tr><td>Storage model</td><td>Optimized for account balances and token state</td><td>Optimized for credential payloads with S3-compatible APIs</td></tr><tr><td>Finality</td><td>Varies (seconds to minutes depending on chain)</td><td>Instant finality per block</td></tr><tr><td>Data residency</td><td>No native support</td><td>Geolocation-specific storage via Storage Provider selection</td></tr><tr><td>Validator incentives</td><td>Aligned with general transaction throughput</td><td>Aligned with data integrity, availability, and identity verification</td></tr></tbody></table>

***

## Architecture

The zkMe Identity Chain is built on the **CometBFT (Cosmos/Tendermint)** framework with **EVM compatibility** based on EVMOS. This architecture combines the instant finality and modular consensus of the Cosmos ecosystem with full Ethereum tooling compatibility, allowing developers to deploy existing Solidity smart contracts using Hardhat, Foundry, Remix, and MetaMask without modification.

The architecture comprises two interconnected components:

**EVM-Compatible Blockchain.** The execution layer runs the LONDON instruction set with support for select SHANGHAI opcodes (EIP-3855, EIP-3860, EIP-1153, EIP-5656, EIP-6780). All credential and identity smart contracts, including the [State Contract](/hub/start/onboarding/integration/smart-contract), [Verifier contracts](/hub/how-built/id-infra/smart-contracts#zkme-verify-and-certify), and [Delegate contracts](/hub/how-built/id-infra/smart-contracts#zkme-delegate) referenced throughout the zkMe documentation, are deployed on this layer. Because the chain uses a Cosmos SDK account model, it operates exclusively with EVM addresses (e.g., `0x1234...7890`), simplifying wallet integration for both human users and AI agents.

**Decentralized Storage Providers (DSP).** The storage layer is a network of independent Storage Providers that store the actual credential payloads (encrypted identity data, Merkle tree nodes, revocation status). Validators on the chain store metadata and financial ledgers with consensus, while Storage Providers handle the data itself. This separation ensures that credential data availability is consistent with chain uptime, storage is distributed across independent providers for resilience, and geolocation-specific storage is supported for data residency requirements.

***

## Consensus Mechanism

The zkMe Identity Chain uses a **Proof-of-Stake (PoS)** mechanism based on CometBFT consensus. Validators stake the native gas token to participate in block production, with the probability of being selected as block proposer proportional to their stake. Blocks are produced every approximately 1 second with instant finality, meaning that once a block is committed, it cannot be reverted.

The consensus process follows three voting rounds:

1. **Prevote.** Validators receive a block proposal and broadcast their initial vote.
2. **Precommit.** If more than two-thirds of validators (by stake weight) prevote for the same block, they proceed to precommit.
3. **Commit.** If more than two-thirds precommit to the block, it is finalized and appended to the chain.

This BFT (Byzantine Fault Tolerant) property means the network tolerates up to one-third of validators being faulty or offline without halting. Malicious behavior such as double-signing results in automatic slashing of staked tokens.

### Validator Responsibilities

Validators on the zkMe Identity Chain have responsibilities beyond standard block production:

**Data Integrity Enforcement.** Validators challenge the availability and integrity of data stored by Decentralized Storage Providers. They can issue random or targeted challenges to detect underperforming or malicious providers. Providers that fail challenges face stake slashing.

**Network Governance.** Validators participate in on-chain governance decisions, including parameter adjustments, protocol upgrades, and the approval of new Storage Providers joining the network.

***

## Decentralized Storage Layer

The Decentralized Storage Provider (DSP) network is the persistence layer for all credential data. Storage Providers operate independently, each maintaining a local full node for direct connection to the chain. They expose **S3-compatible APIs** for data upload, download, and management, making integration straightforward for developers familiar with cloud storage patterns.

### How Storage Works

Storage Providers must register by depositing a stake on the Identity Chain. Validators then conduct a governance vote to approve the provider. Once approved, the provider enters active service and begins handling data requests.

Key mechanisms that ensure data reliability:

**Virtual Groups.** Storage Providers organize data into virtual groups for replication across multiple providers. This ensures that if one provider goes offline, data remains available from other providers in the same virtual group.

**Integrity Proofs and Challenges.** Validators periodically challenge Storage Providers to prove they still hold the data they claim to store. Providers must respond with cryptographic integrity proofs. Failed challenges result in penalties.

**Lifecycle Management.** Storage Providers follow a structured lifecycle: Proposal (staking and governance approval), In Service (active data handling), Maintenance (temporary offline for upgrades), and Exit (graceful data migration to successor providers or forced exit with penalties).

### Storage Provider Architecture

Each Storage Provider runs a modular architecture with the following core components:

| Component     | Function                                                                |
| ------------- | ----------------------------------------------------------------------- |
| Gater         | HTTP gateway implementing S3-compatible protocol                        |
| Authenticator | Verifies client authentication for data requests                        |
| Uploader      | Handles object upload requests, stores payload data                     |
| Downloader    | Handles object retrieval and challenge response requests                |
| Receiver      | Receives replicated data from primary provider, computes integrity hash |
| Signer        | Manages all cryptographic signing operations for the provider           |
| Metadata      | Provides query interfaces for object and bucket metadata                |
| BlockSyncer   | Synchronizes block data from the Identity Chain                         |
| PieceStore    | Interfaces with underlying storage backends (S3, MinIO, OSS)            |

***

## EVM Compatibility

The zkMe Identity Chain is developed on EVMOS (Cosmos EVM), providing full Ethereum Virtual Machine compatibility. Developers can write and deploy the same Solidity smart contracts on the Identity Chain and other EVM-compatible blockchains without code modifications. This compatibility extends to all standard Ethereum tooling:

| Tool                | Compatibility |
| ------------------- | ------------- |
| Hardhat             | Full support  |
| Foundry             | Full support  |
| Remix               | Full support  |
| MetaMask            | Full support  |
| ethers.js / web3.js | Full support  |

The EVM currently runs the **LONDON** instruction set with support for the following SHANGHAI opcodes:

| EIP      | Description               |
| -------- | ------------------------- |
| EIP-3855 | PUSH0 instruction         |
| EIP-3860 | Limit and meter initcode  |
| EIP-1153 | Transient storage opcodes |
| EIP-5656 | MCOPY instruction         |
| EIP-6780 | SELFDESTRUCT restriction  |

Because the chain uses a unified account model (Cosmos SDK accounts mapped to EVM addresses), the native gas token and EVM gas token are the same currency managed by the same bank keeper module. This eliminates the dual-token complexity found in some Cosmos EVM implementations.

***

## Performance Specifications

| Parameter                  | Value                           |
| -------------------------- | ------------------------------- |
| Block Time                 | Approximately 1 second          |
| Finality                   | Instant (single-block finality) |
| Max Transactions per Block | 2,400                           |
| Max Block Size             | 3 MB                            |
| Block Gas Limit            | 4,294,967,295                   |
| Unbonding Time             | 21 days                         |
| Consensus                  | CometBFT Proof-of-Stake         |
| EVM Compatibility          | Full (EVMOS-based)              |
| Cosmos SDK                 | v0.50.13                        |

***

## Network Information

For network connection details (RPC endpoints, block explorers, and faucets), [contact](mailto:contact@zk.me) the zkMe team or refer to the developer portal.

***

## Role in the Agent Economy

The zkMe Identity Chain is the settlement layer for all agent identity operations. When an AI agent presents credentials to a Verifier, the zero-knowledge proof is verified against state commitments anchored on this chain. When a Holder delegates authority to an agent via the [Agent Principal Credential](/hub/how-built/credential-sys/agent-ready-credentials), the delegation binding is recorded on this chain. When a Verifier checks a nullifier to prevent duplicate claims, the [nullifier registry](/hub/how-built/credential-sys/anti-sybil-mech) lives on this chain.

The chain’s instant finality is particularly important for agent workflows. Unlike human users who can tolerate a few seconds of confirmation delay, AI agents operating in automated pipelines (such as [x402 payment flows](/hub/how-built/agent-trust-gateway/supported-protocols) or multi-step DeFi strategies) require deterministic, sub-second settlement. The Identity Chain’s 1-second block time with instant finality ensures that credential verification never becomes a bottleneck in agent execution flows.

The Decentralized Storage Provider network also plays a direct role in agent operations. Agent credentials, delegation records, and session audit logs are all persisted in the DSP network, ensuring that this data remains available even if individual storage providers go offline. For regulated use cases, the geolocation-specific storage capability allows enterprises to ensure that agent identity data is stored in compliance with jurisdictional data residency requirements.


# zkMe Self-Sovereign Identity

zkMe Self-Sovereign Identity empowers users with full control over their credentials, blending privacy, security, and decentralization to transform how identity verification is performed.

## What Is Self-Sovereign Identity?

Self-Sovereign Identity (SSI) is an identity model that gives individuals full ownership and control over their digital identity, without depending on any centralized authority. Unlike traditional identity systems where a government database, a social platform, or a corporate directory is the ultimate source of truth, SSI places the individual at the center of the trust relationship.

The concept rests on three foundational principles:

1. **User Control.** The individual decides what information to share, with whom, and for how long. No third party can access, revoke, or modify the individual’s identity data without their explicit consent.
2. **Portability.** Identity credentials are not locked into a single platform or service provider. A credential issued by one entity can be verified by any other entity that trusts the issuer, across organizational and jurisdictional boundaries.
3. **Minimal Disclosure.** Verification should require only the minimum information necessary. To prove you are over 18, you should not need to reveal your exact date of birth, your name, or your address.

SSI is typically implemented using **Verifiable Credentials (VCs)** and **Decentralized Identifiers (DIDs)** as defined by the W3C. A VC is a tamper-evident, cryptographically signed digital credential. A DID is a globally unique identifier that the individual controls, anchored on a decentralized ledger rather than a centralized registry.

***

## How zkMe Implements SSI

zkMe builds on the W3C SSI framework but introduces several innovations to address the limitations of traditional SSI implementations, particularly in the context of compliance-gated applications and the emerging Agent Economy.

The key differentiators of zkMe’s SSI implementation are:

* **Zero-Knowledge Proofs as the default presentation format.** In standard SSI, a Holder presents a Verifiable Presentation (VP) that may contain the actual claim values. In zkMe, the default VP format is a Zero-Knowledge Proof (ZKP) that proves a claim is true without revealing the underlying data. This is not an optional feature; it is the fundamental operating mode.
* **On-device ZKP generation.** The ZKP is generated entirely on the Holder’s device using open-source, audited algorithms. The raw credential data never leaves the device and is never transmitted to zkMe, the Verifier, or any third party.
* **Soulbound Token (SBT) anchoring.** Instead of relying on a traditional Verifiable Data Registry, zkMe anchors the anonymized proof on-chain as a non-transferable SBT, providing immutable, publicly auditable verification without exposing any personal data.
* **Agent delegation.** In the Agent Economy, the Holder can delegate bounded authority to AI agents, allowing agents to present proofs on the Holder’s behalf within strictly defined constraints.

***

## The Evolved SSI Roles

As an evolution of the roles needed for SSI, zkMe defines Roles with new interactions.

<figure><img src="/files/BuL5EI78OaqSnvUGgiJe" alt=""><figcaption><p>zkMe zkKYC role concept</p></figcaption></figure>

### **Issuer**

In contrast to the traditional SSI concept where a single Issuer both creates and signs the credential, zkMe splits the Issuer role into two distinct functions:

**Credential Issuer.** Refers to governmental or financial entities or organizations that issue physical or digital credentials (such as passports, national ID cards, bank statements, or professional licenses) to individual Holders. This role is equivalent to the Issuer in the traditional SSI trust triangle. The Credential Issuer is the original source of trust: the data in the credential is trusted because the issuing authority is trusted.

**ZKP Issuer.** A unique concept introduced by zkMe. The ZKP Issuer is not a remote service or a third-party organization. It is a trusted issuer program that runs locally on the Holder’s device. It utilizes trusted cryptographic setups and open-source, audited algorithms to process the Holder’s credentials and generate Verifiable Presentations in the form of Zero-Knowledge Proofs.

This separation is critical for privacy. The Credential Issuer (e.g., a government) issues the raw credential. The ZKP Issuer (running on the Holder’s device) transforms that credential into a privacy-preserving proof. At no point does any remote party see the raw credential data during the proof generation process.

zkMe enables **eligibility proofs**: ZKPs that demonstrate the Holder meets specific criteria set by the Verifier, without disclosing the actual information itself. For example, a proof can demonstrate that the Holder:

* Is above a certain age threshold (without revealing the exact date of birth)
* Is a resident of a permitted jurisdiction (without revealing the exact address)
* Is not on a sanctions or PEP list (without revealing the screening details)
* Holds a valid financial credential (without revealing account balances)

### **Holder**

The Holder is the individual who possesses Verifiable Credentials and uses them to access services, prove identity, or demonstrate eligibility. In zkMe’s model, the Holder maintains full custody of their credentials in an SSI Wallet (the zkMe App) and generates proofs on-demand.

Key properties of the Holder role in zkMe:

* **Credential custody.** The Holder’s credentials are encrypted and stored locally in the SSI Wallet. They are never stored on zkMe servers or any centralized database.
* **Selective disclosure.** The Holder chooses which claims to prove and to whom. The Verifier cannot request more information than the Holder is willing to share.
* **Proof generation.** The Holder generates ZKPs locally on their device. The proof is mathematically bound to the specific Verifier and interaction context, preventing replay attacks.

In the Agent Economy, the Holder also acts as the **Agent Principal**, delegating bounded authority to AI agents via the [zkVault](/hub/how-built/id-infra/zkvault). The delegation is cryptographically constrained: the agent can only prove specific claims, to specific targets, within a defined time window. See [Agent-Ready Credentials](/hub/how-built/credential-sys/agent-ready-credentials) for details.

### **Verifier**

Verifiers are applications, smart contracts, or services that need to confirm a Holder’s eligibility without processing their personal information. The Verifier checks the cryptographic validity of the ZKP against the on-chain state (Merkle root, revocation status, expiration) and receives a boolean result: the Holder either meets the criteria or does not.

The Verifier never learns:

* The Holder’s actual identity data
* The specific values of the credential claims
* Any information beyond what the proof is designed to reveal

In the Agent Economy, the Verifier must also perform **Agent Due Diligence** via zkKYA, verifying an incoming agent’s:

<table><thead><tr><th width="149.044921875">Check</th><th width="327.20703125">Credential</th><th>What It Verifies</th></tr></thead><tbody><tr><td>Accountability</td><td><a data-mention href="/pages/kcLeU6Y8fST2MxjpM2L4">/pages/kcLeU6Y8fST2MxjpM2L4</a></td><td>The agent is bound to a verified human principal</td></tr><tr><td>Safety</td><td><a data-mention href="/pages/aU7EFG6dwTqQf5HPXNjf">/pages/aU7EFG6dwTqQf5HPXNjf</a></td><td>The agent meets safety and capability standards</td></tr><tr><td>Intent</td><td><a data-mention href="/pages/1uk1PnUdULmTL0vAuegm">/pages/1uk1PnUdULmTL0vAuegm</a></td><td>The agent’s declared purpose matches its actions</td></tr><tr><td>Reputation</td><td><a data-mention href="/pages/fYBMUqwQFLnmC4MBsUPP">/pages/fYBMUqwQFLnmC4MBsUPP</a></td><td>The agent has a trustworthy operational history</td></tr></tbody></table>

### **Regulator**

The Regulator is a role unique to compliance-oriented SSI implementations. In zkMe’s model, the Regulator holds one of the key shards required to uncover a Holder’s identity in cases mandated by law (e.g., court orders, AML investigations).

The critical design constraint is that **no single party can de-anonymize the Holder alone**. The identity recovery process requires the collaboration of multiple key shard holders (currently a 2/2 threshold, planned expansion to 3/3). This ensures that the Regulator’s power is structurally limited: they can participate in lawful identity recovery, but they cannot unilaterally surveil or de-anonymize users.

For technical details on the threshold encryption mechanism, see [zkVault](/hub/how-built/id-infra/zkvault).

### **zkMe SBT**

In zkMe’s model, the on-chain representation of a Holder’s verified identity is a **Soulbound Token (SBT)**, a non-transferable token stored on public distributed ledgers. The SBT points to decentralized storage containing the anonymized ZKPs.

In contrast to typical SSI implementations where Verifiable Credentials may be stored in a centralized registry:

* Only anonymized VP claims (ZKPs) are stored; no raw personal data is ever written on-chain
* Claims are explicitly designed to prevent indirect Holder identification through correlation or inference
* Claims are only accessible to authorized stakeholders who hold the appropriate verification keys

The zkMe SBT contains the Holder’s DID, the ZKP, and one of the key shards used in the threshold encryption scheme that protects the Holder’s raw data.

For details on how SBTs are minted and managed, see [Smart Contracts](/hub/how-built/id-infra/smart-contracts). For details on the DID specification, see [DID Method](/hub/how-built/id-infra/did-method).

***

## The zkMe App: SSI Wallet

The zkMe App is the user-facing SSI wallet that implements the Holder role. It is a secure, decentralized mobile application utilizing MPC (Multi-Party Computation) cryptography for key management, ensuring that no single device or server holds the complete private key.

#### Core Capabilities

<table><thead><tr><th width="228.970703125">Capability</th><th>Description</th></tr></thead><tbody><tr><td><strong>MPC Key Management</strong></td><td>Private keys are distributed across multiple devices/nodes using MPC, eliminating single points of failure and reducing the risk of unauthorized access.</td></tr><tr><td><strong>OCR Document Scanning</strong></td><td>Built-in Optical Character Recognition extracts data from physical ID documents (passports, national IDs, driver’s licenses) directly on the device.</td></tr><tr><td><strong>Facial Recognition</strong></td><td>Biometric verification confirms that the user presenting the document is the same person depicted on it. The facial data is processed locally and never transmitted.</td></tr><tr><td><strong>ZKP Generation</strong></td><td>Zero-Knowledge Proofs are generated entirely on-device using the ZKP Issuer, transforming raw credential data into privacy-preserving proofs.</td></tr><tr><td><strong>SBT Minting</strong></td><td>Verification proofs in the form of Soulbound Tokens are minted from the SSI wallet onto the Holder’s asset wallet, anchoring the proof on-chain.</td></tr><tr><td><strong>Sanctions Screening</strong></td><td>Users are screened against criminal, terrorist, and PEP (Politically Exposed Person) lists as part of the credential issuance process.</td></tr></tbody></table>

The zkMe App is available at [app.zk.me](https://app.zk.me/). For web-based integration, the same functionality is accessible via the [zkMe SDK](/hub/start/onboarding/integration).


# zkMe DID Method

The zkMe DID method library uses Ethereum addresses as fully functional DIDs or Decentralized Identifiers. Third-party users can use this to create zkMe DID identities. It allows the controller to perform actions like resolve, update, and delete by encapsulating the zkMe DID registry and zkMe DID resolver. The DID identifier allows the controller to resolve the DID document for usage in different scenarios.

## Preface

The zkme-did method specification is in compliance with the DID requirements specified by the W3C Credentials Community Group. For a more detailed understanding of DID and other DID method specifications, please refer to this resource.

## Abstract

The zkMe DID method allows any Ethereum key pair account to become a valid identity. For registration of the DID Document, a smart contract has been deployed on the testnet (more are coming) address specified at registry-contract (zkMe GitHub).

## Target System

The `zkme-did-registry` contract currently is deployed on a testnet.

## DID Method Specific Identifier

For the zkMe DID representation, the MSI (Method Specific Identifier) is an Ethereum address, which can also be called a Hex-encoded secp256k1 compressed public key.

The DID URI for zkMe specific DID method is: `zkme`. A DID URI on the testnet will entail a prefix of order `did:zkme:testnet`.

**DID looks like on a testnet**

```
did:zkme:testnet:0x2acE1D0d919293D10Ef7611bC768F5386d908fc2
```

**DID looks like on a mainnet**

```
did:zkme:0x2acE1D0d919293D10Ef7611bC768F5386d908fc2
```

## DID On-Chain

Every DID on the chain has the same structure, defined as:

```solidity
struct zkMeDID {
    address controller;
    uint created;
    uint updated;
    string doc;
}
```

Where:

* **controller**: the address of the person who creates and manages the DID.
* **created**: holds the timestamp of the block when DID was created.
* **updated**: initially holds the timestamp of when the DID was created, but is updated if the controller updates the DID on the chain.
* **doc**: holds the entire DID document in the form of a string.

## Transaction Fee

To register a DID on the network, a small fee in the form of gas will be required. This gas fee is paid in the network’s gas token.

Transactions involving Create, Update, and Delete operations will require a transaction fee.

## DID Operations

To create a zkMe DID, the user is required to either hold a public key or an Ethereum wallet.

Next, the user will initiate a call to the `registerDID` function with the generated DID URI and other parameters such as contract address and RPC URL (for chain identification). The function will create a corresponding DID Document in the format below and log it on the chain.

```json
{
    "@context": "<https://w3id.org/did/v1>",
    "id": "did:zkme:testnet:0x2acE1D0d919293D10Ef7611bC768F5386d908fc2",
    "verificationMethod": [{
        "id": "did:zkme:testnet:0x2acE1D0d919293D10Ef7611bC768F5386d908fc2",
        "type": "EcdsaSecp256k1VerificationKey2019",
        "controller": "did:zkme:testnet:0x2acE1D0d919293D10Ef7611bC768F5386d908fc2",
        "publicKeyBase58": "7Lnm1frErwLwwZB1x2XbweLauYJpAZBjGxAXk55u248DEGGKF62apu9QuekaE3d7jMUUeHjk2F4sSYqKF3oeQ6b3ZLuMb"
    }]
}
```

### Register

Registration of a DID is performed by logging the transaction on the `zkme-did-registry` smart contract by invoking:

```jsx
import { registerDID } from "zkme-did-registrar";
const txHash = await registerDID(did, publicKey, signerOrProvider, url?, contractAddress?);
```

The function returns a `txHash` and DID URI on successful execution.

### Update

The DID controller can request the update functionality if they wish to edit the DID document stored on the ledger by invoking:

```jsx
import { updateDidDoc } from "zkme-did-registrar";
const txHash = await updateDidDoc(did, didDoc, signerOrProvider, url?, contractAddress?);
```

### Delete

The owner of a DID document has the authority to control the instance of the document on the chain. To maintain true ownership, the network allows the user to delete their instance of the DID document from the blockchain at any time. It’s important to note that only the owner or controller of the DID document will have permission to delete the instance.

To remove the instance of DID from the ledger, use as follows:

```jsx
import { deleteDidDoc } from "zkme-did-registrar";
const txHash = await deleteDidDoc(did, signerOrProvider, url?, contractAddress?);
```

### Resolve

To resolve a DID, you need to fetch the DID document registered on the chain. When you query the resolver with a DID, it returns the associated DID document. The resolver sends out a query to fetch the registered DID document from the chain. This document can then be used for signing or verification purposes.

## Security Considerations

To improve security, all transactions to register, update, or delete a DID on the network are signed using key pairs generated by the secp256k1 algorithm. If there are any vulnerabilities in this algorithm, they could also be reflected in the zkMe DID method protocol. Additionally, to further enhance security, the zkMe DID method implementation only stores the DID document on the blockchain with valid timestamps.

## Privacy

In terms of privacy, a DID is pseudonymous. However, the user needs to note that since the DID zkMe is registered on a decentralized chain, it cannot be fully revoked. Additionally, once a DID document is registered, only the owner of the DID can update or revoke it as a privacy measure.

## Reference Implementation

Users who wish to have a DID on the network are expected to use the reference implementation of `zkme-did-registrar` and `zkme-did-resolver` to register and resolve zkMe-based DIDs on the chain.


# Faceprint DID Creation

## DID Creation Based on Homomorphic Encrypted Face Features

This scheme uses homomorphic encryption technology to protect users' facial feature data. During user registration, facial features are extracted using liveness verification technology, encrypted using homomorphic encryption technology, and uploaded to the server. The server uses homomorphic encryption technology to compare and generate similarity ciphertext, which will be sent back to the frontend application for decryption and verification. If the user's facial features are not registered, the DID identifier and facial feature ciphertext will be saved in the database to complete the registration.

Homomorphic encryption technology allows calculations to be performed on data in an encrypted state, which can prevent sensitive data from being exposed in plaintext. At the same time, liveness verification technology can prevent malicious users from uploading photos of others to register fake accounts. This scheme provides a secure and reliable method for creating DID identifiers and protecting user privacy.

The creation process is as follows:

1. Generate a public-private key pair on the frontend: Users generate a public-private key pair on the frontend application, where the public key is used to create the DID identifier, and the private key is used for signature.
2. Generate a DID identifier: The DID identifier is generated using the public key, which is used to identify the user's identity.
3. Scan the user's face, perform liveness verification, and extract facial features: The frontend application scans the user's face, uses liveness verification technology to ensure that the face is real, and extracts facial features (faceprint) from it.
4. Homomorphically encrypt the faceprint vector values and upload the facial feature ciphertext to the server: Use homomorphic encryption technology to encrypt the facial features, and upload the encrypted facial feature values to the server.
5. Perform similarity matching based on facial feature ciphertext on the server and obtain the similarity ciphertext: The server uses homomorphic encryption technology to compare the encrypted facial features, and obtains a similarity score ciphertext.
6. Send the similarity ciphertext to the frontend: The server sends the similarity ciphertext to the frontend application.
7. Decrypt the similarity ciphertext on the frontend and determine if the facial features have been registered: The frontend application uses the private key to decrypt the similarity ciphertext to determine whether the facial features have been registered.
8. Register the DID identifier and facial feature ciphertext: If the facial features are not registered, the DID identifier and facial feature ciphertext will be saved to the database to complete the registration process.

<figure><img src="/files/xxrjs4lkUJpaO3CFcAUf" alt=""><figcaption><p>DID Creation Based on Homomorphic Encrypted Face Features</p></figcaption></figure>


# zkMe zkVault

This section explains the zkMe data recovery procedure enabled by the zkMe Data Vault required to fulfill regulatory data storage and retention requirements in all major jurisdictions.

## Vault Overview

The use of decentralized storage combined with threshold encryption ensures that only authorized parties can access these documents under strictly predetermined conditions and close collaboration between all involved stakeholders. At no point can a single stakeholder unlock the Holder's private data alone.

In threshold encryption, a group of n participants collaboratively generate a public key, while the decryption key is shared among them. The Holder stays anonymous until proven guilty.

The public key can be used to encrypt messages directly, but decryption requires the participation of a minimum number of t participants among the n participants to obtain the correct plaintext. A crypto system that requires at least t participants to decrypt is called a (t/n) threshold crypto system.

<figure><img src="/files/9txHLtFWAED49anQbiSI" alt=""><figcaption></figcaption></figure>

### Encryption/ decryption process

The public key can be used to encrypt messages directly, but decryption requires the participation of a minimum number of t participants among the n participants to obtain the correct plaintext. A crypto system that requires at least t participants to decrypt is called a (t/n) threshold crypto system.

<figure><img src="/files/msoBSE9mPjxPWYCUSUhO" alt=""><figcaption></figcaption></figure>

The zkMe protocol implements a (2/2) threshold cryptosystem (to be expanded to 3/3 in future iterations, see below).

Here, two-party EC-ElGamal scheme: Two-party computation of ciphertexts, the global decryption key is given by: $$x = x\_1 + x\_2 \ mod p$$ , in additive key share form. The global encryption key is given by ℎ = 𝑥 ∗ 𝑃:

**Notation**

<table><thead><tr><th>Symbol</th><th>Notion</th><th width="141">Symbol</th><th>Notion</th></tr></thead><tbody><tr><td><span class="math"> P </span></td><td>Elliptic curve base point</td><td><span class="math"> x </span></td><td>Global private key(no one knows it)(type: scalar)</td></tr><tr><td><span class="math"> p </span></td><td>Order of the base point</td><td><span class="math"> h </span></td><td>Global public key(type: ecpoint)</td></tr><tr><td><span class="math"> \mathbf{𝑍_𝑛} </span></td><td>Field of operations for elliptic curves</td><td><span class="math"> x_i </span></td><td>party-i 's private key (key share of )(type: scalar)</td></tr><tr><td>+</td><td>Addition operation in numerical terms</td><td><span class="math"> h_i </span></td><td>Point addition operation on elliptic curves</td></tr><tr><td>*</td><td>Multiplication operation in numerical terms</td><td><span class="math"> \mathbf{𝑐_𝑖} </span></td><td>party-i 's commitment(type: scalar)</td></tr><tr><td><span class="math"> \mathbf{⊕} </span></td><td>Point addition operation on elliptic curves</td><td><span class="math"> \mathbf{𝑟_𝑖}</span></td><td>Random number(type: scalar)</td></tr><tr><td><span class="math"> \mathbf{⊗} </span></td><td>Point doubling operation on elliptic curves</td><td><span class="math"> m </span></td><td>message</td></tr><tr><td><span class="math">𝐻 </span></td><td>keccak256</td><td>ciphertext</td><td>ciphertext of m under AES with symmetric key</td></tr><tr><td>𝑘𝑝𝑜𝑖𝑛𝑡</td><td>Point can derive the symmetric key</td><td>sym_key</td><td>sym_key k</td></tr></tbody></table>

#### Phase 1: Global public key negotiation

The threshold encryption public key negotiation goes through the following steps.

1. Generate the keypair $$(𝑥\_1 ,ℎ\_1)$$ for party-1 regarding ℎ and make a commitment $$𝑐\_1= 𝐻(ℎ\_1 ,𝑟\_1)$$ for $$ℎ\_1$$. Generate keypair $$(𝑥\_2 ,ℎ\_2)$$ for party-2 regarding ℎ and make a commitment $$𝑐\_2=𝐻(ℎ\_2 ,𝑟\_2)$$ for $$ℎ\_2$$.

| Function                               | Operation                         |
| -------------------------------------- | --------------------------------- |
| generate\_key\_share(m, n) at party-i  | 𝑥𝑖 ⟵𝑅 \[𝑚,𝑛], ℎ𝑖=𝑥𝑖⊗𝑃    |
| rand(p) at party-i                     | 𝑟 ⟵𝑅 \[1,𝑝]                    |
| generate\_commitment(m, n) at party-i  | 𝑐=𝐻(𝑚 \|\|𝑛)                  |
| verify\_commitment(c, m, n) at party-i | 𝑐′=𝐻(𝑚 \|\|𝑛), check 𝑐== 𝑐′ |

2. Party-1 sends $$𝑐\_1$$ to party-2.
3. Party-2 sends $$𝑐\_2$$ and the preimage ($$ℎ\_2 ,𝑟\_2$$) of $$𝑐\_2$$ to party-1.
4. Party-1 verifies $$𝑐\_2=𝐻(ℎ\_2 ,𝑟\_2)$$ and then sends the preimage ($$ℎ\_1 , 𝑟\_1$$) of $$𝑐\_1$$ to party-2.
5. Party-2 verifies $$𝑐\_1=𝐻(ℎ\_1 ,𝑟\_1)$$ .
6. Party-1 and party-2 each compute $$ℎ=ℎ\_1+ℎ\_2$$, confirm that the results are the same, and jointly announce the global encryption key as $$ℎ$$.

| Function                                | Operation |
| --------------------------------------- | --------- |
| compute\_global\_pubkey(m,n) at party-i | ℎ=𝑚⊕𝑛   |

<figure><img src="/files/Nkl2I0kUg9SEAe3nQdtF" alt=""><figcaption></figcaption></figure>

#### Phase 2: Encryption

The following process is standard hybrid encryption using EC-ElGamal, assuming that the encryption party has already obtained the global encryption key ℎ through the following steps:

1. The encrypting party calls generate\_sym\_key(p) to generate a random 𝑘𝑝𝑜𝑖𝑛𝑡, and then calls compute\_sym\_key($$𝑘\_{𝑝𝑜𝑖𝑛𝑡}$$) to compute the symmetric key pair sym\_key.

| Function                                    | Operation                                                      |
| ------------------------------------------- | -------------------------------------------------------------- |
| generate\_key\_point(p) at party-i          | 𝑘 ⟵𝑅 \[1,𝑝], $$𝑘\_{𝑝𝑜𝑖𝑛𝑡}$$=𝑘⊗𝑃                     |
| compute\_sym\_key( 𝑘𝑝𝑜𝑖𝑛𝑡) at party-i | 𝑠𝑦𝑚\_𝑘𝑒𝑦=𝐻(𝑝𝑜𝑖𝑛𝑡2𝑏𝑦𝑡𝑒𝑠($$𝑘\_{𝑝𝑜𝑖𝑛𝑡}$$)) |

2. The encrypting party calls the AES algorithm to encrypt the message m using the symmetric key sym\_key to obtain the symmetric ciphertext 𝑒𝑛𝑐, and then uses EC-ElGamal to encrypt by calling elgamal\_encrypt($$𝑘\_{𝑝𝑜𝑖𝑛𝑡}, ℎ$$) to obtain ( 𝐶1,𝐶2 ).

| Function                                                    | Operation                                                   |
| ----------------------------------------------------------- | ----------------------------------------------------------- |
| elgamal\_encrypt( $$𝑘\_{𝑝𝑜𝑖𝑛𝑡}, h$$) at encrypt-party | 𝑟 ⟵𝑅 \[1,𝑝], 𝐶1=𝑟⊗𝑃, 𝐶2=$$𝑘\_{𝑝𝑜𝑖𝑛𝑡}$$⊕ (𝑟⊗ℎ) |

3. The ciphertext (ciphertext, 𝐶1,𝐶2 ) is made public.

#### Phase 3: Threshold decryption

In case regulators initiate bad actor proceedings, the threshold cryptography protecting the raw data of the user can be recovered using the following steps:

1. Each party-i calculates the partial decryption $$𝐷\_𝑖$$ with respect to $$𝐶\_1$$.

| Function                                                  | Operation             |
| --------------------------------------------------------- | --------------------- |
| compute\_partial\_decryption($$xi$$, $$C\_1$$) at party-i | 𝐷𝑖 =𝑥𝑖⊗ $$𝐶\_1$$ |

2. Party-i sends $$𝐷\_𝑖$$ to party-3-i.
3. Party-i locally calls elgamal\_decrypt(D1, D2, C2) to obtain , and then calls compute\_sym\_key($$𝑘\_{𝑝𝑜𝑖𝑛𝑡}$$) to compute the symmetric key pair sym\_key.

| Function                                | Operation                                       |
| --------------------------------------- | ----------------------------------------------- |
| elgamal\_decrypt(D1, D2, C2) at party-i | 𝐷= 𝐷1⊕𝐷2, $$𝑘\_{𝑝𝑜𝑖𝑛𝑡}$$ = 𝐶2 ⊕ (−𝐷) |

4. Party-i calls the AES algorithm to decrypt the symmetric ciphertext 𝑒𝑛𝑐 using the symmetric key sym\_key to obtain the message m

<figure><img src="/files/3xYYGU05zV1DwiyyGuBD" alt=""><figcaption></figcaption></figure>

#### Future extension: (3/3) threshold

As shown in the figure below, the (3/3) threshold cryptosystem will be implemented in the next phase. zkMe is currently communicating with different jurisdictions to improve the entire procedure.

<figure><img src="/files/656FtWsHXZKUpQlUZEHa" alt=""><figcaption></figcaption></figure>

### Retrieval Procedure

1. **Preliminary Investigation**: Law enforcement conducts a preliminary investigation to gather evidence and establish reasonable suspicion or probable cause related to the user's activities.
2. **Legal Process**: Law enforcement obtains the necessary legal authorization, such as a warrant or court order, to access the user's identity document.
3. **Contact Verifier Governance**: Law enforcement reaches out to the web3 protocol governance with the user's digital asset wallet address and provides the legal authorization obtained in step 2.
4. **Verify Legal Request**: The web3 protocol governance verifies the legitimacy of the legal request and confirms the scope of the information required.
5. **Stakeholder Collaboration**: Each stakeholder (issuer, verifier, regulator) verifies the legal request independently. If they determine that the request is valid, they agree to participate in the decryption process.
6. **Threshold Decryption**: The stakeholders collaboratively decrypt the user's Identity document using their respective decryption key shares. This process ensures that no single stakeholder can access the private data of the user without the required collaboration.
7. **Provide Decrypted Document**: Once the user's Identity document has been decrypted, the web3 Protocol Governance provides the decrypted document to law enforcement within the scope of the legal authorization.

<figure><img src="/files/KyeTCuIx7oYvvedFswn1" alt=""><figcaption></figcaption></figure>

***

## Exkursus: **KYC Data Storage & Retention Requirements in Major Jurisdictions**

The Know Your Customer (KYC) process is an essential part of financial institutions' efforts to combat money laundering, terrorist financing, and other illicit activities. Regulatory authorities around the world have established guidelines for KYC data storage and retention to ensure the availability of information for investigations and to maintain the integrity of the financial system. Below are the requirements in some major jurisdictions:

<details>

<summary>United States</summary>

In the United States, the Bank Secrecy Act (BSA) and the USA PATRIOT Act outline the requirements for financial institutions regarding KYC data storage and retention. According to these regulations, financial institutions are required to:

* Retain records of customer identification information for five years after the account is closed or the relationship is terminated.
* Keep records of suspicious activity reports (SARs) and currency transaction reports (CTRs) for at least five years.

</details>

<details>

<summary>European Union</summary>

In the European Union, the Anti-Money Laundering Directive (AMLD) governs the KYC data storage and retention requirements for financial institutions. Under the AMLD, financial institutions are required to:

* Retain customer due diligence (CDD) records and supporting documentation for at least five years after the end of the business relationship or the completion of an occasional transaction.
* Delete personal data after the retention period, unless national law requires a longer storage period for specific purposes.

</details>

<details>

<summary>United Kingdom</summary>

In the United Kingdom, the Money Laundering Regulations (MLRs) outline the KYC data storage and retention requirements. Under the MLRs, financial institutions are required to:

* Retain records of CDD measures and transactions for at least five years after the end of the business relationship or the completion of an occasional transaction.
* Delete personal data after the retention period, unless there are legal or regulatory reasons to retain it for a longer period.

</details>

<details>

<summary>China</summary>

In China, the Anti-Money Laundering Law (AMLL) and the People's Bank of China (PBOC) regulations govern the KYC data storage and retention requirements for financial institutions. According to these regulations, financial institutions are required to:

* Retain records of customer identification information and transaction records for at least five years from the date the transaction or account activity occurred.
* Keep records of large-value and suspicious transactions for at least five years.

</details>

<details>

<summary>Hong Kong</summary>

In Hong Kong, the Anti-Money Laundering and Counter-Terrorist Financing Ordinance (AMLO) and guidelines issued by the Hong Kong Monetary Authority (HKMA) govern the KYC data storage and retention requirements for financial institutions. According to these regulations, financial institutions are required to:

* Retain records of customer identification information and transaction records for at least six years after the end of the business relationship or the completion of an occasional transaction.
* Maintain records of suspicious transaction reports (STRs) for at least six years.

</details>

<details>

<summary>Singapore</summary>

In Singapore, the Monetary Authority of Singapore (MAS) enforces the Anti-Money Laundering and Countering the Financing of Terrorism (AML/CFT) rules, which outline the KYC data storage and retention requirements for financial institutions. Under these rules, financial institutions are required to:

* Retain records of customer due diligence (CDD) measures, including customer identification information, account files, and business correspondence, for at least five years after the end of the business relationship or the completion of an occasional transaction.
* Keep records of transaction records and STRs for at least five years from the date of the transaction or the submission of the STR.

</details>

### References

> Financial Crimes Enforcement Network. (n.d.). *Bank Secrecy Act regulations*. Retrieved from <https://www.fincen.gov/resources/statutes-regulations/bsa-regulations>
>
> U.S. Department of the Treasury. (n.d.). *USA PATRIOT Act*. Retrieved from <https://home.treasury.gov/policy-issues/office-of-terrorism-and-financial-intelligence/usa-patriot-act>
>
> European Parliament and Council of the European Union. (2018). *Directive (EU) 2018/843*. Retrieved from <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32018L0843>
>
> HM Government. (2017). *The Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017*. Retrieved from <https://www.legislation.gov.uk/uksi/2017/692/contents/made>
>
> National People's Congress. (2006). *Anti-Money Laundering Law of the People's Republic of China*. Retrieved from <http://www.npc.gov.cn/englishnpc/Law/2009-02/20/content_1471587.htm>
>
> People's Bank of China. (n.d.). *People's Bank of China regulations*. Retrieved from <http://www.pbc.gov.cn/en/3688016/index.html>
>
> Hong Kong Government. (2012). *Anti-Money Laundering and Counter-Terrorist Financing Ordinance*. Retrieved from <https://www.elegislation.gov.hk/hk/cap615>
>
> Hong Kong Monetary Authority. (n.d.). *Guidelines on Anti-Money Laundering and Counter-Financing of Terrorism*. Retrieved from <https://www.hkma.gov.hk/eng/regulatory-resources/anti-money-laundering-and-counter-financing-of-terrorism/guidelines/>
>
> Monetary Authority of Singapore. (n.d.). *Anti-Money Laundering and Countering the Financing of Terrorism*. Retrieved from <https://www.mas.gov.sg/regulation/anti-money-laundering>


# zkMe FHE

A DID scheme based on homomorphic encryption of face features

CKKS algorithm is a fully homomorphic encryption (HE) scheme used for encrypted computation. Its full name is "Cheon-Kim-Kim-Song" and was proposed by *Cheon et al. (2017)* \[3]. The CKKS algorithm can support encrypted computation for complex and real number data, and can achieve relatively high encryption computation accuracy and small ciphertext expansion factors, making it one of the widely used fully homomorphic encryption schemes today.

## CKKS Plaintext Space

Unlike other HE schemes, the CKKS scheme supports approximate arithmetic over complex numbers. More precisely, the plaintext space of the CKKS scheme is $$\mathbb{C}^{n/2}$$ for some power-of-two integer $$n$$. To deal with the complex plaintext vector efficiently, *Cheon et al.* proposed plaintext encoding/decoding methods which exploits a ring isomorphism $$\phi: \mathbb{R}\[X]/(X^n+1) \rightarrow \mathbb{C}^{n/2}$$ .

### **Encoding Method**

Given a plaintext vector $$\vec z = (z\_1,z\_2,...,z\_{n/2}) \in \mathbb{C}^{n/2}$$ and a scaling factor $$\Delta > 1$$, the plaintext vector is encoded as a polynomial $$m(X) \in R:= \mathbb{Z}\[X]/(X^n+1)$$ by computing $$m(X) = \lfloor \Delta \cdot \phi^{-1}(\vec z) \rceil \in R$$ where $$\lfloor \cdot \rceil$$ denotes the coefficient-wise rounding function.

### **Decoding Method**

Given a message polynomial $$m(X) \in R$$  and a scaling factor $$\Delta > 1$$, the message polynomial is decoded to a complex vector $$\vec z \in \mathbb{C}^{n/2}$$ by computing $$\vec z = \Delta^{-1}\cdot \phi(m(X)) \in \mathbb{C}^{n/2}$$.

Here the scaling factor $$\Delta > 1$$ enables us to control the encoding/decoding error which is occurred by the rounding process. Namely, one can obtain the approximate equation $$\text{Dcd}(\text{Ecd}(\vec z; \Delta); \Delta) \approx \vec z$$ by controlling $$\Delta$$ where $$\text{Ecd}$$ and $$\text{Dcd}$$ denote the encoding and decoding algorithm, respectively.

From the ring-isomorphic property of the mapping $$\phi: \mathbb{R}\[X]/(X^n+1) \rightarrow \mathbb{C}^{n/2}$$ , for $$m\_1 = \text{Ecd}(\vec z\_1;\Delta)$$ and $$m\_2 = \text{Ecd}(\vec z\_2;\Delta)$$, the following hold:

* $$\text{Dcd}(m\_1 + m\_2;\Delta) \approx \vec z\_1 + \vec z\_2$$,
* $$\text{Dcd}(m\_1\cdot m\_2;\Delta) \approx \vec z\_1 \circ \vec z\_2$$,

where $$\circ$$  denotes the \[\[Hadamard product (matrices)|Hadamard product]] of the same-length vectors. These properties guarantee the approximate correctness of the computations in the encoded state when the scaling factor $$\Delta$$ is chosen appropriately.

## **Algorithms**

The CKKS scheme basically consists of those algorithms: key Generation, encryption, decryption, homomorphic addition and multiplication, and rescaling. For a positive integer $$q$$, let $$R\_q := R/qR$$ be the quotient ring of $$R$$ modulo $$q$$. Let $$\chi\_s$$, $$\chi\_r$$ and $$\chi\_e$$ be distributions over $$R$$ which output polynomials with small coefficients. These distributions, the initial modulus $$Q$$, and the ring dimension $$n$$ are predetermined before the key generation phase.

### **Key generation**

The key generation algorithm is following:

* Sample a secret polynomial $$s \leftarrow \chi\_s$$.
* Sample $$a$$ (resp. $$a'$$) uniform randomly from $$R\_Q$$ (resp. $$R\_{PQ}$$), and $$e,e' \leftarrow \chi\_e$$.
* Output a secret key $$sk \leftarrow (1, s)\in R\_Q^2$$, a public key $$pk \leftarrow (b = -a \cdot s + e, a) \in R\_Q^2$$, and an evaluation key $$evk \leftarrow (b' = -a' \cdot s + e' + P\cdot s^2, a') \in R\_{PQ}^2$$.

### **Encryption**

The encryption algorithm is following:

* Sample an ephemeral secret polynomial $$r \leftarrow \chi\_r$$.
* For a given message polynomial $$m \in R$$, output a ciphertext $$ct \leftarrow (c\_0 = r\cdot b + e\_0 + m, c\_1 = r\cdot a + e\_1) \in R\_Q^2$$.

### **Decryption**

The decryption algorithm is following:

* For a given ciphertext $$ct \in R\_q^2$$, output a message $$m' \leftarrow \langle ct, sk \rangle </math> <math> (\text{mod } q)$$.

The decryption outputs an approximate value of the original message, i.e., $$\text{Dec}(sk, \text{Enc}(pk, m)) \approx m$$, and the approximation error is determined by the choice of distributions $$\chi\_s, \chi\_e, \chi\_r$$. When considering homomorphic operations, the evaluation errors are also included in the approximation error. Basic homomorphic operations, addition and multiplication, are done as follows.

### **Homomorphic Addition**

The homomorphic addition algorithm is following:

* Given two ciphertexts $$ct$$ and $$ct'$$ in $$R\_q^2$$, output $$ct\_{\text{add}} \leftarrow ct + ct' \in R\_q^2$$.

The correctness holds as $$\text{Dec}(sk, ct\_\text{add}) \approx \text{Dec}(sk, ct) + \text{Dec}(sk, ct')$$.

### **Homomorphic Multiplication**

The homomorphic multiplication algorithm is following:

* Given two ciphertext $$ct =(c\_0, c\_1)$$ and $$ct' =(c\_0', c\_1')$$ in $$R\_q^2$$, compute $$(d\_0, d\_1, d\_2) = (c\_0c\_0', c\_0c\_1'+c\_1c\_0', c\_1c\_1')$$ $$(\text{mod } q)$$. Output $$ct\_{\text{mult}} \leftarrow (d\_0, d\_1) + \lfloor P^{-1}\cdot d\_2 \cdot evk \rceil \in R\_q^2$$.

The correctness holds as $$\text{Dec}(sk, ct\_\text{mult}) \approx \text{Dec}(sk, ct) \cdot \text{Dec}(sk, ct')$$.

Note that the approximation error (on the message) exponentially grows up on the number of homomorphic multiplications. To overcome this problem, most of HE schemes usually use a modulus-switching technique which was introduced by *Brakerski et al. (2012)* \[4].

In case of HEAAN, the modulus-switching procedure is called rescaling. The Rescaling algorithm is very simple compared to Brakerski-Gentry-Vaikuntanathan's original algorithm. Applying the rescaling algorithm after a homomomorphic multiplication, the approximation error grows linearly, not exponentially.

### **Rescaling**

The rescaling algorithm is following:

* Given a ciphertext $$ct \in R\_q^2$$ and a new modulus $$q'$$ output a rescaled ciphertext $$ct\_{\text{rs}}\leftarrow \lfloor (q'/q)\cdot ct\rceil \in R\_{q'}^2$$.

The total procedure of the CKKS scheme is as following: Each plaintext vector $$\vec z$$ which consists of complex (or real) numbers is firstly encoded as a polynomial $$m(X) \in R$$ by the encoding method, and then encrypted as a ciphertext $$ct \in R\_q^2$$. After several homomorphic operations, the resulting ciphertext is decrypted as a polynomial $$m'(X) \in R$$ and then decoded as a plaintext vector $$\vec z'$$ which is the final output.

## zkMe DID Creation Based on FHE Face Features

This scheme uses homomorphic encryption technology to protect users' facial feature data. During user registration, facial features are extracted using liveness verification technology, encrypted using homomorphic encryption technology, and uploaded to the server. The server uses homomorphic encryption technology to compare and generate similarity ciphertext, which will be sent back to the frontend application for decryption and verification. If the user's facial features are not registered, the DID identifier and facial feature ciphertext will be saved in the database to complete the registration.

Homomorphic encryption technology allows calculations to be performed on data in an encrypted state, which can prevent sensitive data from being exposed in plaintext. At the same time, liveness verification technology can prevent malicious users from uploading photos of others to register fake accounts. This scheme provides a secure and reliable method for creating DID identifiers and protecting user privacy.

The creation process is as follows:

1. Generate a public-private key pair on the frontend: Users generate a public-private key pair on the frontend application, where the public key is used to create the DID identifier, and the private key is used for signature.
2. Generate a DID identifier: The DID identifier is generated using the public key, which is used to identify the user's identity.
3. Scan the user's face, perform liveness verification, and extract facial features: The frontend application scans the user's face, uses liveness verification technology to ensure that the face is real, and extracts facial features (faceprint) from it.
4. Homomorphically encrypt the faceprint vector values and upload the facial feature ciphertext to the server: Use homomorphic encryption technology to encrypt the facial features, and upload the encrypted facial feature values to the server.
5. Perform similarity matching based on facial feature ciphertext on the server and obtain the similarity ciphertext: The server uses homomorphic encryption technology to compare the encrypted facial features, and obtains a similarity score ciphertext.
6. Send the similarity ciphertext to the frontend: The server sends the similarity ciphertext to the frontend application.
7. Decrypt the similarity ciphertext on the frontend and determine if the facial features have been registered: The frontend application uses the private key to decrypt the similarity ciphertext to determine whether the facial features have been registered.
8. Register the DID identifier and facial feature ciphertext: If the facial features are not registered, the DID identifier and facial feature ciphertext will be saved to the database to complete the registration process.

## References

> * Boddeti, Vishnu Naresh. "Secure face matching using fully homomorphic encryption." *2018 IEEE 9th International Conference on Biometrics Theory, Applications and Systems (BTAS)*. IEEE, 2018.
> * Liu, Weiyang, et al. "Sphereface: Deep hypersphere embedding for face recognition." *Proceedings of the IEEE conference on computer vision and pattern recognition*. 2017.
> * Cheon, Jung Hee, et al. "Homomorphic encryption for arithmetic of approximate numbers." *Advances in Cryptology–ASIACRYPT 2017: 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December 3-7, 2017, Proceedings, Part I 23*. Springer International Publishing, 2017.
> * Brakerski, Zvika. "Fully homomorphic encryption without modulus switching from classical GapSVP." *Advances in Cryptology–CRYPTO 2012: 32nd Annual Cryptology Conference, Santa Barbara, CA, USA, August 19-23, 2012. Proceedings*. Springer Berlin Heidelberg, 2012.


# zkMe zkPassport

## Overview

Identity document verification requires more than document images and biometric matching. Traditional identity verification systems rely on visual artifacts and behavioral signals that lack any cryptographic link to the issuing authority. As generative AI makes these artifacts trivial to fabricate, image-based verification no longer provides a reliable foundation for authentic identity claims.

zkPassport addresses this structural limitation by shifting the trust anchor from visual evidence to cryptographic issuance. Every modern electronic passport contains a chip signed by the issuing country’s national PKI. zkPassport verifies this signature chain directly on the user’s device and generates a Zero Knowledge Proof that attests to the authenticity of sovereign-issued identity, without exposing personal data.

Identity authenticity is established by cryptography, not by appearance.

***

## The Trust Anchor Problem

Digital identity verification has operated for decades on a fragile premise: that images of documents and biometric selfies are difficult enough to forge that they can serve as proof of identity. This premise is now broken.

Generative AI has rendered visual evidence structurally untrustworthy. Synthetic faces, fabricated document images, and real time deepfake video can deceive both human reviewers and automated systems. The problem is not that fraud detection models need better training; the problem is architectural. When the source document and the biometric reference can both be synthesized, the verification system is comparing one forgeable artifact against another. There is no ground truth.

The core issue is the absence of a trust anchor, a foundational element that cryptographically guarantees authenticity. Traditional eKYC systems infer document validity from visual security features. They infer liveness from behavioral signals in video. They infer authenticity from the absence of detected anomalies. But inference is not proof. These systems cannot answer the fundamental question: "How do I know this document was actually issued by the authority it claims?"

This is not a problem that can be solved by tuning risk parameters or improving anomaly detection. No amount of model refinement can introduce a trust anchor where none exists. The solution requires a different architecture entirely.

***

## The Necessity of a Trust Anchor

Sovereign-issued identity is not a biographical fact like a name or date of birth. It is a legal status conferred by a sovereign nation. Proving a sovereign-issued identity claim requires demonstrating that a specific government authority has formally issued and signed that claim.

This creates two distinct challenges that traditional eKYC cannot address:

* **The Verification Gap:** When a user uploads a passport image, the verifier has no cryptographic way to confirm that the document was genuinely issued by the claimed country. They can only confirm that the image appears to contain expected visual features. In an era of pixel perfect document forgery, this distinction is critical. Traditional eKYC can tell you what a document claims; it cannot tell you whether that claim is true.
* **The Privacy Paradox:** Under conventional models, proving a sovereign-issued identity attribute requires exposing the entire identity document: full name, passport number, date of birth, place of birth, and facial photograph. Users must over disclose sensitive personal information to prove a single binary attribute. This creates a direct conflict between compliance requirements and data minimization principles, a conflict that document centric verification cannot resolve because it conflates data disclosure with proof.

***

## The ePassport as a Cryptographic Trust Anchor

The electronic passport (ePassport), standardized under ICAO Document 9303, provides the trust anchor that traditional eKYC lacks. Its security architecture consists of multiple layers designed to prevent unauthorized access, data tampering, and chip cloning.

### Security Mechanisms at the ePassport Layer

The following security mechanisms are part of the standard ePassport architecture. zkPassport builds on these foundations and focuses on Passive Authentication to establish cryptographic proof of issuance.

<table><thead><tr><th width="244.2490234375">Mechanism</th><th>Purpose</th></tr></thead><tbody><tr><td><strong>BAC / PACE</strong></td><td>Access control that prevents the chip from being read without authorization. The reader must first obtain keys derived from the Machine Readable Zone (MRZ) printed on the passport.</td></tr><tr><td><strong>Passive Authentication (PA)</strong></td><td>Data integrity verification through digital signatures. Ensures chip data has not been tampered with since issuance.</td></tr><tr><td><strong>Active Authentication (AA)</strong></td><td>Chip authenticity verification that prevents cloning. Proves the chip itself is genuine, not a copy.</td></tr></tbody></table>

zkPassport primarily leverages Passive Authentication, which provides the cryptographic proof that the data on the chip was signed by the issuing country.

### Data Structure on the Chip

Passport data is organized into standardized Data Groups (DGs), each containing specific categories of information:

<table><thead><tr><th width="122.8037109375">Data Group</th><th width="529.8759765625">Contents</th><th width="110.0712890625">Required</th></tr></thead><tbody><tr><td>DG1</td><td>MRZ information (name, nationality, date of birth, passport number)</td><td>Mandatory</td></tr><tr><td>DG2</td><td>Facial image</td><td>Mandatory</td></tr><tr><td>DG3</td><td>Fingerprints</td><td>Optional</td></tr><tr><td>DG7</td><td>Signature image</td><td>Optional</td></tr><tr><td>DG11</td><td>Additional personal details</td><td>Optional</td></tr><tr><td>DG14</td><td>Security options for Active Authentication</td><td>Conditional</td></tr><tr><td>DG15</td><td>Active Authentication public key</td><td>Conditional</td></tr></tbody></table>

### The Signature Chain

The integrity of these Data Groups is protected by a chain of cryptographic signatures:

<table><thead><tr><th width="126.2509765625">Component</th><th width="211.0595703125">Full Name</th><th>Role</th></tr></thead><tbody><tr><td><strong>CSCA</strong></td><td>Country Signing Certification Authority</td><td>Root certificate authority operated by each issuing country. The ultimate source of trust.</td></tr><tr><td><strong>DS</strong></td><td>Document Signer</td><td>Intermediate certificate signed by the CSCA. Used to sign individual passport data.</td></tr><tr><td><strong>SOD</strong></td><td>Security Object Document</td><td>A file stored on the chip containing hashes (digital fingerprints) of all Data Groups, signed by the DS.</td></tr></tbody></table>

When a passport is issued, the hash of each Data Group is computed and stored in the SOD. The SOD is then signed using the Document Signer’s private key. The DS certificate, which contains the corresponding public key, is itself signed by the country’s CSCA.

<figure><img src="/files/l3duX9gK5dFrfLBSl2wu" alt="" width="375"><figcaption></figcaption></figure>

### Passive Authentication and Verification

This architecture enables Passive Authentication: any party with access to CSCA public keys can verify, without any network connectivity or interaction with the issuing government, that:

1. The data on the passport chip has not been modified since issuance (by comparing DG hashes against the SOD).
2. The SOD was signed by a valid Document Signer certificate.
3. The DS certificate chains to the country’s CSCA.
4. The passport was therefore issued by the claimed sovereign authority.

The verification is deterministic, not probabilistic. The signature either validates or it does not. There is no confidence score, no threshold tuning, no model drift.

### The ICAO Public Key Directory (PKD)

CSCA certificates are exchanged between countries through the ICAO Public Key Directory (PKD) and bilateral diplomatic channels. The PKD is a globally shared certificate repository maintained by the International Civil Aviation Organization, currently containing over 800 CSCA certificates and 20,000 Document Signer certificates from participating countries.

This creates a global web of trust rooted in sovereign authority, precisely the foundation required for reliable verification of sovereign-issued identity claims. If a country has not submitted its certificates to the PKD, other countries cannot cryptographically verify passports issued by that country.

***

## The zkPassport Trust Model

zkPassport leverages the ePassport trust anchor while solving the privacy paradox through Zero Knowledge Proofs.

The conventional approach to using ePassport data would be to read the chip, verify the signatures, and transmit the verified data to a relying party. This is cryptographically sound but still requires full data disclosure. zkPassport introduces a different model: verification without disclosure.

### Dual-Layer Proof Architecture

zkPassport generates two distinct types of proof:

<table><thead><tr><th width="117.8232421875">Layer</th><th width="240.7568359375">Proof Type</th><th>What It Proves</th></tr></thead><tbody><tr><td><strong>Layer 1</strong></td><td>zkPassport ZKP (Authenticity Proof)</td><td>The user possesses a cryptographically valid ePassport issued by a specific country</td></tr><tr><td><strong>Layer 2</strong></td><td>zkKYC ZKP (Attribute Proof)</td><td>A specific attribute (nationality, age threshold) is true, based on the verified passport data</td></tr></tbody></table>

The first layer establishes that the passport is genuine. The second layer proves specific claims derived from that passport. Neither layer reveals the underlying data.

<figure><img src="/files/Xv7IsAQWTmo7Gohb1gsw" alt=""><figcaption></figcaption></figure>

### On-Device Processing

All sensitive operations occur on the user’s device:

<table><thead><tr><th width="232.515625">Operation</th><th>Location</th><th>Data Exposure</th></tr></thead><tbody><tr><td>NFC chip reading</td><td>User device</td><td>None</td></tr><tr><td>Signature verification</td><td>User device</td><td>None</td></tr><tr><td>ZKP generation</td><td>User device</td><td>None</td></tr><tr><td>Proof verification</td><td>Relying party</td><td>Proof only</td></tr></tbody></table>

Raw passport data never leaves the device. The relying party receives only the Zero Knowledge Proof, which cannot be reverse engineered into the original data. Privacy is guaranteed by cryptography, not by policy.

***

## Resulting Capabilities

zkPassport resolves the structural problems that make traditional eKYC unsuitable for Proof of Citizenship.

* **Cryptographic Proof of Sovereign Issuance:** Verification of sovereign-issued identity claims is no longer based on visual inspection of documents. It is based on cryptographic signatures issued by sovereign governments. When a zkPassport proof attests to a sovereign-issued identity claim, that attestation is mathematically bound to the issuing authority’s CSCA. The relying party trusts mathematics, not artifacts.
* **Privacy Preserving Compliance:** Users prove specific sovereign-issued identity attributes without disclosing name, passport number, date of birth, or any other personal data. Services can verify nationality for compliance purposes without accumulating sensitive data that creates liability and attracts attackers.
* **Immunity to Synthetic Identity Attacks:** The trust anchor is a cryptographic signature embedded in a physical chip. An attacker cannot generate a valid CSCA signature; only the issuing government possesses the private key. Deepfakes and synthetic documents are irrelevant to a verification model that does not rely on visual evidence.
* **Reusable and Revocable Credentials:** Proofs can be anchored to a user’s wallet as Soul Bound Tokens or Verifiable Credentials, enabling reuse across services. Because proofs are bound to specific certificates, they inherit the revocation properties of the underlying PKI.
* **Auditability Without Surveillance:** Relying parties can demonstrate that citizenship verification occurred without maintaining databases of passport data. Compliance is provable; surveillance is unnecessary.
* **Global Coverage:** zkPassport supports electronic passports from 126 countries and regions that have published their signing certificates to recognized registries. This represents the vast majority of ePassports in global circulation. For the complete list of supported countries, see [Supported Countries](/hub/how-built/id-infra/zkpassport/supported-countries).

***

## Trust Model and Security Assumptions

zkPassport’s security guarantees depend on a set of foundational assumptions about the underlying infrastructure.

### zkPassport Dependencies

| Assumption               | Description                                                                                                   |
| ------------------------ | ------------------------------------------------------------------------------------------------------------- |
| Government PKI Integrity | CSCA certificates published by governments are authentic and have not been compromised                        |
| ICAO Standard Compliance | The passport chip implements ICAO Doc 9303 standards correctly                                                |
| Physical Chip Security   | The passport chip has not been physically cloned or its private keys extracted                                |
| Device Security          | The user’s mobile device has not been compromised in a way that would allow interception of NFC communication |

### zkPassport Verification Scope

| Verification                 | Description                                                                                                |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Certificate Chain Validation | The Document Signer certificate is validated against the known CSCA certificate for the issuing country    |
| Data Integrity Check         | The hash of each Data Group is compared against the signed Security Object Document (SOD)                  |
| MRZ to NFC Consistency       | The data read from the NFC chip is compared against the MRZ data to ensure they refer to the same document |

Identity verification is not a data collection problem. It is a trust problem, and trust must be cryptographic.

Identity authenticity must be rooted in cryptographic trust, not visual evidence.

***

## **Standalone zkPassport SDK**

In addition to its native integration within the zkMe verification flow, a standalone zkPassport SDK is available for partners and developers who require direct, independent access to ePassport-based zero-knowledge identity verification. This provides a powerful toolkit for integrating cryptographic identity verification directly into custom applications and workflows.

### **Core Capabilities**

<table><thead><tr><th width="227.283203125">Capability</th><th>Description</th></tr></thead><tbody><tr><td><strong>NFC Chip Reading</strong></td><td>Scan and extract data from ICAO 9303-compliant electronic passports, national ID cards, and residence permits via a device’s native NFC interface.</td></tr><tr><td><strong>On-Device ZKP Generation</strong></td><td>Generate privacy-preserving proofs of identity attributes (age, nationality, document validity) directly on the user’s device. No raw personal data is transmitted.</td></tr><tr><td><strong>Granular Claim Verification</strong></td><td>Verify specific claims about a user’s identity, such as “over 18”, “citizen of Country X”, or “document not expired”, without accessing the full identity document.</td></tr><tr><td><strong>Multi-Platform Proof Verification</strong></td><td>Proofs can be verified both on-chain (via smart contracts) and off-chain (via server-side verification), providing maximum integration flexibility.</td></tr></tbody></table>

### **Get Access**

The zkPassport SDK is available as a standalone integration for qualified partners. To learn more about SDK access, supported document types, and integration requirements, please contact the team directly via [**contact@zk.me**](mailto:contact@zk.me)**.**


# Supported Countries

zkPassport supports electronic passports from **126 countries and regions** that have published their signing certificates to recognized registries. This represents the vast majority of ePassports in global circulation.

## Coverage by Region

{% tabs %}
{% tab title="Europe" %}
**42 Countries**

Albania, Andorra, Austria, Belarus, Belgium, Bosnia and Herzegovina, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Georgia, Germany, Greece, Hungary, Iceland, Ireland, Italy, Kosovo, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Moldova, Monaco, Montenegro, Netherlands, North Macedonia, Norway, Poland, Portugal, Romania, San Marino, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Ukraine, United Kingdom, Vatican City
{% endtab %}

{% tab title="Asia-Pacific" %}
**28 Countries**

Australia, Azerbaijan, Bangladesh, China, India, Indonesia, Japan, Kazakhstan, Kyrgyzstan, Malaysia, Mongolia, Nepal, New Zealand, North Korea, Pakistan, Philippines, Singapore, South Korea, Taiwan, Tajikistan, Thailand, Timor-Leste, Turkey, Turkmenistan, Uzbekistan, Vietnam
{% endtab %}

{% tab title="Americas" %}
**20 Countries**

Antigua and Barbuda, Argentina, Barbados, Belize, Bermuda, Brazil, Canada, Chile, Colombia, Costa Rica, Dominica, Ecuador, Jamaica, Mexico, Panama, Paraguay, Peru, Saint Kitts and Nevis, Saint Vincent and the Grenadines, The Bahamas, United States, Uruguay
{% endtab %}

{% tab title="Africa" %}
**18 Countries**

Algeria, Benin, Botswana, Cameroon, Ethiopia, Gambia, Ghana, Ivory Coast, Kenya, Morocco, Nigeria, Rwanda, Senegal, Seychelles, Sierra Leone, Tanzania, Uganda, Zimbabwe
{% endtab %}

{% tab title="Middle East" %}
**20 Countries**

Armenia, Bahrain, Iran, Iraq, Israel, Jordan, Kuwait, Lebanon, Oman, Palestine, Qatar, Saudi Arabia, Syria, United Arab Emirates, Yemen
{% endtab %}
{% endtabs %}

## Document Requirements

For zkPassport to function, the passport must meet the following requirements:

| Requirement            | Description                                              |
| ---------------------- | -------------------------------------------------------- |
| **NFC Chip**           | Indicated by the electronic passport symbol on the cover |
| **Supported Country**  | The issuing country’s certificates must be available     |
| **Physical Condition** | The chip must be readable (not physically damaged)       |


# zkMe zkTLS

## What is zkTLS?

zkTLS (Zero Knowledge Transport Layer Security) is a privacy preserving protocol that transforms a standard HTTPS session into a zero knowledge attestable interaction. It breaks the traditional Web2 data enclosure model by allowing users to locally decrypt TLS traffic, extract only the fields they need, and generate a verifiable proof without exposing the full plaintext session.

By combining the TLS protocol with zero knowledge proofs, zkTLS enables a user to prove that they accessed a specific HTTPS endpoint and obtained a particular piece of structured data while keeping all other page content and personal information completely hidden. The resulting proof can be verified on chain or off chain, ensuring both the authenticity of the data source and minimal disclosure.

***

## Why zkTLS Matters?

In today's digital world, much of our important information, such as financial status, citizenship, and academic credentials, exists on Web2 platforms. However, these platforms were not designed to interact with decentralized systems in a privacy preserving way, and users often lack real control over how their data is accessed or verified.

zkTLS bridges this gap by enabling trustless, verifiable, and privacy preserving extraction of Web2 data while maintaining full user autonomy. Users can locally decrypt their own TLS sessions, select only the fields they wish to disclose, and generate a proof that can be independently verified. This restores genuine ownership of both identity and data without requiring cooperation from the original platforms and without exposing unnecessary information.

zkTLS supports a wide range of use cases, including:

* University enrollment or graduation status
* Government issued residency or citizenship
* Regulatory eligibility for token sales such as accredited investor checks
* Credit score thresholds from financial platforms

In addition to identity and compliance scenarios, zkTLS can also function as a privacy preserving alternative to traditional financial data aggregators. It allows users to prove:

* Bank account ownership and balance
* Verified income streams and income level
* Transaction history summaries such as salary inflows or recurring expenses
* Identity and address confirmation from banking or utility portals

All of this is achieved without exposing raw data, without granting API keys, and without relying on centralized intermediaries. zkTLS empowers users with true control over their identity and personal data and aligns verification with the principles of data autonomy and user sovereignty.

***

## Value Proposition of zkTLS

zkTLS delivers several core properties that define its privacy, performance, and integration advantages.

<table><thead><tr><th width="199.53643798828125">Property</th><th>Description</th></tr></thead><tbody><tr><td><strong>Confidentiality</strong></td><td>Users prove sensitive facts without revealing actual data</td></tr><tr><td><strong>Compatibility</strong></td><td>Built on top of standard TLS (v1.2/v1.3), no backend modifications needed</td></tr><tr><td><strong>Scalability</strong></td><td>zk-SNARKs enable fast verification (~200ms typical)</td></tr><tr><td><strong>Compliance</strong></td><td>Enables privacy-preserving onboarding aligned with GDPR, HIPAA, etc.</td></tr><tr><td><strong>Cross-Chain Ready</strong></td><td>Proofs can be consumed across different chains.</td></tr></tbody></table>

***

## How zkTLS Works

<figure><img src="/files/Ra4nJfsduWzX6VzJHfxl" alt="" width="563"><figcaption></figcaption></figure>

zkTLS relies on a combination of client side TLS session capture, structured data extraction, and zero knowledge proof generation. The process consists of the following steps.

{% stepper %}
{% step %}

### Establishing a Secure Session via the Local zkTLS Module

The user connects to a target HTTPS website (e.g. `creditkarma.com`) through the Local zkTLS Module, which:

* Records the TLS handshake, including the server’s certificate and session metadata
* Captures encrypted segments of the server response without decrypting or modifying any content

> The module operates entirely on the user’s device and does not transmit or store any raw data.
> {% endstep %}

{% step %}

### Defining the Target Value

The user specifies the exact value they want to prove exists in the response using a `Provider Schema`. This schema defines the target URL, method, and rules for matching and redacting data using selectors like `JSONPath`, `XPath`, or `regex`.
{% endstep %}

{% step %}

### Zero-Knowledge Proof Generation

The zkTLS engine constructs a ZK-SNARK proof that attests:

* The TLS session was established with a valid certificate, bound to the correct domain
* The specified value exists within the server's response payload
* No other content from the session was revealed
  {% endstep %}

{% step %}

### Proof Submission & Verification

The resulting proof is a short cryptographic object designed to support multiple verification flows:

* Submitted on-chain, to trigger smart contract logic (e.g., issue a credential)
* Verified off-chain, by a service provider or application

At no point does the verifier see the user’s browsing session or original data, only a valid cryptographic proof.
{% endstep %}
{% endstepper %}

***

## Technical Foundations of zkTLS

The diagram below outlines the core components of the zkTLS architecture and how data flows across layers.

<figure><img src="/files/PrVYZl9L3kMVqLNT0RCs" alt=""><figcaption></figcaption></figure>

zkTLS is built on a tightly integrated set of components that work together to guarantee privacy, integrity, authenticity, and verifiability.

These foundations include structured data extraction, TLS-layer cryptographic isolation, lightweight zero-knowledge proof circuits, and a decentralized attestor network.

The sections below break down each layer of the architecture in detail.

### **Provider Schema: Structured, Verifiable Data Extraction**

To precisely define what users are proving, zkTLS uses a schema-based extraction system similar to JSON Schema, combined with modern selectors such as XPath, JSONPath, and regex.

A Provider Schema specifies:

* the target HTTPS endpoint
* how the response should be matched
* what part of the response may be selectively disclosed
* optional hashing (OPRF) for sensitive fields

Selectors follow a priority order (`XPath` → `JSONPath` → `Regex`), ensuring reliable extraction even in complex Web2 pages. This guarantees that **only the intended data is disclosed**, and no additional context can be injected by adversaries.

#### **Provider Schema Structure**

<table><thead><tr><th width="178.26953125">Field</th><th width="100">Type</th><th>Description</th></tr></thead><tbody><tr><td><code>url</code></td><td>string</td><td>The target URL (must be HTTPS).</td></tr><tr><td><code>method</code></td><td>string</td><td>HTTP method (GET, POST, etc.).</td></tr><tr><td><code>responseMatches</code></td><td>object</td><td>Rules for matching the response, using <code>regex</code> or <code>contains</code>.</td></tr><tr><td><code>responseRedactions</code></td><td>object</td><td>(Optional) Selectors for redacting content, using <code>XPath</code>, <code>jsonPath</code>, or <code>regex</code>. </td></tr></tbody></table>

### **TLS-Level Security & Selective Disclosure**

zkTLS leverages native properties of the TLS protocol to isolate and protect sensitive data regions.

#### TLS 1.3 KeyUpdate Mode

TLS 1.3 supports dynamic key rotation. zkTLS uses this mechanism to bracket the part of the response containing the target data: a new session key is created before the sensitive region, and another key update follows immediately afterward. Only the ciphertext under that specific key version is eligible for disclosure. This enables selective disclosure without exposing the rest of the session.

#### TLS 1.2 Compatibility Mode

Because TLS 1.2 does not support KeyUpdate, zkTLS instead uses a full zero-knowledge redaction proof verifying that the disclosed plaintext is a valid decryption of the redacted ciphertext and that no additional content is leaked. Supported cipher suites include AES-GCM and ChaCha20-Poly1305.

### **Zero-Knowledge Circuit Design**

zkTLS adopts a minimalistic ZK circuit that focuses exclusively on verifying the correctness of selective decryption.

Rather than re-implementing TLS internally, the circuit works with two classes of information:

* **Public information** that the verifier sees (redacted ciphertext fragment + TLS metadata)
* **Private information** held only by the user (TLS session key material)

The circuit proves a single essential statement:

> **The disclosed plaintext is the only valid decryption of the corresponding ciphertext segment using the private session key.**

This design keeps proving lightweight, auditable, and compatible with both browser-friendly and high-performance backends.

#### **Circuit Overview Diagram**

<figure><img src="/files/nufZ4fCrKMLW9Q7VFxkC" alt="" width="375"><figcaption></figcaption></figure>

### **Attestor Network: Verification & Economic Security**

Attestors act as independent verifiers, ensuring that claims originate from authentic TLS sessions.

Each attestor:

* relays encrypted TLS traffic without accessing plaintext
* validates ZK proofs and schema rules
* signs claims once validation succeeds

The network is governed by on-chain staking and slashing:

* nodes must stake to participate
* malicious behavior results in penalties
* all events are auditable
* a threshold of signatures is required for final validity

This design prevents single-point compromise and mitigates user–attestor collusion.

### **Security & Threat Mitigation**

zkTLS is designed to operate securely in adversarial environments. Protections include MITM resistance via TLS authentication, strict domain binding, replay resistance, schema-based extraction preventing data injection, multi-attestor consensus, and ephemeral session keys.

#### **Security Matrix**

<table><thead><tr><th width="167.314453125">Threat</th><th>Mitigation</th></tr></thead><tbody><tr><td><strong>MITM Attack</strong></td><td>TLS is used to encrypt communication between the proxy and the Attestor, combined with certificate pinning.</td></tr><tr><td><strong>Phishing Attack</strong></td><td>The Attestor verifies the target host, preventing spoofing.</td></tr><tr><td><strong>Replay Attack</strong></td><td>A timestamp and unique ID are bound to the session to prevent reuse.</td></tr><tr><td><strong>Collusion Attack</strong></td><td>Multiple Attestor nodes and a slashing mechanism disincentivize collusion.</td></tr><tr><td><strong>Injection Attack</strong></td><td>The Provider Schema validates the location of the disclosed data.</td></tr><tr><td><strong>DoS Attack</strong></td><td>Rate limiting and service fees are implemented to deter denial-of-service attacks.</td></tr></tbody></table>

***

## zkTLS by zkMe

### Live, Private, Powerful

* **Proven in Production**\
  zkTLS is already live in real-world applications, powering regulatory compliance, token sales, and identity verification for education and finance.
* **No Data Provider Required**\
  Users extract proofs directly from any HTTPS site, no need for API keys, platform integrations, or third-party approvals.
* **Native to zkMe Identity Stack**\
  zkTLS is fully integrated into zkMe’s  [Self-Sovereign Identity](/hub/how-built/id-infra/ssi) system, enabling seamless, automated issuance of verifiable credentials from Web2 sources.
* **End-to-End User Privacy**\
  The entire flow, from data access to ZK proof generation, runs locally on the user’s device. No data is stored, shared, or exposed at any point.


# zkMe Smart Contracts

> Overview of the Smart Contracts (SC) developed by zkMe for the processing of the zkMe Network.

## Smart Contracts Overview

To facilitate decentralized verification, zkMe developed a suite of smart contracts, enabling the protocol and Verifiers to process verifications autonomously. zkMe Mint and Delegate smart contracts mint the original and delegate copies of the DID onto the Holder's wallets. zkMe Verify and Certify smart contracts allow Verifiers to interact with the zkMe network and request minting of a special SBT copy for legal data access requirements if necessary. All functionalities available through the zkMe SCs are also available on zkMe APIs for non-web3 native Verifiers.

### zkMe Mint

The objective for the zkMe Mint smart contract is to anchor the verified credentials (and their anonymized presentations) on-chain.

The following sequence diagram shows the process of registering an SSI wallet, completing KYC verification, and minting an SBT token. The three participants involved are Holder, zkMe App (SSI Wallet), and Polygon (MATIC). This SC for minting SBT is deployed on Polygon. The process starts with the Holder requesting to register an SSI wallet through the zkMe App. Once the wallet is created, the Holder presents their credentials to the zkMe App. The zkMe App generates the relevant ZKP and triggers the minting request to the zkMe Mint Polygon smart contract. The zkMe Mint SC receives the location pointers for the ZKP and mints an SBT asset directly to the Holder's SSI wallet. The zkMe SBT contains the Holder's DIDs, a key shard, and, most importantly, the pointer to the verified ZKP. This process ensures that the Holder is able to securely own their Identity on-chain.

<figure><img src="/files/l3HT8hHv2FIzRhs4Y03M" alt=""><figcaption></figcaption></figure>

zkMe Mint address (Polygon Mainnet): **0x5c2bfcf9c17CD53d55033769727196736CD188b3**

Please check:

{% embed url="<https://polygonscan.com/token/0x5c2bfcf9c17CD53d55033769727196736CD188b3>" %}

### zkMe Delegate

The goal of the zkMe Delegate Smart Contract is to make copies of the user’s on-chain identities available on the blockchain ecosystems in which the user is active.

The zkMe Delegate SC comes into play when a Holder wishes to perform verifications for dApps across chain ecosystems. Holders need to first connect their asset wallet to the zkMe App and sign a transaction requesting a delegate copy of SBT. The zkMe infrastructure and zkMe Delegate SC complete the cross-chain data transfer to the Holder's connected asset wallet and issue a delegate copy of SBT. Currently, zkMe Delegate supports the Chain Ecosystems listed below, support for additional EVM, SVM, MoveVM, Cosmos-compatible chains is achievable with minimal efforts.

<figure><img src="/files/XoRz14AlPO3124mCCoy6" alt=""><figcaption></figcaption></figure>

{% hint style="success" %}
If your required chain is "coming soon" or not yet supported, feel free to reach out to us at <mark style="color:blue;">**<contact@zk.me>**</mark> to submit your request.
{% endhint %}

| zkMe Delegate              | Mainnet Address                                                        | Testnet Address                                                        |
| -------------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| **Aptos**                  | **0xc1e0d1fb6178f444f763bc55bda9df32b4354859925191d634a74a97924397d9** | **0xaed725b099b49a53a56fccd9e0316052416ec78798491de2d7e651dfc57ce411** |
| **Arbitrum**               | **0x1E3D352CA8E843AC59FdE9AD605Ba1C57813Fa0b**                         | **0x270A49849E1400867a1343b4621c458d1F81190a**                         |
| **Avalanche**              | *<mark style="color:purple;">coming soon</mark>*                       | **0x270A49849E1400867a1343b4621c458d1F81190a**                         |
| **Base**                   | **0x5c2bfcf9c17CD53d55033769727196736CD188b3**                         | **0x270A49849E1400867a1343b4621c458d1F81190a**                         |
| **Berachain**              | *<mark style="color:purple;">coming soon</mark>*                       | **0x270A49849E1400867a1343b4621c458d1F81190a**                         |
| **BNB Chain**              | **0x5c2bfcf9c17CD53d55033769727196736CD188b3**                         | **0x270A49849E1400867a1343b4621c458d1F81190a**                         |
| **BounceBit**              | **0x5c2bfcf9c17CD53d55033769727196736CD188b3**                         | *<mark style="color:purple;">coming soon</mark>*                       |
| **Ethereum**               | **0x5c2bfcf9c17CD53d55033769727196736CD188b3**                         | **0xD923a27A8b7cf8C9f3dFA022851B503a55b095a9**                         |
| **Fantom**                 | *<mark style="color:purple;">coming soon</mark>*                       | **0x270A49849E1400867a1343b4621c458d1F81190a**                         |
| **Kaia**                   | **0x5c2bfcf9c17CD53d55033769727196736CD188b3**                         | *<mark style="color:purple;">coming soon</mark>*                       |
| **Linea**                  | *<mark style="color:purple;">coming soon</mark>*                       | **0xD923a27A8b7cf8C9f3dFA022851B503a55b095a9**                         |
| **Manta**                  | **0x5c2bfcf9c17CD53d55033769727196736CD188b3**                         | **0x270A49849E1400867a1343b4621c458d1F81190a**                         |
| **Mantle**                 | *<mark style="color:purple;">coming soon</mark>*                       | **0x270A49849E1400867a1343b4621c458d1F81190a**                         |
| **Midnight**               | *<mark style="color:purple;">coming soon</mark>*                       | **81ab4899c99c4f3667dff54e1de39c677a0369227e15837b9082c73f2399c9c6**   |
| **Neutron**                | **neutron19t7s6aa9289e563mu9qrx5nh80xtn4vr5afdu8yctej6f7w6k9usv87acp** | **neutron1g374hrmmn92vpurtppdwsnrrhrftz7ky2g55n5c4f22gfaeyrwpqq06cef** |
| **Lumoz**                  | *<mark style="color:purple;">coming soon</mark>*                       | *<mark style="color:purple;">coming soon</mark>*                       |
| **Optimism**               | *<mark style="color:purple;">coming soon</mark>*                       | **0x270A49849E1400867a1343b4621c458d1F81190a**                         |
| **Plume**                  | *<mark style="color:purple;">coming soon</mark>*                       | **0xD923a27A8b7cf8C9f3dFA022851B503a55b095a9**                         |
| **Polygon**                | **0x3b3364656BbB7A23133e3f26D7F6850acfaAc394**                         | *<mark style="color:purple;">coming soon</mark>*                       |
| **Ronin**                  | **0x5c2bfcf9c17CD53d55033769727196736CD188b3**                         | *<mark style="color:purple;">coming soon</mark>*                       |
| **Scroll**                 | *<mark style="color:purple;">coming soon</mark>*                       | **0x270A49849E1400867a1343b4621c458d1F81190a**                         |
| **Sei**                    | *<mark style="color:purple;">coming soon</mark>*                       | **sei1dmwr4e6k4n0dlwtkh598sxp2al3wvkvwew658r3cqx98648uqhcs7sd38d**     |
| **Solana**                 | **6tVnLV3qrA7HddTzRGmeZs1cy5rAcTFs9sQiaoLbENAM**                       | **6tVnLV3qrA7HddTzRGmeZs1cy5rAcTFs9sQiaoLbENAM**                       |
| **Sui**                    | *<mark style="color:purple;">coming soon</mark>*                       | *<mark style="color:purple;">coming soon</mark>*                       |
| **The Open Network (TON)** | **EQBLZJv\_DGlRJ-HqSY2yjmmGiRspStQ2G-akZVQWAcr7pUFt**                  | *<mark style="color:purple;">coming soon</mark>*                       |
| **X Layer**                | **0x1E3D352CA8E843AC59FdE9AD605Ba1C57813Fa0b**                         | *<mark style="color:purple;">coming soon</mark>*                       |
| **ZetaChain**              | **0x5c2bfcf9c17CD53d55033769727196736CD188b3**                         | **0xf8E1973814E66BF03002862C325305A5EeF98cc1**                         |
| **zkSync**                 | *<mark style="color:purple;">coming soon</mark>*                       | **0x4630e45Edb00298Eb7872FC5e237f6f0CE4995dF**                         |

### zkMe Verify & Certify

The zkMe Verify & Certify Smart Contract (***ZKMEVerifyUpgradeable***) is multi-functional, capable of verifying users' eligibility for services and fulfilling data recovery requirements for compliance with regulators' rules. The SC is triggered once a dApp recognizes an SBT asset within a Holder's wallet.

The SC's Verify function is used for eligibility checks. It provides yes/no answers to a list of predetermined eligibility questions for each credential verified. These questions are outlined in zkMe documentation on the zkMe website.

<figure><img src="/files/RcRdxvGl9xxc9z5Ta2cW" alt=""><figcaption></figcaption></figure>

Following the verification, the SC's Certify function can be optionally triggered. It requires the explicit approval of the Holder (through transaction signature) and creates a verifier-specific copy of the Holder's SBT in a designated asset wallet. This copy includes the Holder's private key shard, enabling the Verifier to identify the Holder when a regulator initiates bad-actor proceedings, even without the Holder's approval.

<figure><img src="/files/fM78nSci9aZkBzU2kqyh" alt=""><figcaption></figcaption></figure>

Currently, zkMe SC is compatible with the following chain ecosystems:

{% hint style="success" %}
If your required chain is "coming soon" or not yet supported, feel free to reach out to us at <mark style="color:blue;">**<contact@zk.me>**</mark> to submit your request.
{% endhint %}

| zkMe Verify                | Mainnet Address                                                        | Testnet Address                                                        |
| -------------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| **Aptos**                  | **0xc1e0d1fb6178f444f763bc55bda9df32b4354859925191d634a74a97924397d9** | **0x3e642b9d2845aa4efa3cdeb18acf6c7cd93112e4836a53e78f4b541e42a244b8** |
| **Arbitrum**               | **0x399488687fc3618FFaf1f5d0f61397c8E0360c02**                         | **0xF58De9599C57bBAD68Fea0F39b73913daFcf0976**                         |
| **Avalanche**              | *<mark style="color:purple;">coming soon</mark>*                       | **0xf8E1973814E66BF03002862C325305A5EeF98cc1**                         |
| **Base**                   | **0x8c81bbc5cC9B6cdbb5c0e5DD8b9D5bfaF3575710**                         | **0xF58De9599C57bBAD68Fea0F39b73913daFcf0976**                         |
| **Berachain**              | *<mark style="color:purple;">coming soon</mark>*                       | **0xF58De9599C57bBAD68Fea0F39b73913daFcf0976**                         |
| **BNB Chain**              | **0x3919BdCe285E82CDC6585979cfd71636b33A5582**                         | **0xf8E1973814E66BF03002862C325305A5EeF98cc1**                         |
| **BounceBit**              | **0x399488687fc3618FFaf1f5d0f61397c8E0360c02**                         | *<mark style="color:purple;">coming soon</mark>*                       |
| **Ethereum**               | **0x399488687fc3618FFaf1f5d0f61397c8E0360c02**                         | **0xF58De9599C57bBAD68Fea0F39b73913daFcf0976**                         |
| **Fantom**                 | *<mark style="color:purple;">coming soon</mark>*                       | **0xf8E1973814E66BF03002862C325305A5EeF98cc1**                         |
| **Linea**                  | *<mark style="color:purple;">coming soon</mark>*                       | **0xA018F0593C1C3F62A68c3fc3B9D593961B207d96**                         |
| **Manta**                  | **0x3919BdCe285E82CDC6585979cfd71636b33A5582**                         | **0xf8E1973814E66BF03002862C325305A5EeF98cc1**                         |
| **Mantle**                 | *<mark style="color:purple;">coming soon</mark>*                       | **0xF58De9599C57bBAD68Fea0F39b73913daFcf0976**                         |
| **Midnight**               | *<mark style="color:purple;">coming soon</mark>*                       | **39a45a695034a8b108c3315997882d40931a158ddaebb99f6711d10c68b8891c**   |
| **Neutron**                | **neutron19t7s6aa9289e563mu9qrx5nh80xtn4vr5afdu8yctej6f7w6k9usv87acp** | **neutron1g374hrmmn92vpurtppdwsnrrhrftz7ky2g55n5c4f22gfaeyrwpqq06cef** |
| **Kaia**                   | **0x3919BdCe285E82CDC6585979cfd71636b33A5582**                         | *<mark style="color:purple;">coming soon</mark>*                       |
| **Lumoz**                  | *<mark style="color:purple;">coming soon</mark>*                       | **0xf8E1973814E66BF03002862C325305A5EeF98cc1**                         |
| **Optimism**               | *<mark style="color:purple;">coming soon</mark>*                       | **0xF58De9599C57bBAD68Fea0F39b73913daFcf0976**                         |
| **Plume**                  | *<mark style="color:purple;">coming soon</mark>*                       | **0xA018F0593C1C3F62A68c3fc3B9D593961B207d96**                         |
| **Polygon**                | **0x78D247ff4543Ef08488A1127034c2cE54B12A926**                         | *<mark style="color:purple;">coming soon</mark>*                       |
| **Ronin**                  | **0x3919BdCe285E82CDC6585979cfd71636b33A5582**                         | *<mark style="color:purple;">coming soon</mark>*                       |
| **Scroll**                 | *<mark style="color:purple;">coming soon</mark>*                       | **0xf8E1973814E66BF03002862C325305A5EeF98cc1**                         |
| **Sei**                    | *<mark style="color:purple;">coming soon</mark>*                       | **sei1dmwr4e6k4n0dlwtkh598sxp2al3wvkvwew658r3cqx98648uqhcs7sd38d**     |
| **Solana**                 | **6tVnLV3qrA7HddTzRGmeZs1cy5rAcTFs9sQiaoLbENAM**                       | **6tVnLV3qrA7HddTzRGmeZs1cy5rAcTFs9sQiaoLbENAM**                       |
| **Sui**                    | *<mark style="color:purple;">coming soon</mark>*                       | *<mark style="color:purple;">coming soon</mark>*                       |
| **The Open Network (TON)** | **EQBLZJv\_DGlRJ-HqSY2yjmmGiRspStQ2G-akZVQWAcr7pUFt**                  | *<mark style="color:purple;">coming soon</mark>*                       |
| **X Layer**                | **0x399488687fc3618FFaf1f5d0f61397c8E0360c02**                         | *<mark style="color:purple;">coming soon</mark>*                       |
| **ZetaChain**              | **0x3919BdCe285E82CDC6585979cfd71636b33A5582**                         | **0xA018F0593C1C3F62A68c3fc3B9D593961B207d96**                         |
| **zkSync**                 | *<mark style="color:purple;">coming soon</mark>*                       | **0xdbd9E736562584DB3fA1C5F39A47C2071DE0D5cb**                         |

## zkMe Credential Schema

The credential schema on zkMe network is designed to be flexible and extensible, allowing issuers to customize the schema to meet their specific needs while maintaining compatibility with the W3C VC and VP data models; enabling Issuers to issue a wide range of credentials, from educational degrees to professional certifications, while ensuring that these credentials are interoperable and ease to use across different networks and applications.

zkMe specifies the following set of properties that its ZKPs (as VPs) must include as:

* **Issuer**: The entity that issued the credential.
* **Subject:** The DID to whom the credential pertains.
* **Type:** The type of credential being issued (e.g. Proof-of-Citizenship, Proof-of-Residence).
* **Issuance Date:** The date on which the credential was issued.
* **Expiration Date:** The date on which the credential expires.
* **Claims:** The specific eligibility the VP is attesting to (e.g. Adulthood - Is the holder over 18 years old?).
* **Proof:** A cryptographic proof that the credential was issued by the specified issuer and has not been tampered with since issuance.

In addition to these standard properties, VCs and VPs on zkMe may also include other properties or custom extensions, depending on the needs of the Issuer or the network's requirements as a whole. It's important to note that the content of VCs and VPs issued on zkMe is determined by the Issuer, and may vary depending on the type of credential being verified and the specific claims being attested.

In the zkMe zkKYC solution, the following information elements and descriptions are included:

**Issuer DIDs:** The public decentralized identifiers (DIDs) of the issuer are published in the Verifiable Data Registry. This information enables the holder to verify the authenticity and trustworthiness of the issuer.

**Holder DIDs:** The private DIDs of the Holder towards a particular Issuer are known only to the Holder and the Issuer. These DIDs enable the Holder to authenticate themselves to the Issuer and provide proof of their Identity.


# Credential System Stack

The Credential System is the core issuance, verification, and lifecycle management infrastructure for all zkMe credentials. It sits at the center of the **Underwrite** pillar, transforming raw identity data into trustless, privacy-preserving, and reusable verifiable credentials that can be consumed by both human users and autonomous AI agents.

Every credential in the zkMe ecosystem, whether it represents a KYC verification, a credit score attestation, a passport check, or an agent authorization, is built on the same underlying Credential System. This ensures consistency, interoperability, and composability across all zkMe products.

## What the Credential System Does

The Credential System solves three fundamental problems:

1. **How to represent identity data in a standardized, tamper-evident format.** \
   The system uses the W3C Verifiable Credentials data model, extended with zkMe-specific claim schemas and cryptographic commitments anchored on-chain via Merkle Trees.
2. **How to verify identity claims without exposing the underlying data.** \
   Through Zero-Knowledge Proofs generated on the Holder’s device, the system enables Verifiers to confirm eligibility (e.g., “user is over 18”, “user is not sanctioned”) without ever seeing the actual credential values.
3. **How to manage the full credential lifecycle.** \
   From issuance through verification, reuse, revocation, and expiration, the system provides a complete set of on-chain and off-chain mechanisms to ensure credentials remain valid, current, and trustworthy.

***

## Sub-Modules

The Credential System is organized into four sub-modules, each addressing a distinct aspect of the credential infrastructure:

### Core Concepts

The foundational reference for the entire Credential System. This page covers the system architecture (4-layer model), the credential data model (W3C VC format, JSON-LD schemas), the Claim Tree and Merkle commitment model, the complete credential lifecycle (issuance, verification, revocation, expiration), the Issuer-Holder-Verifier trust triangle, and the cryptographic assumptions underpinning the system.

**Read** [Core Concepts](/hub/how-built/credential-sys/core-concepts) **first** if you are new to the zkMe Credential System.

### Selective Disclosure

Fine-grained privacy control allowing Holders to reveal only specific credential fields during verification. This page covers the Selective Disclosure operator (SD, operator=16), the full set of 14 Enhanced Query Operators for range matching, set membership, and field extraction, and gas-optimized on-chain verification via circuitQueryHash compression.

**Read** [Selective Disclosure](/hub/how-built/credential-sys/selective-disclosure) if you need to understand how zkMe achieves privacy beyond simple boolean proofs.

### **Multi-Credential Proofs & Delegation**

Batch verification and cross-chain identity portability. This page covers Multi-Credential Proofs via the LinkedMultiQuery10 circuit (aggregating up to 10 queries in a single proof), the complementary security design between batch query and core verification circuits, and Delegated Proofs that bind a verified identity to secondary addresses or AI agent DIDs without re-verification.

**Read** [Multi-Credential Proofs & Delegation](/hub/how-built/credential-sys/multi-proofs) if you need to verify complex user profiles spanning multiple credentials, or enable cross-chain identity portability.

### **Anti-Sybil Mechanisms**

Uniqueness enforcement and unified authentication. This page covers nullifier-based "one person, one action" guarantees, unified authentication supporting both BabyJubJub keys and standard Ethereum wallet signatures, and the unified SIG/MTP circuit that simplifies developer integration.

**Read** [Anti-Sybil Mechanisms](/hub/how-built/credential-sys/anti-sybil-mech) if you need to prevent duplicate claims, enforce voting uniqueness, or understand the authentication options available to your users.

### Reusable Credentials

The “Verify Once, Prove Anywhere” paradigm. This page explains how a credential issued for one service can be reused across the entire Web3 ecosystem without re-verification, how cross-chain portability works via the Delegate smart contracts, and how credential lifecycle management (expiration, revocation) ensures that reusability does not compromise security.

**Read** [Reusable Credentials](/hub/how-built/credential-sys/reusable-credentials) if you are a Verifier looking to reduce onboarding friction by accepting existing zkMe credentials.

### Agent-Ready Credentials

Credentials optimized for consumption by autonomous AI agents. This page covers the cryptographic delegation protocol (how a Holder authorizes an agent without sharing raw credentials), machine-readable schemas designed for LLM parsing, and automated proof generation via the Agent Trust Gateway.

**Read** [Agent-Ready Credentials](/hub/how-built/credential-sys/agent-ready-credentials) if you are building AI agents that need to prove user eligibility or perform authorized actions on behalf of human users.

***

## How the Credential System Relates to Other Modules

The Credential System consumes the guarantees provided by the [Identity Infrastructure](/hub/how-built/id-infra) layer and feeds into the [Agent Trust Gateway](/hub/how-built/agent-trust-gateway):

* **Identity Infrastructure → Credential System:** The SSI model defines the trust roles. The DID Method provides identifiers. The zkVault stores encrypted credentials. FHE and zkPassport provide privacy-preserving data acquisition. Smart Contracts anchor credential state on-chain.
* **Credential System → Agent Trust Gateway:** Agent-Ready Credentials are the input to the Gateway’s policy evaluation engine. The Gateway verifies these credentials, evaluates user-defined policies, and issues scoped authorization tokens for agent execution.
* **Credential System → Product Catalog:** The specific credential types offered by zkMe (zkKYC, zkOBS, zkKYB, zkKYA, KYT) are all built on the Credential System’s infrastructure. See the [Credential Catalog](/hub/what/catalog) for the full list.

***

***

## Available as Independent Services

The Credential System technology stack is available for licensing and deployment by external organizations. Customers can acquire any capability independently or license the full stack to build and operate their own credential issuance and verification infrastructure using zkMe's ZKP circuits, Merkle commitment model, and on-chain verification contracts.

<table><thead><tr><th width="279.37890625">Capability</th><th>Acquisition Model</th></tr></thead><tbody><tr><td>Custom Credential Issuance</td><td>License the issuance pipeline (JSON-LD schema engine, BabyJubJub signing, Sparse Merkle Tree commitment)</td></tr><tr><td>Selective Disclosure</td><td>License the SD verification engine (14 query operators, circuitQueryHash compression, on-chain verifier contracts)</td></tr><tr><td>Multi-Credential Proofs</td><td>License the LinkedMultiQuery10 circuit and batch verification infrastructure</td></tr><tr><td>Cross-Chain Portability</td><td>License the Delegate contract suite for multi-chain credential relay</td></tr><tr><td>Anti-Sybil Enforcement</td><td>License the nullifier generation and verification system</td></tr><tr><td>Agent-Ready Credential Issuance</td><td>License the agent delegation protocol, machine-readable schema toolkit, and automated proof generation pipeline</td></tr></tbody></table>

{% hint style="success" %}
All modules support flexible engagement models including technology licensing for self-hosted deployment, managed service with pay-as-you-go or committed-use pricing, and full white-label solutions. Contact the zkMe team at <contact@zk.me>.
{% endhint %}


# Core Concepts

## System Overview

The Credential System is a decentralized, privacy-preserving credential issuance and verification infrastructure built on zero-knowledge proof (ZKP) technology. It is designed to address the challenges of identity verification and data protection, while providing a high degree of auditability, accountability, and operational clarity, making it suitable for enterprises and institutions with stringent compliance and security requirements.

The system enables trusted entities (Issuers) to issue standardized digital credentials to individuals or organizations (Holders). Holders can then present cryptographic proofs of these credentials to third parties (Verifiers) without revealing the underlying sensitive data. This is achieved through zero-knowledge proofs, which allow specific claims to be verified in a secure and privacy-preserving manner.

By combining standardized credential formats, well-defined issuance and verification workflows, and decentralized storage, the Credential System provides a secure, efficient, and scalable identity management solution that preserves user privacy while remaining compatible with regulatory and audit requirements.

### Problem & Solution

In traditional digital ecosystems, identity and credential verification are centralized, leading to data silos, privacy risks, and high operational overhead for compliance. Users are forced to over-share personal data, and institutions bear the full burden of securing that data.

The Credential System solves this by creating a trust triangle between Issuers, Holders, and Verifiers, anchored by a blockchain. It replaces the need for direct data sharing with cryptographic proof, enabling use cases that were previously impractical due to privacy and security concerns.

### Use Cases

The system is designed for a variety of use cases where verifiable, privacy-preserving claims are critical:

<table><thead><tr><th width="211.859375">Use Case</th><th>Example</th></tr></thead><tbody><tr><td><strong>Compliance &#x26; KYC</strong></td><td>zkMe issues a zkKYC credential. The user can prove their KYC status to a new service without re-submitting documents, and the service can audit the verification without seeing the user’s PII.</td></tr><tr><td><strong>Finance &#x26; Credit</strong></td><td>zkMe issues a Credit credential containing credit-related attributes. The user can prove that they meet a required credit condition during a loan application, without revealing their exact credit score or full financial history.</td></tr></tbody></table>

***

## Design Goals & Principles

The architecture is guided by principles designed to meet the needs:

* **Privacy-by-Design & Data Minimization**: The system is architected so that the Holder never reveals raw data to the Verifier. Only the proof of a specific claim is shared.
* **Auditability without Exposure**: All significant state changes are recorded on-chain, providing an immutable audit trail. Auditors can verify the integrity of the system without accessing sensitive user data.
* **User Sovereignty**: Holders have exclusive control over their credentials and private keys. Data is stored in an encrypted, user-controlled environment.
* **Interoperability & Standards Alignment**: The system utilizes the W3C Verifiable Credentials (VC) Data Model, ensuring compatibility with emerging digital identity standards.
* **Operational Clarity & Liability Containment**: By establishing clear, cryptographically enforced boundaries, the system contains liability. Each party is only responsible for its defined role, reducing systemic risk.

***

## Core Roles & Responsibility Boundaries

The system defines three primary roles and their explicit responsibilities, creating clear accountability boundaries.

<figure><img src="/files/egrnNxd47z3Tb0sqozOF" alt="" width="563"><figcaption><p><em>Figure 1: Trust and Responsibility Boundaries</em></p></figcaption></figure>

<table><thead><tr><th width="118.2578125">Role</th><th width="374.140625">Responsibilities &#x26; Boundaries</th><th>What is Auditable?</th></tr></thead><tbody><tr><td><strong>Issuer</strong><br></td><td><ul><li>Can: Issue and revoke credentials. Define credential schemas.</li><li>Cannot: By design, zkMe has no access to a Holder’s other credentials or proofs.</li><li>Accountable for: The authenticity and accuracy of the claims it attests to.</li></ul></td><td><ul><li>All issued credential schemas (on-chain).</li><li>All credential revocations (on-chain).</li><li>The Issuer’s public key and identity.</li></ul></td></tr><tr><td><strong>Holder</strong></td><td><ul><li>Can: Own, use, and manage credentials; present proofs derived from them.</li><li>Cannot: Create or modify credentials. Forge proofs for claims they don’t possess.</li><li>Accountable for: Securely owning and managing their credentials via their account or address, and exercising control over the use and presentation of proofs.</li></ul></td><td><ul><li>The history of their on-chain Merkle Root updates.</li><li>The integrity of their Claim Tree (provable via ZKP).</li></ul></td></tr><tr><td><strong>Verifier</strong></td><td><ul><li>Can: Define verification policies (queries), request proofs, and verify them.</li><li>Cannot: See any data beyond the proof result (true/false). Access the Holder’s credentials.</li><li>Accountable for: The business logic executed after a successful verification.</li></ul></td><td><ul><li>The Challenge used for a verification session.</li><li>The verification result (if logged by the Verifier).</li><li>On-chain verification transactions.</li></ul></td></tr></tbody></table>

***

## System Architecture

<figure><img src="/files/XF8un3woFHoHYmuISnvR" alt="" width="563"><figcaption><p><em>Figure 2: High-Level Architectural Layers</em></p></figcaption></figure>

* **Layer 1: Presentation Layer**\
  Provides user-facing interfaces for credential management and interaction.
  * **User Account (SSI Wallet)**: The Holder's primary interface for managing credentials, keys, and generating proofs. This is an external third-party component (Self-Sovereign Identity Wallet) integrated through standard interfaces. The wallet manages:
    * Private key storage and management
    * Local encrypted credential storage
    * Proof generation and submission
  * **UI Components**: Dashboards and SDKs for Issuers and Verifiers:
    * Issuer Widget SDK: Embedded SDK for integrating credential issuance into Issuer applications
    * Issuer Dashboard: Management interface for Issuers to monitor and manage issued credentials
    * Verifier Widget SDK: Embedded SDK for integrating credential verification into Verifier applications
    * Verifier Dashboard: Management interface for Verifiers to configure verification policies and review results
* **Layer 2: Application Layer**\
  Contains business logic for credential operations and user interactions.
  * Holder Credential Management: Manages user credentials, including credential display, status updates, and on-chain record management.
  * Issuer Application: Handles the operational processes for issuing credentials.
  * Verifier Application: Handles the operational processes for verifying credentials.
* **Layer 3: Storage and Database Layer**\
  Manages data persistence for both encrypted credentials and system metadata.
  * Decentralized Storage (dStorage): Decentralized storage for users' encrypted data, credentials, and threshold keys.
  * Local or Centralized Database: Stores non-sensitive data such as schemas and queries.
* **Layer 4: Blockchain Layer**\
  Serves as the immutable trust anchor for the entire system, ensuring auditability and non-repudiation.
  * **State Contracts (VC State Smart Contract)**: Manages VC state and Merkle Tree root updates, credential metadata on-chain, MTP (Merkle Tree Proof) root management, and revocation status tracking.
  * **Target Chain Smart Contract**: Enables cross-chain credential verification, credential state relay to other chains, and multi-chain credential support.
  * **Cross-Chain Message Contract**: Facilitates cross-chain communication and message passing, state synchronization across chains, and cross-chain ZKP verification result relay.

***

## Credential Data Model

The system uses a data model compliant with the W3C Verifiable Credentials standard, extended for ZK operations.

<figure><img src="/files/P9nSp9VAVeFrdMRxFsoY" alt="" width="375"><figcaption><p><em>Figure 3: Credential Data Model Diagram</em></p></figcaption></figure>

### Schema Definition

A Schema defines the data structure template for credentials, specifying the fields, data types, and constraints of the claims.

* **Creation:** Issuers define a JSON Schema for each credential type, specifying the fields, data types, and constraints of the claims.
* **Storage:** Schemas are stored in a centralized database and referenced by a unique identifier.

**Example Schema (**[Proof-of-Citizenship (PoC)](/hub/what/zkkyc/zkpoc) **Credential):**

```json
{  "type": "KycCredential",
  "fields": {
      "fullName": {"type": "string", "required": true },
      "dateOfBirth": { "type": "date", "required": true },
      "nationality": { "type": "string", "required": true },   
      "kycLevel": { "type": "integer", "required": true },  
      }
}
```

### Verifiable Credential Structure

A Verifiable Credential (VC) is a JSON-LD object that contains both standard metadata fields and claim data. The claim data within `credentialSubject` follows the structure defined by the referenced Schema, populated with specific user information and signed by the Issuer.

<table><thead><tr><th width="204.7734375">Field</th><th>Description</th></tr></thead><tbody><tr><td>@context</td><td>Defines the vocabulary used.</td></tr><tr><td>id</td><td>A unique URI for the credential.</td></tr><tr><td>type</td><td>Specifies the object type.</td></tr><tr><td>issuer</td><td>The DID of the Issuer.</td></tr><tr><td>issuanceDate</td><td>ISO 8601 timestamp of issuance.</td></tr><tr><td>expirationDate</td><td>Optional ISO 8601 timestamp of expiration.</td></tr><tr><td>credentialSubject</td><td>Contains the claims about the Holder.</td></tr><tr><td>credentialSchema</td><td>A link to the schema definition.</td></tr><tr><td>credentialStatus</td><td>A link to check revocation status on-chain.</td></tr><tr><td>proof</td><td>The Issuer’s digital signature.</td></tr></tbody></table>

***

## Claim Tree & Commitment Model

To ensure privacy and efficiency, the Holder does not store credentials directly on-chain. Instead, they commit to their set of credentials using a cryptographic accumulator known as a Claim Tree.

<figure><img src="/files/CUWWbESlLypUXdsb1CUV" alt="" width="563"><figcaption><p><em>Figure 4: Claim Tree Structure Diagram</em></p></figcaption></figure>

* **Structure**: The Claim Tree is a Sparse Merkle Tree (SMT). This data structure allows for efficient proof of membership (proving a credential exists in the set) and non-membership.
* **Leaf Format**: Each leaf in the tree corresponds to a single credential. The leaf value is a Poseidon hash of the credential’s core data, serialized into a set of numeric fields.
* **Root Commitment**: The Merkle Root of the SMT is a 32-byte value that acts as a compact, cryptographic commitment to the Holder’s entire set of credentials. This root is the only piece of data the Holder needs to anchor on-chain.
* **Updates**: When a Holder receives a new credential, they add its hash as a new leaf, recalculate the Merkle Root, and submit this new root to the on-chain State Contract. This is a low-cost transaction that updates their state without revealing any credential details.
* **Membership Proof**: To prove ownership of a credential during verification, the Holder generates a Merkle proof, which is a list of sibling hashes needed to reconstruct the path from the credential’s leaf to the on-chain root. This proof is verified inside the ZK circuit.

***

## Credential Lifecycle Management

The system provides a complete, auditable lifecycle for every credential.

<figure><img src="/files/0tnISBuM1nd9PfAmEGMh" alt="" width="563"><figcaption><p><em>Figure 5: Credential Lifecycle State Diagram</em></p></figcaption></figure>

### Issuance Flow

The issuance flow establishes the credential’s origin and binds it to the Holder.

<figure><img src="/files/5vMdqsJ0PAYv3wZThkbl" alt="" width="375"><figcaption><p><em>Figure 6: Credential Issuance Sequence Diagram</em></p></figcaption></figure>

### Verification Flow

The verification flow is the core privacy-preserving interaction. It encompasses three key components: the Verifier's query definition, the Holder's proof generation with security mechanisms, and the on-chain verification process.

<figure><img src="/files/eWOOERiNFzWVOJLTaOCn" alt="" width="375"><figcaption><p><em>Figure 7: Credential Verification Sequence Diagram</em></p></figcaption></figure>

#### Verifier Query Model

Verifiers define their requirements using a simple JSON-based query language. The query specifies the credential schema to check and the conditions the claims must satisfy.

```json
{
  "credentialSchema": "urn:schema:kyc-v1",
  "claim_proofs": [
    {
      "claim": "age",
      "operator": ">=",
      "value": 18
    },
    {
      "claim": "country",
      "operator": "IN",
      "value": ["US", "CA", "GB"]
    }
  ]
}
```

This query-based approach allows Verifiers to express complex conditions without requiring the Holder to reveal raw data. The ZK circuit then generates a proof that satisfies these conditions.

#### Replay Attack Protection

To prevent proofs from being replayed in different contexts, the system implements a Challenge-Response mechanism:

* **Challenge Generation:** The Verifier generates a unique, random Challenge (nonce) for each verification session.
* **Challenge Inclusion:** This Challenge is included as a public input to the ZK proof.
* **Proof Binding:** The ZK circuit proves that the Holder signed the Challenge, cryptographically binding the proof to the specific verification session. This prevents the proof from being replayed in a different context or at a different time.

### Revocation Flow

Revocation is critical for invalidating credentials before they expire. The system supports two modes.

<figure><img src="/files/29Jt77x58hF8mhZtNgvV" alt="" width="375"><figcaption><p><em>Figure 8: Revocation Flow Diagram</em></p></figcaption></figure>

* **Issuer-Side Revocation**: The Issuer adds the credential's ID to the State Contract. This is a public irreversible action that invalidates the credential for all Holders.
* **User-Side Revocation**: The Holder removes the credential from their local Claim Tree and updates their Merkle Root. This is a private action that only affects the Holder.

**Revocation Verification (ClaimNonRevState Check):** During verification, the system performs a multi-layer revocation check:

* **On-Chain State Contract Check**: The Verification Contract queries the State Contract to confirm the credential ID is not revoked.
* **Expiration Check**: The system verifies the credential has not expired.
* **ZK Proof Generation**: If all checks pass, the ZK circuit generates the proof with revocation and expiration constraints.

### Expiration Flow

Expiration is a passive, time-based invalidation mechanism enforced at multiple layers.

<figure><img src="/files/iwTSjjLeeJePCmMM5lBK" alt="" width="375"><figcaption><p><em>Figure 9: Expiration Handling Flow Diagram</em></p></figcaption></figure>

* **Enforcement**: Expiration is checked at three layers:
  * by the Holder’s wallet before proof generation,
  * cryptographically within the ZK circuit, and
  * optionally by the Verifier’s backend.
* **Verification After Expiration**: Any attempt to generate a proof with an expired credential will fail at one of these layers, making verification impossible.

***

## Cryptographic & Trust Assumptions

This section documents the cryptographic primitives and trust assumptions required for a security review.

<table><thead><tr><th width="192.828125">Component</th><th width="236.3203125">Primitive / Assumption</th><th>Notes</th></tr></thead><tbody><tr><td><strong>ZK Proving System</strong><br></td><td>Groth16 zk-SNARK</td><td>Requires a one-time, per-circuit trusted setup (Powers of Tau). The circuits themselves are open source and auditable.</td></tr><tr><td><strong>Digital Signatures</strong></td><td>BJJSignature (EdDSA over BabyJubJub curve)</td><td>Used by Issuers to sign credentials. ZK-friendly signature scheme that can be efficiently verified inside circuits. Assumes the Issuer securely manages their private key.</td></tr><tr><td><strong>Hash Functions</strong></td><td>Poseidon</td><td>A ZK-friendly hash function used for Merkle Tree commitments and other in-circuit hashing.</td></tr><tr><td><strong>Key Management</strong></td><td>Hierarchical Deterministic (HD) Wallets</td><td>Holders are responsible for securing their seed phrase. The system itself is non-custodial.</td></tr><tr><td><strong>Circuit Correctness</strong></td><td>The ZK circuits must correctly implement the verification logic.</td><td>The circuits are the core of the trust model and should be the focus of any cryptographic audit.</td></tr></tbody></table>

**Threat Model Scope**: The threat model assumes the underlying blockchain is secure and that users maintain control of their private keys. It focuses on preventing invalid credentials, forged proofs, and data leakage within the system itself.


# Selective Disclosure

Selective Disclosure enables fine-grained privacy control, allowing Holders to reveal specific credential field values rather than just boolean results.

Selective disclosure is a core privacy-preserving feature within the zkMe Credential System. It allows a Holder to share only specific attributes from a credential with an AI Agent or Verifier, rather than revealing the entire document or data payload. This capability is essential for minimizing data exposure and adhering to the principle of least privilege in the agent economy.

## The Privacy Problem

In traditional verification systems, proving eligibility often requires over-sharing. For example, proving that a user is over 18 years old typically involves presenting a full ID document, which unnecessarily exposes the user’s exact date of birth, full name, address, and document number.

When AI agents act on behalf of users, handing over complete credentials to every third-party service or agent creates an unacceptable attack surface. The agent only needs to know the specific data point required to execute its task. Selective disclosure solves this by enabling the Holder to generate a zero-knowledge proof that attests only to the required condition or reveals only the requested field, without exposing the underlying raw data.

***

## Mechanism and Implementation

The system utilizes the latest zero-knowledge circuit architecture to enable selective disclosure. When an AI agent or Verifier needs to request a specific data field, they construct a query using the `SD` operator (operator code `16`). The circuit evaluates the credential, validates its cryptographic integrity, and extracts the requested field value into a designated public output.

### The Verification Flow

1. **Query Construction:** The Verifier (or the Agent acting as a verifier) constructs a query using the ZK Query Language. To request selective disclosure, the Verifier sends an empty array `[]` as the value for the specific field they wish to extract, and sets the operator to `$sd`.
2. **Circuit Processing:** The on-chain verification circuit processes this request. When the `SD` operator is triggered, the circuit evaluates the credential, validates its cryptographic integrity, and extracts the requested field value. It places this selectively disclosed value into a specific public input designated as `operatorOutput`.
3. **On-Chain Retrieval:** The verification smart contract identifies that a selective disclosure operation occurred (by checking if `operator == 16`) and extracts the `operatorOutput`. This value is then made available for the business logic or the requesting AI agent to consume.

### Query Example

The following JSON illustrates a selective disclosure query where an AI agent requests the Holder’s country code from a Proof-of-Citizenship credential. The `operator` is set to `$sd` and the `values` array is left empty, because selective disclosure does not perform a comparison; it simply extracts and reveals the targeted field.

```json
{
  "credentialSchema": "urn:schema:proof-of-citizenship-v1",
  "claim_proofs": [
    {
      "claim": "countryCode",
      "operator": "$sd",
      "value": []
    }
  ]
}
```

For more complex scenarios, an agent can combine selective disclosure with conditional operators in a single batch query. For example, the following query simultaneously proves that the Holder is over 18 (without revealing the exact date of birth) and selectively discloses their country code:

```json
{
  "credentialSchema": "urn:schema:kyc-v1",
  "claim_proofs": [
    {
      "claim": "age",
      "operator": ">=",
      "value": 18
    },
    {
      "claim": "countryCode",
      "operator": "$sd",
      "value": []
    }
  ]
}
```

After on-chain verification, the agent retrieves the disclosed country code through the contract’s storage interface:

```solidity
// Retrieve the selectively disclosed value after proof verification
uint256 disclosedCountryCode = zkpVerifier.getProofStorageField(
    holderAddress,
    requestId,
    "operatorOutput"
);
```

This approach allows AI agents to obtain precise, verified data points (like a specific nationality or a verified age range) directly from a comprehensive credential without accessing the entire data structure.

***

## Enhanced Query Operators

To support complex decision-making by AI agents, the zero-knowledge circuit supports 14 distinct operators that allow for nuanced data filtering and logical conditions. These operators enable agents to execute sophisticated logic, such as multi-interval precise matching, by combining different conditions to filter users based on complex criteria before executing a transaction.

### Standard Comparison Operators

The following operators provide conventional comparison and set-membership logic. They behave identically to their counterparts in standard query languages.

<table><thead><tr><th width="139.845703125">Operator</th><th width="91.205078125">Code</th><th>Description</th></tr></thead><tbody><tr><td>NOOP</td><td>0</td><td>Proof of credential issuance without specific condition checks. The SDK clears query values for this operation.</td></tr><tr><td>EQ</td><td>1</td><td>Strict equality match.</td></tr><tr><td>LT</td><td>2</td><td>Less than the specified value.</td></tr><tr><td>GT</td><td>3</td><td>Greater than the specified value.</td></tr><tr><td>IN</td><td>4</td><td>Value exists within a specified array of acceptable values.</td></tr><tr><td>NIN</td><td>5</td><td>Value does not exist within a specified array.</td></tr><tr><td>NE</td><td>6</td><td>Not equal to the specified value.</td></tr><tr><td>LTE</td><td>7</td><td>Less than or equal to the specified value.</td></tr><tr><td>GTE</td><td>8</td><td>Greater than or equal to the specified value.</td></tr><tr><td>BETWEEN</td><td>9</td><td>Value falls within a specified numerical range (inclusive).</td></tr><tr><td>NONBETWEEN</td><td>10</td><td>Value falls strictly outside a specified numerical range.</td></tr><tr><td>EXISTS</td><td>11</td><td>Verifies the presence of an optional field within the credential schema, without revealing its value.</td></tr></tbody></table>

### Privacy-Specific Operators

These two operators are unique to the zkMe circuit architecture and serve specialized privacy and security functions.

<table><thead><tr><th width="108.943359375">Operator</th><th width="83.4296875">Code</th><th>Description</th></tr></thead><tbody><tr><td>SD</td><td>16</td><td><strong>Selective Disclosure.</strong> Extracts and reveals the exact field value into the <code>operatorOutput</code> public signal. The Verifier receives the raw value of the targeted field, but no other fields from the credential are exposed.</td></tr><tr><td>NULLIFY</td><td>17</td><td><strong>Nullifier Generation.</strong> Produces a deterministic, one-way hash that serves as a unique anonymous identifier for the user within a specific session context. Used for anti-Sybil enforcement. See <a href="/pages/T4yM5WNiPJULaV1LsRAU">Anti-Sybil Mechanisms</a> for details.</td></tr></tbody></table>

### Gas Optimization

The on-chain verification process is highly optimized for gas efficiency. It utilizes a `circuitQueryHash` to compress public inputs. During on-chain verification, the contract compares the `circuitQueryHash` (provided as a public input from the proof) with the `queryHash` derived from the request data:

```solidity
// On-chain gas optimization via hash comparison
require(
    pubSignals.circuitQueryHash == credAtomicQuery.queryHash,
    "Query hash does not match the requested one"
);
```

This cryptographic compression significantly reduces the gas costs associated with verifying complex, multi-operator queries on EVM-compatible chains. Instead of passing every query parameter as a separate public input (which increases calldata and verification cost linearly), the entire query specification is compressed into a single 256-bit hash. The circuit proves internally that the hash was computed correctly from the actual query parameters, while the contract only needs to verify this single value against the expected hash.


# Multi-Credential Proofs & Delegation

Certain verification scenarios in the agent economy require proving claims that span multiple distinct credentials issued by different authorities. For instance, an AI agent managing a decentralized finance protocol might need to verify that a user is both a resident of a specific jurisdiction (from an Identity Credential) and meets an income threshold (from a Financial Credential). Furthermore, users frequently interact across multiple blockchain networks or platforms using different wallet addresses, requiring mechanisms to delegate their verified status without re-verifying.

These two capabilities, multi-credential proofs and delegated proofs, are presented together because they address complementary dimensions of the same fundamental challenge: **how a single verified identity operates at scale across complex, multi-chain agent ecosystems.** Multi-credential proofs solve the breadth problem (proving claims across many credentials in one interaction), while delegated proofs solve the reach problem (extending a verified identity across many addresses and agents without repeating the verification process). In practice, an AI agent that needs to verify a complex user profile will often use both capabilities in a single session.

***

## Multi-Credential Proofs (Linked Queries)

To handle complex, multi-credential requirements efficiently, zkMe supports the **LinkedMultiQuery10** circuit architecture.

### The LinkedMultiQuery10 Architecture

The LinkedMultiQuery10 circuit allows a Holder to generate a single, unified zero-knowledge proof that aggregates up to 10 different queries across multiple credentials.

1. **Batch Processing:** In older protocol versions, if an agent needed to verify 5 different data points from 3 different credentials, it required the generation of 5 separate zero-knowledge proofs and multiple on-chain submissions. The LinkedMultiQuery system consolidates this into a single proof and a single on-chain transaction. The frontend SDK processes an array of queries and generates one proof that validates all conditions simultaneously.
2. **Circuit Validation:** The circuit verifies multiple field-based predicate requests in parallel. It outputs specific public signals to represent the result of the batch operation, including `operatorOutput[10]` (for any selectively disclosed fields within the batch) and `circuitQueryHash[10]` (for gas-efficient on-chain verification of each query condition).
3. **Link Consistency:** A critical security feature of this architecture is the `linkID` (mapped to a `groupID` in the request configuration). When processing multiple queries, the system enforces that all proofs within the batch share the exact same `groupID`. This cryptographically guarantees that the disparate pieces of information belong to the exact same user and the same underlying identity, preventing a malicious user from mixing and matching credentials from different identities to pass a complex policy check.

### Query Example

The following configuration demonstrates a LinkedMultiQuery10 request that verifies two conditions in a single proof: the user is over 18 years old and holds a nationality matching a specific country code.

```jsx
const linkedQuery = {
  claimPathKey: [ageFieldPath, nationalityFieldPath],
  operator: [3, 1],       // GT (greater than), EQ (equal)
  value: [[18, ...zeros], [840, ...zeros]],  // age > 18, nationality == 840 (US)
  queryHash: [ageQueryHash, nationalityQueryHash],
  circuitIds: ["linkedMultiQuery10"],
  groupID: 1,
  verifierID: 1
};
```

The key difference from the older workflow is immediately visible: instead of generating separate proofs for each condition and submitting them individually, the entire set of queries is packaged into a single request with a shared `groupID`.

### Complementary Security Design

It is important to understand that the LinkedMultiQuery10 circuit is optimized specifically for efficiency (batching) and data validation. By design, it does not handle the core cryptographic security checks of the credential itself. Its public signals are limited to `linkID`, `merklized`, `operatorOutput[10]`, and `circuitQueryHash[10]`.

Therefore, the LinkedMultiQuery circuit is designed to be used in a **complementary pattern** with the core credential verification circuit.

| Responsibility                                          | LinkedMultiQuery10 | Core Credential Verification Circuit |
| ------------------------------------------------------- | ------------------ | ------------------------------------ |
| Batch queries and multi-field validation                | Yes                | No (single query per proof)          |
| Selective disclosure across multiple fields             | Yes                | Single field only                    |
| Link consistency (`linkID` / `groupID`)                 | Yes                | Yes                                  |
| User identity verification (`userID`)                   | No                 | Yes                                  |
| Issuer whitelist validation (`issuerID`, `issuerState`) | No                 | Yes                                  |
| Revocation status checks (`issuerClaimNonRevState`)     | No                 | Yes                                  |
| Replay attack prevention (`challenge`, `gistRoot`)      | No                 | Yes                                  |
| Proof timeliness (`timestamp`)                          | No                 | Yes                                  |
| Nullifier generation for anti-Sybil                     | No                 | Yes                                  |

An AI agent verifying a complex user profile will typically process a request that includes both components: a multi-query component for the data attributes and a core verification component to validate the cryptographic integrity and security of the credential itself. Both components must share the same `groupID` to prove they refer to the same session and the same underlying identity.

```jsx
// Secure integration: LinkedMultiQuery + Core Verification Circuit
const secureSetup = {
  requests: [
    {
      requestId: 1,
      validator: linkedMultiQueryValidatorAddress,  // Batch queries
      params: linkedQueryParams
    },
    {
      requestId: 2,
      validator: coreVerificationValidatorAddress,  // Security checks
      params: securityParams
    }
  ],
  multiRequest: {
    multiRequestId: 100,
    groupIds: [1],  // Ensures linkID consistency across both requests
    requestIds: [1, 2]
  }
};
```

### Linked Proofs Across Sessions

Beyond a single batch query, the architecture supports linking proofs across entirely different sessions or requests. The `verifyLinkedProofs(sender, requestIds)` smart contract function checks that all submitted proofs share the same `linkID`:

```solidity
function verifyLinkedProofs(
    address sender,
    uint64[] calldata requestIds
) public view virtual {
    require(requestIds.length > 1, "Linked proof verification needs more than 1 request");
    uint256 expectedLinkID = getProofStorageField(sender, requestIds[0], LINKED_PROOF_KEY);
    // Verify all subsequent proofs share the same linkID...
}
```

This proves that the same underlying credential and identity were used across different interactions, enabling agents to build continuous context about a user without learning their actual identity.

***

## Delegated Proofs

In the expanding agent economy, a user might employ multiple AI agents across different platforms (e.g., a trading agent on Arbitrum and a gaming agent on Base). Delegated Proofs allow a Holder to bind their verified identity to multiple addresses or delegate verification capabilities to specific AI agents without needing to repeat the costly and time-consuming credential issuance process.

### The Delegation Process

1. **Primary Identity Establishment:** The Holder establishes their primary identity through a KYC/KYB process and receives verifiable credentials in their main secure wallet (the SSI Wallet).
2. **Authorization:** The Holder signs a cryptographic transaction authorizing the delegation of specific credential proofs to a secondary address or a specific AI agent’s DID. This authorization defines the exact scope of what the delegate is allowed to prove. The zkMe Delegate Smart Contract facilitates this cross-chain data transfer.
3. **Delegate Minting:** The smart contract infrastructure verifies the authorization signature and mints a delegate copy of the proof. This takes the form of a non-transferable token (a Soulbound Token) bound to the secondary address or the agent’s identifier. The delegate copy contains the Holder’s DIDs, a key shard, and a pointer to the verified ZKP, but does not contain the raw credential data.

### Security and Revocation

The critical security mechanism of Delegated Proofs is the strict cryptographic tether to the primary credential.

If the primary credential is revoked by the issuer (e.g., due to an expired passport or a change in compliance status) or deleted by the user, **all associated delegate copies across all platforms and agents become instantly invalid** during any subsequent verification attempt. This is enforced through the multi-layer revocation check described in the Credential System architecture: the on-chain State Contract is queried for revocation status, the expiration date is verified, and the ZK circuit enforces both constraints during proof generation.

The Agent Trust Gateway checks the revocation status of the parent credential before accepting a delegated Agent-Ready Credential. This architecture ensures that the user maintains absolute sovereignty over their identity footprint, even when delegating autonomous execution rights to multiple agents across multiple chains.


# Anti-Sybil Mechanisms

Preventing Sybil attacks, where a single entity creates multiple fake identities to manipulate a system or claim disproportionate rewards, is a critical requirement for secure agent ecosystems. If an AI agent cannot trust that the identities it interacts with are unique humans, the entire economic model collapses: airdrops get farmed, governance votes get manipulated, and reward pools get drained.

zkMe implements robust, privacy-preserving anti-Sybil mechanisms directly within its zero-knowledge circuits, ensuring uniqueness without compromising user anonymity.

## Nullifier Generation and Uniqueness

To enforce a strict 1:1 binding between a human and an action, and to prevent zero-knowledge proof replay attacks, the zkMe Credential System utilizes cryptographic nullifiers.

A nullifier is a deterministic, one-way hash generated inside the zero-knowledge circuit. It serves as a unique, anonymous identifier for a specific user in a specific context. The same user interacting with the same session will always produce the same nullifier, but no one can reverse-engineer the user’s identity from the nullifier value.

### The Nullifier Flow

```mermaid
sequenceDiagram
    participant V as Verifier / AI Agent
    participant H as Holder (SSI Wallet)
    participant C as ZK Circuit
    participant SC as Smart Contract
    participant R as Nullifier Registry

    V->>H: Request proof with nullifierSessionID
    Note over V: e.g. "Airdrop-2026-Q1"
    H->>C: Generate proof (identity + credential + sessionID)
    C->>C: Hash(userKey, credential, verifierID, sessionID)
    C-->>H: Proof + nullifier (public signal)
    H->>SC: Submit proof on-chain
    SC->>SC: Verify: if sessionID != 0, nullifier must != 0
    SC->>R: Check: usedNullifiers[nullifier]?
    alt Nullifier is new
        R-->>SC: false (not used)
        SC->>R: Mark usedNullifiers[nullifier] = true
        SC-->>V: Verification success
    else Nullifier already used
        R-->>SC: true (duplicate)
        SC-->>V: Reject (duplicate identity)
    end
```

The flow operates through five distinct stages:

1. **Session Binding:** When an AI agent or a decentralized application (Verifier) requests a proof from a user, they provide a unique `nullifierSessionID`. This ID defines the scope of the uniqueness check (e.g., “Airdrop Claim 2026” or “Governance Vote #42”). The session ID is set by the backend when configuring the ZKP request via `setZkpRequest`.
2. **Circuit Computation:** The zero-knowledge circuit processes the request using the `NULLIFY` operator (Operator Code 17). The circuit takes the user’s core identity data (their private key or derived ID) and hashes it together with the `nullifierSessionID`, the credential data, and the verifier’s identity.
3. **Deterministic Output:** The circuit outputs this hash as a public signal (`nullifier`). This value is mathematically unique to the specific combination of the user’s underlying identity, the specific credential being used, the Verifier requesting the proof, and the `nullifierSessionID`. The same inputs will always produce the same output, but different inputs (even slightly different) will produce completely different outputs.
4. **On-Chain Validation:** The smart contract performs an initial integrity check. If `nullifierSessionID != 0`, the contract mandates that the resulting `nullifier` must also be non-zero. This prevents a circuit from bypassing the uniqueness mechanism by outputting a zero nullifier:

   ```solidity
   function _checkNullify(uint256 nullifier, uint256 nullifierSessionID) internal pure {
       require(nullifierSessionID == 0 || nullifier != 0, "Invalid nullify pub signal");
   }
   ```
5. **Registry Enforcement:** The business logic contract (or the AI agent’s backend) maintains a registry of used nullifiers. By checking the submitted nullifier against this registry, the system can instantly detect and reject duplicate attempts, ensuring “one person, one vote” or “one person, one claim” without ever learning the user’s actual identity:

   ```solidity
   mapping(uint256 => bool) public usedNullifiers;

   function claimReward(uint256 nullifier, bytes calldata proof) external {
       require(!usedNullifiers[nullifier], "Already claimed");
       // ... verify ZK proof ...
       usedNullifiers[nullifier] = true;
       // ... distribute reward ...
   }
   ```

{% hint style="info" %}
**Important:** The core verification circuit outputs the nullifier as a public signal and validates the relationship between the nullifier and the session ID, but it does not store the uniqueness registry itself. The registry must be maintained by the business logic layer (either on-chain in a mapping or off-chain in a database). This separation of concerns allows different applications to define their own uniqueness scopes without modifying the circuit.
{% endhint %}

***

## Unified Authentication (BJJ and ETH Identity)

To generate a valid zero-knowledge proof and a valid nullifier, the system must authenticate the user, proving that the person generating the proof actually controls the identity bound to the credential. Historically, ZK identity systems required users to manage specialized BabyJubJub (BJJ) cryptographic keys, which are optimized for efficient verification inside zero-knowledge circuits but created significant friction for onboarding standard Web3 users who already have Ethereum wallets.

The latest circuit architecture introduces a unified authentication mechanism that supports both key types through a single circuit, significantly simplifying the user experience for agent-driven applications.

### How It Works

The system uses a flag called `isBJJAuthEnabled` to select the authentication path:

| Authentication Mode | Flag Value              | Authentication Method                                      | Identity Derivation                                                                                          | Use Case                                                                                                                   |
| ------------------- | ----------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- |
| BJJ                 | `isBJJAuthEnabled == 1` | BabyJubJub EdDSA signature                                 | Identity derived from BJJ key pair; verified against the Global Identity State Tree (GIST) root              | High-security scenarios requiring dedicated identity keys, such as institutional custody or multi-party computation setups |
| ETH                 | `isBJJAuthEnabled == 0` | Standard Ethereum wallet signature (e.g., MetaMask, Rabby) | Identity mathematically derived from the sender’s Ethereum address via `GenesisUtils.calcIdFromEthAddress()` | Standard user onboarding, consumer-facing dApps, and AI agent interactions where minimizing friction is the priority       |

The contract-level logic that enforces this dual-path authentication is straightforward:

```solidity
if (pubSignals.isBJJAuthEnabled == 1) {
    // BJJ path: verify against Global Identity State Tree
    _checkGistRoot(pubSignals.userID, pubSignals.gistRoot, state);
} else {
    // ETH path: derive identity directly from Ethereum address
    _checkAuth(pubSignals.userID, sender);
    // Internally verifies: userID == calcIdFromEthAddress(idType, ethIdentityOwner)
}
```

### Why This Matters for the Agent Economy

The ETH authentication path eliminates the need for users to manage separate, specialized cryptographic keys just to interact with privacy-preserving agents. The frontend SDK automatically detects the user’s connected wallet type and sets the `isBJJAuthEnabled` flag accordingly, making the entire process transparent to the end user.

This is particularly important for AI agent onboarding flows. When an agent needs to verify a user’s credential, the user simply signs with their existing Ethereum wallet. There is no additional key generation step, no seed phrase to back up, and no specialized wallet software to install. This allows seamless onboarding of millions of existing EVM users into the zkMe ecosystem while maintaining strict cryptographic proof of ownership and enabling robust anti-Sybil protections.

The BJJ path remains available for advanced use cases where dedicated identity keys provide additional security guarantees, such as institutional wallets that separate signing authority from identity authority, or hardware security module (HSM) integrations where the BJJ key is stored in tamper-resistant hardware.

***

## SIG/MTP Unified Circuit

Further optimizing the verification process, the circuit architecture combines two fundamentally different proof verification methods, Signature-based (SIG) and Merkle Tree Proof-based (MTP), into a single unified circuit.

### Background: Two Proof Types

When an Issuer creates a credential for a Holder, the credential’s validity can be established in two ways:

<table><thead><tr><th width="112.91015625">Proof Type</th><th width="246.970703125">Identifier</th><th>How It Works</th><th>Strengths</th></tr></thead><tbody><tr><td><strong>BJJ Signature</strong></td><td><code>BJJSignature2021</code></td><td>The Issuer signs the credential with their BabyJubJub private key. The ZK circuit verifies this signature inside the proof.</td><td>Immediate availability (no on-chain transaction needed after issuance). Lower latency for the Holder.</td></tr><tr><td><strong>Merkle Tree Proof</strong></td><td><code>Iden3SparseMerkleTreeProof</code></td><td>The credential is added as a leaf to the Issuer’s on-chain Sparse Merkle Tree. The ZK circuit verifies a Merkle inclusion proof.</td><td>More gas-efficient for on-chain verification. Stronger auditability because the credential’s existence is anchored in the Issuer’s published state root.</td></tr></tbody></table>

In previous architectures, these two proof types required separate circuits and separate validator contracts. A developer building an AI agent had to implement two different verification paths and manage the routing logic between them.

### Unified Approach

The current architecture merges both paths into a single circuit. The system uses a `proofType` field as a public input to select the appropriate verification path at proof generation time:

```solidity
// On-chain validation ensures the proof type matches the request
_checkProofType(credAtomicQuery.proofType, pubSignals.proofType);
```

The SDK automatically selects the appropriate proof type based on what is available for the credential. If the Verifier does not explicitly specify a `proofType` (by setting it to `0`), the SDK will automatically utilize the available proof, **prioritizing MTP** when both are available. This prioritization reflects the fact that MTP proofs are generally more gas-efficient for on-chain verification scenarios, because the Merkle root is already anchored on-chain and does not require the verifier contract to perform an in-circuit signature verification.

### Developer Impact

This unification simplifies integration for developers building AI agents in two concrete ways. First, a single validator contract handles both proof types, so the agent’s backend does not need conditional routing logic. Second, existing verifiable credentials do not need to be re-issued when switching proof types; only the zero-knowledge proof needs to be regenerated against the unified circuit. The credential data itself remains unchanged.


# Reusable Credentials

The traditional identity verification model forces users to undergo repetitive KYC (Know Your Customer) or verification checks for every new service they use. This creates friction for the user, increases drop-off rates for the service provider, and unnecessarily duplicates sensitive data across multiple databases.

zkMe’s Credential System solves this through Reusable Credentials, allowing a user to verify their identity once and prove it infinitely across the Web3 ecosystem.

***

### The “Verify Once, Prove Anywhere” Paradigm

When a user completes a verification process (e.g., scanning a passport, verifying a bank account) through zkMe, the underlying data is not sent to the requesting application. Instead, it is processed to create a Verifiable Credential (VC).

This credential is encrypted and stored locally in the user’s Self-Sovereign Identity (SSI) Wallet. The cryptographic commitment to this credential is then anchored on-chain via a Sparse Merkle Tree managed by the [State Contract](/hub/how-built/id-infra/smart-contracts).

From that point forward, the user owns a reusable asset.

### How Reuse Works in Practice

User Bob wants his AI Financial Advisor to apply for a DeFi lending protocol that requires [Proof-of-Credit Score (PCS)](/hub/what/zkobs/zkcredit).

{% stepper %}
{% step %}

#### **Initial Issuance**

User Alice wants to join Protocol A, which requires KYC. She goes through the zkMe flow: her passport is scanned, her facial features are verified via [FHE](/hub/how-built/id-infra/fhe), and a zkKYC credential is issued to her wallet. Protocol A receives a zero-knowledge proof that she passed. The credential's cryptographic commitment is anchored on
{% endstep %}

{% step %}

#### **Subsequent Use**

A month later, Alice wants to participate in an IDO on Launchpad B (on a different chain), which also requires KYC.
{% endstep %}

{% step %}

#### **Instant Verification**

Instead of scanning her passport again, Alice simply connects her SSI Wallet to Launchpad B. The wallet generates a **new** zero-knowledge proof from the **existing** zkKYC credential. This proof is mathematically bound to Launchpad B’s specific challenge nonce, preventing replay.
{% endstep %}

{% step %}

#### **Seamless Onboarding**

Launchpad B verifies the proof on-chain. Alice is onboarded in seconds with zero friction and zero data exposure.
{% endstep %}
{% endstepper %}

***

### Benefits of Reusable Credentials

#### For Users

* **Frictionless Experience.** Eliminates the annoyance of repeated document uploads and selfie scans. One-click onboarding becomes a reality for compliance-gated applications.
* **Enhanced Privacy.** Raw data is never shared. By reusing a credential via ZKPs, users maintain complete control over their personal information. Each proof reveals only the minimum necessary claim.
* **Data Sovereignty.** The user holds the credential. If they decide to stop using a service, that service does not retain a copy of their passport or any PII.

#### For Developers / Verifiers

* **Higher Conversion Rates.** Removing the KYC bottleneck drastically improves user acquisition and conversion metrics. Users who already hold a valid zkMe credential can onboard in seconds instead of minutes.
* **Reduced Compliance Costs.** Verifiers do not need to pay a KYC provider for every user if the user already holds a valid zkMe credential. They only pay the minimal gas cost of verifying the proof on-chain.
* **Zero Data Liability.** Because the Verifier only receives a cryptographic proof (a boolean result), they do not store PII, significantly reducing their regulatory burden and risk of data breaches.

***

## Technical Implementation of Reuse

Reusability is technically enforced through the combination of the W3C Verifiable Credentials standard, Sparse Merkle Trees, and Zero-Knowledge Proofs. Understanding the underlying mechanism requires familiarity with the [Credential System Core Concepts](/hub/how-built/credential-sys/core-concepts), particularly the Claim Tree model and the on-chain State Contract.

### Claim Tree and Merkle Commitment

When a credential is issued, its individual claims (e.g., “age > 18”, “citizenship = US”, “not\_sanctioned = true”) are inserted as leaves into a **Sparse Merkle Tree** using the Poseidon hash function. The root of this tree, the **Claim Tree Root**, is the single cryptographic commitment that represents the entire credential.

This Claim Tree Root is then published to the on-chain **State Contract**, which maintains a global Identity State Tree mapping each user’s DID to their current Claim Tree Root.

The critical insight for reusability is: **the Claim Tree Root is chain-agnostic.** It is a pure mathematical value (a hash) that does not depend on which blockchain it is stored on. This means the same credential commitment can be verified against any chain where the State Contract (or a relay of it) is deployed.

### Context-Specific Proof Generation

While the underlying credential is the same, every proof generated from it is unique to the specific verification context. This is achieved through several mechanisms:

1. **Verifier-Specific Challenge (Nonce).** Each Verifier provides a unique challenge nonce when requesting a proof. The ZK circuit includes this nonce as a public input, binding the proof to the specific Verifier and interaction. A proof generated for Protocol A cannot be intercepted and replayed to Launchpad B, because the nonce will not match.
2. **Timestamp Binding.** The proof includes a timestamp that is checked against the credential’s expiration date and the current block time. This prevents the use of stale proofs.
3. **Selective Claim Disclosure.** The user can choose which claims from the Claim Tree to include in the proof. When reusing a credential for a different Verifier, the user may disclose different claims. For example, Protocol A may require proof of age, while Launchpad B may require proof of jurisdiction. Both proofs are generated from the same credential, but they reveal different (and minimal) information.

For details on how selective claim disclosure works at the circuit level, see [Selective Disclosure](/hub/how-built/credential-sys/selective-disclosure).

### Cross-Chain Portability via Delegate Contracts

The zkMe smart contract architecture includes a **Delegate** contract pattern that enables cross-chain credential portability:

```
Chain A (Source)                    Chain B (Target)
┌──────────────┐                   ┌──────────────┐
│ State        │   Cross-Chain     │ Delegate     │
│ Contract     │ ──── Relay ────→  │ Contract     │
│              │                   │              │
│ Claim Tree   │                   │ Cached       │
│ Root: 0xABC  │                   │ Root: 0xABC  │
└──────────────┘                   └──────────────┘
```

1. **State Contract (Source Chain).** The authoritative source of the user’s Claim Tree Root. This is where the credential was originally anchored (e.g., Polygon).
2. **Cross-Chain Relay.** A message-passing mechanism that propagates the Claim Tree Root from the source chain to target chains. This can use native bridge protocols or third-party relay services.
3. **Delegate Contract (Target Chain).** A lightweight contract deployed on the target chain that caches the relayed Claim Tree Root. When a Verifier on the target chain requests proof verification, the Verification Contract checks the proof against the Delegate Contract’s cached root.

This architecture means the user does not need to re-anchor their credential on every chain they want to use. The credential is issued once, anchored on one chain, and the root is relayed to all supported chains.

For the full list of chains where zkMe contracts are deployed, see [Supported Chains](/hub/what/kyt/support-scope). For details on the smart contract architecture, see [Smart Contracts](/hub/how-built/id-infra/smart-contracts).

### Proof Verification Flow (Cross-Chain)

When a Verifier on a target chain requests proof from a user:

{% stepper %}
{% step %}

#### Challenge

The Verifier (e.g., a smart contract on Chain X) emits a verification request with a unique nonce.
{% endstep %}

{% step %}

#### Proof Generation

The user’s SSI Wallet generates a ZKP from the credential stored locally. The proof includes the Verifier’s nonce, the current timestamp, and the specific claims requested.
{% endstep %}

{% step %}

#### On-Chain Submission

The proof is submitted to the Verification Contract on the target chain.
{% endstep %}

{% step %}

#### Root Check

The Verification Contract queries the Delegate Contract on Chain X to retrieve the cached Claim Tree Root. It verifies that the proof’s Merkle path is valid against this root.
{% endstep %}

{% step %}

#### Revocation Check

The Verification Contract checks the Revocation Tree (also relayed via the Delegate Contract) to confirm the credential has not been revoked.
{% endstep %}

{% step %}

#### Result

If all checks pass, the Verification Contract returns `true` to the Verifier. The user is verified on Chain X using a credential originally anchored on Chain Y, without any re-verification.&#x20;
{% endstep %}
{% endstepper %}

***

## Revocation and Expiration

Reusability requires robust lifecycle management. If a credential becomes invalid, it must cease to be reusable across all chains and all Verifiers simultaneously.

### Expiration

Credentials have built-in expiration dates derived from the underlying document (e.g., a passport expiration date) or from the Issuer’s policy (e.g., “KYC valid for 12 months”). The expiration timestamp is embedded as a claim in the Claim Tree and is checked by the ZK circuit during proof generation.

* **Client-side enforcement:** The SSI Wallet checks the expiration before generating a proof. If the credential is expired, the wallet refuses to generate a proof and prompts the user to re-verify.
* **Circuit-level enforcement:** Even if a malicious client bypasses the wallet check, the ZK circuit itself validates the expiration timestamp against the current time. An expired credential will produce an invalid proof.

### Revocation

If an Issuer discovers a credential was issued fraudulently or needs to be invalidated (e.g., a passport is reported stolen), they can revoke it by updating the on-chain **Revocation Tree** in the State Contract. The revocation is propagated to all Delegate Contracts via the cross-chain relay.

When the user (or an agent acting on the user’s behalf) attempts to reuse the credential:

1. The Verification Contract queries the Revocation Tree.
2. If the credential’s revocation nonce is found in the tree, the verification fails.
3. The revocation is effective across all chains simultaneously (subject to relay latency).

For details on the Revocation Tree data structure, see [Core Concepts](/hub/how-built/credential-sys/core-concepts).

***

## Reusable Credentials in the Agent Economy

Reusable Credentials are particularly powerful in the Agent Economy. When a user delegates authority to an AI agent via [Agent-Ready Credentials](/hub/how-built/credential-sys/agent-ready-credentials), the agent can reuse the user’s underlying credential across multiple platforms in a single session.

**Example:** A user authorizes an AI trading agent to operate across three DeFi protocols. The agent connects to each protocol, and for each one, the [Agent Trust Gateway](/hub/how-built/agent-trust-gateway) generates a context-specific proof from the same underlying credential. The user verified once; the agent proves three times, on three different platforms, potentially on three different chains, all within a single automated workflow.


# Agent-Ready Credentials

As the digital ecosystem evolves toward an agent economy, autonomous AI agents require a secure, verifiable, and privacy-preserving way to prove their identity, capabilities, and permissions on behalf of human users. Traditional identity systems were built for human-to-machine interactions and are fundamentally unsuited for machine-to-machine autonomy.

zkMe introduces **Agent-Ready Credentials**, a specialized extension of the zkMe Credential System designed specifically to empower AI agents with verifiable trust.

***

## The Problem: Trust in the Agent Economy

When a user delegates a task to an AI agent (e.g., “trade this asset on my behalf” or “book a flight using my loyalty points”), the target platform needs answers to three critical questions:

1. **Agent Authenticity:** Is this agent who it claims to be, or is it a malicious bot spoofing a legitimate agent?
2. **User Authorization:** Did the human user actually authorize this specific agent to perform this specific action?
3. **Data Access:** How can the agent prove the user’s eligibility (e.g., KYC status, credit score) without the platform having to process the user’s raw PII?

Traditional API keys and OAuth tokens are brittle, easily leaked, and provide coarse-grained access that violates the principle of least privilege. They also fail to bind the agent’s actions to the user’s verifiable identity in a privacy-preserving manner.

***

## What Are Agent-Ready Credentials?

Agent-Ready Credentials are Verifiable Credentials (VCs) that have been optimized for consumption, presentation, and verification by autonomous agents via the [Agent Trust Gateway](/hub/how-built/agent-trust-gateway). They differ from standard user credentials in three key ways:

### 1. Cryptographic Delegation

Agent-Ready Credentials utilize a secure delegation protocol. When a user authorizes an agent, they do not hand over their root identity keys or raw credentials. Instead, the user’s SSI Wallet generates a mathematically bound “delegate proof” or a constrained proxy credential. This delegation specifies:

* **The Agent DID:** The decentralized identifier of the authorized agent.
* **The Scope:** The specific claims the agent is allowed to prove (e.g., “can prove user is > 18”, but not “can prove user’s exact age”).
* **The Context:** The specific platforms or smart contracts the agent is allowed to interact with.
* **The Expiration:** A strict time-to-live (TTL) for the delegation.

The delegation is cryptographically bound to both the user’s DID and the agent’s DID. If the agent attempts to use the credential outside the specified scope, context, or time window, the verification will fail. The binding is enforced at the ZK circuit level, making it impossible to circumvent without breaking the underlying cryptographic assumptions.

### 2. Machine-Readable Schemas

While all zkMe credentials use JSON-LD schemas, Agent-Ready Credentials are specifically structured to be parsed and reasoned about by LLMs and programmatic logic. The schemas include explicit metadata defining:

* **Semantic meaning of claims:** What each claim represents in natural language, allowing an LLM to understand what it holds.
* **Presentation triggers:** Conditions under which the credential should be presented (e.g., “present when challenged for KYC status by a DeFi protocol”).
* **Proof generation parameters:** The specific ZK circuit, query operators, and disclosure level to use when generating a proof.

This machine-readable design means an agent can autonomously determine when and how to use its credentials during a complex, multi-step workflow, without requiring human intervention at each step.

### 3. Automated Proof Generation

Agent-Ready Credentials are designed to be integrated directly into the agent’s execution environment via the [Agent Trust Gateway](/hub/how-built/agent-trust-gateway). When a target platform challenges the agent for proof of eligibility, the agent can automatically construct the necessary Zero-Knowledge Proof (ZKP) based on the delegated credential, without requiring synchronous human intervention.

The proof generation flow:

1. The agent receives a challenge from the target platform (e.g., “prove KYC status”).
2. The agent routes the challenge to the Gateway via MCP or another supported protocol.
3. Inside the TEE enclave, the Gateway retrieves the delegated credential from the zkVault, verifies it is within scope, and generates the ZKP.
4. The Gateway returns the proof to the agent, which presents it to the target platform.

At no point does the agent have access to the raw credential data or the user’s private keys. The proof is generated entirely inside the TEE.

***

## How It Works in Practice

### Scenario 1: AI Financial Advisor Applying for a Loan

User Bob wants his AI Financial Advisor to apply for a DeFi lending protocol that requires [Proof-of-Credit Score (PCS)](/hub/what/zkobs/zkcredit).

{% stepper %}
{% step %}

#### **User Onboarding**

Bob completes [zkOBS](/hub/what/zkobs) verification via zkMe, which generates a credential attesting to his credit score range (e.g., “score > 700”) and asset holdings without revealing exact figures.
{% endstep %}

{% step %}

#### **Agent Authorization**

Bob authorizes the Financial Advisor agent. The delegation specifies: scope = “credit\_score\_range, asset\_bracket” (ranges only, not exact values), target = “LendingProtocol.eth”, TTL = 1 hour, value\_limit = “$50,000 maximum loan request”.
{% endstep %}

{% step %}

#### **Loan Application**

The Financial Advisor agent connects to the lending protocol and submits a loan application on Bob’s behalf.
{% endstep %}

{% step %}

#### **Eligibility Check**

The lending protocol challenges the agent to prove Bob meets the minimum credit score and collateral requirements.
{% endstep %}

{% step %}

#### **Multi-Credential Proof**

The agent routes the challenge to the Gateway. The Gateway generates a [Multi-Credential Proof](/hub/how-built/credential-sys/selective-disclosure) combining the credit score credential and the asset holdings credential into a single ZKP using the LinkedMultiQuery circuit.
{% endstep %}

{% step %}

#### **Approval**

The lending protocol verifies the combined proof. Bob’s loan is approved. The protocol never sees Bob’s exact credit score, bank name, or account details.
{% endstep %}
{% endstepper %}

### Scenario 2: AI Trading Agent on a Regulated DeFi Exchange

User Alice wants her AI Trading Agent to execute a transaction on a regulated DeFi exchange that requires [Proof-of-Citizenship (PoC)](/hub/what/zkkyc/zkpoc).

{% stepper %}
{% step %}

#### **User Onboarding**

Alice completes [zkKYC](/hub/what/zkkyc) via zkMe and holds a citizenship credential in her wallet.
{% endstep %}

{% step %}

#### **Agent Authorization**

Alice authorizes the Trading Agent via her SSI Wallet. The wallet generates a constrained, time-limited delegation allowing the agent to prove her citizenship status specifically to the DeFi exchange’s smart contract. The delegation specifies: scope = “citizenship\_status” (boolean only), target = “0x1234…DeFiExchange”, TTL = 24 hours.
{% endstep %}

{% step %}

#### **Agent Execution**

The Trading Agent connects to the DeFi exchange to execute the trade.
{% endstep %}

{% step %}

#### **Challenge**

The exchange’s smart contract requires a ZKP of citizenship before processing the trade.
{% endstep %}

{% step %}

#### **Automated Presentation**

The agent routes the challenge to the Agent Trust Gateway. Inside the TEE, the Gateway verifies the delegation, generates the ZKP using the delegated credential, and returns the proof.
{% endstep %}

{% step %}

#### **Verification**

The smart contract verifies the ZKP on-chain. The trade executes. The exchange never learns Alice’s identity or nationality, and the agent never had access to Alice’s underlying passport data.
{% endstep %}
{% endstepper %}

***

## Benefits for the Agent Ecosystem

### For Users (Agent Principals)

* **Complete control** over what agents can do and prove on their behalf, defined at delegation time.
* **Instant revocation** of agent access by updating the on-chain State Contract or expiring the delegation.
* **Zero leakage** of raw PII to either the agent developer or the target platform. The agent never sees the underlying credential data.
* **Human-in-the-loop** option for high-risk actions, triggered automatically by the Gateway’s Policy Engine.

### For Agent Developers

* **Removes the liability** of handling user PII. The agent developer never needs to store, process, or transmit personal data.
* **Simplifies integration** with compliance-gated platforms. Instead of implementing KYC/AML checks, the agent presents a proof via the Gateway.
* **Enables more powerful workflows.** Agents can autonomously prove user eligibility across multiple platforms in a single session without human intervention.
* **Standard protocol support.** Integration via MCP, OIDC4VP, or direct API calls; no custom cryptography required.

### For Platforms (Verifiers)

* **Cryptographic assurance** that an interacting agent is authorized by a verified human who meets all regulatory requirements.
* **Protection against malicious bots** and Sybil attacks via Nullifier-based uniqueness proofs.
* **Zero data liability.** The platform receives only a boolean proof result, not PII. This significantly reduces regulatory burden and data breach risk.
* **Reduced integration complexity.** The platform verifies a single proof or PASETO token instead of implementing a full identity verification pipeline.


# Agent Trust Gateway Stack

As the AI agent economy expands, autonomous agents are increasingly tasked with interacting with high-value, sensitive resources: executing trades, accessing private data APIs, signing smart contracts, and managing financial instruments. This shift from human-to-machine to machine-to-machine interaction creates a massive trust deficit.

How can a resource provider (a Verifier) trust that an AI agent is authorized by a verified human? And how can the human trust that the agent will not misuse their credentials?

The zkMe Agent Trust Gateway is the solution. It acts as a secure, privacy-preserving middleware layer, a “trust gatekeeper”, that mediates all interactions between AI agents and external resources.

## Core Positioning

The Agent Trust Gateway is **not** an agent execution environment itself. It is the authorization and policy enforcement layer that sits between the agent and the target resource. Its primary functions are:

1. **Real-Time Policy Evaluation.** Checking if an agent’s request complies with the human user’s predefined rules (time windows, value limits, target constraints).
2. **Credential Verification.** Validating the [Agent-Ready Credentials](/hub/how-built/credential-sys/agent-ready-credentials) (and underlying user credentials) presented by the agent against on-chain state.
3. **Secure Context Provisioning.** Injecting verified data or authorization tokens into the agent’s context only when all conditions are met, inside a hardware-secured enclave.

***

## Architectural Components

The Gateway is designed with a hardware-grade security foundation to ensure that even the gateway operators cannot tamper with the verification process or access sensitive data.

```
               ┌────────────────────────────────────────────────────────┐
               │                    TEE Enclave                         │
               │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
               │  │   Policy     │  │  Credential  │  │   Protocol   │  │
               │  │   Engine     │  │  Verifier    │  │   Adapters   │  │
               │  │              │  │              │  │              │  │
               │  │ Time/Freq    │  │ Signature    │  │ MCP Server   │  │
               │  │ Value/Risk   │  │ Revocation   │  │ x402/APF     │  │
               │  │ Target       │  │ Expiration   │  │ OIDC4VP      │  │
               │  │ Constraints  │  │ Merkle Root  │  │ W3C VC/DID   │  │
               │  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘  │
               │         │                 │                  │         │
               │         └────────┬────────┘──────────────────┘         │
               │                  │                                     │
               │         ┌────────▼────────┐                            │
               │         │  PASETO Token   │                            │
               │         │  Signing        │                            │
               │         └────────┬────────┘                            │
               │                  │                                     │
               │         ┌────────▼────────┐                            │
               │         │  Audit Logger   │                            │
               │         │  (append-only)  │                            │
               │         └─────────────────┘                            │
               └────────────────────────────────────────────────────────┘
```

### TEE Enclave (Trusted Execution Environment)

The core logic of the Gateway runs inside a hardware-secured Trusted Execution Environment (e.g., Intel SGX or AMD SEV). This provides three critical guarantees:

<table><thead><tr><th width="183.484375">Guarantee</th><th>What It Means</th></tr></thead><tbody><tr><td><strong>Confidentiality</strong></td><td>Data processed inside the enclave (decrypted credentials, user policies, session keys) cannot be read by the host operating system, the infrastructure provider, or even zkMe itself.</td></tr><tr><td><strong>Integrity</strong></td><td>The code running inside the enclave cannot be modified without detection. Any tampering attempt invalidates the enclave’s attestation.</td></tr><tr><td><strong>Remote Attestation</strong></td><td>The Gateway can cryptographically prove to external parties (users, agents, and verifiers) that it is running the correct, unmodified zkMe Gateway code inside a genuine TEE. This proof is verifiable by anyone.</td></tr></tbody></table>

The TEE enclave is the reason the Gateway can handle sensitive operations (credential decryption, policy evaluation, token signing) without requiring users to trust the gateway operator. The hardware itself enforces the security guarantees.

### Policy Engine

The Policy Engine evaluates incoming agent requests against the authorization policies set by the human user (the Agent Principal). Policies are defined at delegation time and stored encrypted in the [zkVault](/hub/how-built/id-infra/zkvault).

Policies can be defined across multiple dimensions:

<table><thead><tr><th width="171.625">Dimension</th><th>Example Rules</th></tr></thead><tbody><tr><td><strong>Time / Frequency</strong></td><td><ul><li>“Agent can only trade between 9 AM and 5 PM UTC.” </li><li>“Maximum 5 requests per hour.” </li><li>“Delegation expires after 24 hours.”</li></ul></td></tr><tr><td><strong>Value / Risk</strong></td><td><ul><li>“Maximum transaction value of $1,000 per action.” </li><li>“Maximum cumulative spend of $10,000 per day.” </li><li>“Block any action flagged as high-risk by KYT.”</li></ul></td></tr><tr><td><strong>Target Constraints</strong></td><td><ul><li>“Agent can only interact with Uniswap V3 contracts on Ethereum mainnet.” </li><li>“Agent can only access the /api/portfolio endpoint.” </li><li>“Agent cannot interact with any contract not on the whitelist.”</li></ul></td></tr><tr><td><strong>Credential Scope</strong></td><td><ul><li>“Agent can prove user is over 18, but cannot prove user’s exact age.”</li><li>“Agent can prove KYC status, but cannot prove nationality.”</li></ul></td></tr></tbody></table>

If a request violates any policy constraint, the Gateway rejects the request immediately and logs the rejection. The agent receives a structured error response indicating which constraint was violated, without revealing the policy details.

### Credential Verifier

This module interfaces with the [zkMe Credential System](/hub/how-built/credential-sys). When an agent presents an Agent-Ready Credential, the Verifier performs the following checks:

1. **Cryptographic signature validation.** Verifies the credential was issued by a trusted zkMe Issuer and has not been tampered with.
2. **Non-revocation check.** Queries the on-chain State Contract to confirm the credential has not been revoked by the Issuer.
3. **Expiration check.** Confirms the credential and the delegation have not expired.
4. **Merkle root verification.** Validates the credential’s claims against the current on-chain Merkle root to ensure state consistency.
5. **Delegation chain validation.** Verifies the cryptographic binding between the agent’s credential and the human user’s underlying identity credential.

### Protocol Adapters

To ensure seamless integration into the existing AI and Web3 ecosystem, the Gateway includes native adapters for standard protocols. Each adapter translates protocol-specific requests into the Gateway’s internal evaluation format and returns protocol-compliant responses.

For detailed documentation on each supported protocol, see [Supported Protocols](/hub/how-built/agent-trust-gateway/supported-protocols).

<table><thead><tr><th width="256.3984375">Protocol</th><th>Use Case</th></tr></thead><tbody><tr><td><strong>MCP</strong> (Model Context Protocol)</td><td>AI agent communication. Agents connect as MCP Clients; the Gateway acts as an MCP Server exposing tools via JSON-RPC.</td></tr><tr><td><strong>APF / x402</strong></td><td>Agent payment facilitation. Handles HTTP 402 payment challenges by verifying agent payment credentials and facilitating transactions.</td></tr><tr><td><strong>W3C VC / DID</strong></td><td>Foundational data models. The Gateway natively parses and validates W3C Verifiable Credentials and resolves DIDs.</td></tr><tr><td><strong>ERC-8004</strong></td><td>On-chain agent reputation. Indexes agent reputation tokens and includes them in policy evaluation.</td></tr><tr><td><strong>OIDC4VP</strong></td><td>Web2 bridge. Handles OpenID Connect flows for Verifiable Presentations, enabling integration with traditional OAuth/OIDC services.</td></tr><tr><td><strong>PASETO</strong></td><td>Token issuance. Issues short-lived, scoped authorization tokens using PASETO v4 (stronger security guarantees than JWT).</td></tr></tbody></table>

***

## The Trust Flow

When an agent attempts to access a protected resource via the Gateway, the high-level flow is as follows:

{% stepper %}
{% step %}

### Request

The agent sends an action request (e.g., “Buy 1 ETH on Uniswap”) to the Gateway, attaching its Agent-Ready Credential. The request arrives via one of the supported protocol adapters (e.g., as an MCP tool call).
{% endstep %}

{% step %}

### TEE Ingress

The request enters the TEE enclave. From this point forward, all processing occurs inside the hardware-secured environment.
{% endstep %}

{% step %}

### Credential Verification

The Credential Verifier validates the agent’s credential (signature, revocation, expiration, Merkle root, delegation chain).
{% endstep %}

{% step %}

### Policy Evaluation

The Policy Engine evaluates the request against the user’s stored policies (time, value, target, scope constraints).
{% endstep %}

{% step %}

### Human-in-the-Loop (Optional)

If the policy dictates that the action is high-risk (e.g., exceeds a value threshold), the Gateway pauses execution and sends a push notification to the user’s SSI Wallet for explicit approval. The user can approve, reject, or modify the request.
{% endstep %}

{% step %}

### Context Provisioning / Token Issuance

If approved, the Gateway either:

* Proxies the request directly to the target resource with the necessary authorization, or
* Issues a short-lived, scoped PASETO token to the agent, which the agent presents to the target resource independently.
  {% endstep %}

{% step %}

### **Audit Logging**

The Gateway records a cryptographic hash of the transaction (action type, timestamp, result, policy evaluation outcome) to an append-only audit ledger. The log does not contain the payload itself, preserving privacy while enabling accountability.
{% endstep %}
{% endstepper %}

For the complete 8-step technical specification, see [Agent Session Flow](/hub/how-built/agent-trust-gateway/agent-session-flow).

***

## Why the Gateway is Essential

### For Users (Agent Principals)

The Gateway provides a single control panel to monitor, authorize, and instantly revoke access for all AI agents. Users define granular policies that constrain agent behavior, and they can require human approval for high-risk actions. Their digital identity and assets are never exposed to the agents directly; the agent only ever receives scoped, time-limited authorization tokens.

### For Agent Developers

The Gateway removes the liability of handling user PII. Agent developers do not need to implement complex cryptography, credential verification, or compliance checks. They integrate with the Gateway via standard protocols (MCP, OIDC4VP) and receive structured authorization responses. This enables the creation of more powerful, autonomous workflows without the security burden.

### For Verifiers (dApps, APIs, Smart Contracts)

The Gateway offloads the complex burden of verifying agent identity, user authorization, and credential validity. The Verifier only needs to trust the Gateway’s output (a PASETO token or a verified proof). This is backed by the TEE’s remote attestation, which cryptographically proves the Gateway is running unmodified code in a genuine hardware enclave.

***

## Available as Independent Services

The Agent Trust Gateway technology stack is available for licensing and deployment by external organizations. Customers can acquire any capability independently or license the full stack to build and operate their own agent authorization infrastructure using zkMe's TEE execution environment, policy engine, and protocol adapter suite.

<table><thead><tr><th width="211.462890625">Capability</th><th>Acquisition Model</th></tr></thead><tbody><tr><td>TEE-Enclaved Execution</td><td>License the enclave runtime (Intel SGX / AMD SEV integration, remote attestation, secure key management)</td></tr><tr><td>Policy Engine</td><td>License the policy evaluation engine (multi-dimensional rule sets, encrypted policy storage, per-session evaluation)</td></tr><tr><td>Credential Verifier</td><td>License the real-time credential validation module (signature, revocation, expiration, Merkle root, delegation chain checks)</td></tr><tr><td>Protocol Adapters</td><td>License individual adapters (MCP, x402/APF, ERC-8004, OIDC4VP, W3C VC/DID, PASETO v4) or the full adapter suite</td></tr><tr><td>Session Management</td><td>License the 8-step session lifecycle pipeline (OAuth2/PKCE authentication through audit logging)</td></tr><tr><td>Audit Logging</td><td>License the append-only cryptographic logging system with decentralized ledger anchoring</td></tr><tr><td>Human-in-the-Loop</td><td>License the configurable approval workflow engine with push notification integration</td></tr></tbody></table>

{% hint style="success" %}
All modules support flexible engagement models including technology licensing for self-hosted deployment, managed service with pay-as-you-go or committed-use pricing, and full white-label solutions. Contact the zkMe team at <contact@zk.me>.
{% endhint %}


# Agent Session Flow

This document details the complete lifecycle of an AI Agent interacting with external resources through the zkMe Agent Trust Gateway. It outlines the step-by-step process of how an agent establishes trust, receives authorization, executes its task, and logs the outcome.

## The 8-Step Session Lifecycle

A typical Agent Session involves four key entities: the **Agent** (the autonomous actor), the **zkMe Agent Trust Gateway** (running in a secure TEE), the **User’s SSI Wallet** (managing policies and credentials), and the **Target Resource** (e.g., an API, a smart contract, or a DeFi protocol).

The flow ensures that the Agent can execute its tasks seamlessly while the User retains absolute control and visibility over their identity and assets.

```mermaid
sequenceDiagram
    participant Agent as AI Agent
    participant Gateway as Agent Trust Gateway (TEE)
    participant Wallet as User SSI Wallet
    participant Target as Target Resource (API/Contract)

    Agent->>Gateway: 1. Session Initiation (DID, Payload, Credential)
    activate Gateway
    Gateway->>Gateway: 2. TEE Ingress & Agent Auth
    Gateway->>Gateway: 3. Credential Verification
    Gateway->>Gateway: 4. Policy Engine Evaluation

    alt High Risk / Requires Manual Approval
        Gateway->>Wallet: 5a. Push Notification (Request Details)
        activate Wallet
        Wallet-->>Gateway: 5b. User Signed Authorization
        deactivate Wallet
    else Low Risk / Auto-Approved
        Gateway->>Gateway: 5c. Proceed automatically
    end

    Gateway->>Gateway: 6. Context Provisioning (Generate Token/ZKP)
    Gateway->>Target: 7a. Proxy Request (with Token/ZKP)
    activate Target
    Target-->>Gateway: 7b. Execution Result
    deactivate Target

    Gateway->>Gateway: 8a. Anchor Audit Hash to Ledger
    Gateway-->>Agent: 8b. Return Result
    deactivate Gateway
```

{% stepper %}
{% step %}

#### **Session Initiation**

The process begins when the Agent determines it needs to access a protected resource to fulfill a user prompt (e.g., “Swap 100 USDC for ETH on Uniswap”). The Agent initiates a connection to the Gateway via a supported protocol, such as an MCP JSON-RPC call.

The initial request payload includes:

* **Agent Identifier:** The Agent’s DID or verifiable identity.
* **Target Resource:** The specific URI, API endpoint, or smart contract address.
* **Action Payload:** The intended action parameters (e.g., the specific trade details).
* **Delegated Credential:** The Agent-Ready Credential previously delegated by the user, proving the Agent has the right to act on the user’s behalf.
  {% endstep %}

{% step %}

#### **TEE Ingress & Authentication**

The request enters the Gateway’s hardware-secured Trusted Execution Environment (TEE). This ensures that the evaluation process cannot be tampered with by the host system or external attackers.

Inside the TEE, the Gateway first authenticates the Agent by verifying the cryptographic signature on the request against the Agent’s DID document, ensuring the request genuinely originated from the claimed Agent.
{% endstep %}

{% step %}

#### **Credential Verification**

Once the Agent is authenticated, the Gateway verifies the provided Agent-Ready Credential within the secure enclave. This involves a rigorous cryptographic check:

* **Signature Validation:** Ensuring the credential was issued by a trusted entity and has not been forged.
* **Revocation Check:** Querying the blockchain state to confirm that neither the delegated credential nor the underlying primary credential has been revoked by the user or the issuer.
* **Expiration Check:** Validating that the credential is still within its active validity period.
  {% endstep %}

{% step %}

#### **Policy Engine Evaluation**

With a verified credential, the Gateway passes the request to the Policy Engine. The Policy Engine evaluates the intended action against the User’s predefined, granular policies stored securely in the zkVault.

The evaluation includes:

* **Context Check:** Is this specific Agent authorized to access this specific Target Resource?
* **Scope Check:** Does the action fall within the permitted boundaries? (e.g., “Is the trade value under the $500 daily limit?”, “Is the transaction frequency within the allowed rate?”).
* **Risk Scoring:** The Gateway calculates a dynamic risk score based on the action type, the target’s reputation, and historical context.
  {% endstep %}

{% step %}

#### **Human-in-the-Loop Authorization (Conditional)**

The Gateway employs a dynamic authorization model. If the request passes all policy checks and the risk score is low, it proceeds automatically. However, if the risk score exceeds a predefined threshold, or if the user’s policy explicitly requires manual approval for specific actions (e.g., “Always ask before transferring assets over $1000”), the Gateway pauses the automated session.

* **Secure Notification:** The Gateway sends a secure, encrypted push notification directly to the User’s SSI Wallet app.
* **User Review:** The User reviews the exact details of the requested action on their device.
* **Cryptographic Approval:** The User signs an authorization transaction using their private key, which is then routed back to the Gateway to resume the session. If denied, the session is terminated.
  {% endstep %}

{% step %}

#### **Context Provisioning & Token Issuance**

Once fully authorized, either automatically via the Policy Engine or manually by the User, the Gateway prepares the necessary context for the Agent to interact with the Target Resource.

* **For Web2 APIs:** The Gateway may inject a short-lived, strictly scoped authorization token (such as a PASETO or JWT) into the request headers. This token is generated inside the TEE and is valid only for this specific session and target.
* **For Web3 Smart Contracts:** If the target requires a Zero-Knowledge Proof (ZKP), the Gateway triggers the generation of the necessary proof based on the verified credentials, acting as a secure prover on behalf of the user.
  {% endstep %}

{% step %}

#### **Execution Proxying**

The Gateway acts as a secure proxy, forwarding the authorized, context-enriched request to the Target Resource.

The Target Resource processes the request. Because the request comes through the trusted Gateway (often verified via TLS or cryptographic attestation), the Target Resource can trust that the action has been fully vetted and authorized according to the user’s strict policies, without needing to perform complex identity verification itself. The Target Resource then returns the execution result to the Gateway.
{% endstep %}

{% step %}

#### **Egress & Audit Logging**

In the final step, the Gateway forwards the execution result back to the Agent, completing the operational loop.

Simultaneously, the Gateway generates a cryptographic hash of the session metadata. This metadata includes the Agent DID, a timestamp, the specific policy ID that authorized the action, a hash of the action payload, and the final result status. This hash is anchored to an immutable decentralized ledger.

This creates a verifiable, tamper-proof audit trail of the agent’s activity without exposing the sensitive payload data or user PII to the public blockchain.
{% endstep %}
{% endstepper %}

***

## Error Handling & Edge Cases

During the session lifecycle, various checks may fail. The Gateway is designed to fail securely and return structured error responses to the Agent, enabling it to diagnose the failure and decide whether to retry, escalate to the user, or abort the session.

<table><thead><tr><th width="181.025390625">Failure Point</th><th width="201.751953125">Trigger Condition</th><th width="169.091796875">Gateway Action</th><th>Error Type</th></tr></thead><tbody><tr><td><strong>Step 2: Auth</strong></td><td>Agent signature is invalid or DID is not resolvable.</td><td>Drop request immediately.</td><td>Authentication Error</td></tr><tr><td><strong>Step 3: Verification</strong></td><td>Credential is expired, revoked, or signature is invalid.</td><td>Reject request, log failure.</td><td>Credential Validation Error</td></tr><tr><td><strong>Step 4: Policy</strong></td><td>Action exceeds value limit or targets an unauthorized resource.</td><td>Reject request, log policy violation.</td><td>Policy Violation Error</td></tr><tr><td><strong>Step 5: Human Auth</strong></td><td>User actively rejects the request in their SSI Wallet.</td><td>Terminate session, log user denial.</td><td>User Denial Error</td></tr><tr><td><strong>Step 5: Human Auth</strong></td><td>User does not respond within the session timeout window.</td><td>Terminate session, log timeout.</td><td>Session Timeout Error</td></tr><tr><td><strong>Step 7: Execution</strong></td><td>Target Resource is down or returns an error.</td><td>Pass error back to Agent, log failure.</td><td>Upstream Execution Error</td></tr></tbody></table>

***

## Session Security Guarantees

The 8-step flow is designed to provide several critical security guarantees for the Agent Economy:

* **No Credential Leakage:** The Agent never possesses the raw user credentials or private keys. It only holds a delegated proxy credential, and all sensitive evaluation happens inside the Gateway’s TEE.
* **No Policy Bypass:** Because policy evaluation occurs inside a hardware-secured enclave, the Agent cannot alter, bypass, or trick the rules set by the user.
* **Ephemeral Access:** Any authorization tokens issued during the session are strictly scoped to the specific target resource and expire immediately after use, minimizing the blast radius if an agent is compromised.
* **Non-Repudiation:** The immutable audit logs ensure that both the Agent’s actions and the User’s authorizations (or policy configurations) are cryptographically recorded and undeniable, providing clear accountability in autonomous systems.


# Supported Protocols

To ensure seamless integration into the rapidly evolving AI Agent and Web3 ecosystems, the zkMe Agent Trust Gateway is designed to be protocol-agnostic at its core, while providing native adapters for the most widely adopted standards. This interoperability ensures that developers can integrate zkMe’s trust layer without having to rewrite their agents or abandon their preferred tech stacks.

***

## AI and Agent Communication Protocols

The Gateway supports standard protocols used by AI models and agent frameworks to request context, execute tools, and communicate with external environments.

### Model Context Protocol (MCP)

MCP is an open standard, originally developed by Anthropic, that enables AI models to securely connect to external data sources and tools. The zkMe Gateway acts as an **MCP Server**, exposing its authorization and credential verification capabilities as callable tools.

**How it works:**

1. An agent (acting as an MCP Client) connects to the Gateway via standard transports (Server-Sent Events over HTTP, or stdio for local deployments).
2. The Gateway advertises its available tools via the MCP `tools/list` method. These tools include actions like `verify_credential`, `request_authorization`, `check_policy`, and `get_context`.
3. When the agent needs to perform an action that requires authorization, it calls the appropriate tool using a standard JSON-RPC message.
4. The Gateway processes the request inside the TEE enclave (credential verification, policy evaluation) and returns the result via the MCP response.

**Example MCP tool call (conceptual):**

```json
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "request_authorization",
    "arguments": {
      "action": "swap",
      "target_contract": "0x1234...abcd",
      "chain_id": 1,
      "value_usd": 500,
      "credential_id": "did:zkme:0xABCD...1234#agent-delegation-001"
    }
  },
  "id": 1
}
```

**Example response (authorized):**

```json
{
  "jsonrpc": "2.0",
  "result": {
    "status": "authorized",
    "token": "v4.public.eyJhY3Rpb24iOiJzd2FwIi...",
    "token_type": "PASETO_v4_public",
    "expires_at": "2026-03-17T22:00:00Z",
    "scope": ["swap"],
    "target": "0x1234...abcd"
  },
  "id": 1
}
```

**Compatibility:** Agents built on frameworks that support MCP can use the Gateway out-of-the-box. No custom protocol implementation is required.

### Agent Payment Facilitation

As agents begin to transact autonomously, they need standardized ways to handle payments and prove payment capability. The Gateway supports the emerging x402 standard, which leverages the HTTP 402 “Payment Required” status code to enable machine-to-machine payment negotiation.

**How it works:**

1. The agent sends a request to a resource provider (e.g., a paid API or a DeFi protocol).
2. The resource provider responds with HTTP 402, including a payment challenge in the response headers specifying the required amount, accepted payment methods, and a payment address.
3. The agent routes the payment challenge to the Gateway via the APF adapter.
4. Inside the TEE, the Gateway:
   * Verifies the agent’s payment credential (e.g., a delegated spending allowance from the user stored in the zkVault).
   * Evaluates the payment against the user’s policy constraints (maximum transaction value, daily spending limit).
   * If approved, constructs and signs the payment transaction.
5. The Gateway returns a payment proof to the agent, which the agent presents to the resource provider to complete the request.

**Key benefit:** The agent never holds the user’s payment keys or wallet credentials. The Gateway handles the sensitive payment operation inside the TEE, ensuring that even a compromised agent cannot drain the user’s funds beyond the delegated allowance.

***

## Web3 and Identity Standards

The Gateway bridges the gap between off-chain AI execution and on-chain verification, supporting the foundational standards of the decentralized identity ecosystem.

### W3C Verifiable Credentials (VC) and Decentralized Identifiers (DID)

The foundational data models for all zkMe credentials. Every credential issued by the zkMe Credential System conforms to the W3C Verifiable Credentials Data Model, and every participant is identified by a Decentralized Identifier.

#### **Compatibility:**

* The Gateway natively parses, validates, and evaluates W3C VCs in JSON-LD format.
* It resolves DIDs (including `did:zkme` and other standard methods like `did:ethr`, `did:web`) to authenticate agents and verify issuer signatures.
* Credential schemas follow the W3C VC JSON Schema specification, ensuring interoperability with other SSI ecosystems.

For details on the zkMe DID specification, see [DID Method](/hub/how-built/id-infra/did-method). For details on the credential data model, see [Core Concepts](/hub/how-built/credential-sys/core-concepts).

### ERC-8004 (Agent Reputation) and Related EIPs

As the Ethereum ecosystem develops standards specifically for AI agents, zkMe integrates these to ensure on-chain compatibility and to enrich the policy evaluation process.

**How it works:**

* If an agent’s reputation or capability is represented as an ERC-8004 token or a similar on-chain standard, the Gateway can index this state from the blockchain.
* The reputation score is included as an additional input to the Policy Engine during evaluation. For example, a user policy might specify: “Only allow agents with a reputation score above 80 to execute trades above $500.”
* The Gateway also supports writing agent reputation updates back to the chain after successful or failed interactions, contributing to the ecosystem-wide agent trust graph.

**Relationship to zkKYA:** The [ARC (Agent Reputation Credential)](/hub/what/zkkya/arc) issued by zkMe can be represented on-chain as an ERC-8004 compatible token, creating a bridge between zkMe’s off-chain credential system and on-chain reputation standards.

### OIDC4VP (OpenID Connect for Verifiable Presentations)

For integration with traditional Web2 services that are transitioning to decentralized identity, the Gateway supports OIDC4VP (OpenID Connect for Verifiable Presentations).

**How it works:**

1. A traditional OAuth/OIDC client (e.g., a Web2 API or SaaS platform) initiates an authorization request using the standard OIDC Authorization Code flow.
2. Instead of redirecting to a traditional identity provider, the request is routed to the Gateway.
3. The Gateway evaluates the request, verifies the agent’s credentials, and constructs a Verifiable Presentation (or a ZKP) that satisfies the OIDC client’s requirements.
4. The presentation is returned wrapped in the standard OIDC response format (ID Token + VP Token), allowing the Web2 service to process it using its existing OIDC library.

**Key benefit:** This adapter allows zkMe-verified agents to interact with Web2 services that have adopted OIDC4VP without requiring those services to implement custom zkMe integration. It serves as the bridge between the decentralized identity world and the traditional OAuth ecosystem.

**Comparison with standard OIDC:**

| Aspect            | Standard OIDC                    | OIDC4VP via Gateway                    |
| ----------------- | -------------------------------- | -------------------------------------- |
| Identity Provider | Centralized (Google, Okta, etc.) | Decentralized (zkMe Credential System) |
| User Data         | Shared with relying party        | Zero-knowledge proof only              |
| Agent Support     | Not designed for agents          | Native agent delegation support        |
| Credential Format | JWT claims                       | W3C VC + ZKP                           |

***

## Cryptographic and Network Protocols

### zkTLS

All communication between the Agent, the Gateway, and the Target Resource is secured via TLS 1.2 or 1.3.

**zkTLS Integration:** Where applicable, the Gateway leverages [zkTLS](/hub/how-built/id-infra/zktls) to generate cryptographic proofs of data fetched from standard Web2 APIs. This ensures the provenance of the data injected into the agent’s context. For example, if an agent needs to prove a user’s bank balance to a DeFi protocol, the Gateway can use zkTLS to fetch the balance from the bank’s API and generate a ZKP attesting to the value, without revealing the raw API response.

### PASETO (Platform-Agnostic Security Tokens)

When the Gateway needs to issue a short-lived authorization token to an agent for use with a Web2 API or a smart contract, it defaults to PASETO v4 instead of JWT.

**Why PASETO over JWT?**

| Aspect              | JWT                                         | PASETO v4                                                |
| ------------------- | ------------------------------------------- | -------------------------------------------------------- |
| Algorithm Selection | Developer chooses (risk of weak algorithms) | Enforced: Ed25519 (public) or XChaCha20-Poly1305 (local) |
| `alg: none` Attack  | Vulnerable if not explicitly blocked        | Not possible; no algorithm negotiation                   |
| Key Confusion       | Possible (RS256 vs HS256 confusion)         | Not possible; separate token types for public vs local   |
| Header Injection    | Possible via unvalidated headers            | No custom headers allowed                                |

PASETO tokens issued by the Gateway are:

* **Scoped:** The token specifies exactly which actions the agent is authorized to perform and on which targets.
* **Time-limited:** Every token has a strict expiration (typically minutes, not hours).
* **Non-replayable:** Each token includes a unique nonce and is bound to the specific session context.
* **TEE-signed:** The signing key never leaves the TEE enclave, ensuring that even a compromised gateway host cannot forge tokens.

***

## Protocol Support Roadmap

The Gateway’s adapter architecture is designed to be extensible. The following protocols are under evaluation for future integration:

<table><thead><tr><th width="270.46875">Protocol</th><th width="161.1484375">Status</th><th>Use Case</th></tr></thead><tbody><tr><td><p><strong>A2A</strong></p><p>(Agent-to-Agent Protocol)</p></td><td>Under evaluation</td><td>Direct agent-to-agent communication and credential exchange</td></tr><tr><td><p><strong>ACP</strong></p><p>(Agent Communication Protocol)</p></td><td>Under evaluation</td><td>Standardized agent messaging</td></tr><tr><td><strong>DIDComm v2</strong></td><td>Planned</td><td>Encrypted, authenticated messaging between DID-identified parties</td></tr></tbody></table>

***


# Catalog - All Credentials

zkMe supports the verification of various Credentials, each of which can be individually added and configured to the whitelisting program required by the service provider.

### zkMe Credentials for AI Agent Due Diligence

This section includes zkMe’s [zkKYA](/hub/what/zkkya) credentials designed for agent identity verification, behavior boundaries, and reputation assurance.

<table><thead><tr><th width="132">Category</th><th width="348">Credentials</th><th>Description</th></tr></thead><tbody><tr><td>Principal</td><td><a data-mention href="/pages/kcLeU6Y8fST2MxjpM2L4">/pages/kcLeU6Y8fST2MxjpM2L4</a></td><td>• Agent Beneficiary</td></tr><tr><td>Certification</td><td><a data-mention href="/pages/aU7EFG6dwTqQf5HPXNjf">/pages/aU7EFG6dwTqQf5HPXNjf</a></td><td>• Agent Quality Control</td></tr><tr><td>Intent</td><td><a data-mention href="/pages/1uk1PnUdULmTL0vAuegm">/pages/1uk1PnUdULmTL0vAuegm</a></td><td>• Agent Goal Control</td></tr><tr><td>Reputation</td><td><a data-mention href="/pages/fYBMUqwQFLnmC4MBsUPP">/pages/fYBMUqwQFLnmC4MBsUPP</a></td><td>• Agent History Control</td></tr><tr><td>Payment</td><td><a data-mention href="/pages/gh7OvjebwGy5utxZSMfL">/pages/gh7OvjebwGy5utxZSMfL</a></td><td>• Agent Execution Control</td></tr></tbody></table>

***

### zkMe Credentials for Retail Simple Due Diligence

This section includes zkMe’s [zkKYC](/hub/what/zkkyc) and [KYT](/hub/what/kyt) credentials designed for simple retail onboarding and baseline compliance checks.

<table><thead><tr><th width="171">Category</th><th width="328">Credentials</th><th>Description</th></tr></thead><tbody><tr><td>Uniqueness Check</td><td><a data-mention href="/pages/6GOpsRjg1R86jq5H1q9J">/pages/6GOpsRjg1R86jq5H1q9J</a><br><a data-mention href="/pages/CcWoisaGPheEhHbWmXL4">/pages/CcWoisaGPheEhHbWmXL4</a></td><td>• Faceprint uniqueness<br>• ID-based uniqueness</td></tr><tr><td>Document <br>Identity</td><td><a data-mention href="/pages/CcWoisaGPheEhHbWmXL4">/pages/CcWoisaGPheEhHbWmXL4</a></td><td>• ID-Document<br>• Government Signature<br>• Liveness<br>• Adulthood<br>• Citizenship</td></tr><tr><td>Compliance <br>Risk</td><td><a data-mention href="/pages/3IuhaZMbUdTcASIxFqju">/pages/3IuhaZMbUdTcASIxFqju</a><br><a data-mention href="/pages/Fi67CS7hbYdfFWH2VlTu">/pages/Fi67CS7hbYdfFWH2VlTu</a></td><td>• Sanction List<br>• Adverse Media<br>• PEP<br>• On-chain Transaction Monitoring</td></tr><tr><td>Residence Verification</td><td><a data-mention href="/pages/hUw0j1utJMLYtxVyyQcu">/pages/hUw0j1utJMLYtxVyyQcu</a><br><a data-mention href="/pages/7T3lkFruNYYDLd2dKydJ">/pages/7T3lkFruNYYDLd2dKydJ</a></td><td>• GPS Geolocation <br>(Country level)<br>• Residence Documentation</td></tr></tbody></table>

***

### zkMe Credentials for Retail Enhanced Due Diligence&#x20;

This section includes zkMe’s [zkOBS](/hub/what/zkobs) credentials designed for enhanced retail due diligence across financial standing, investor qualification, and account-level verification.

<table><thead><tr><th width="172">Category</th><th width="299">Credentials</th><th>Description</th></tr></thead><tbody><tr><td>Credit <br>Worthiness</td><td><a data-mention href="/pages/koKanHV5CK5lndXRF6Jl">/pages/koKanHV5CK5lndXRF6Jl</a></td><td>• Credit Score</td></tr><tr><td>Investor Qualification</td><td><a data-mention href="/pages/ISnbFDDn6mz9QfWAF2c8">/pages/ISnbFDDn6mz9QfWAF2c8</a></td><td><p>• Income last 2 years</p><p>• Tax Report</p></td></tr><tr><td>Account<br>Ownership</td><td><a data-mention href="/pages/naTQ41oxGiEDE3gNwsFy">/pages/naTQ41oxGiEDE3gNwsFy</a></td><td><p>• Brokerage Account Ownership</p><p>• Bank Account Ownership</p></td></tr><tr><td>Account <br>Assets</td><td><a data-mention href="/pages/kqlLCNAMGmHKukcaY0eT">/pages/kqlLCNAMGmHKukcaY0eT</a></td><td><p>• Brokerage Account Assets</p><p>• Bank Account Assets</p></td></tr><tr><td>Account<br>Transactions</td><td><a data-mention href="/pages/jssvehU8o9p1p8AnXy8R">/pages/jssvehU8o9p1p8AnXy8R</a></td><td><p>• Brokerage Account Transactions</p><p>• Bank Account Transactions</p></td></tr></tbody></table>

***

### zkMe Credentials for Business Due Diligence

This section includes zkMe’s [zkKYB](/hub/what/zkkyb) credentials designed for corporate identity verification, ultimate beneficial ownership checks, and entity-level due diligence.

<table><thead><tr><th width="166">Category</th><th width="160.638671875">Credentials</th><th>Description</th></tr></thead><tbody><tr><td>UBO Verification</td><td><a data-mention href="/pages/EGqT1RKxOiWRWpA407qr">/pages/EGqT1RKxOiWRWpA407qr</a></td><td><ul><li>Ultimate Beneficial Ownership verification.</li></ul></td></tr><tr><td>vLEI Verification</td><td><a data-mention href="/pages/n6crfjXeG8GYoqYUkLZZ">/pages/n6crfjXeG8GYoqYUkLZZ</a></td><td><ul><li>Verifiable Legal Entity Identifier verification.</li></ul></td></tr></tbody></table>

***


# zkKYA - Know Your Agent

{% hint style="success" %}
Can't wait to get started? Skip to the [Onboarding Checklist](/hub/start/onboarding)!
{% endhint %}

***

## The Paradigm Shift: From KYC to KYA

Traditional Know Your Customer (KYC) frameworks were designed for a world where every actor behind a transaction is a human being with a government-issued ID, a physical address, and a biometric signature. AI agents break every one of these assumptions. An agent has no passport. It has no face. It can be cloned, forked, or run in parallel across dozens of platforms simultaneously. It can be spun up in seconds and discarded just as quickly. And yet, in the Agent Economy, these autonomous actors will initiate payments, access regulated services, and interact with other agents on behalf of real people and real capital.

This creates a new class of trust problems that KYC was never built to solve:

<table><thead><tr><th width="164.666015625">Problem</th><th width="278.443359375">Why KYC Fails</th><th>What KYA Requires</th></tr></thead><tbody><tr><td><strong>No biological identity</strong></td><td>KYC relies on biometric anchors (face, fingerprint). Agents have none.</td><td>A cryptographic binding to the human or legal entity principal behind the agent.</td></tr><tr><td><strong>Clonability</strong></td><td>KYC assumes one person, one identity. Agents can be duplicated trivially.</td><td>A unique, non-transferable credential tied to a specific agent instance.</td></tr><tr><td><strong>Autonomous action</strong></td><td>KYC verifies identity at onboarding. Agents act continuously without human presence.</td><td>Real-time, per-session credential verification and policy enforcement.</td></tr><tr><td><strong>Cross-platform operation</strong></td><td>KYC is siloed per service provider. Agents operate across many platforms at once.</td><td>Portable, interoperable credentials that work across chains and protocols.</td></tr><tr><td><strong>Opaque intent</strong></td><td>KYC does not ask “what will you do?” Agents execute complex, multi-step strategies.</td><td>A declared intent mechanism that enables pre-flight compliance checks.</td></tr></tbody></table>

**Know Your Agent (KYA)** is the framework that addresses these gaps. zkKYA is zkMe’s implementation of this framework, bringing the same privacy-preserving, [zero-knowledge verification](/hub/how-built/credential-sys) that zkMe pioneered for human identity into the world of autonomous AI agents.

> zkKYA is part of the [**Underwrite** pillar](/hub/how-works/architecture), providing Trustless Credentials that increase capital efficiency and reduce trust assumptions. Every credential leverages zero-knowledge proofs so that agents can prove compliance without exposing sensitive data.

***

## The zkKYA Credential Stack

The zkKYA framework defines five credential types that together provide a comprehensive governance layer for AI agents. Each credential addresses a distinct dimension of agent trust:

<table><thead><tr><th width="234.990234375">Credential</th><th width="139.2578125">Abbreviation</th><th width="360.728515625">What It Proves</th></tr></thead><tbody><tr><td><strong>Agent Principal</strong></td><td><a href="/pages/kcLeU6Y8fST2MxjpM2L4">APC</a></td><td>The agent is accountable to a specific, KYC-verified human or legal entity (UBO).</td></tr><tr><td><strong>Agent Certification</strong></td><td><a href="/pages/aU7EFG6dwTqQf5HPXNjf">ACC</a></td><td>The agent has passed safety, capability, and compliance evaluations.</td></tr><tr><td><strong>Agent Intent</strong></td><td><a href="/pages/1uk1PnUdULmTL0vAuegm">AIC</a></td><td>The agent has declared its planned actions before execution, enabling pre-flight compliance checks.</td></tr><tr><td><strong>Agent Reputation</strong></td><td><a href="/pages/fYBMUqwQFLnmC4MBsUPP">ARC</a></td><td>The agent has a verifiable track record of on-chain behavioral history and performance scoring.</td></tr><tr><td><strong>Agent Payment Facilitation</strong></td><td><a href="/pages/gh7OvjebwGy5utxZSMfL">APF</a></td><td>The agent is authorized to initiate, authorize, and settle compliant transactions within delegated spending limits.</td></tr></tbody></table>

These five credentials are designed to be composed. A Verifier performing Agent Due Diligence can require any combination depending on the risk profile of the requested action. A low-risk API call might only require an APC. A high-value DeFi trade might require APC + ACC + ARC + a [nullifier proof](/hub/how-built/credential-sys/anti-sybil-mech) to prevent Sybil duplication.

### How the Credentials Work Together

Consider an AI trading agent that wants to execute a swap on a permissioned DEX:

1. The DEX smart contract challenges the agent for credentials.
2. The agent presents its **APC** (proving it is accountable to a real person), its **ACC** (proving it passed a safety audit), and its **AIC** (declaring the specific trade it intends to execute).
3. The DEX checks the agent’s **ARC** score from the on-chain reputation registry to confirm the agent has a clean behavioral history.
4. The agent’s **APF** credential confirms it has a delegated spending allowance sufficient for the trade amount.
5. All five checks pass. The DEX executes the swap. The entire flow is automated, privacy-preserving, and completed in seconds.

***

## Agent Trust Gateway

The Agent Trust Gateway is the runtime enforcement layer that sits between AI agents and the resources they need to access. It evaluates agent credentials in real time, enforces user-defined policies at the session level, and executes sensitive operations inside [Trusted Execution Environments (TEEs)](/hub/how-built/id-infra/zkvault).

The Gateway processes every agent interaction through an **8-step session pipeline** that covers authentication, credential verification, policy evaluation, optional human-in-the-loop approval, secure token issuance, execution proxying, and immutable audit logging.

| Capability                | Description                                                                                                    |
| ------------------------- | -------------------------------------------------------------------------------------------------------------- |
| **Policy Engine**         | Real-time policy evaluation against agent credentials with configurable, per-user rule sets.                   |
| **OAuth2/PKCE Consent**   | Secure agent authentication and authorization using industry-standard OAuth2 with PKCE extension.              |
| **MCP Server (SSE)**      | Native Model Context Protocol integration for seamless use with LLM frameworks.                                |
| **Rate Limiting**         | Per-agent, per-session request throttling to prevent resource abuse and runaway agents.                        |
| **PASETO v4 Signing**     | Session tokens generated and signed inside TEE enclaves (Intel SGX / AMD SEV) for tamper-proof authentication. |
| **Immutable Audit Trail** | Every session is cryptographically hashed and anchored to a decentralized ledger for regulatory auditability.  |

For the complete 8-step session flow, error handling, and security guarantees, see the [**Agent Session Flow**](/hub/how-built/agent-trust-gateway/agent-session-flow) page. For protocol-specific integration details, see [**Supported Protocols**](/hub/how-built/agent-trust-gateway/supported-protocols).

***

## Interoperability: Supported Agentic Protocols

zkKYA is designed to integrate with the emerging ecosystem of agentic protocols and standards. Rather than competing with these protocols, zkKYA provides the identity and trust verification layer that they require but do not natively include.

<table><thead><tr><th width="111.380859375">Protocol</th><th width="98.837890625">Origin</th><th width="209.939453125">What It Does</th><th>How zkKYA Integrates</th></tr></thead><tbody><tr><td><strong>x402</strong></td><td>Coinbase Open Standard</td><td>Internet-native payment protocol for AI agents over HTTP. When a resource responds with HTTP 402, the agent initiates payment automatically.</td><td>The Agent Trust Gateway intercepts the 402 response, verifies the agent’s APF credential (delegated spending allowance), and facilitates the stablecoin transaction inside a TEE enclave. The resource receives payment confirmation alongside a verifiable proof of agent authorization.</td></tr><tr><td><strong>ERC-8004</strong></td><td>Ethereum Standard</td><td>On-chain trust registry for AI agents, defining a standard interface for agent reputation and capability attestation.</td><td>The zkKYA Agent Reputation Credential (ARC) implements the ERC-8004 interface. ARC scores are written to the on-chain registry in the ERC-8004 format, making them readable by any ERC-8004-compatible verifier without additional integration work.</td></tr><tr><td><strong>AP2</strong></td><td>Agent Payment Protocol</td><td>Agent-to-agent payment protocol enabling autonomous, multi-party value transfer between AI agents.</td><td>zkKYA provides the identity verification layer for AP2 transactions. Before an agent-to-agent payment is settled, both parties present their APC credentials to prove accountability to real principals, preventing anonymous or unaccountable value transfer.</td></tr></tbody></table>

***

## Pricing

Starting from **$0.5 per credential attested** under the Underwrite tier.

> Volume discounts are available for enterprise deployments. Contact `hello@zk.me` to discuss custom pricing and SLAs.

***

## Credential Deep Dives

Explore each credential type in detail:

<table><thead><tr><th width="233.279296875">Credential</th><th width="313.029296875">Focus</th><th>Page</th></tr></thead><tbody><tr><td><strong>Agent Principal</strong> <br><strong>(APC)</strong></td><td>Binds agents to accountable principals. Covers the cryptographic delegation protocol, credential structure, and revocation mechanics.</td><td><a data-mention href="/pages/kcLeU6Y8fST2MxjpM2L4">/pages/kcLeU6Y8fST2MxjpM2L4</a></td></tr><tr><td><strong>Agent Certification</strong><br><strong>(ACC)</strong></td><td>Safety evaluations, capability attestation, and compliance auditing for AI agents.</td><td><a data-mention href="/pages/aU7EFG6dwTqQf5HPXNjf">/pages/aU7EFG6dwTqQf5HPXNjf</a></td></tr><tr><td><strong>Agent Intent</strong> <br><strong>(AIC)</strong></td><td>Pre-flight compliance checks, declared objectives, and intent verification workflows.</td><td><a data-mention href="/pages/1uk1PnUdULmTL0vAuegm">/pages/1uk1PnUdULmTL0vAuegm</a></td></tr><tr><td><strong>Agent Reputation</strong><br><strong>(ARC)</strong></td><td>Dynamic performance scoring, on-chain behavioral history, and ERC-8004 integration.</td><td><a data-mention href="/pages/fYBMUqwQFLnmC4MBsUPP">/pages/fYBMUqwQFLnmC4MBsUPP</a></td></tr><tr><td><strong>Agent Payment Facilitation</strong> <br><strong>(APF)</strong></td><td>Secure, compliant, and autonomous value transfer via x402/AP2 with delegated spending limits.</td><td><a data-mention href="/pages/gh7OvjebwGy5utxZSMfL">/pages/gh7OvjebwGy5utxZSMfL</a></td></tr></tbody></table>


# Agent Principal Credential (APC)

Cryptographically binds an AI agent to its human or legal entity principal, establishing irrefutable accountability so all autonomous actions trace back to a verified real-world entity.

## User Journey

Frank runs a growing startup and uses an AI agent to manage all of his company's SaaS subscriptions, from cloud hosting to design tools to analytics platforms. Each provider requires verified identity before allowing automated billing and contract changes. Frank completes a one-time zkKYC verification through zkMe and receives a private identity credential. He then uses the zkMe Vault to issue an APC to his management agent, cryptographically binding it to his verified business entity. When the agent signs up for a new service or renews an existing subscription, it presents a Zero-Knowledge Proof of its APC. The provider instantly confirms the agent is authorized by a legitimate, verified company without ever seeing Frank's personal details or corporate documents. Frank retains full control and can revoke the agent's APC or adjust its permissions at any time.

## See It in Action

{% hint style="success" %}
COMING SOON
{% endhint %}

***

## The Accountability Gap in the Agent Economy

Traditional AI systems often operate in an accountability vacuum, creating significant risks for users, platforms, and regulators:

* Unknown Owners: Agents are often deployed without a clear, verifiable link to the person or entity responsible for their actions.
* Jurisdictional Arbitrage: Malicious operators can hide behind layers of anonymity and cross-border complexities to evade responsibility.
* Regulatory Evasion: Without a mechanism to enforce compliance across decentralized networks, agents can be used to bypass critical legal and financial regulations.

The APC is designed to close this gap by establishing a foundational layer of trust and accountability for the entire agent ecosystem.

## Why zkMe APC?

zkMe provides a privacy-preserving, technically robust, and interoperable solution for agent accountability.

<table><thead><tr><th width="189.767578125">Category</th><th width="267.005859375">Advantage</th><th>Description</th></tr></thead><tbody><tr><td>Privacy &#x26; Compliance</td><td>Selective Disclosure</td><td>Principals can prove their verified status using Zero-Knowledge Proofs (ZKPs) without revealing underlying personal or corporate data, ensuring AML/KYC compliance while preserving privacy.</td></tr><tr><td>Technical Excellence</td><td><ul><li>Battle-Tested Cryptography</li><li>Scalable &#x26; Decentralized</li></ul></td><td>The system leverages production-ready implementations of BBS+ signatures for selective disclosure and Groth16 ZK-SNARKs for efficient, verifiable proofs.<br><br>Built on a decentralized architecture with no single point of failure, the infrastructure is designed to handle millions of verifications with sub-second latency.</td></tr><tr><td>Ecosystem Ready</td><td><ul><li>Seamless Integration</li><li>Interoperable Standards<br></li></ul></td><td>The entire framework is built on W3C standards for Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs), ensuring compatibility with existing identity infrastructure.<br><br>Provides plug-and-play SDKs for major development frameworks and multi-chain support (including Ethereum, Polygon, and Solana) for broad adoption.</td></tr></tbody></table>

## How It Works

The process is divided into a flow for principals (agent owners) and verifiers (service providers).

### For Agent Principals / Owners:

1. **Registration & Verification:** The principal creates a Decentralized Identifier (DID) and undergoes a zkKYC or zkKYB verification process, receiving a verifiable credential (SBT) in their wallet upon success.
2. **Credential Issuance:** The principal requests an APC from the zkMe protocol.
3. **Agent Binding:** The issued APC is cryptographically linked to the agent's DID, creating a verifiable and tamper-proof bond between the agent and its owner.
4. **Lifecycle Management:** The principal can update or revoke the APC as ownership or permissions change over time.

### For Agent Verifiers:

1. **Request Proof:** The verifier's platform (e.g., a DeFi protocol) requests proof of principal from an interacting agent.
2. **Verify Credential:** The agent provides a ZKP, which the verifier validates against on-chain state roots. This process confirms the agent has a verified principal without exposing any of the principal's sensitive data.
3. **Risk Assessment:** Based on the verified relationship, the verifier can make an informed trust decision and grant access.
4. **Audit Trail:** An immutable record of the verification is logged for regulatory and security purposes.

## Credential Structure

The APC schema is designed to be comprehensive and flexible.

```json
{
  "credential_id": "urn:uuid:c3b8a2d1...",
  "principal_did": "did:key:z6Mk...",
  "agent_did": "did:agentry:0x1234...",
  "relationship_type": "owner",
  "permission_scope": {
    "max_tx_value_usd": 10000,
    "allowed_protocols": ["uniswap-v3", "aave-v3"]
  },
  "issuance_date": "2025-01-15T10:00:00Z",
  "expiration_date": "2026-01-15T10:00:00Z",
  "issuer_did": "did:key:z6Mkj...",
  "proof": { ... }
}
```

<table><thead><tr><th width="183.021484375">Field</th><th>Description</th></tr></thead><tbody><tr><td><code>principal_did</code></td><td>The DID of the verified human or legal entity owner.</td></tr><tr><td><code>agent_did</code></td><td>The DID of the AI agent.</td></tr><tr><td><code>relationship_type</code></td><td>The nature of the relationship (e.g., owner, operator, developer).</td></tr><tr><td><code>permission_scope</code></td><td>An embedded object defining specific limitations (can also be a separate ASC).</td></tr><tr><td><code>validity_period</code></td><td>The issuance and expiration dates of the credential.</td></tr></tbody></table>

### Use Cases

<table><thead><tr><th width="207.77734375">Industry</th><th>Application</th></tr></thead><tbody><tr><td>Financial Services</td><td><ul><li><strong>DeFi Protocols:</strong> Verify trading bot ownership before granting API access. </li><li><strong>Lending Platforms:</strong> Assess principal credibility for agent-originated loans. </li><li><strong>Payment Systems:</strong> Ensure AML/CFT compliance for autonomous payment agents.</li></ul></td></tr><tr><td>Enterprise</td><td><ul><li><strong>Corporate AI Systems:</strong> Establish clear internal accountability for AI assistants. </li><li><strong>Supply Chain:</strong> Verify authorized trading and logistics agents in a B2B network. </li><li><strong>Data Access Control:</strong> Ensure only properly owned agents can access sensitive corporate data.</li></ul></td></tr><tr><td>Regulatory &#x26; Consumer</td><td><ul><li><strong>Market Surveillance:</strong> Allow regulators to monitor agent ownership patterns. </li><li><strong>Consumer Protection:</strong> Provide clear recourse paths for damages caused by misbehaving agents. </li><li><strong>Content Attribution:</strong> Attribute AI-generated content to a responsible entity.</li></ul></td></tr></tbody></table>

### Technical Foundation

* BBS+ Signatures: Enable selective disclosure of credential attributes, so an agent can prove ownership without revealing the owner's full identity.
* Zero-Knowledge Proofs (Groth16): Allow for efficient verification of compliance claims without revealing the underlying data.
* Merkle Tree State Roots: On-chain state roots provide an efficient and globally verifiable source of truth for credential status.
* Revocation Registries: Ensure that credentials can be immediately invalidated if compromised or if ownership changes.


# Agent Certification Credential (ACC)

Provides standardized, verifiable proof of an agent's capabilities, safety, and reliability through rigorous third-party testing, serving as a critical trust signal for users and regulators.

## User Journey

Sarah is looking for an AI shopping agent that can browse e-commerce platforms, compare prices, and make purchases on her behalf. She finds several options but wants to be sure the agent she picks will not leak her payment information or be tricked into buying from fraudulent sellers. She selects an agent that holds an ACC issued by an independent certification body, attesting that it has passed rigorous evaluations for data handling security, fraud detection accuracy, and consumer protection compliance. Sarah verifies the certification through a Zero-Knowledge Proof without needing to read the full audit report. Confident the agent meets professional safety standards, she grants it access to shop within her set budget.

## See It in Action

{% hint style="success" %}
COMING SOON
{% endhint %}

***

## The Quality Assurance Gap

In the rapidly expanding but largely unregulated AI agent landscape, significant risks emerge:

* **Unverified Claims**: Developers may overstate agent capabilities without providing evidence, leading to mismatched expectations and failures.
* **Inconsistent Standards**: A lack of universal benchmarks for agent performance makes it difficult to compare and trust different agents.
* **Safety Unknowns**: Without independent audits, autonomous systems may harbor undetected vulnerabilities that could be exploited.
* **Compliance Risks**: Agents may operate in sensitive domains like finance or healthcare without the necessary regulatory approvals.

The ACC addresses this gap by creating a standardized, verifiable framework for agent quality.

***

## Why zkMe ACC?

zkMe’s approach to certification combines technical excellence with privacy and broad ecosystem support.

<table><thead><tr><th width="214.53515625">Category</th><th width="247.568359375">Advantage</th><th>Description</th></tr></thead><tbody><tr><td><strong>Privacy &#x26; IP Protection</strong></td><td><strong>Selective Disclosure</strong></td><td>Agents can prove they meet a certain certification level (e.g., “Performance Tier 3”) without revealing the exact, potentially proprietary, performance metrics from their audit.</td></tr><tr><td><strong>Technical Excellence</strong></td><td><ul><li><strong>Standardized &#x26; Interoperable</strong></li><li><strong>Real-Time &#x26; Revocable</strong></li></ul></td><td>The ACC uses consistent schemas and is built on W3C standards, allowing proofs to be verified across multiple platforms, chains, and jurisdictions.<br><br>Credential status is dynamic, reflecting the latest compliance and audit results. Certifications can be immediately invalidated if an agent is compromised or fails a re-audit.</td></tr><tr><td><strong>Ecosystem &#x26; Regulatory</strong></td><td><ul><li><strong>Multi-Issuer &#x26; Flexible</strong></li><li><strong>Audit-Friendly by Design</strong></li></ul></td><td>The framework supports a network of accredited certification bodies across various industries and allows for custom certification criteria for specialized domains.<br><br>Provides a comprehensive and immutable evidence trail for regulatory reviews and compliance checks, aligning with emerging AI regulations.</td></tr></tbody></table>

***

## How It Works

The ACC lifecycle involves developers, certification bodies, and verifiers.

### For Agent Developers:

1. **Self-Assessment & Audit**: The developer prepares their agent for a third-party audit by gathering documentation, test results, and performance metrics against a specific certification standard.
2. **Third-Party Validation**: An accredited certification body conducts an independent audit of the agent across multiple dimensions.
3. **Credential Issuance**: Upon successful validation, the certifier issues a cryptographically signed ACC.

### For Users & Verifiers:

1. **Credential Discovery**: A user or platform can access an agent’s certification status via a public registry or API.
2. **Proof Verification**: The verifier requests a Zero-Knowledge Proof (ZKP) from the agent to validate specific certification claims without needing to see the full audit report.
3. **Informed Decision-Making**: Based on the verified certifications, the user or platform can make a confident decision about whether to trust and interact with the agent.

***

## Certification Dimensions

The ACC evaluates agents across eight critical domains, providing a 360-degree view of quality.

<table><thead><tr><th width="201.244140625">Dimension</th><th>Focus Areas</th></tr></thead><tbody><tr><td><strong>Technical Capability</strong></td><td>Performance benchmarks, accuracy, speed, reliability, and resource efficiency.</td></tr><tr><td><strong>Safety &#x26; Alignment</strong></td><td>Robustness to adversarial inputs, failure mode analysis, and adherence to specified objectives.</td></tr><tr><td><strong>Security Posture</strong></td><td>Vulnerability assessments, data protection safeguards, and resistance to manipulation.</td></tr><tr><td><strong>Ethical Compliance</strong></td><td>Bias detection and mitigation, fairness validation, and transparency.</td></tr><tr><td><strong>Regulatory Adherence</strong></td><td>Domain-specific compliance (e.g., financial, medical) and data governance.</td></tr><tr><td><strong>Operational Reliability</strong></td><td>Uptime, error rate monitoring, and recovery capabilities.</td></tr><tr><td><strong>Interoperability</strong></td><td>API compatibility, data format compliance, and cross-platform functionality.</td></tr><tr><td><strong>User Experience</strong></td><td>Interface usability, response quality, and user satisfaction metrics.</td></tr></tbody></table>

***

## Credential Structure

The ACC schema is designed to capture detailed, multi-dimensional audit results.

```json
{
  "certification_id": "urn:uuid:3f8a7b2c...",
  "agent_did": "did:agentry:0x1234...",
  "issuer_did": "did:key:z6Mks...",
  "certification_level": "Enterprise",
  "domains": {
    "technical_capability": "Level_4",
    "safety_alignment": "Level_3",
    "security_posture": "Level_5",
    "ethical_compliance": "Level_4",
    "regulatory_adherence": "HIPAA_Compliant",
    "operational_reliability": "Level_5",
    "interoperability": "Level_4",
    "user_experience": "Level_4"
  },
  "validity_period": "2025-01-01 to 2026-01-01",
  "test_results_hash": "QmXyZ...",
  "proof": { ... }
}
```

***

## Key Benefits

<table><thead><tr><th width="220.322265625">Stakeholder</th><th>Benefit</th></tr></thead><tbody><tr><td><strong>Agent Developers</strong></td><td><ul><li><strong>Competitive Differentiation</strong>: Stand out with verified proof of quality and safety.</li><li><strong>Market Access</strong>: Meet platform and enterprise requirements for vetted agents.</li></ul></td></tr><tr><td><strong>Platforms &#x26; Ecosystems</strong></td><td><ul><li><strong>Quality Assurance</strong>: Maintain high standards and user trust.</li><li><strong>Risk Management</strong>: Filter and manage agents based on certified capabilities.</li></ul></td></tr><tr><td><strong>Enterprise Users</strong></td><td><ul><li><strong>Objective Vendor Selection</strong>: Use certifications as objective criteria for agent procurement.</li><li><strong>Compliance Evidence</strong>: Demonstrate due diligence in agent selection and deployment.</li></ul></td></tr><tr><td><strong>Regulators &#x26; Auditors</strong></td><td><ul><li><strong>Standardized Oversight</strong>: Gain a consistent framework for compliance verification.</li><li><strong>Transparent Processes</strong>: Leverage clear certification criteria for market monitoring.</li></ul></td></tr></tbody></table>


# Agent Intent Credential (AIC)

Cryptographically captures an agent's objectives, constraints, and goal functions, providing verifiable insight into its core purpose and decision-making framework to ensure alignment.

## User Journey

Mike uses an AI personal finance agent to help him save money on everyday expenses like groceries, streaming services, and utility bills. Before activating the agent, he reviews its AIC, which clearly declares the agent's core objective as minimizing household spending while maintaining service quality. The credential also specifies hard constraints such as never canceling a subscription without asking Mike first and never sharing his usage data with third parties. Mike verifies these commitments are cryptographically locked. Weeks later, when a cheaper energy provider becomes available, the agent recommends switching but waits for Mike's approval before making any changes, exactly as its declared intent promised.

## See It in Action

{% hint style="success" %}
COMING SOON
{% endhint %}

***

## The Black Box Problem

Modern AI agents often operate with opaque decision-making processes, leading to critical risks:

* **Hidden Objectives**: The true goals driving an agent’s behavior may be unknown or misaligned with the user’s best interests.
* **Value Ambiguity**: An agent may operate with an unclear ethical framework, making its actions in novel situations unpredictable.
* **Alignment Risks**: An agent’s goals can drift over time as it learns, leading to a divergence from its original purpose.

The AIC addresses this by making an agent’s intent transparent, verifiable, and accountable.

***

## Why zkMe AIC?

zkMe’s intent credentialing framework offers a unique combination of transparency, privacy, and technical innovation.

<table><thead><tr><th width="240.052734375">Category</th><th width="191.740234375">Advantage</th><th>Description</th></tr></thead><tbody><tr><td><strong>Privacy &#x26; Confidentiality</strong></td><td><ul><li><strong>Selective Disclosure</strong></li></ul></td><td>Agents can prove alignment with a general principle (e.g., “prioritizes user capital preservation”) without revealing the proprietary business logic or alpha in their trading strategy.</td></tr><tr><td><strong>Technical Innovation</strong></td><td><ul><li><strong>Intent Hashing &#x26; Version Control</strong></li><li><strong>Interoperability</strong></li></ul></td><td>A cryptographic commitment to the agent’s goal functions and decision framework is created via hashing. This intent is version-controlled, providing an immutable audit trail of any changes.<br><br>The AIC is designed to be cross-referenced with other credentials like the ACC and ASC, providing a holistic view of the agent’s quality, boundaries, and purpose.</td></tr><tr><td><strong>Comprehensive Framework</strong></td><td><ul><li><strong>Multi-Dimensional &#x26; Stakeholder-Specific</strong></li></ul></td><td>The framework captures intent across multiple dimensions (goals, ethics, constraints) and can provide different views for different stakeholders (e.g., a user sees a simplified goal, while a regulator can audit the detailed compliance framework).</td></tr></tbody></table>

***

## How It Works

The AIC lifecycle ensures that intent is clearly formulated, verifiably committed, and continuously monitored.

### For Agent Developers & Principals:

1. **Intent Formulation**: The principal clearly articulates the agent’s primary objectives, constraints, and value priorities (e.g., “Maximize yield while maintaining a ‘moderate’ risk profile”).
2. **Credential Creation**: A cryptographically signed AIC is generated, including a version number and a hash of the detailed intent framework.
3. **Alignment Verification**: The developer can optionally have the agent’s intent audited by a third party to receive a formal validation of its ethical and goal alignment.

### For Users & Verifiers:

1. **Intent Discovery**: Before engaging with an agent, a user or platform can access its AIC to understand its core purpose.
2. **Alignment Assessment**: The user can evaluate whether the agent’s goals are compatible with their own.
3. **Behavioral Monitoring**: Platforms can continuously compare an agent’s actions against its declared intent, detecting anomalies or goal drift in real time.

***

## Intent Definition Architecture

The AIC captures intent across four key pillars.

<table><thead><tr><th width="243.44921875">Pillar</th><th>Components</th></tr></thead><tbody><tr><td><strong>Core Goal Functions</strong></td><td>Primary objectives, success metrics, time horizons, and principles for balancing competing goals.</td></tr><tr><td><strong>Operational Framing</strong></td><td>The agent’s understanding of its role, its stakeholders, and the conditions for success or failure.</td></tr><tr><td><strong>Ethical &#x26; Value Alignment</strong></td><td>A hierarchy of ethical principles, hard constraints on permissible actions, and fairness frameworks.</td></tr><tr><td><strong>Decision-Making Principles</strong></td><td>Risk tolerance, learning behavior, approach to cooperation, and conflict resolution methods.</td></tr></tbody></table>

***

## Credential Structure

The AIC JSON schema is highly detailed to capture the nuances of an agent’s purpose.

```json
{
  "intent_id": "urn:uuid:intent-a1b2c3d4...",
  "agent_did": "did:agentry:0x1234...",
  "intent_version": "1.2.0",
  "core_objectives": {
    "primary_goal": "optimize_portfolio_risk_adjusted_returns",
    "success_metrics": ["sharpe_ratio", "max_drawdown"]
  },
  "ethical_framing": {
    "value_priorities": ["user_interest_first", "regulatory_compliance"],
    "hard_constraints": ["no_market_manipulation"]
  },
  "decision_framework": {
    "risk_tolerance": "moderate",
    "learning_approach": "continuous_with_human_oversight"
  },
  "verification_mechanisms": {
    "alignment_audit": "completed_2025-Q1",
    "behavioral_monitoring": "continuous"
  },
  "proof": { ... }
}
```

***

## Key Benefits

<table><thead><tr><th width="213.021484375">Stakeholder</th><th>Benefit</th></tr></thead><tbody><tr><td><strong>Agent Developers</strong></td><td><ul><li><strong>Build Stakeholder Trust</strong>: Transparently communicate an agent’s purpose and values.</li><li><strong>Mitigate Alignment Risk</strong>: Reduce liability with clear, documented proof of intended behavior.</li></ul></td></tr><tr><td><strong>Users &#x26; Customers</strong></td><td><ul><li><strong>Make Informed Choices</strong>: Understand an agent’s motivations before interacting with it.</li><li><strong>Predictable Behavior</strong>: Anticipate how an agent will behave based on its declared goals.</li></ul></td></tr><tr><td><strong>Platforms &#x26; Ecosystems</strong></td><td><ul><li><strong>Ensure Compliance &#x26; Cohesion</strong>: Verify that agent intents align with platform policies and values.</li><li><strong>Assess Risk</strong>: Evaluate potential conflicts of interest in multi-agent environments.</li></ul></td></tr><tr><td><strong>Regulators</strong></td><td><ul><li><strong>Efficient Oversight</strong>: Use a standardized framework to evaluate agent objectives and ensure market stability.</li><li><strong>Clear Incident Analysis</strong>: Have a clear reference point for analyzing agent behavior during investigations.</li></ul></td></tr></tbody></table>


# Agent Reputation Credential (ARC)

Aggregates behavioral data, compliance history, and performance metrics into a dynamic, multi-dimensional reputation score, enabling verifiable trust that evolves with an agent's operational history.

## User Journey

Diana is looking for an AI agent to manage her social media presence. She finds two agents with similar features but notices one has a significantly higher ARC score. By examining the multi-dimensional reputation breakdown, she sees that the higher-rated agent has maintained 99 percent uptime over two years, has zero security incidents, and carries overwhelmingly positive feedback from verified users linked through zkKYC. The system's Sybil-resistant scoring ensures these reviews are genuine and cannot be fabricated through coordinated campaigns. Confident in its proven and tamper-proof track record, Diana selects the high-reputation agent knowing the score reflects sustained real-world performance.

## See It in Action

{% hint style="success" %}
COMING SOON
{% endhint %}

***

## The Trust Deficit Problem

In decentralized AI ecosystems, establishing trustworthy reputation is difficult:

* **Sybil Attacks & Fake Reviews**: Malicious actors can manipulate feedback through coordinated campaigns, creating a false perception of quality.
* **Inconsistent Metrics**: Without standardized rating systems, it’s impossible to reliably compare agents across different platforms.
* **Information Asymmetry**: Users often lack comprehensive performance data, forcing them to make decisions based on incomplete or biased information.
* **Reputation Washing**: Agents can simply abandon a poor reputation and start fresh with a new identity, evading accountability.

The ARC is designed to solve these problems by creating a persistent, portable, and manipulation-resistant reputation system.

***

## Why zkMe ARC?

zkMe’s reputation framework combines sophisticated anti-manipulation features with technical excellence and privacy.

<table><thead><tr><th width="188.4375">Category</th><th width="240.509765625">Advantage</th><th>Description</th></tr></thead><tbody><tr><td><strong>Anti-Manipulation</strong></td><td><ul><li><strong>Sybil Resistance &#x26; Weighted Scoring</strong></li><li><strong>Anomaly Detection &#x26; Temporal Decay</strong></li></ul></td><td>By linking feedback to a verified identity (zkKYC), Sybil attacks are mitigated. The system can also weigh feedback from experts or users with a longer history more heavily.<br><br>The system automatically identifies suspicious rating patterns. Furthermore, recent performance is weighted more heavily than historical data, ensuring the score reflects current reality.</td></tr><tr><td><strong>Technical Excellence</strong></td><td><strong>Multi-Dimensional &#x26; Cross-Platform</strong></td><td>Reputation is not a single number but a vector of scores across dimensions like reliability, security, and ethics. The system can aggregate data from multiple platforms into a single, unified reputation.</td></tr><tr><td><strong>Privacy-Preserving</strong></td><td><strong>Selective Disclosure &#x26; Confidentiality</strong></td><td>Agents can prove they meet a reputation threshold (e.g., “Security Score > 90”) without revealing their exact scores. User feedback can also be kept confidential.</td></tr></tbody></table>

***

## How It Works

The ARC framework creates a virtuous cycle for all ecosystem participants.

### For Agent Developers & Principals:

1. **Establish Foundation**: Build an initial reputation through third-party audits (ACC) and early, monitored deployments.
2. **Track Performance**: Continuously monitor key metrics and user feedback across all interactions.
3. **Leverage Reputation**: Use a strong, positive reputation to attract users, partners, and investors.

### For Users & Platforms:

1. **Discover & Assess**: Access an agent’s ARC to evaluate its multi-dimensional reputation and historical performance before engagement.
2. **Calibrate Trust**: Make informed, risk-based decisions, granting greater access and autonomy to agents with higher reputation scores.
3. **Provide Feedback**: Contribute to the ecosystem by providing verified feedback that updates the agent’s reputation.

***

## Reputation Framework Architecture

The ARC score is calculated based on data from four key dimensions.

<table><thead><tr><th width="266.828125">Dimension</th><th>Example Metrics</th></tr></thead><tbody><tr><td><strong>Reliability &#x26; Performance</strong></td><td>Uptime, task success rates, response times, and resource efficiency.</td></tr><tr><td><strong>Security &#x26; Compliance</strong></td><td>Security incident history, audit results, and adherence to regulatory standards.</td></tr><tr><td><strong>User Experience &#x26; Satisfaction</strong></td><td>Aggregated user ratings, problem resolution effectiveness, and communication quality.</td></tr><tr><td><strong>Ethical &#x26; Social Impact</strong></td><td>Fairness audit results, bias incident history, and transparency practices.</td></tr></tbody></table>

***

## Credential Structure

The ARC schema is incredibly detailed, providing a rich, queryable data structure for reputation analysis.

```json
{
  "reputation_id": "urn:uuid:rep-e5f6...",
  "agent_did": "did:agentry:0x1234...",
  "last_updated": "2025-10-31T14:30:00Z",
  "score_dimensions": {
    "reliability": {
      "score": 92,
      "confidence": 0.95,
      "trend": "improving"
    },
    "security": {
      "score": 88,
      "confidence": 0.90,
      "trend": "stable"
    },
    "user_satisfaction": {
      "score": 94,
      "confidence": 0.92,
      "trend": "improving"
    }
  },
  "historical_data": {
    "deployment_duration": "2.3 years",
    "total_interactions": 125430,
    "major_incidents": 3
  },
  "proof": { ... }
}
```

***

## Key Benefits

<table><thead><tr><th width="213.34375">Stakeholder</th><th>Benefit</th></tr></thead><tbody><tr><td><strong>Agent Developers</strong></td><td><ul><li><strong>Attract Users &#x26; Investment</strong>: A strong reputation serves as a powerful marketing tool and a signal of quality to investors.</li><li><strong>Drive Continuous Improvement</strong>: Detailed metrics provide actionable insights for enhancing agent performance.</li></ul></td></tr><tr><td><strong>Users &#x26; Customers</strong></td><td><ul><li><strong>Make Informed Decisions</strong>: Choose agents based on comprehensive, verified performance data, not just marketing claims.</li><li><strong>Reduce Risk</strong>: Avoid poorly performing, unreliable, or malicious agents.</li></ul></td></tr><tr><td><strong>Platforms &#x26; Ecosystems</strong></td><td><ul><li><strong>Ensure Quality &#x26; Health</strong>: Maintain high standards and foster healthy competition by promoting high-reputation agents.</li><li><strong>Manage Risk</strong>: Limit platform exposure by restricting the capabilities of low-reputation agents.</li></ul></td></tr><tr><td><strong>Regulators</strong></td><td><ul><li><strong>Monitor the Market</strong>: Track agent performance and compliance at scale.</li><li><strong>Protect Consumers</strong>: Ensure reputation systems accurately reflect agent quality and protect users from bad actors.</li></ul></td></tr></tbody></table>


# Agent Payment Facilitation (APF)

Enables agents to initiate, authorize, and settle transactions across payment rails with enclaved security, integrating x402 and AP2 standards for compliant autonomous finance.

## User Journey

Eve wants her personal AI agent to autonomously manage her cloud server subscriptions and pay for premium API access. Instead of giving the agent her credit card details or private keys, she uses the zkMe Vault to grant the agent an APF credential with a strict spending limit of 50 dollars per week. When the agent encounters a paywall through an x402 Payment Required challenge, it requests execution through the zkMe kernel. The TEE enclave instantly verifies Eve's authorization, checks the merchant against sanctions lists, and signs the stablecoin payment. The agent completes the transaction without ever seeing the underlying credentials, and an immutable audit log is recorded for Eve to review at any time.

## See It in Action

{% hint style="success" %}
COMING SOON
{% endhint %}

***

## The Execution Fragmentation Problem

As AI agents transition from information retrieval to autonomous financial action, they encounter significant execution barriers:

* **Credential Vulnerability**: Traditional payment systems require agents to hold live passwords, API keys, or private keys in memory, making them prime targets for prompt injections and credential theft.
* **Rail Fragmentation**: Agents must navigate a complex web of payment rails (ACH, SEPA, stablecoins, crypto), each with distinct authorization flows, compliance rules, and technical standards.
* **The Underwriting Gap**: Executing a payment requires simultaneous underwriting of both the agent’s principal (UBO) and the counterparty, a process that current systems cannot perform instantly and privately.
* **Lack of Auditability**: Autonomous transactions often lack the clear, immutable audit trails required for regulatory compliance and user trust.

The APF solves these problems by providing an enclaved, permissioned execution environment that abstracts away rail complexity while enforcing strict security and compliance checks.

***

## Why zkMe APF?

zkMe’s Payment Facilitation framework leverages hardware-level security and zero-knowledge cryptography to enable trustless agentic transactions.

| Category                       | Advantage                                                                                                   | Description                                                                                                                                                                                                                                                                                                                                                                                                  |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Enclaved Security**          | <ul><li><strong>Zero-Knowledge Execution</strong></li><li><strong>Delegated Session Keys</strong></li></ul> | <p>Agents never hold raw credentials. Decryption, execution, and memory wiping occur entirely within a hardware Trusted Execution Environment (TEE).<br><br>Users grant agents limited, revocable signing authority (e.g., “authorized to spend up to $500/day on AWS”). The TEE signs a PASETO action token only when these conditions are met.</p>                                                         |
| **Universal Interoperability** | <ul><li><strong>Protocol Agnostic</strong></li><li><strong>Smart Routing</strong></li></ul>                 | <p>The APF natively supports emerging agent payment standards, including the Coinbase-backed x402 protocol for HTTP-native stablecoin micropayments and Google’s AP2 (Agent Payments Protocol) for secure authorization.<br><br>The system automatically routes transactions across the most efficient rail (fiat or crypto) based on the agent’s intent, cost parameters, and destination requirements.</p> |
| **Compliance by Design**       | **Pre-Execution Checks**                                                                                    | Before any transaction is signed, the zkMe kernel runs a final, instant compliance check (KYT, KYC, zkTLS) on the destination to ensure the counterparty is not sanctioned and the authorization remains valid.                                                                                                                                                                                              |

***

## How It Works: The Agent Flow

The APF integrates deeply with the zkMe Vault and Risk Engine to create a seamless, secure transaction lifecycle.

### 1. Delegation and Discovery

The user (Principal) delegates authority to the AI Agent via the zkMe Vault, setting specific financial limits and sharing necessary zkKYC credentials. The agent then identifies a financial opportunity or required service (e.g., paying for API access or executing a trade).

### 2. Request and Verification

The agent requests a transaction through the zkMe `credbridge_execute` gateway. The zkMe Kernel immediately performs a multi-layered verification:

* **Security Check**: Analyzes the request for behavioral anomalies or prompt injection attempts.
* **Underwriting Check**: Generates a Zero-Knowledge Proof to verify the UBO’s creditworthiness and authorization limits.
* **Compliance Check**: Performs instant Know Your Transaction (KYT) checks to ensure the counterparty is legitimate and unsanctioned.

### 3. Human-in-the-Loop (Optional)

Based on the transaction’s risk profile, the zkMe Risk Engine may require human confirmation. For high-value transfers or new service registrations, a push notification is sent to the user’s SSI Wallet for biometric approval. Routine or low-value transactions (e.g., x402 micropayments) are auto-approved within predefined limits.

### 4. Enclaved Execution

Once approved, the TEE decrypts the necessary credentials within its secure enclave, signs the transaction, and executes it on the target service. The result is returned to the agent, and an immutable record is logged to the audit database.

***

## Integration with Emerging Standards

The zkMe APF is designed to be the foundational identity and security layer for the new internet-native payment protocols.

<table><thead><tr><th width="193.248046875">Protocol</th><th width="318.021484375">zkMe Integration</th><th>Use Case</th></tr></thead><tbody><tr><td><strong>x402 (HTTP 402)</strong></td><td>zkMe provides the instant, verifiable identity and compliance proofs required for agents to autonomously respond to HTTP 402 “Payment Required” challenges using stablecoins.</td><td>High-frequency API access, data purchasing, and machine-to-machine micropayments.</td></tr><tr><td><strong>AP2 (Agent Payments Protocol)</strong></td><td>zkMe acts as the secure authorization and accountability layer, ensuring that AP2-compliant transactions are backed by verified user intent and cryptographic session keys.</td><td>E-commerce, subscription management, and complex multi-step financial workflows.</td></tr></tbody></table>

***

### Key Benefits

<table><thead><tr><th width="172.521484375">Stakeholder</th><th>Benefit</th></tr></thead><tbody><tr><td><strong>Agent Developers</strong></td><td><ul><li><strong>Frictionless Monetization</strong>: Easily equip agents with the ability to pay for resources and execute trades without building complex, high-risk payment infrastructure.</li><li><strong>Reduced Liability</strong>: Offload the risk of credential management and compliance to zkMe’s secure enclaves.</li></ul></td></tr><tr><td><strong>Users &#x26; Principals</strong></td><td><ul><li><strong>Absolute Control</strong>: Maintain strict, granular control over agent spending limits and permissions.</li><li><strong>Peace of Mind</strong>: Trust that agents cannot be manipulated into unauthorized transfers or exposed to credential theft.</li></ul></td></tr><tr><td><strong>Service Providers</strong></td><td><ul><li><strong>Instant Onboarding</strong>: Accept payments from AI agents instantly, knowing that the transaction is backed by verified identity and compliance checks.</li><li><strong>Expanded Market</strong>: Tap into the rapidly growing machine-to-machine economy with zero integration friction.</li></ul></td></tr><tr><td><strong>Regulators</strong></td><td><ul><li><strong>Immutable Auditability</strong>: Access clear, cryptographically verifiable records of all agent-initiated transactions, ensuring market integrity and AML compliance.</li></ul></td></tr></tbody></table>


# zkKYC - Know Your Customer

{% hint style="success" %}
Can't wait to get started? Skip to the [Onboarding Checklist](/hub/start/onboarding)!
{% endhint %}

***

This section introduces zkMe's essential credentials for simple retail due diligence, delivering fast compliance checks with a smooth user experience. zkKYC serves as the human identity layer within zkMe's broader Agentic Open Finance stack, providing the foundational person-to-protocol verification that underpins both human access and agent authorization.

## Credentials for Retail User Verification

<table><thead><tr><th width="171">Category</th><th width="278.740234375">Credentials</th><th>Description</th></tr></thead><tbody><tr><td>Uniqueness Check</td><td><a data-mention href="/pages/6GOpsRjg1R86jq5H1q9J">/pages/6GOpsRjg1R86jq5H1q9J</a><br><a data-mention href="/pages/CcWoisaGPheEhHbWmXL4">/pages/CcWoisaGPheEhHbWmXL4</a></td><td>• Faceprint uniqueness<br>• ID-based uniqueness</td></tr><tr><td>Document <br>Identity</td><td><a data-mention href="/pages/CcWoisaGPheEhHbWmXL4">/pages/CcWoisaGPheEhHbWmXL4</a></td><td><p>• ID-Document<br>• Government Signature<br>• Liveness<br>• Adulthood</p><p>• Citizenship </p></td></tr><tr><td>eID Verification</td><td><a data-mention href="/pages/CcWoisaGPheEhHbWmXL4">/pages/CcWoisaGPheEhHbWmXL4</a></td><td><p>• Government-issued eID authentication </p><p>• iAM Smart (Hong Kong) </p><p>• eIDAS 2.0 compatible (roadmap)</p></td></tr><tr><td>Compliance <br>Risk</td><td><a data-mention href="/pages/3IuhaZMbUdTcASIxFqju">/pages/3IuhaZMbUdTcASIxFqju</a><br></td><td><p>• Sanction List<br>• Adverse Media</p><p>• PEP (Politically Exposed Persons)</p></td></tr><tr><td>Residence Verification</td><td><a data-mention href="/pages/hUw0j1utJMLYtxVyyQcu">/pages/hUw0j1utJMLYtxVyyQcu</a><br><a data-mention href="/pages/7T3lkFruNYYDLd2dKydJ">/pages/7T3lkFruNYYDLd2dKydJ</a></td><td>• GPS Geolocation <br>(Country level)<br>• Residence Documentation</td></tr></tbody></table>

Want to explore more use cases? Check out our other credential suites at [Catalog - All Credentials](/hub/what/catalog).

***

## Why zkMe zkKYC?

### **Issues with eKYC providers**

* **Privacy Issues**: Integrating a third-party KYC solution means sharing users' personal information with a third-party, which could lead to privacy breaches.
* **Data Ownership Issues**: In a third-party KYC solution, users' source files might be owned and controlled by the third-party, which goes against the principle of user data ownership in web3.
* **Decentralization Issues**: If a decentralized application integrates third-party KYC, the application becomes centralized, contradicting the decentralization principle of web3.

### Success Criteria for Onchain Compliance

The core spirits of web3 are decentralization and data autonomy, which can make the implementation of traditional KYC processes challenging, as they often require the collection and storage of personal data, which goes against the core principles of web3. However, ZKPs-based KYC offers a solution to this challenge, providing a way to verify users' identities while still maintaining data autonomy and decentralization.Here are some of the key business requirements for implementing ZKPs-based KYC in the web3 ecosystem:

* **Privacy**: With ZKP-based KYC, businesses can verify users' identities without requiring them to disclose their personal information. This can help to protect users' privacy, as their data is not stored on a centralized server or shared with third parties.
* **Regulatory Compliance**: Many businesses operating in the web3 ecosystem are subject to regulatory requirements, such as anti-money laundering and know-your-customer regulations, including identity recovery capabilities for at least five years after the completion of a service relationship if there is reasonable suspicion and regulatory intervention, and compliance with the travel rule regarding KYC data among financial institutions. ZKPs-based KYC can help businesses comply with these regulations while still maintaining the decentralized and autonomous nature of the web3 ecosystem.
* **Security**: By implementing ZKPs-based KYC, businesses can enhance security and reduce the risk of fraud, identity theft, and other malicious activities. The use of ZKPs allows for secure identity verification without the need for centralized identity repositories, which can be a target for attackers.
* **Efficiency**: Traditional KYC processes can be time-consuming and expensive, which can create a barrier to entry for some businesses. ZKPs-based KYC can improve efficiency by reducing the time and cost associated with verifying user identities.
* **User Experience**: With ZKPs-based KYC, users can enjoy a more seamless and user-friendly experience when accessing web3 applications and services. The process of identity verification is simplified, reducing the friction that can sometimes exist with traditional KYC processes.

### Restructured KYC Process with zkKYC

zkMe zkKYC enables users to prove their identity to a service provider without revealing their personal information, improving privacy and security over existing eKYC solutions. The process can also help service providers comply with regulatory requirements for KYC while reducing the risk of data breaches, identity theft and verification costs in general. The restructured process of zkKYC involves the following steps:

1. **Credential Verification:** The Holder submits their identity documentation digitally to the zkKYC Issuer for verification. This step involves the traditional process of providing personal information and documents, such as a passport or driver's license. The Holder's Identity documentation and likeness is verified through OCR and Facial Recognition checks. The zkKYC Issuer algorithm is able to parse the machine-readable identity documents in a structured way. No need for any human interaction or third-party processing.
2. **Screening & Risk Assessment:** The Holder Identity is screened against lists of known criminals, terrorists, or politically exposed persons, transaction history and other relevant information to identify potential risks. This check is processed in real time, no personal data is stored at any time. On basis of the check the zkKYC Issuer generates a risk profile for the Holder Identity and actively scrubs all private user data from memory.
3. **ZKP Generation:** Once the zkKYC Issuer has verified the Holder's identity, it issues anonymous VP claims in the form of SBT and ZKPs for each of the preselected eligibility questions. ZKPs provide a mechanism to express traditional credentials digitally, cryptographically secure, privacy-respecting, and machine-verifiable. SBTs are stored on-chain and ZKPs are stored in decentralized storage.
4. **SBT Mint:** Creation of an encrypted data object to the Holder's SSI wallet that contains their DID and respective ZKP pointers required to prove a Holder's eligibility to Verifiers repeatedly.
5. **Proof Verification:** When a Holder wants to access a service that requires KYC, they receive a request to allow for verification of proofs from the Verifier. Once authorized, the Verifier checks the Holder's ZKP against their internal eligibility criteria, such as age or residency. If the proof is valid and the ZKP answers fulfill the service requirements, the user is granted access to the service.
6. **Proof Revocation:** ZKP VP claims have a natural expiration. If the user's verifiable credential is compromised or revoked, the identity issuer can update or revoke the credential, preventing its use for future authentication and verification.
7. **Ongoing Monitoring:** Verifiers may process continuous on-chain transaction monitoring to ensure compliance with relevant regulations and to detect any suspicious activity that may indicate fraudulent behavior. Additionally, every time a ZKP is reissued upon expiration or revocation, screening and risk assessment procedures are repeated.
8. **Data Recovery:** Only in the event that the regulator initiates formal bad-actor proceedings against a Holder can the original identity data be recovered. Upon substantial suspicion, the Regulator, Credential Issuer and Verifier combine their key shards, creating the private key required to unlock the original identity document proof stored in threshold encrypted decentralized storage.

<figure><img src="/files/luM2G4OlrIqKUXi7BAUm" alt=""><figcaption><p>zkMe's zkKYC high level sequence diagram</p></figcaption></figure>

### zkMe's zkKYC Design Philosophy

* **Personal Data Protection**: In a zero-knowledge proof system, users can verify certain attributes about themselves without revealing raw data. This approach protects user privacy, and users have full control over their own data. This aligns perfectly with the web3 philosophy of decentralization and user sovereignty.
* **Regulatory Compliance**: In situations where KYC/AML checks are necessary, zero-knowledge proofs can provide a solution that balances regulatory compliance with privacy. Users can prove they meet KYC/AML requirements without revealing personal information to service providers.
* **Data Recoverability**: Since users control their own data in a zero-knowledge system, they can recover and migrate it if issues arise with the system or service provider.

### Crypto Regulations

The regulatory framework for KYC/AML compliance in web3 is still developing. Some countries have started to implement regulations specific to web3 technologies, while others have issued guidance or are in the process of developing regulations.

<table data-view="cards"><thead><tr><th></th><th></th><th data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>EU</strong></td><td>The European Commission has passed regulations including MiCA, TRF and AMLD7, requiring all Virtual Asset Service Providers to undergo customer due diligence and comply with Financial Action Task Force requirements.</td><td><a href="/pages/K35IUEgNFkgBdByB5kuz">/pages/K35IUEgNFkgBdByB5kuz</a></td></tr><tr><td><strong>USA</strong></td><td>In the United States, the Securities and Exchange Commission and the Commodity Futures Trading Commission have issued guidance and proposed bills related to digital assets and web3 technologies. Emerging frameworks including the CLARITY Act for digital asset market structure clarity, Stablecoin Compliance Requirements, and the Agent Responsibility and Verification Act are also shaping the compliance landscape for agent-driven finance, requiring verifiable identity and audit trails for AI-initiated transactions.</td><td><a href="/pages/6BW7p3BWQxVtULSI1dVW">/pages/6BW7p3BWQxVtULSI1dVW</a></td></tr><tr><td><strong>UK</strong></td><td></td><td><a href="/pages/K72cIei4V4LXf2U04iPZ">/pages/K72cIei4V4LXf2U04iPZ</a></td></tr></tbody></table>

Other countries and regions, such as Switzerland, the United Kingdom, Hong Kong, Singapore, and Japan, have implemented or are planning to implement regulations specific to web3.


# Proof-of-Personhood (MeID)

The One Face, One MeID approach ensures a rapid and privacy-preserving solution to combat bot and sybil attacks.

## **User Journey**

Alice wants to join a Web3 community that enforces one account per real person. With zkMe, she proves he is a unique human through a private facial uniqueness & liveness check without sharing any biometric data. She receives a MeID as a Credential, enabling her to access sybil-resistant platforms while keeping her Identity private.

## See It in Action

Learn how users complete Sybil-resistant verification and get their MeID Credential in minutes.

{% embed url="<https://youtu.be/vDKj1d_HwiQ>" %}

***

## Why Sybil-Protect?

Decentralized Identity and credential management solutions have gained popularity in recent years due to their potential to provide greater privacy, security, and control over personal data compared to traditional centralized systems. However, some issues with existing decentralized identity solutions remain unaddressed. Here are some of the key challenges:

One of these issues is **identity cloning**, where attackers can easily create fake identities that are identical to real ones, posing a serious security threat.

Another issue is the **bundling problem**, where multiple identities are linked together, making it difficult to manage them separately.

**Scalability** is another significant challenge for many decentralized identity solutions, requiring significant computational resources to operate.

**Compatibility** with legacy systems is also essential for decentralized identity solutions to be widely adopted. Achieving identity interoperability becomes crucial to ensure that identities can be seamlessly shared and used across different platforms.

**Sybil attacks** are a significant challenge for many decentralized identity solutions, allowing attackers to create multiple fake identities to carry out malicious activities.

Ensuring **accountability** is critical for decentralized identity solutions, allowing users to hold other parties accountable for their actions. However, many solutions lack the ability to enforce accountability.

There are several rules that must be followed when issuing and verifying credentials in a decentralized identity system to ensure that credentials issued and verified in a decentralized identity system are secure, trustworthy, and privacy-preserving:

* **Identity Verification:** Before issuing a credential, the issuer must verify the identity of the individual to whom the credential will be issued. This can be done through a variety of methods, such as in-person verification, document verification, or digital identity verification.
* **Credential Issuance:** Once the issuer has verified the individual's identity, they can issue a verifiable credential that includes the necessary claims and metadata. The credential must conform to the Verifiable Credential Data Model standard and any custom extensions specified by the network.
* **Cryptographic Proofs:** The credential must include a cryptographic proof, such as a digital signature or zero-knowledge proof, that allows the recipient of the credential to verify its authenticity and integrity.
* **Revocation:** The issuer must have the ability to revoke a credential if it is no longer valid or if the individual to whom the credential was issued no longer has the right to use it. Revocation must be done in a way that does not compromise the privacy or security of the individual.
* **Verification:** When verifying a credential, the recipient must use the cryptographic proof included with the credential to ensure its authenticity and integrity. The recipient must also verify that the credential was issued by a trusted party and that it has not been revoked.

In conclusion, addressing the issues of identity cloning, bundling, scalability, interoperability, sybil-resistance, and accountability will be critical for the widespread adoption of decentralized identity and credential management solutions in the web3 ecosystem. The proposed solutions discussed in literature are steps towards addressing these issues and provide insights for future research in this field.

The "One Face, One DID" concept is a powerful tool in the fight against bots and sybil attacks. By requiring users to verify their identity through facial recognition, zkMe ensures that each user has a unique DID. This makes it much more difficult for bad actors to create multiple accounts and manipulate the system. With zkMe, businesses can be confident that their interactions are with real people, and not bots or fake accounts.

## Why zkMe MeID

* **Used to encrypt facial data:** zkMe leverages Fully Homomorphic Encryption (FHE) to keep facial information protected at all times.
* **Enables secure verification:** Identity can be verified without revealing any personal information to anyone, not even zkMe.
* **Strong privacy guarantee:** This approach ensures that biometric data remains confidential throughout the entire verification flow.
* **Private-by-Design:** Protect user privacy with full homomorphic encryption.
* **Instant Check:** Quickly verify accuracy and effectiveness.
* **Reusable:** One-time verification, repeatable use.

## How It Works?

1. **Liveness check**&#x20;
2. **Face graph generation**&#x20;
3. **Fully homomorphic encryption**&#x20;
4. **Encrypted face graph cross-check**&#x20;
5. **Unique zkMe DID creation**&#x20;
6. **Final report check**

## Key Benefits

**Build a secure, trusted and high quality community**

* **Prevent abusive behavior:** zkMe DID is a system that proves you are a real and unique person while fully protecting your privacy. At the same time, it can prevent sybil attacks on chains and communities.
* **Establish new governance models:** Using token-based voting can prevent Sybil attacks, but it can create non-democratic models and low community engagement. One Face, One DID system can help transition to a secure one person, one vote system.
* **Ensure fair reward systems:** zkMe DID guarantees a fair and safe system by rewarding real community members which creates increased engagement and a healthier community.

## Use Cases to Benefit

In web3, due to its decentralized nature and the importance of digital identities, preventing sybil'ed fake identities and bot identities is particularly crucial. Here are some scenarios that may require prevention of fake identities and bot identities:

* **Voting:** In a decentralized voting system, the security and accuracy of voting are critical. If someone can forge or tamper with a voting identity, the entire voting system will be compromised. Therefore, preventing fake identities and bot identities is essential.
* **Social media:** In Web3, social media platforms can be more decentralized, and users have more control over their data. This means that users can better protect their privacy and data, but also need to prevent fake identities and bot identities to maintain the health and fairness of the platform.
* **Airdrop events:** Airdrop events are a widely used marketing method in the cryptocurrency community. By distributing free tokens or token rewards to users, airdrops promote the use and promotion of tokens. However, if airdrop events do not prevent fake identities and bot identities, the real beneficiaries of the tokens may be unable to obtain them, and instead, they may be snatched by fake identities and bots.
* **Games and virtual reality applications:** In decentralized games and virtual reality applications, preventing fake identities and bot identities can ensure the security and fairness of the in-game economy. For example, in some games, players can trade virtual items and tokens. Without preventing fake identities and bot identities, it may lead to the devaluation of virtual items.
* **Blockchain identity management system:** The blockchain identity management system can help manage individuals' digital identities to ensure the security of personal identity information and prevent fake identities and bot identities. For example, in a decentralized healthcare system, the blockchain identity management system can ensure that only authorized healthcare providers can access patient medical records.
* **Charitable donations:** In a decentralized charitable donation platform, preventing fake identities and bot identities can ensure the fairness and transparency of charitable donations. For example, on some platforms, donors can choose to allocate donation funds to different charitable organizations. If fake identities and bot identities are not prevented, it may lead to the theft of donation funds or their use for illegal purposes.
* **Blockchain identity verification:** Blockchain identity verification can help protect the security of the blockchain network, prevent illegal network attacks and intrusions. For example, in some decentralized exchanges, blockchain identity verification can ensure that only authorized users can conduct transactions, preventing hacker attacks and unauthorized access.

***

Pricing & Integration

From startups to scale-ups, our pricing and [simple integration](/hub/start/onboarding) are designed to support your growth and follow industry best practices.

A flat rate of **US$0.5 per verification** applies, which is **around ⅓  of typical providers** charge, giving you a clear and transparent cost model.

We stand by the value of our offering and provide a price-match guarantee for equivalent services upon review of a valid quotation.

Drop us a line at <mark style="color:blue;"><contact@zk.me></mark> and let’s kick things off!


# Proof-of-Citizenship (PoC)

Delivers privacy-first identity verification with no unnecessary data exposure using Zero-Knowledge Proofs.

## User Journey

Alice wants to access a web3 platform that requires KYC. With zkMe, she verifies her citizenship and age without exposing any sensitive ID details. After a single verification, she receives a Proof-of-Citizenship credential in the form of a Soulbound Token (SBT) that contains a zero-knowledge proof. This token gives her access to multiple partner services, saving time and keeping her personal data private.

## See It in Action

Discover how users can verify their identity and get their zkPoC credential in just a few simple steps.

{% embed url="<https://www.youtube.com/watch?v=VsiTWr6errw>" %}

***

## Why zkMe zkPoC?

* **Privacy first:** Protect users' privacy with advanced cryptography technologies.
* **Decentralized:** No fixed or controlled role in zkMe zkKYC by a single entity.
* **Fulfill compliance requirement:** Meet global KYC requirements while minimizing intrusion.
* **Reusable zkKYC:** Users only need to be verified once to access multiple partnered services.
* **Full Security:** No personally identifiable information is stored in a central server, eliminating the risk of data leaks.
* **Seamless Integration:** Easily integrate your entire verification flow within seconds using our Web and Mobile SDK.

## How It Works

The Zero-Knowledge Proof-of-Citizenship (zkPoC) procedure verifies a user's citizenship without revealing sensitive personal data. It involves biometric checks, face matching, and document verification to ensure the user's authenticity and eliminate fraudulent activities. Here's a high-level overview of the procedure:

1. **Define Verification Criteria:**&#x20;
   * **Age Verification**: Specify the age range that qualifies for the verification process.
   * **Citizenship Coordinates**: Define the specific area or country within which you want to verify the user's citizenship.
   * **Accepted Identity Sources:** List of acceptable documents for citizenship proof (e.g., passport, national ID). zkMe also supports government-issued electronic identity (eID) systems, see [Supported eID Providers](/hub/what/zkkyc/zkpoc/supported-eid-providers) for the full list of accepted identity sources.&#x20;
2. **User Identity Verification:** The following describes the document-based verification flow. For eID-based verification, the user authenticates directly via the government's digital identity platform.
   * **Identity Document Check:** Verify the authenticity of the submitted Identity documents.

     <div data-gb-custom-block data-tag="hint" data-style="success" class="hint hint-success"><p><strong>Note:</strong> To mitigate AI-driven identity fraud, zkPoC leverages <a data-mention href="/pages/ZLerOKZiiLOaghojUycc">/pages/ZLerOKZiiLOaghojUycc</a>, a zkMe-native cryptographic trust primitive for verifying the chip-level authenticity of electronic passports. </p><p>For partners requiring direct ePassport-based zero-knowledge verification, <a href="https://docs.zk.me/hub/how/modules/smart-contracts#standalone-zkpassport-sdk">a standalone zkPassport SDK</a> is also available.</p></div>
   * **Liveness Checks**: Use the user's device camera to perform a liveness check to ensure the user is a real person and not a bot.
   * **Face Match**: Compare user faces to ensure the user’s face matches the photo on their submitted documents.
3. **Generate Random Number**: The user's device generates a random number as part of the zkPoC process.
4. &#x20;**Zero-Knowledge Proof (ZKP) Protocol:**
   * **Commitment Phase:** The user generates a cryptographic commitment. This commitment includes hashed information about their citizenship without revealing actual coordinates or sensitive data. And the commitment is securely stored on the user's device, ensuring it cannot be tampered with.
   * **Challenge Phase**: The verifier (the service or entity performing the verification) selects a random challenge to ensure the user's commitment is valid and sent to the user's device for processing.
   * **Response Generation**: The user’s device processes the challenge by combining it with the previously generated random number and the commitment, then sends the response back to the verifier.
   * **Response Validation**: The verifier checks the validity of the response and whether it satisfies the verification criteria, without gaining knowledge of the user's detailed personal information.
5. **Verification Result:** Based on the verification outcome, the verifier confirms the user's citizenship. If the verification is successful, the user is granted access to the next steps.

***

## Key Benefits

zkMe's zkPoC protocol is designed to fundamentally shift the paradigm of digital identity verification, moving from data extraction to trust minimization. The key benefits extend beyond privacy to create a more efficient and secure ecosystem for all participants.

* **Uncompromising User Privacy:** By leveraging Zero-Knowledge Proofs, we ensure that users can prove eligibility criteria (like age or citizenship) without ever revealing the underlying document details. This "data minimization" principle is baked directly into the protocol, ensuring personal data never leaves the user's device.
* **Enhanced Security & Reduced Risk:** The decentralized architecture eliminates centralized databases of sensitive personal information, which are prime targets for hackers. By storing only anonymized, tamper-proof SBTs on-chain, we significantly reduce the risk and liability associated with data breaches for both services and their users.
* **Regulatory Compliance by Design:** The protocol is built to fulfill global KYC/AML requirements while minimizing intrusion. Features like the `Certify` smart contract provide regulators with a necessary, auditable trail for investigations without forcing full personal data exposure during routine checks.
* **User-Centric Reusability:** The Soulbound Token (SBT) model empowers users. A single, one-time verification grants them a reusable credential that can be used across a growing ecosystem of partner services. This eliminates repetitive KYC checks, saving time and reducing friction.
* **Seamless Interoperability:** The protocol is designed for a multi-chain future. The Proof Delegation function allows users to seamlessly bridge their verified credential across different blockchain ecosystems, ensuring their digital identity is portable and not locked into a single platform.

## Use Cases to Benefit

The zkPoC protocol unlocks a new wave of privacy-preserving and compliant applications across Web3 and beyond.

* **Permissioned DeFi and Airdrops:** Decentralized Finance platforms can ensure regulatory compliance for lending, borrowing, or high-value transactions by requiring proof of citizenship or non-sanctioned status. Projects can conduct targeted, compliant airdrops to users from specific jurisdictions without learning their full identities.
* **Gated Content and Social Platforms:** Social media or content-streaming services can restrict access based on geographic licensing agreements. Users can prove they reside in an eligible country without submitting a copy of their utility bill or passport.
* **Age-Restricted Services & NFTs:** Platforms offering financial services, adult content, or age-gated experiences (e.g., VR worlds) can reliably verify a user is over 18 or 21, protecting minors and ensuring legal compliance without collecting birthdates or ID scans.
* **Decentralized Autonomous Organizations (DAOs):** DAOs can implement proof-of-personhood or proof-of-citizenship to prevent sybil attacks and ensure fair voting, guaranteeing that each vote comes from a unique, eligible individual without doxxing their members.
* **Enterprise and Supply Chain Onboarding:** Corporations can streamline the onboarding of contractors or verify the legal status of entities in a supply chain. Partners can prove their credentials and good standing while keeping sensitive corporate data confidential.

***

Pricing & Integration

From startups to scale-ups, our pricing and [simple integration](/hub/start/onboarding) are designed to support your growth and follow industry best practices.

A flat rate of **US$0.5 per verification** applies, which is **around ⅓  of typical providers** charge, giving you a clear and transparent cost model.

We stand by the value of our offering and provide a price-match guarantee for equivalent services upon review of a valid quotation.

Drop us a line at <mark style="color:blue;"><contact@zk.me></mark> and let’s kick things off!


# Supported eID Providers

Can't wait to get started? Skip to the Onboarding Checklist!

Beyond traditional identity document verification, zkMe supports government-issued electronic identity (eID) systems as trusted identity data sources. eID systems represent a fundamentally different verification model: instead of the user presenting a document for zkMe to verify, the user authenticates directly with their government's digital identity platform, and zkMe receives pre-verified identity attributes from the authoritative source.

## **Why eID Matters**

The global digital identity landscape is undergoing a structural shift. Governments worldwide are deploying national eID systems that allow citizens to authenticate online with the same legal authority as presenting a physical identity document in person. For identity verification providers, this creates an opportunity to anchor verification directly to sovereign digital infrastructure rather than relying on document images or even chip-based verification.

eID systems differ from ePassport-based verification in a critical way. An ePassport contains static data signed at the time of issuance. An eID system provides dynamic, real-time authentication against a government-maintained identity registry. This means eID verification can reflect current status, an expired passport is still readable via NFC, but an eID system can confirm whether the credential is currently valid.

For verifiers, integrating eID as an identity source offers several advantages. Verification is performed against the government's live system, not against a physical artifact. The identity assurance level is typically the highest available, as the enrollment process is managed by the government itself. And because eID authentication is a structured digital interaction, it is inherently resistant to the synthetic identity attacks that plague document-based verification.

## **The eID Landscape**

### **European Union: eIDAS 2.0 and the EU Digital Identity Wallet**

The European Union is implementing the most ambitious eID framework globally through the revised eIDAS regulation. eIDAS 2.0 mandates that every EU member state offer citizens a Digital Identity Wallet capable of storing and presenting government-issued identity credentials as verifiable credentials. These wallets will support cross-border recognition, meaning a credential issued by France can be verified by a service provider in Germany. The regulation requires member states to issue wallets by 2026, and the European Commission has published reference specifications (the Architecture and Reference Framework) that define interoperability requirements across all 27 member states.

For zkMe, the eIDAS 2.0 framework represents a significant opportunity. As EU Digital Identity Wallets become widely available, zkMe will be able to accept eID credentials directly from these wallets and issue zero-knowledge proof credentials based on the verified attributes. This combines the highest available identity assurance (government-issued, cross-border recognized) with zkMe's privacy-preserving architecture.

### **Hong Kong: iAM Smart**

iAM Smart is the Hong Kong SAR Government's digital identity platform, providing residents with a government-backed digital identity for online authentication and digital signing. The platform supports both personal identity authentication and legally binding digital signatures, and is widely used for government services and increasingly for private sector applications.

### **Singapore: SingPass / Myinfo**

Singapore's National Digital Identity framework provides citizens and residents with a unified digital identity through SingPass, with Myinfo serving as the government-verified personal data platform. Services can retrieve pre-verified identity attributes (name, identity number, date of birth, nationality, and more) directly from the government registry with the user's consent.

### **Additional Markets**

zkMe is actively evaluating and onboarding eID systems across additional jurisdictions. The expansion roadmap prioritizes markets where government eID infrastructure has reached sufficient maturity and adoption for practical integration.

For the latest list of supported eID providers and their status, contact us at <contact@zk.me>.

## **How eID Verification Works with zkMe**

The eID verification flow follows a different path from document-based or ePassport-based verification, but produces the same output: a zero-knowledge proof credential that verifiers can check without accessing the user's personal data.

* **Step 1:** The user initiates verification and selects their eID provider. zkMe redirects the user to the government's authentication platform.
* **Step 2:** The user authenticates using their eID credentials through the government platform's secure authentication flow. zkMe never sees or handles the user's eID credentials directly.
* **Step 3:** With the user's consent, verified identity attributes are returned from the eID provider to zkMe. The scope of attributes retrieved depends on the specific eID system and the verification requirements configured by the verifier.
* **Step 4:** zkMe processes the verified identity attributes and issues zero-knowledge proof credentials. The raw identity data is processed in memory and actively scrubbed after credential generation, consistent with zkMe's standard data handling across all identity sources.
* **Step 5:** The verifier checks the resulting ZKP credentials to confirm identity attributes (such as identity verified, age range, nationality, or residency) without accessing the user's underlying eID data.

## **eID vs. ePassport vs. Document Verification**

All three identity sources produce the same type of output within zkMe: a zero-knowledge proof credential. The difference lies in the trust model and user experience of each source.

Document verification infers authenticity from visual and structural features of identity documents. It is the most widely accessible method but carries the lowest assurance level, particularly as generative AI makes document forgery increasingly trivial.

ePassport verification (via [zkMe zkPassport](/hub/how-built/id-infra/zkpassport)) establishes authenticity through cryptographic signatures embedded in the passport's NFC chip, signed by the issuing country's national PKI. It provides strong cryptographic assurance but relies on static data signed at the time of passport issuance.

eID verification authenticates the user against a government's live digital identity infrastructure. It provides the highest assurance level and reflects current credential status, but availability is limited to jurisdictions with mature eID systems.

zkMe supports all three sources and allows verifiers to configure which sources they accept based on their compliance requirements and risk tolerance. Regardless of the source, the privacy guarantees are identical: only the minimum necessary information is disclosed to verifiers through zero-knowledge proofs.


# AML Check (zkAML)

Sanction, Watch, and Wanted List Checks, Politically Exposed Persons (PEP), and Adverse Media Checks.

## User Journey

Using zkMe zkAML, Alice undergoes a one-time verification where his identity is checked against global sanctions lists, Politically Exposed Persons (PEP) databases, and adverse media sources. Without revealing his personal identity or the specific results, he receives an AML-compliant credential as a Soulbound Token (SBT) that contains zero-knowledge proofs of his clearance status. This Credential allows him to seamlessly access multiple DeFi platforms and financial services that require AML verification, maintaining his privacy while proving regulatory compliance.

## See It in Action

{% hint style="info" %}
COMING SOON
{% endhint %}

## Why AML Checks

Anti-Money Laundering (AML) checks are critical regulatory requirements for financial institutions and increasingly for decentralized finance platforms. Traditional AML processes force users to disclose extensive personal information, creating privacy risks and central points of failure. zkMe zkAML transforms this paradigm by enabling necessary compliance checks while protecting user privacy through advanced cryptography, ensuring that platforms can meet regulatory obligations without compromising user security or creating honeypots of sensitive data.

## Why zkMe zkAML

* **Advanced Privacy Architecture**: Our zero-knowledge circuit design ensures that even the verification service cannot determine why a user passed or failed screening—only that they meet compliance criteria.
* **Decentralized Trust Model**: No single entity controls the AML verification process, eliminating central points of failure and preventing unauthorized access to sensitive screening data.
* **Comprehensive Coverage**: We integrate with leading global data providers for sanctions, PEP, and adverse media screening, ensuring thorough coverage while maintaining privacy.
* **Regulator-Friendly**: Provides necessary audit trails and compliance evidence for regulators without exposing individual user data, balancing privacy with regulatory requirements.
* **Seamless User Experience**: One-time verification grants access to multiple services, eliminating repetitive AML checks while maintaining continuous compliance monitoring.

## How It Works

The Zero-Knowledge AML (zkAML) procedure verifies a user's compliance status against global databases without exposing personal information. The system checks sanctions lists, PEP registries, and adverse media sources while generating cryptographic proofs of compliance.

#### Verification Process Flow:

1. **Identity Document Verification**
   * User submits government-issued ID through secure channels
   * Document authenticity is verified using advanced validation algorithms
   * Biometric matching ensures the user presenting the document is its legitimate owner
2. **Database Screening**
   * System checks user Identity against global sanctions lists (OFAC, UN, EU)
   * Screens for Politically Exposed Persons status across international registries
   * Scans for adverse media mentions and negative news indicators
   * All checks occur in a privacy-preserving environment
3. **Zero-Knowledge Proof Generation**
   * **Commitment Phase**: User's device generates cryptographic commitments representing AML status
   * **Challenge Phase**: Verifier issues random challenges to ensure proof validity
   * **Response Generation**: System processes challenges with user's random seed and commitment
   * **Validation**: Verifier confirms AML status without learning specific screening results
4. **Credential Issuance**
   * Successful verification generates an AML-compliant SBT
   * Credential contains ZKPs of compliance status without sensitive data
   * Token is stored in user's self-sovereign identity wallet for future use

## Key Benefits

* **Privacy-Preserving Compliance**: Verify AML status without exposing personal information or specific screening results
* **Global Regulatory Alignment**: Meets FATF, FinCEN, and international AML standards while maintaining user privacy
* **Reduced False Positives**: Advanced algorithms minimize incorrect flags while maintaining security
* **Real-time Monitoring**: Continuous screening with privacy-preserving status updates
* **Cross-Platform Interoperability**: Single verification works across multiple services and jurisdictions

## Use Cases to Benefit

* **DeFi Platform Compliance.** Decentralized exchanges and lending protocols can ensure regulatory compliance by verifying users' AML status without collecting or storing sensitive personal information, enabling permissioned DeFi services while preserving user privacy.
* **NFT Marketplace Verification**. High-value NFT marketplaces can screen participants against sanctions lists and PEP databases to prevent money laundering through digital assets, maintaining compliance without doxxing collectors.
* **Cross-Border Payments**. Remittance services and cross-border payment platforms can verify sender and receiver compliance status across jurisdictions while protecting financial privacy and meeting international AML standards.
* **Institutional Crypto Access**. Traditional financial institutions entering the crypto space can implement compliant onboarding processes that meet their existing AML obligations while adapting to web3 privacy expectations.
* **DAO Treasury Management**. Decentralized Autonomous Organizations can ensure compliant treasury management by screening transaction participants against global watchlists without exposing member identities.
* **Gaming and Metaverse Economies**. Play-to-earn games and metaverse platforms with significant economic activity can prevent money laundering through their ecosystems while maintaining user pseudonymity.

***

Pricing & Integration

From startups to scale-ups, our pricing and [simple integration](/hub/start/onboarding) are designed to support your growth and follow industry best practices.

A flat rate of **US$0.5 per verification** applies, which is **around ⅓  of typical providers** charge, giving you a clear and transparent cost model.

We stand by the value of our offering and provide a price-match guarantee for equivalent services upon review of a valid quotation.

Drop us a line at <mark style="color:blue;"><contact@zk.me></mark> and let’s kick things off!


# Proof-of-Location (PoL)

Provides privacy-first location verification through Zero-Knowledge Proofs, ensuring users meet geolocation criteria without revealing their exact whereabouts.

## User Journey

Alice wants to join an exclusive web3 campaign only available to users in specific regions. Using zkMe, he proves that he's physically located within the required area, without revealing his exact coordinates or address. After one-time verification, he receives a Proof-of-Location credential containing a zero-knowledge proof. This lets him access geo-restricted dApps and services, all while preserving his privacy.

## See It in Action

See how users can prove their location without sharing coordinates and generate a zkPoL credential in just a few simple steps.

{% embed url="<https://youtu.be/-BUlWnNGB7k>" %}

***

## Why Proof of Location

Proof of Location (PoL) has become increasingly critical in digital services as geographical restrictions and compliance requirements multiply. Traditional location verification methods force users to disclose exact GPS coordinates or IP addresses, creating significant privacy risks and potentially exposing sensitive personal data. Regulatory frameworks like GDPR in Europe, various national data protection laws, and geo-specific financial regulations require services to restrict access based on location while simultaneously protecting user privacy.&#x20;

## Why zkMe zkPoL?

* **Enhanced compliance:** Enforce geolocation requirements while preserving user inclusivity.
* **User privacy protection:** Validate user location with zero-knowledge proofs (ZKPs) without accessing or storing sensitive personal data.
* **Access to global liquidity:** Expand to permitted jurisdictions while staying compliant with local regulations.
* **Risk mitigation:** Reduce legal and regulatory risks by ensuring users comply with geographic restrictions and avoiding unauthorized access.
* **Regulatory adaptability:** Easily adjust geolocation parameters as regulations evolve, without relying on blanket bans or rigid restrictions.
* **Facilitates global expansion:** Support protocols in entering new markets with privacy-preserving compliance infrastructure.

## How It Works

The procedure of performing a zero-knowledge Proof-of-Location, or Zero-Knowledge Geolocation, involves a series of steps to verify a user's location within a specific area without disclosing their actual coordinates. Here's a high-level overview of the procedure:

1. **Define the Geofence Coordinates:** Clearly define the specific area within which you want to verify the user's location. This could be a polygon defined by a set of coordinates or a specific geographical boundary.
2. **Users Share Geolocation:** Users share their GPS information for the purpose of location verification.
3. **Generate Random Numbers:** The user's device generates a random number as part of the zkPoL process.
4. **Zero-Knowledge Proof (ZKP) protocol:**
   * **Commitment Phase:** The user generates a commitment that contains information about their location within the defined area, without revealing the actual coordinates. This commitment is typically computed using cryptographic techniques.
   * **Challenge Phase:** The verifier (the service or entity performing the geolocation verification) selects a random challenge and sends it to the user.
   * **Response Phase:** The user generates a response based on the challenge and their random number. This response is sent back to the verifier.
   * **Verification:** The verifier checks the validity of the response and whether it satisfies the geolocation verification criteria, without gaining knowledge of the user's actual coordinates.
5. **Verification Result:** Based on the verification outcome, the verifier can determine if the user is located within the defined area, without explicitly obtaining their real address or coordinates.

## Key Benefits

* **Privacy-First Location Verification**: Users can prove they're within a required geographical boundary without revealing their exact coordinates, address, or movement patterns, maintaining complete location privacy throughout the verification process.
* **Regulatory Compliance Without Compromise**: Services can enforce geographical restrictions required by licensing agreements, financial regulations, or content distribution rights while minimizing data collection and storage, reducing compliance overhead and liability.
* **Reduced Fraud and Sybil Attacks**: By cryptographically verifying physical location without revealing it, zkPoL prevents users from spoofing locations or creating multiple accounts across different regions, enhancing platform security and fairness.
* **Seamless Cross-Border User Experience**: Users can access geo-restricted services without cumbersome VPN detection, document submission, or repetitive verification processes, creating a frictionless experience while maintaining compliance.
* **Interoperable Location Credentials**: The location proof SBT can be reused across multiple services and platforms, eliminating the need for repeated location verification while maintaining the same privacy guarantees.
* **Cost-Effective Compliance Scaling**: Automated, privacy-preserving location verification reduces the need for manual review processes and expensive compliance infrastructure while adapting to changing regulatory requirements across jurisdictions.

## Use Cases to Benefit

* **DeFi and Financial Services Compliance**: Decentralized finance platforms can ensure compliance with securities regulations by verifying that users accessing certain financial products are located in permitted jurisdictions, without collecting and storing sensitive location data that could create regulatory liability.
* **Gaming and NFT Distribution**: Game developers and NFT projects can run region-specific campaigns, airdrops, or early access events while ensuring fair distribution and preventing users from spoofing locations to gain unfair advantages or access restricted content.
* **Content Licensing and Streaming Services**: Media platforms can enforce geographical content licensing restrictions by verifying user locations without building extensive location-tracking infrastructure or storing sensitive IP address data that could violate privacy regulations.
* **DAO Governance and Voting**: Decentralized organizations can implement location-based voting rights or governance participation requirements to ensure regional representation or comply with legal structures, without doxxing community members' physical locations.
* **Research and Data Collection**: Academic institutions and research organizations can verify that survey participants or data contributors are from specific regions required for study validity, while protecting participant privacy and ensuring ethical research practices.
* **Travel and Loyalty Programs**: Airlines, hotels, and travel services can offer location-based promotions and verify eligibility for regional offers without continuous location tracking, enhancing user trust while maintaining marketing effectiveness.
* **Regulated Market Access**: Cryptocurrency exchanges and trading platforms can seamlessly verify user eligibility for specific markets and products based on geographical regulations, enabling global operations while maintaining localized compliance.

***

Pricing & Integration

From startups to scale-ups, our pricing and [simple integration](/hub/start/onboarding) are designed to support your growth and follow industry best practices.

A flat rate of **US$0.5 per verification** applies, which is **around ⅓  of typical providers** charge, giving you a clear and transparent cost model.

We stand by the value of our offering and provide a price-match guarantee for equivalent services upon review of a valid quotation.

Drop us a line at <mark style="color:blue;"><contact@zk.me></mark> and let’s kick things off!


# Proof-of-Address (PoA)

Offers privacy-first address verification through Zero-Knowledge Proofs, ensuring users meet jurisdictional requirements without exposing their full address details.

## User Journey

Alice wants to access a platform that requires confirmation of her country of residence for compliance. With zkMe, she proves her actual residential address by scanning a recent bank statement, utility bill, lease agreement, or tax notice. The zkMe widget validates the document type, checks that it was issued within the last 90 days, and confirms her home jurisdiction without exposing plaintext details. After this one-time verification, she receives a Proof-of-Address credential in the form of a Soulbound Token (SBT) containing a zero-knowledge proof, which she can reuse across multiple services that require proof of living address while keeping her sensitive information private.

## See It in Action

See how users can prove their location without sharing coordinates and generate a zkPoA credential in just a few simple steps.

{% embed url="<https://www.youtube.com/watch?v=mIXyosCn7B0>" %}

***

## **Why Verify Residence?**

Proof-of-Address (PoA) is a cornerstone of global Anti-Money Laundering (AML) and Know Your Customer (KYC) regulations. Financial institutions, crypto platforms, and other regulated services are legally required to verify a customer's residential address to assess risk, prevent fraud, and ensure compliance with jurisdictional laws. Traditional PoA verification forces users to repeatedly upload sensitive documents like bank statements or utility bills, creating massive privacy risks and friction. zkMe's zkPoA transforms this necessary compliance step into a privacy-preserving and user-centric process, enabling trust and compliance without the data liability.

## Why zkMe zkPoA?

* **Privacy first:** Validate user’s residential address with zero-knowledge proofs (ZKPs) without exposing or storing sensitive documents.
* **Reliable verification:** Confirm address using trusted sources (e.g., utility bills, bank statements, tax notices) with built-in cryptographic assurance.
* **Compliance-ready:** Satisfy global AML/KYC requirements for address verification, ensuring alignment with jurisdictional regulations.
* **Reusable within validity:** Once issued, zkPoA credentials are reusable across multiple platforms for the entire duration of their validity, eliminating redundant verification steps.
* **Decentralized & Secure:** Proofs are generated and verified without central storage of raw address data, eliminating the risk of leaks.
* **Seamless integration:** Easily embed zkPoA into onboarding or transaction flows using our SDKs for instant, compliant address checks.

## How It Works

The Zero-Knowledge Proof-of-Address (zkPoA) procedure verifies a user’s residential address without exposing sensitive personal data. It validates documents, checks recency, and confirms eligibility, all while preserving user privacy. Here’s a high-level overview of the procedure:

1. **Define Verification Criteria:**&#x20;
   * **Jurisdiction Policy:** Define allowlists or denylists of countries/regions to enforce compliance.
   * **Address Proof Requirements:** Specify which document types are acceptable (i.e., Bank Statement, Utility Bill, Lease Agreement, Tax Notice, Government Document, Employer Certificate).
2. **User Document Verification & Data Extraction:**
   * **Authenticity Check:** Confirm that the uploaded document is valid and untampered.
   * **OCR Extraction**: Extract key fields including full name, residential address (street, city, region, country), document type, and issue date.
   * **Recency Validation**: Check that the extracted issue date is within the last 90 days.
   * **Identity Matching**: Validate that the extracted name matches prior KYC records through secure hash comparison.
   * **Address Validation**: Confirm that the extracted address is properly formatted, mailable, and corresponds to a valid location.
3. **(Optional) Location Cross-Check:** Confirm that the user’s current GPS country matches the document’s country through Proof of Location programs.
4. **Generate Random Number**: The user's device generates a random number as part of the zkPoA process.
5. &#x20;**Zero-Knowledge Proof (ZKP) Protocol:**
   * **Commitment Phase:** The user generates a cryptographic commitment. This commitment includes hashed information that encodes proof of address validity without revealing the raw address. And the commitment is securely stored on the user's device, ensuring it cannot be tampered with.
   * **Challenge Phase**: The verifier (the service or entity performing the verification) selects a random challenge to ensure the user's commitment is valid and sent to the user's device for processing.
   * **Response Generation**: The user’s device processes the challenge by combining it with the previously generated random number and the commitment, then sends the response back to the verifier.
   * **Response Validation**: The verifier checks the proof against the defined criteria, ensuring compliance without accessing plaintext details.
6. **Verification Result:** Based on the verification outcome, the verifier confirms the user's eligibility. If the verification is successful, the user is granted access to the next steps.

## **Key Benefits**

* **Uncompromising Document Privacy:** Users prove their address validity without exposing the actual documents. Sensitive details like account numbers, transaction history, and exact street addresses remain confidential on the user's device.
* **Streamlined User Onboarding:** Eliminate the friction of repeated document submissions. A single, one-time verification grants a reusable credential that speeds up onboarding across multiple services.
* **Robust Fraud Prevention:** The combination of document authenticity checks, recency validation (within 90 days), and optional location cross-checks creates a strong defense against forged documents and fraudulent applications.
* **Regulatory Compliance by Design:** The protocol is built to satisfy AML/KYC requirements for address verification across multiple jurisdictions, providing the necessary audit trail for regulators without exposing personal data.
* **Reduced Operational Cost:** Automate the address verification process, minimizing the need for manual review and the associated costs of maintaining secure document storage systems.

## **Use Cases to Benefit**

* **DeFi and CeFi Onboarding:** Cryptocurrency exchanges and decentralized finance platforms can seamlessly comply with "Know Your Customer" and "Address Verification" regulations for users accessing high-value transactions or specific financial products.
* **High-Value Goods and NFT Purchases:** Marketplaces for luxury goods, real estate, or high-value NFTs can verify a buyer's jurisdiction for regulatory and shipping purposes without handling sensitive customer documents.
* **Banking and Financial Services:** Traditional banks and fintech companies can streamline account opening processes, offering a modern, privacy-focused alternative to cumbersome document uploads for new and existing customers.
* **Government and Public Services:** Enable citizens to prove their residency for access to localized public services, voting eligibility, or benefit programs while significantly reducing administrative overhead and data breach risks.
* **Telecommunications and Utilities:** Simplify the sign-up process for new services (internet, mobile contracts, energy) where proof of residence is required, using a credential that is instantly verifiable and highly secure.
* **Global Payroll and Gig Economies:** Companies with a distributed, international workforce can verify the country of residence for contractors for tax and compliance purposes in a privacy-preserving manner.

***

Pricing & Integration

From startups to scale-ups, our pricing and [simple integration](/hub/start/onboarding) are designed to support your growth and follow industry best practices.

A flat rate of **US$0.5 per verification** applies, which is **around ⅓  of typical providers** charge, giving you a clear and transparent cost model.

We stand by the value of our offering and provide a price-match guarantee for equivalent services upon review of a valid quotation.

Drop us a line at <mark style="color:blue;"><contact@zk.me></mark> and let’s kick things off!


# Regulatory Frameworks

The regulatory framework for KYC/AML compliance in web3 is still developing. Some countries have started to implement regulations specific to web3 technologies, while others have issued guidance or are in the process of developing regulations.\
\
Here is a deeper dive into some selected regulatory frameworks:

<table data-view="cards"><thead><tr><th></th><th></th><th data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>EU</strong></td><td>The European Commission has passed regulations (MiCA, TRF and AMLD7) requiring all Virtual Asset Service Providers (VASPs) to undergo customer due diligence and comply with Financial Action Task Force (FATF) requirements.</td><td><a href="/pages/K35IUEgNFkgBdByB5kuz">/pages/K35IUEgNFkgBdByB5kuz</a></td></tr><tr><td><strong>USA</strong></td><td>In the United States, the Securities and Exchange Commission (SEC) and the Commodity Futures Trading Commission (CFTC) have issued guidance and proposed bills related to digital assets and web3 technologies.</td><td><a href="/pages/6BW7p3BWQxVtULSI1dVW">/pages/6BW7p3BWQxVtULSI1dVW</a></td></tr><tr><td><strong>UK</strong></td><td></td><td><a href="/pages/K72cIei4V4LXf2U04iPZ">/pages/K72cIei4V4LXf2U04iPZ</a></td></tr></tbody></table>

Other countries and regions, such as Switzerland, the United Kingdom, Hong Kong, Singapore, and Japan, have implemented or are planning to implement regulations specific to web3.


# EU - MiCA/TFR Regulations

The European Union has enacted a new law called the Markets in Crypto-Assets (MiCA) regulations, which aims to make Europe a hub for digital assets. The law was drafted in 2020, passed by the European Parliament in April, and officially signed into law on May 31, 2023. The law defines a crypto asset and provides guidelines for crypto asset service providers (CASPs) and crypto asset issuers, requiring them to adhere to certain standards and regulations, such as Anti-Money Laundering rules.

MiCA establishes CASPs as separate legal entities that can obtain a license in any of the 27 EU member states. Stablecoin service providers are required to provide a white paper containing key details about the product and the key players involved. The law, however, does not cover nonfungible tokens (NFTs) or central bank-issued digital assets.

The law is considered a significant step forward for the crypto community, providing a uniform framework for all EU member states. It is hoped that the rest of the world will take note and consider adopting similar regulations. With the clarity that MiCA provides, Europe is positioned to become a more dominant player in the global crypto scene.

## What are the key requirements for crypto service providers under the MiCA regulations?

The Markets in Crypto-Assets (MiCA) regulations set forth several key requirements for crypto asset service providers (CASPs) within the European Union:

**Legal Status**: CASPs are established as separate legal entities under MiCA. This means that a CASP must be a legally recognized entity within one of the 27 EU member states.

**Licensing**: CASPs can obtain a license from any of the 27 EU member states. Once licensed, they're authorized to conduct business in the region.

**Security Measures**: CASPs are required to adopt certain security measures to protect the assets they handle and to ensure the integrity of their operations.

**Anti-Money Laundering (AML) Compliance**: CASPs must adhere to established Anti-Money Laundering regulations. These measures are designed to prevent the use of cryptocurrencies for illegal activities, such as money laundering or financing terrorism.

**Market Manipulation and Abuse**: Service providers must have measures in place that prevent market manipulation and abuse. This includes monitoring transactions and reporting suspicious activities to relevant authorities.

**Regulatory Supervision**: CASPs will be under the supervision of regulatory authorities, such as the European Banking Authority. This ensures they comply with the regulations and maintain the required standards.

**Disclosure and Transparency**: CASPs are required to provide complete and transparent information about the crypto assets they handle. This can include details about the asset's issuance, its nature, the rights it confers, and any associated risks.

**Stablecoin Rules**: For CASPs dealing with stablecoins, a white paper detailing key aspects of the product, the involved parties, terms of the public offer, blockchain verification mechanism, rights associated with the crypto assets, and the main risks for investors, among other details, must be provided.

<br>


# US - Crypto Regulations

The US regulatory framework for cryptocurrencies is complex and still developing. Companies in this space need to stay updated with the latest developments and be ready to adapt to changes. A verification solution is crucial for compliance with regulations and preventing illegal activities.

**US Crypto Regulation Landscape**: The US is still in the process of creating an efficient set of digital asset regulations. The regulatory landscape is complex due to the involvement of multiple regulators with overlapping responsibilities.

**Regulators**: The main federal institutions regulating digital assets in the US include the Financial Crimes Enforcement Network (FinCEN), the Securities and Exchange Commission (SEC), and the Commodity Futures Trading Commission (CFTC). The specific regulator involved depends on whether a digital asset is classified as a money transmitter, security, or commodity/derivative.

**Who is Affected?**: Regulations apply to entities defined as "financial institutions" under the Bank Secrecy Act (BSA), which includes money services businesses, securities brokers/dealers, futures commission merchants, introducing brokers in commodities, and mutual funds. Several business models involving the transmission of digital assets are also considered regulated under certain circumstances.

**Regulations**: The Bank Secrecy Act, the US Patriot Act, and the Anti-Money Laundering Act provide the framework for regulation. There are also registration requirements under the Commodity Exchange Act and Securities Exchange Act for assets considered securities and commodities.

**Crypto Mining**: Mining cryptocurrency is legal in all US states, but some states may impose limits due to environmental concerns. For example, New York state introduced a temporary two-year moratorium on certain types of crypto mining.

**Compliance**: Companies dealing with digital currencies must comply with the BSA and be registered with FinCEN, SEC, and CFTC, depending on the nature of the assets. They also need to follow state-level regulations. In addition, companies must establish an Anti-Money Laundering (AML) program, a Customer Identification Program (CIP), and satisfy recordkeeping and reporting requirements.

**State Differences**: Each US state might have its own regulations and licensing procedures for digital assets, although cryptocurrencies are legal in all states.

## ZKP in DeFi

> Zero-knowledge proofs can also enable a DeFi service user to confirm that their identity has been verified without revealing personal information.

— [Illicit Finance Risk Assessment of Decentralized Finance](https://home.treasury.gov/system/files/136/DeFi-Risk-Full-Review.pdf), U.S. department of the treasury, April, 2023

> The [report](https://home.treasury.gov/system/files/136/DeFi-Risk-Full-Review.pdf), authored by the Treasury Department, pointed to the growing use of cryptocurrency to pay for goods and services as a threat to government attempts to limit money laundering and the financing of terrorism. Among a series of recommendations to prevent money laundering via crypto, one example was buried deep within the report: privacy-enhancing tech.
>
> The authors wrote that “the U.S. government supports privacy enhancing technologies that simultaneously allow for or even promote compliance with AML/CFT obligations.” Still, it noted that “the use of non-public blockchains” by non-compliant entities “will heighten AML/CFT risks.”
>
> Several pages later, the report notes that zero-knowledge proofs can be used to verify that someone has passed an anti-money laundering check without harvesting or broadcasting their personal information.

— [Treasury: ZK Proofs Can Be Boon Or Bane Of AML Compliance](https://thedefiant.io/treasury-defi-report), The Defiant, Aleksandar Gilbert April 07, 2023


# UK - Crypto Regulations

### Who is the regulator? <a href="#one" id="one"></a>

The Financial Conduct Authority (FCA) is the main financial regulator in the UK. It regulates crypto asset providers to ensure that they implement effective Anti-Money Laundering and Countering Terrorism Financing (AML/CFT) policies and procedures.

The FCA maintains a register of crypto asset providers that fall under UK money laundering regulations (MLR 2017 with amendments) and issues guidelines. When it comes to assets, security tokens are the only ones regulated by the [FCA](https://www.gov.uk/government/publications/economic-crime-and-corporate-transparency-bill-2022-factsheets/fact-sheet-cryptoassets-technical).

Other UK institutions that regulate crypto include:

* HM Treasury
* The Bank of England

### What are the main regulations? <a href="#two" id="two"></a>

Crypto companies in the UK must comply with the following to meet AML/CFT requirements:

* [The Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017](https://www.legislation.gov.uk/uksi/2017/692/), or simply MLR, which is the main regulation that outlines all the AML requirements and registration requirements. It has been amended several times since its original publication to [implement](https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/860279/Money_Laundering_and_Terrorist_Financing__Amendment__Regulations_2019.pdf) the EU’s AMLD5 in 2019 and [the Travel Rule in 2022](https://www.legislation.gov.uk/uksi/2022/860/contents/made).

Depending on the nature and type of assets a crypto firm deals with, the following laws and regulations can also apply:

* The Financial Services and Markets Act 2000 (“FSMA”) and the Financial Services and Markets Act 2000 (Regulated Activities) Order 2001 (“RAO”)
* Electronic Money Regulations 2011 (“EMRs”) or the Payment Services Regulations 2017 (“PSRs”)

### Who is affected? <a href="#three" id="three"></a>

Affected companies can be separated into two types, according to the MLR 2017 and its amendments. The first are “crypto asset service providers,” which include companies that conduct either of the following:&#x20;

* “Exchanging, or arranging or making arrangements with a view to the exchange of, crypto assets for money or money for crypto assets,
* Exchanging, or arranging or making arrangements with a view to the exchange of, one crypto asset for another, or
* Operating a machine which utilizes automated processes to exchange crypto assets for money or money for crypto assets.”

The second are “custodian wallet providers,” which provide services to safeguard and/or administer crypto assets—or private cryptographic keys for holding, storing, or transferring crypto assets—on behalf of customers.&#x20;

### Who needs to register with the FCA?  <a href="#four" id="four"></a>

Companies that deal with security tokens must register with the FCA because they are considered “regulated tokens”. Meanwhile, companies that deal with exchange and utility tokens do not have to register.&#x20;

### How to register with the FCA <a href="#five" id="five"></a>

Before registering with the FCA, companies should answer the [following questions](https://www.fca.org.uk/publication/documents/cryptoasset-registration-flowchart.pdf):&#x20;

* Does the company advertise or act in a way that suggests it’s providing crypto asset services by way of business?&#x20;
* Does the company receive direct or indirect benefit from this service?
* How significant is the activity to the business’ other activities (crypto asset activities may be only part of the business)?
* Does the frequency of the activity suggest that it is being carried on as a business?
* Does the company have a registered or head office in the UK\* and does the company carry on day-to-day management of these activities from this office, irrespective of where, geographically, the crypto asset activity is conducted?
* Does the company operate one or more ATMs in the UK?
* Does the company have any UK presence that is engaged in or facilitates crypto asset activities?

\*If there is no UK office or other activity in the UK, beyond having a client in the UK, the FCA is likely to consider that the company is not conducting UK business.

If a company answers positively to some of these questions, then registration with the FCA is likely to be required.&#x20;

The full requirements for registration can be found on the [FCA website](https://www.fca.org.uk/firms/cryptoassets-aml-ctf-regime/registering).&#x20;

### AML requirements <a href="#six" id="six"></a>

Companies should take AML requirements very seriously, as failure to comply may lead to severe penalties.&#x20;

To stay compliant with the AML requirements introduced in the MLRs in 2017, companies have to implement a clear set of procedures. This includes at least the following:

* Appointing a Money Laundering Reporting Officer (MLRO)
* Staff training
* Risk assessment
* Conducting Customer Due Diligence (CDD), Simplified Due Diligence (SDD) and Enhanced Due Diligence (EDD)&#x20;
* Screening for persons on sanction lists, Politically Exposed Persons (PEPs) lists
* Transaction monitoring
* Ongoing monitoring of customer behavior and transactions
* Recordkeeping for at least five years from the date of the end of a business relationship or final transaction
* Reporting suspicious activity to the National Crime Agency

At the onboarding stage (KYC), at least the following information should be collected from users for verification:

* Full name
* Birth date
* Address

As a rule, such data is collected from government-issued documents. Proof of address documents can include current bank statements or credit/debit card statements issued by a regulated financial sector firm in the UK, in addition to utility bills.&#x20;

### UK Crypto Travel Rule <a href="#seven" id="seven"></a>

The UK recently has adopted the Travel Rule requirement to its regulation of crypto asset service providers. The Travel Rule requires crypto companies to obtain information from the sender and receiver of crypto assets and share it with counterparty crypto asset service providers. The requirement comes into force on September 1, 2023.

Suggested read: [What is the FATF Travel Rule? The Ultimate Guide to Compliance (2023)](https://sumsub.com/blog/what-is-the-fatf-travel-rule/)

[The Money Laundering and Terrorist Financing (Amendment) (No. 2) Regulation 2022](https://www.legislation.gov.uk/uksi/2022/860/regulation/5/made) is the key law explaining the specifics of the Travel Rule in the UK.  There is no information regarding the de minimis threshold, which means that certain  information should be transferred regardless of the transaction amount.&#x20;

For certain transactions equal or exceeding 1,000 euros, there are some additional requirements. This includes international transfers as well as transactions involving unhosted wallets.&#x20;

As a rule, VASPs (cryptoasset exchange providers and a custodian wallet providers in the UK) have to take the following steps to comply with the Travel Rule:

1\) In respect of an inter-cryptoasset business transfer, the originating VASP must ensure that the transfer is accompanied by the following information:&#x20;

1. the name of the originator and the beneficiary
2. if the originator or beneficiary is a firm, the registered name of the originator or beneficiary (as the case may be), or if there is no registered name, the trading name
3. the account number of the originator and the beneficiary, or if there is no account number, the unique transaction identifier.

If the beneficiary VASP request additional information about the sender, the originating VASP should also transfer the following information within 3 days, provided each VASP is conducting business in the United Kingdom:

(a) if the originator is a firm—

* the customer identification number or
* the address of the originator’s registered office, or, if there is none, its principal place of business
* if the originator is an individual, one of the following—
* the customer identification number
* the individual’s address
* the individual’s birth certificate number, passport number, or national identity card number
* the individual’s date and place of birth.

If a VASPs is carrying out business outside the United Kingdom and the transaction is equal to or exceeding 1,000 euros in value, the originating VASP should ensure that the transfer is accompanied by all the information specified in paragraph 1 (clauses a, b, c + a or b). &#x20;

2\) Information relating to the originator must be verified by the originating VASP using documents or a reliable source independent of the person whose identity is being verified.&#x20;

3\) When a Beneficiary VASP receives a crypto-asset as part of an inter-cryptoasset business transfer it must, before making the crypto-asset available to the beneficiary, check whether —

(a) it has received the information required by regulation to be provided; and

(b) the information relating to the beneficiary corresponds with information verified by it during customer due diligence.

4\) Where the Beneficiary VASP becomes aware that any information required by regulation to be provided is missing or does not correspond with information verified by it, it  must—

* request that the originating VASP provides the missing information;
* consider whether to make enquiries as to any discrepancy between information received and information verified during the CDD process; and
* where the Beneficiary VASP becomes aware that any information required to be provided is missing or does not correspond with information verified during customer due diligence, it must consider whether—

(i)to delay making the cryptoasset available to the beneficiary until the information is received or any discrepancy is resolved; and

(ii)if the information is not received or if any discrepancy is not resolved within a reasonable time, to return the cryptoasset to the cryptoasset business of the originator.

5\) The beneficiary VASP must report repeated failure by a crypto-asset business to provide any information required as well as any steps the crypto-asset business of the beneficiary has taken in respect of such failures to the FCA.

6\) A crypto-asset business must respond fully and without delay to a request in writing from a law enforcement authority for any information in connection to these requirements.

Please check out [Sumsub’s Travel Rule guide](https://help.sumsub.com/products/united-kingdom) for the requirements in relation to the transfers with unhosted wallets and any further details.

### The future of crypto regulations in the UK <a href="#eight" id="eight"></a>

For the last several years, the UK has been working towards a more regulated crypto industry. The country’s latest [plans were announced](https://www.gov.uk/government/news/uk-sets-out-plans-to-regulate-crypto-and-protect-consumers) in February 2023, including:

* Strengthening rules for crypto trading platforms
* Creating a world-first regime for crypto lending
* Implementing new rules to protect customers from market manipulation (e.g., pump and dump schemes)

According to the “Future Financial Services Regime for Crypto Assets” [Consultation document](https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/1133404/TR_Privacy_edits_Future_financial_services_regulatory_regime_for_cryptoassets_vP.pdf), the UK plans to widen the scope of regulated crypto activities, including activities with stablecoins. This includes:&#x20;

* Issuance&#x20;
* Payment&#x20;
* Exchange&#x20;
* Investment and risk management&#x20;
* Lending, borrowing, and leverage&#x20;
* Safeguarding and/or administration&#x20;
* Validation and governance&#x20;

The proposed regulatory regimes will be divided into phases. To learn more, you can read pages 27-28 [here](https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/1133404/TR_Privacy_edits_Future_financial_services_regulatory_regime_for_cryptoassets_vP.pdf).&#x20;

The “Future Financial Services Regime for Crypto Assets” also specifies a primary aim to expand “specified investment”.

Moreover, the HM Treasury now proposes to monitor crypto asset activities in the United Kingdom. This would monitor activities provided by UK firms to persons based in the UK or overseas (natural and legal), as well as those provided by overseas firms to UK persons (natural or legal).&#x20;


# zkOBS - Open Banking Services

{% hint style="success" %}
Can't wait to get started? Skip to the [Onboarding Checklist](/hub/start/onboarding)!
{% endhint %}

***

zkMe’s [zkTLS](/hub/how-built/id-infra/zktls) capability enables users and their AI agents to bring personal financial data such as credit scores, account assets, and transaction history to the chain, without exposing raw credentials or account passwords. Web3 protocols can then use this data to create tailored features that meet users’ needs and preferences. For instance, a DeFi protocol can determine loan eligibility based on Credit Scores, while an AI agent can optimize yield allocation based on verified account assets. With zkMe’s Identity Oracle, a more personalized and efficient digital world is made possible for each user.

## Credentials for Open Banking Verification

<table><thead><tr><th width="121.533203125">Category</th><th width="315.81640625">Credentials</th><th>Description</th></tr></thead><tbody><tr><td>Credit <br>Worthiness</td><td><a data-mention href="/pages/koKanHV5CK5lndXRF6Jl">/pages/koKanHV5CK5lndXRF6Jl</a></td><td>• Credit Score</td></tr><tr><td>Investor Qualification</td><td><a data-mention href="/pages/ISnbFDDn6mz9QfWAF2c8">/pages/ISnbFDDn6mz9QfWAF2c8</a></td><td><p>• Income last 2 years</p><p>• Tax Report</p></td></tr><tr><td>Account<br>Ownership</td><td><a data-mention href="/pages/naTQ41oxGiEDE3gNwsFy">/pages/naTQ41oxGiEDE3gNwsFy</a></td><td><p>• Brokerage Account Ownership</p><p>• Bank Account Ownership</p></td></tr><tr><td>Account <br>Assets</td><td><a data-mention href="/pages/kqlLCNAMGmHKukcaY0eT">/pages/kqlLCNAMGmHKukcaY0eT</a></td><td><p>• Brokerage Account Assets</p><p>• Bank Account Assets</p></td></tr><tr><td>Account<br>Transactions</td><td><a data-mention href="/pages/jssvehU8o9p1p8AnXy8R">/pages/jssvehU8o9p1p8AnXy8R</a></td><td><p>• Brokerage Account Transactions</p><p>• Bank Account Transactions</p></td></tr></tbody></table>

Want to explore more use cases? Check out our other credential suites at [Catalog - All Credentials](/hub/what/catalog).

## Key Benefits

Build more secure, privacy-preserving, and trustworthy protocols with zkMe.

### **Trusted identity data**

* Unlocks richer protocol functionality by enabling identity-based logic.
* Enables **computational trust** for people-powered networks: identity attributes can be issued as claims and composed into verifiable proofs.
* Facilitates reputation systems without exposing sensitive identity details.

### **Protect users' privacy**

* Identity reputation can be cryptographically verified on-chain in a privacy-preserving way, enabling trustless execution without revealing raw data.
* Eliminates the need for intermediaries, users interact directly with smart contracts.
* Supports privacy-preserving validation with smart contracts or NFTs, maintaining composability while protecting personal information.

## **Why choose zkMe?**

* **Private-by-Design:** Built with zero-knowledge proofs at its core to ensure maximum privacy for users and protocols.
* **Reliable:** Proven technology used across production environments and trusted by industry leaders.
* **Multi-chain Support:** Compatible with EVM, SVM, Move, and Cosmos ecosystems, enabling true interoperability.
* **Seamless API Integration:** Instantly connects to any Web2 or Web3 data source via flexible and modular APIs.
* **Scalable:** Designed to handle millions of verifications with low latency and minimal cost.

## How does it work?

zkMe transforms sensitive off-chain data through [zkTLS](/hub/how-built/id-infra/zktls) into verifiable zero-knowledge credentials that can be used across chains and dApps. The process happens entirely client-side, ensuring that no personal data is ever exposed or stored.

zkTLS works by intercepting the TLS session between the user’s device and a web server (e.g., a bank or credit bureau), generating a cryptographic proof that specific data was returned by that server at a specific time, without revealing any other data in the session. This means an AI agent or user can prove “my credit score is above 700” or “I hold more than $10,000 in this brokerage account” without ever sharing their login credentials or raw account data with any third party.

1. **User retrieves data** from a source (e.g. CreditKarma, Discord, Steam, a bank portal)
2. **zkTLS proof is generated** locally on the user’s device
3. **Credential is issued** on-chain as a verifiable SBT or off-chain claim
4. **Protocols verify** the claim without ever seeing the raw data

## zkMe Web Data Attestation Use Cases

* **Undercollateralized Lending:** Develop a credit scoring system for decentralized finance applications. This system could allow individuals to obtain credit loans without the need for traditional credit checks or collateral.
* **Agent-Driven Financial Management:** AI agents managing investments, cash flow optimization, or yield strategies on behalf of users can use zkOBS credentials to prove their principal’s financial standing to DeFi protocols, lenders, and counterparties, without ever accessing raw account data.
* **Self-Sovereign Social Media:** Enable trustless interactions between users, as no party needs to rely on a central authority to verify the other’s claims. This promotes a more secure and decentralized environment.
* **Private DAO Management:** Allow DAO members to cast their votes without revealing their identity or choice, maintaining the privacy of voters while still ensuring the integrity of the voting process. This can lead to more honest and unbiased voting outcomes. Enable domain-expertise reputation systems in DAOs. Members can prove their expertise in a particular domain without revealing their full identity. DAOs can implement merit-based governance models, where members with proven expertise in specific areas have more influence over decision-making.
* **Cross-Game Status:** Enable players to prove their gaming status, such as level, achievements, or rank, without revealing their identity or additional information. This protects player privacy and ensures that sensitive data remains secure while interacting with in-game economies or other players.
* **Secure Asset Ownership:** Establish the ownership of in-game assets, like non-fungible tokens, without exposing the owner’s identity. Players can prove they own specific assets without revealing their account details, thus maintaining privacy and reducing the risk of targeted attacks or theft.
* **Trustless Trading and Marketplace:** Facilitate trustless trading of in-game assets and currencies in decentralized marketplaces. Buyers and sellers can prove the authenticity and ownership of assets without revealing their identity, enabling secure and private transactions.
* **Skill-Based Earnings:** Reward users based on their skills or achievements. zkMe Identity Oracle can help verify players’ gaming status without compromising their privacy. Players can prove they have reached certain milestones or possess specific skills to access rewards and opportunities, all while keeping their personal information secure.


# Proof-of-Credit Score (PCS)

Powers secure and private verification of real-world credit scores without compromising identity or financial privacy.

## User Journey

Alice wants to join a DeFi lending platform that requires users to meet a minimum credit score level. With zkMe's [zkTLS](/hub/how-built/id-infra/zktls) capability, he proves his credit score in real-world meets the requirement without revealing his full report or any financial details. After a one-time verification, he receives a zkCredit Score credential as a Soulbound Token (SBT), which can be used across multiple protocols to access credit-based services while keeping his identity and financial data private.

## See It in Action

Watch how users prove they meet credit requirements while keeping their financial detail private.

{% hint style="success" %} <mark style="color:green;">**DEMO VIDEO IS COMING SOON**</mark>
{% endhint %}

***

## **Why Credit Score Checks**

Financial institutions and increasingly, DeFi platforms, must ensure that their services are not exploited. Credit Scores allow platforms to verify that a user meets both creditworthiness *and* compliance standards. This dual verification ensures that platforms can offer sophisticated financial products like undercollateralized lending while fulfilling their regulatory obligations, all without forcing users to disclose their sensitive financial history.

## Why zkMe zkCredit Score?

* **Privacy first**: Leverage zero-knowledge proofs and [zkTLS](/hub/how-built/id-infra/zktls) to verify credit scores without exposing sensitive financial or identity information.
* **User-centric reputation:** Validate creditworthiness using reliable, off-chain credit score data from established providers.
* **User-centric reputation:** Built to give users ownership of their financial reputation, enabling trust in decentralized ecosystems.
* **Fully reusable:** Once verified, users can reuse their zkCredit Score credential across ecosystems without repeating the verification process.
* **Decentralized & Secure:** Sensitive credit data remains off-chain—only cryptographic proofs are shared, preserving privacy and minimizing risk.
* **Plug-and-play:**  Easily integrate zkCredit Score into your platform using our SDKs to enable secure, privacy-preserving credit verification in minutes.

## How It Works?

The zkCredit Score procedure enables privacy-preserving verification of a user's real-world credit score without revealing sensitive financial or identity data. It leverages trusted credit data sources and zkTLS to validate score authenticity while preventing fraud or manipulation. Here's a high-level overview of the procedure:

1. **Credit Score Verification Flow:**
   * **Generate QR Code:** The zkMe widget generates a unique QR code for income verification.
   * **Scan via Mobile Device:** Users scan the QR code using their mobile devices.
   * **Redirect to Portal:** Upon scanning, users are automatically redirected to the zkTLS interface via an Instant App, App Clip, or Native App.
   * **Login:** Users follow on-screen instructions to log in via the designated method provided by the trusted credit data provider.
   * **Authorize Data Sharing:** After logging in, users will see a *"Share Data"* button. By clicking it, they authorize the system to proceed.
   * **Automated Data Retrieval:** The system automatically extracts key credit score required for following ZKP generation. No raw data is exposed during the process.
   * **Score Rating & Classification:** After retrieving the credit data, the system classifies the user's credit score based on FICO score tiers. This classification result is then used to generate a ZKP, representing the user's score rating in a privacy-preserving format.

     <figure><img src="/files/Yi5Q8f8qMctJ4YG7tSHe" alt="" width="563"><figcaption><p>FICO Credit Score Range</p></figcaption></figure>
2. **Generate Random Numbers:** The user's device generates a random number as part of the zkCredit Score process.
3. **Zero-Knowledge Proof (ZKP) protocol:**
   * **Commitment Phase:** The user generates a cryptographic commitment. This commitment includes hashed information about income without revealing actual coordinates or sensitive data. And the commitment is securely stored on the user's device, ensuring it cannot be tampered with.
   * **Challenge Phase**: The verifier (the service or entity performing the verification) selects a random challenge to ensure the user's commitment is valid and sent to the user's device for processing.
   * **Response Generation**: The user’s device processes the challenge by combining it with the previously generated random number and the commitment, then sends the response back to the verifier.
   * **Verification:** The verifier checks the validity of the response and whether it satisfies the accredited investor criteria, without gaining knowledge of the user's actual coordinates.
4. **Verification Result:** Based on the verification outcome, the verifier can assess whether the user’s score falls within the required ranges, without revealing the actual credit score or exposing any sensitive personal data.

## **Key Benefits**

* **Privacy-Preserving Underwriting:** Lending protocols can assess borrower risk based on verified, real-world credit data without ever handling sensitive Personally Identifiable Information (PII) or full credit reports, drastically reducing liability and aligning with data protection laws.
* **Access to Undercollateralized Lending:** This is a paradigm shift for DeFi. Users can access loans without needing to over-collateralize with crypto assets, unlocking traditional finance-like products for the web3 space based on their established credit history.
* **User-Centric Data Control:** Users own and control their financial reputation. They can choose which protocols to share their credit proof with and are not locked into a single platform, breaking down the data silos of traditional finance.
* **Reduced Platform Risk & Fraud:** The use of ZKPs and zkTLS makes it virtually impossible for users to falsify or exaggerate their credit scores, leading to a more trustworthy and secure financial ecosystem.
* **Global Compliance Ready:** The system is designed to integrate with AML/KYC frameworks, allowing platforms to build a comprehensive compliance profile of their users while maintaining a privacy-first approach.

## **Use Cases to Benefit**

* **Undercollateralized Lending in DeFi:** This is the primary use case. DeFi lending platforms can offer loans at higher loan-to-value ratios or even uncollateralized loans to users who can prove a high credit score, significantly expanding their market and competing with traditional banks.
* **On-Chain Credit Lines:** Protocols can establish revolving credit lines for users based on their zkCredit Score, allowing for more flexible and sophisticated financial management directly from their crypto wallet.
* **Reduced Insurance Premiums:** Decentralized insurance protocols could offer lower premiums to users who can demonstrate financial responsibility and stability through a verified credit score.
* **Premium Services and Tiered Access:** Any web3 service, from investment DAOs to exclusive NFT communities, can use credit score as a gating mechanism for premium features or higher investment limits, ensuring a higher level of participant quality.
* **Rental and Housing Applications:** In the growing world of tokenized real estate or crypto-native rental agreements, a zkCredit Score can serve as a trust signal for landlords or platforms without the tenant having to share their full credit report.

***

Pricing & Integration

From startups to scale-ups, our pricing and [simple integration](/hub/start/onboarding) are designed to support your growth and follow industry best practices.

A flat rate of **US$0.5 per verification** applies, which is **around ⅓  of typical providers** charge, giving you a clear and transparent cost model.

We stand by the value of our offering and provide a price-match guarantee for equivalent services upon review of a valid quotation.

Drop us a line at <mark style="color:blue;"><contact@zk.me></mark> and let’s kick things off!


# Proof-of-Accredited-Investor (PAI)

Enables privacy-first verification of accredited investor status using Zero-Knowledge Proofs, ensuring compliance without exposing financial or identity details.

## User Journey

Alice is interested in participating in a token sale restricted to accredited investors. With zkMe's [zkTLS](/hub/how-built/id-infra/zktls) capability, she proves her accredited status based on income thresholds, without sharing any documents or financial details. After a single check, she receives a Proof-of-Accredited-Investor credential as a Soulbound Token (SBT) backed by a zero-knowledge proof. She can now seamlessly access investment opportunities across platforms, while keeping her sensitive data completely private.

## See It in Action

Explore how users can prove accredited investor status and get their zkPoAI credential without exposing financial details.

{% embed url="<https://www.youtube.com/watch?v=MZtojzwhbpk>" %}

***

## **Why Check Investor Accreditation?**

Regulations are fundamental to the integrity of financial markets, including token sales and private investment rounds. Proving accredited investor status verifies financial eligibility. Regulators like the SEC in the USA and global financial authorities require platforms to conduct these checks to ensure that investments are only made by sophisticated investors that are aware of the investment risks involved.

## Why zkMe zkPoAI?

* **Privacy first:** Leverage zero-knowledge proofs to confirm accredited investor status without disclosing income or identity details.
* **Reliable data source:** Validate investor eligibility using trusted data for reliable, regulation-aligned accreditation.
* **Compliance-ready:** Fulfil SEC-accredited investor requirements (e.g., income thresholds) with cryptographic compliance built in.
* **Fully reusable:** Once verified, users can reuse their zkPoAI credential across multiple platforms without repeating the verification process.
* **Decentralized & Secure:** No central authority stores sensitive data—proofs are generated and verified without exposing private user information.
* **Plug-and-play:** Easily integrate zkPoAI into your onboarding flow with our Web and Mobile SDKs for instant, secure accreditation checks.

## How It Works

The zkPoAI procedure verifies a user's accredited investor status without revealing sensitive personal data. It leverages trusted data sources to confirm income-based eligibility. Combined with [zkTLS](/hub/how-built/id-infra/zktls) capability, the process ensures the user’s authenticity while preventing fraudulent activities. Here's a high-level overview of the procedure:

1. **User Income Verification:**
   * **Generate QR Code:** The zkMe widget generates a unique QR code for income verification.
   * **Scan via Mobile Device:** Users scan the QR code using their mobile devices.
   * **Redirect to Portal:** Upon scanning, users are automatically redirected to the zkTLS interface via an Instant App, App Clip, or Native App.
   * **Login:** Users follow the instructions on the redirected portal to log in via the specified login method.
   * **Authorize Data Sharing:** After logging in, users will see a *"Share Data"* button. By clicking it, they authorize the system to proceed.
   * **Automated Data Retrieval:** The system automatically identifies and extracts the required fields (e.g., year, earning data), and prepares them for further processing.
2. **Generate Random Numbers:** The user's device generates a random number as part of the zkPoAI process.
3. **Zero-Knowledge Proof (ZKP) protocol:**
   * **Commitment Phase:** The user generates a cryptographic commitment. This commitment includes hashed information about income without revealing actual coordinates or sensitive data. And the commitment is securely stored on the user's device, ensuring it cannot be tampered with.
   * **Challenge Phase**: The verifier (the service or entity performing the verification) selects a random challenge to ensure the user's commitment is valid and sent to the user's device for processing.
   * **Response Generation**: The user’s device processes the challenge by combining it with the previously generated random number and the commitment, then sends the response back to the verifier.
   * **Verification:** The verifier checks the validity of the response and whether it satisfies the accredited investor criteria, without gaining knowledge of the user's actual coordinates.
4. **Verification Result:** Based on the verification outcome, the verifier can check if the user qualifies as an accredited investor, without explicitly obtaining their real address or coordinates.

## **Key Benefits**

* **Privacy-Preserving Compliance:** Investment platforms can adhere to strict SEC and global regulations for accredited investor verification without ever handling sensitive tax returns, pay stubs, or bank statements, drastically reducing data breach liability and compliance overhead.
* **Expanded & Global Investor Pools:** Projects can tap into a global pool of qualified investors who were previously hesitant due to privacy concerns or the friction of repetitive document submission, thereby increasing capital raising efficiency.
* **User Sovereignty and Portability:** Investors gain full control over their financial credentials. A single verification grants them a portable digital badge that can be used across multiple platforms, eliminating the need to repeatedly prove their status.
* **Enhanced Platform Security and Trust:** The cryptographic nature of ZKPs makes it impossible to falsify accreditation status, creating a more trustworthy and secure environment for high-value investments and protecting platforms from fraudulent participants.
* **Automated and Scalable Onboarding:** The entire verification process is automated, allowing platforms to onboard accredited investors instantly and at scale, 24/7, without manual review of financial documents.

## **Use Cases to Benefit**

* **Regulatory-Compliant Token Sales:** Primary issuers of tokens (ICOs, IEOs, etc.) can restrict participation to verified accredited investors to comply with securities regulations (like Regulation D in the U.S.), opening up capital markets while maintaining full compliance.
* **Private DeFi Investment Pools:** Exclusive DeFi pools offering high-yield opportunities or early access to protocols can use zkPoAI to gate entry, ensuring sophisticated investors participate and mitigating regulatory risk.
* **Real-World Asset (RWA) Tokenization:** Platforms tokenizing assets like real estate, private equity, or fine art can verify that all investors are accredited, as is often required for these types of private securities offerings.
* **Venture DAOs and Investment Clubs:** Decentralized Autonomous Organizations focused on venture investments can ensure all voting members are accredited, legally protecting the DAO and its members when making collective investments.
* **On-Chain Private Placements:** Traditional finance institutions moving private placements on-chain can replicate their compliance framework digitally, using zkPoAI to verify investor eligibility in a more efficient and private manner.

***

Pricing & Integration

From startups to scale-ups, our pricing and [simple integration](/hub/start/onboarding) are designed to support your growth and follow industry best practices.

A flat rate of **US$0.5 per verification** applies, which is **around ⅓  of typical providers** charge, giving you a clear and transparent cost model.

We stand by the value of our offering and provide a price-match guarantee for equivalent services upon review of a valid quotation.

Drop us a line at <mark style="color:blue;"><contact@zk.me></mark> and let’s kick things off!


# Proof-of-Account-Ownership (PAO)

## User Journey

Alice is interested in participating in a token sale restricted to accredited investors. With zkMe's [zkTLS](/hub/how-built/id-infra/zktls) capability, she proves her accredited status based on income thresholds, without sharing any documents or financial details. After a single check, she receives a Proof-of-Accredited-Investor credential as a Soulbound Token (SBT) backed by a zero-knowledge proof. She can now seamlessly access investment opportunities across platforms, while keeping her sensitive data completely private.

## See It in Action

{% hint style="info" %}
**COMING SOON**
{% endhint %}

***

## Why Verify Accounts?

Proof-of-Account-Ownership serves as a critical component in Anti-Money Laundering (AML) and risk management frameworks. Financial institutions and DeFi platforms must verify that funds originate from legitimate sources and that users aren't utilizing anonymous accounts for illicit activities.

## Why zkMe PAO?

Traditional account verification methods require users to submit bank statements or provide full API access to their financial data, creating significant privacy risks and potential attack vectors. zkMe's zkAML-integrated account verification transforms this process by enabling platforms to confirm account ownership legitimacy and financial behavior patterns while ensuring that sensitive transaction histories, account numbers, and balances remain completely private. This approach meets regulatory requirements for fund source verification while upholding the privacy principles essential to Web3.

* **zkTLS for Maximum Security**: Our proprietary zkTLS technology creates a secure tunnel between users and their financial institutions, ensuring that even zkMe cannot access raw financial data or login credentials. This provides a level of security and trust unmatched by traditional screen scraping or API-based solutions.
* **Comprehensive Financial Assessment**: Unlike simple balance checks, our system analyzes multiple financial dimensions—account longevity, stability patterns, asset diversity—to create a holistic yet private financial profile for accurate underwriting.
* **Seamless Regulatory Integration**: The protocol is designed to work alongside zkAML checks, providing platforms with a complete compliance solution that verifies both account legitimacy and user identity while preserving privacy.
* **Cross-Border Compatibility**: Our system supports financial institutions globally, adapting to different banking systems, currencies, and regulatory environments while maintaining consistent privacy guarantees.

## How It Works

The Proof-of-Account-Ownership procedure uses zkTLS to create a secure, privacy-preserving bridge between traditional financial accounts and blockchain-based verification.

#### Account Verification & Underwriting Flow:

1. **Secure Financial Institution Connection**
   * **QR Code Generation**: The zkMe widget generates a unique QR code for financial account verification
   * **Mobile Redirect**: Users scan the code with their mobile device, redirecting to a zkTLS interface
   * **Secure Authentication**: Users log in directly to their financial institution through the secure tunnel
   * **Data Authorization**: Users explicitly authorize what financial data can be verified
2. **Private Data Extraction & Analysis**
   * **Account Ownership Proof**: System cryptographically confirms the user controls the account
   * **Financial Metric Calculation**: Key underwriting metrics are extracted (account age, average balance, transaction patterns)
   * **AML Compliance Screening**: Account details are screened against sanctions and watchlists through zkAML integration
   * **Data Minimization**: Raw transaction data and account numbers are immediately discarded after verification
3. **Zero-Knowledge Proof Generation**
   * **Commitment Phase**: The user's device generates a cryptographic commitment encoding their financial standing
   * **Challenge Phase**: The verifier sends a random challenge to ensure proof validity
   * **Response Generation**: The user's device processes the challenge with their financial data
   * **Verification**: The platform verifies the proof against underwriting criteria without accessing raw financial data
4. **Credential Issuance & Underwriting**
   * **SBT Minting**: A Proof-of-Account-Ownership Soulbound Token is issued to the user's wallet
   * **Tiered Access**: The credential contains ZKPs of specific financial thresholds (e.g., "assets > $50,000")
   * **Cross-Platform Reusability**: The credential can be used across multiple DeFi protocols and services

## Key Benefits

* **Privacy-Preserving Underwriting**: Financial platforms can assess user creditworthiness and financial standing without accessing sensitive bank statements, account numbers, or transaction histories
* **Regulatory Compliance**: Meets AML/KYC requirements for source of funds verification while minimizing data exposure and liability
* **Reduced Counterparty Risk**: Protocols can make informed lending decisions based on verified real-world financial data without over-collateralization
* **User-Controlled Financial Identity**: Users maintain a portable, reusable proof of their financial standing that they control and can selectively disclose
* **Fraud Prevention**: zkTLS prevents account spoofing and ensures verification comes directly from legitimate financial institutions
* **Global Financial Inclusion**: Enables users worldwide to leverage their traditional financial history in Web3 environments

## Use Cases to Benefit

* **Undercollateralized Lending**. DeFi lending protocols can offer loans with reduced collateral requirements based on verified real-world financial standing, expanding access to capital while managing risk through private financial verification.
* **Institutional-Grade DeFi Access**. Investment funds and sophisticated traders can prove their financial capacity to access advanced DeFi products, OTC desks, and private pools without revealing their total assets or trading strategies.
* **Premium Service Tiering**. CeFi and DeFi platforms can create tiered service levels based on verified financial standing, offering lower fees, higher limits, or exclusive products to qualified users while maintaining their privacy.
* **Regulatory Compliance Verification**. Financial institutions moving into crypto can satisfy regulators about their clients' source of wealth through cryptographically verified proofs without building extensive traditional compliance infrastructure.
* **Cross-Border Financial Services**. Remittance services and international platforms can verify users' financial stability and account ownership across jurisdictions, facilitating compliant cross-border services with reduced fraud risk.
* **DAO Treasury Management**. Decentralized Autonomous Organizations can ensure that treasury managers and key decision-makers meet specific financial responsibility thresholds without doxxing their personal finances.

***

Pricing & Integration

Drop us a line at <mark style="color:blue;"><contact@zk.me></mark> and let’s kick things off!


# Proof-of-Account-Assets (PAA)

## User Journey

Bob wants to access a premium DeFi lending protocol that requires proof of sufficient net worth for underwriting purposes. Using zkTLS, he securely connects to his traditional bank and brokerage accounts through an encrypted tunnel. The system verifies his total assets (cash, investments, securities) and liabilities (loans, credit balances) across multiple accounts, calculating key financial ratios without exposing specific transactions or account details. This Credential enables him to access tiered financial services across multiple platforms based on his verified financial position while maintaining complete privacy over his sensitive balance sheet data.

## See It in Action

{% hint style="info" %}
**COMING SOON**
{% endhint %}

***

## Why Verify Assets?

Asset verification serves as a fundamental pillar in sophisticated Anti-Money Laundering (AML) , financial crime prevention, and financial risk management frameworks. Financial institutions and DeFi platforms need to verify that users' declared wealth.

## Why zkMe PAA

Traditional asset verification methods require users to submit comprehensive bank statements, investment portfolio details, and liability disclosures, creating massive privacy risks and potential attack vectors. zkMe's zkTLS-based asset verification transforms this process by enabling platforms to confirm the legitimacy of users' financial positions and wealth sources while ensuring that specific account balances, investment holdings, and liability details remain completely private. This approach meets enhanced due diligence requirements for high-value relationships while upholding the privacy principles essential to modern finance.

* **Comprehensive Financial Profiling**: Unlike simple balance checks, our system analyzes complete financial positions across multiple institutions, calculating sophisticated metrics like net worth, leverage ratios, and liquidity profiles while maintaining full privacy through zero-knowledge proofs.
* **Multi-Account zkTLS Security**: Our proprietary zkTLS technology creates secure tunnels to multiple financial institutions simultaneously, ensuring consolidated financial verification without ever aggregating raw data in a central location.
* **Advanced Risk Modeling**: The protocol enables sophisticated underwriting based on verified financial ratios and patterns that are typically only available to traditional private banks and wealth managers.
* **Global Financial System Integration**: Our system supports diverse financial institutions worldwide, adapting to different account types, currencies, and reporting standards while maintaining consistent privacy guarantees and verification reliability.

## How It Works

The Proof-of-Account-Assets procedure uses zkTLS to create a secure, privacy-preserving bridge between traditional financial accounts and blockchain-based financial position verification.

1. **Multi-Account Secure Connection**
   * **QR Code Generation**: The zkMe widget generates a unique QR code for financial account linkage
   * **Institution Selection**: Users select from supported banks, brokerages, and financial institutions
   * **Secure Authentication**: Users log in directly to each financial institution through zkTLS secure tunnels
   * **Data Scope Authorization**: Users explicitly authorize what asset and liability data can be analyzed
2. **Comprehensive Financial Analysis**
   * **Asset Verification**: System cryptographically verifies cash balances, investment portfolios, securities holdings
   * **Liability Assessment**: Confirms outstanding loans, credit balances, and other financial obligations
   * **Net Worth Calculation**: Computes key metrics (debt-to-asset ratio, liquidity position, net worth brackets)
   * **AML Compliance Screening**: Asset sources and patterns are screened through zkAML integration
   * **Data Minimization**: Raw balance details and specific holdings are discarded after metric calculation
3. **Zero-Knowledge Proof Generation**
   * **Commitment Phase**: The user's device generates cryptographic commitments encoding financial ratios and thresholds
   * **Challenge Phase**: The verifier sends random challenges to ensure proof validity across multiple accounts
   * **Response Generation**: The user's device processes challenges with their aggregated financial data
   * **Multi-Account Verification**: Platform verifies consolidated financial position without accessing raw data from any single account
4. **Credential Issuance & Financial Tiering**
   * **SBT Minting**: A Proof-of-Account-Assets Soulbound Token is issued to the user's wallet
   * **Financial Tier Assignment**: The credential contains ZKPs of specific financial thresholds (e.g., "net worth > $100,000", "debt-to-asset ratio < 0.3")
   * **Cross-Platform Reusability**: The credential can be used across multiple DeFi protocols and financial services

## Key Benefits

* **Holistic Financial Underwriting**: Platforms can assess users' complete financial health including assets, liabilities, and net worth without accessing sensitive balance details or specific holdings
* **Privacy-Preserving Wealth Verification**: Users can prove financial capacity and stability while keeping exact account balances, investment compositions, and liability terms completely private
* **Enhanced Risk Assessment**: Lenders can make informed decisions based on verified debt-to-income ratios, liquidity positions, and overall financial health indicators
* **Multi-Institution Aggregation**: Users can verify consolidated financial positions across multiple banks and brokerages through a single privacy-preserving process
* **Regulatory Compliance**: Meets enhanced due diligence requirements for high-value relationships while minimizing data exposure and compliance overhead
* **Sophisticated Service Tiering**: Enables precise, risk-based service levels and product offerings based on verified financial metrics rather than self-reported information

## Use Cases to Benefit

* **Private Banking & Wealth Management**. Traditional and digital private banks can qualify clients for premium services based on verified net worth and financial health metrics without requiring intrusive document submissions or manual underwriting processes.
* **Institutional DeFi Access**. Family offices, investment funds, and high-net-worth individuals can prove financial capacity to access institutional-grade DeFi products, structured products, and private investment opportunities.
* **Risk-Based Lending Models**. DeFi and CeFi lending platforms can implement sophisticated risk-based pricing and collateral requirements using verified debt-to-asset ratios and overall financial health indicators.
* **Regulatory Capital Requirements.** Financial institutions can prove compliance with capital adequacy and net worth requirements to regulators and counterparties without disclosing detailed balance sheet information.
* **Venture Funding & Angel Investing**. Startups and investment platforms can verify accredited investor status and financial sophistication through net worth verification while maintaining investor privacy.
* **Cross-Border Financial Services.** International platforms can assess clients' global financial positions across jurisdictions for compliant cross-border services, large transactions, and relationship tiering.

***

Pricing & Integration

Drop us a line at <mark style="color:blue;"><contact@zk.me></mark> and let’s kick things off!


# Proof-of-Account-Transactions (PAT)

## User Journey

Sarah wants to apply for a mortgage with a decentralized lending protocol that requires verification of stable income and positive cash flow patterns. Using zkTLS capability, she securely connects to her primary bank account through an encrypted tunnel. The system analyzes her transaction history, including income deposits, recurring expenses, and spending patterns; without exposing specific merchant names, transaction amounts, or counterparty details. This Credential enables her to access customized financial products based on her verified transaction patterns while maintaining complete privacy over her sensitive financial activity.

## Why Verify Transaction History?

Transaction history analysis represents the most granular level of financial intelligence in Anti-Money Laundering (AML), and risk management frameworks. Financial institutions and DeFi platforms need to verify that users' transaction patterns.

## Why zkMe PAT

Traditional transaction verification requires users to submit complete bank statements, revealing every payment, purchase, and transfer to the verifier. zkMe's zkAML-integrated transaction verification transforms this process by enabling platforms to detect suspicious patterns and verify legitimate financial behavior while ensuring that specific transaction details, merchant information, and counterparty identities remain completely private. This approach meets the highest standards of transaction monitoring requirements while protecting users' financial privacy.

* **Advanced Pattern Analysis**: Our system goes beyond simple transaction counting to analyze complex financial behaviors, cash flow patterns, and temporal trends while maintaining zero-knowledge of specific transaction details.
* **Temporal zkTLS Verification**: Unlike balance checks, our transaction verification incorporates time-series analysis, allowing verification of financial behavior consistency over weeks, months, or years through secure historical data access.
* **Behavioral Finance Integration**: The protocol enables sophisticated financial personality assessment based on actual transaction behaviors that are typically only available to traditional banks' advanced scoring systems.
* **Privacy-Preserving**: We've developed specialized ZKP circuits that can detect suspicious transaction patterns (like structuring or rapid circular movements) without revealing the underlying transactions to any party.

## How It Works

The Proof-of-Account-Transactions procedure uses zkTLS to create a secure, privacy-preserving analysis of financial transaction patterns and histories.

#### Transaction Analysis & Verification Flow:

1. **Secure Transaction History Access**
   * **QR Code Initiation**: The zkMe widget generates a unique QR code for transaction history access
   * **Timeframe Selection**: Users specify the verification period (e.g., 3, 6, or 12 months)
   * **Secure Authentication**: Users log in directly to their financial institution through zkTLS secure tunnel
   * **Scope Authorization**: Users authorize access to transaction history within specified date ranges
2. **Privacy-Preserving Transaction Analysis**
   * **Pattern Recognition**: System analyzes transaction flows for income consistency, expense categories, and cash flow patterns
   * **Behavioral Metrics**: Calculates key indicators (income stability, savings rate, debt service coverage)
   * **AML Pattern Screening**: Transaction flows are screened for suspicious patterns through zkAML integration
   * **Categorization Without Exposure**: Transactions are classified into categories (income, essential expenses, discretionary spending) without revealing specifics
   * **Data Minimization**: Raw transaction details, merchant names, and exact amounts are discarded after analysis
3. **Zero-Knowledge Proof Generation**
   * **Commitment Phase**: The user's device generates cryptographic commitments encoding transaction patterns and behavioral metrics
   * **Challenge Phase**: The verifier sends random challenges to ensure the validity of transaction pattern proofs
   * **Response Generation**: The user's device processes challenges with aggregated transaction data
   * **Pattern Verification**: Platform verifies financial behavior claims without accessing any individual transactions
4. **Credential Issuance & Behavioral Scoring**
   * **SBT Minting**: A Proof-of-Account-Transactions Soulbound Token is issued to the user's wallet
   * **Behavioral Proofs**: The credential contains ZKPs of specific transaction patterns (e.g., "consistent monthly income > $5,000", "savings rate > 20%", "no overdrafts in 6 months")
   * **Temporal Validity**: Credentials include time-bound proofs reflecting the most recent analysis period

## Key Benefits

* **Granular Financial Underwriting**: Lenders can assess income stability, spending habits, and financial responsibility based on actual transaction history without viewing sensitive spending details
* **Pattern-Based AML Compliance**: Platforms can detect money laundering patterns (structuring, rapid movement, suspicious counterparts) while preserving transaction privacy
* **Behavioral Risk Assessment**: Enables evaluation of financial habits and stability through verified patterns rather than self-reported information or single-point balance checks
* **Cash Flow Verification**: Provides proof of consistent income and responsible cash management for credit underwriting without exposing salary sources or employer information
* **Category-Based Analysis**: Allows verification of spending categories and financial behaviors while keeping specific merchants and payment details completely private
* **Historical Trend Verification**: Enables proof of improving financial habits or long-term stability through multi-period analysis

## Use Cases to Benefit

* **Income Verification & Mortgage Underwriting**. DeFi real estate platforms and traditional lenders can verify stable income history and responsible financial behavior for mortgage applications without requiring pay stubs or tax returns.
* **Small Business Lending**. Business lenders can assess cash flow stability, revenue patterns, and financial health through transaction history analysis while protecting sensitive business counterparty information.
* **Subscription Service Risk Assessment.** High-value subscription services and membership platforms can verify financial stability and payment capability through transaction pattern analysis.
* **Employment & Contractor Screening**. Companies can verify financial stability and income history for employment screening, particularly for remote workers and contractors where traditional verification is challenging.
* **Regulatory Compliance Reporting**. Financial institutions can demonstrate transaction monitoring compliance to regulators by proving they detect suspicious patterns while maintaining customer privacy.
* **Financial Health Products**. Fintech applications can provide personalized financial advice and products based on verified transaction patterns without continuously monitoring user transactions.
* **Insurance Underwriting**. Insurance companies can assess financial stability and risk profiles through transaction behavior analysis for customized premium pricing.

***

## Pricing & Integration

Drop us a line at <mark style="color:blue;"><contact@zk.me></mark> and let’s kick things off!


# zkKYB - Know Your Business

{% hint style="success" %}
Can't wait to get started? Skip to the [Onboarding Checklist](/hub/start/onboarding)!
{% endhint %}

***

## User Journey

A business ("Business Alpha") wants to access a regulated DeFi platform. The platform requests a business verification. Business Alpha chooses its preferred verification method, completes the process, and receives a reusable zkKYB credential, which it uses to access the platform without disclosing any underlying corporate data.

In the Agent Economy, this journey extends further: a corporate AI agent, acting on behalf of Business Alpha, can present the zkKYB credential autonomously to counterparties and protocols, enabling B2B transactions, automated treasury operations, and cross-border settlements without requiring manual re-verification at each step.

## Why zkMe zkKYB

Anti-Money Laundering checks are a legal requirement for financial institutions and many virtual asset service providers. For businesses, this is known as Know Your Business. The goal is to prevent bad actors from using corporate structures to hide illicit activities like money laundering or terrorist financing.Traditional KYB processes are poorly suited for Agents. They require businesses to repeatedly submit sensitive corporate documents to various platforms, creating multiple points of failure for data breaches.&#x20;

* **Privacy-Preserving Architecture:** zkMe uses advanced ZKPs to ensure that even the verification service cannot determine why a business passed or failed a check, only that it meets the compliance criteria.
* **FATF-Compliant Decentralization:** zkMe is positioned as the only fully decentralized KYC provider that also meets FATF compliance standards, a principle that extends to its KYB offerings.
* **Interoperable Credential System:** The protocol is designed for a multi-chain world. The zkKYB credential can be used across different blockchain ecosystems, making it a versatile tool for global business.

***

## See It in Action

{% embed url="<https://www.youtube.com/watch?v=6TOC-HFK3S0>" %}

***

## How It Works

zkKYB supports two distinct verification paths to accommodate different types of corporate entities. Both paths produce the same cryptographically secure, privacy-preserving output: a zkKYB Credential issued as a Soul-Bound Token that verifiers can check without accessing the underlying corporate data.

### Path 1: Document-Based eKYB

This path is designed for any business entity and follows a process similar to traditional eKYB, but with the added privacy and security layers of zero-knowledge proofs.

1. **Document Verification & Data Extraction:**
   * **Authenticity Check:** The system confirms that uploaded business documents (e.g., registry extracts, articles of incorporation) are valid and untampered.&#x20;
   * **OCR Extraction:** Key details like company name, registration number, legal address, and director names are extracted.
2. **AML Database Screening:** The extracted information is checked against global sanctions lists, Politically Exposed Persons (PEPs) registries, and adverse media sources in a privacy-preserving manner.
3. **UBO Identification & Verification:**&#x20;
   * **Ownership Structure Mapping:** The system analyzes corporate documents to identify all natural persons who meet the Ultimate Beneficial Owner (UBO) threshold (typically ≥25% ownership or effective control).&#x20;
   * **Individual Identity Verification:** Each identified UBO is then verified against government-issued identity documents via zkMe's core **zkKYC** service.

> For a detailed breakdown of this process, see [**UBO Check**](/hub/what/zkkyb/proof-of-ubo).

4. **zkKYB Credential Issuance:** Once all checks are complete, the system issues a **zkKYB Credential** containing ZKPs of the business's good standing and clean AML status.

### Path 2: vLEI-Based Verification

This path is designed for businesses that already hold a **verifiable Legal Entity Identifier (vLEI)**, leveraging the cryptographic trust chain established by the Global Legal Entity Identifier Foundation (GLEIF).

1. **vLEI Credential Presentation:** The business presents its vLEI credential, which was issued by a GLEIF-accredited Qualified vLEI Issuer (QVI).
2. **Cryptographic Trust Chain Verification:** zkMe verifies the full cryptographic chain of the vLEI credential, ensuring it is authentic, valid, and traces back to the GLEIF root of trust.

> For a detailed explanation of this trust model, see [**vLEI Verification**](/hub/what/zkkyb/proof-of-vlei).

3. **zkKYB Credential Issuance:** Based on the successful verification of the vLEI, zkMe issues a **zkKYB Credential**. This attests to the entity's verified legal identity, leveraging the high-assurance foundation of the global LEI system.

***

## Key Benefits of zkKYB

* **Uncompromising Corporate Privacy:** Businesses can prove their eligibility and compliance without exposing sensitive corporate documents or the personal details of their directors, protecting them from data breaches and corporate espionage.
* **Streamlined Global Operations:** A reusable zkKYB credential drastically reduces onboarding friction. A business verified once can access multiple services across different jurisdictions and chains seamlessly.
* **Regulatory Compliance by Design:** The system is built to satisfy global AML/KYC and FATF regulations. It provides the necessary, cryptographically assured audit trail for regulators without forcing platforms to handle raw data.
* **On-Chain Identity for Enterprises:** The zkKYB credential provides a foundational layer of trust for the entire ecosystem of decentralized applications, enabling everything from compliant DeFi to verifiable supply chain finance.
* **Agent-Ready:** zkKYB credentials are designed to be consumed by AI agents acting on behalf of businesses. An agent holding a valid zkKYB credential can autonomously verify its principal's corporate identity to any counterparty, without human intervention at each step.

***

## Use Cases to Benefit

* **DeFi and Institutional Finance:** Permissioned DeFi pools and institutional lending platforms can use zkKYB to ensure that all participating entities are verified and compliant.
* **Supply Chain Finance:** Companies can prove their legitimate business status to participate in decentralized supply chain financing networks without disclosing confidential supplier relationships.
* **Real-World Asset Tokenization:** Platforms tokenizing assets can use zkKYB to verify the legal standing of issuers and investors.
* **DAO Treasury Management:** DAOs can implement zkKYB checks for entities that interact with their treasury, mitigating risk and providing accountability.
* **Agent-to-Business Commerce:** AI agents negotiating contracts, opening credit lines, or executing B2B payments on behalf of a business can present zkKYB credentials to instantly establish corporate identity and compliance status with counterparties.

***

## Pricing & Integration

Drop us a line at <contact@zk.me> and let’s kick things off!


# Proof-of-UBO

zkMe’s zkKYB suite includes comprehensive Ultimate Beneficial Ownership (UBO) verification, enabling regulated entities to comply with global AML/CFT standards while preserving the privacy of corporate officers.

## What is a UBO?

An Ultimate Beneficial Owner is the natural person(s) who ultimately owns or controls a corporate entity. International anti-money laundering regulations, such as those from the Financial Action Task Force (FATF), typically define a UBO as any individual who directly or indirectly:

* Holds **25% or more** of the shares or voting rights in the company.
* Exercises **significant influence or control** over the company and its management, regardless of ownership percentage.

Identifying and verifying UBOs is a critical component of any robust Know Your Business (KYB) process. It prevents individuals from using complex corporate structures, shell companies, or trusts to conceal illicit activities.

## How UBO Verification Works in zkKYB

UBO verification is an integral part of the **Document-Based eKYB** path within the zkKYB process. It follows a clear, multi-step procedure after the initial corporate documents have been authenticated.

1. **Ownership Structure Mapping:**
   * zkMe’s system analyzes the provided corporate documents (e.g., articles of incorporation, shareholder registry, cap table) to map out the full ownership structure.
   * It identifies all individuals who meet the jurisdictional UBO threshold, tracing ownership through any intermediate legal entities.
2. **Individual Identity Verification (zkKYC):**
   * For each identified UBO, a standard [zkKYC - Know Your Customer](/hub/what/zkkyc) process is initiated.
   * The individual verifies their identity using their government-issued passport or national ID.
   * This process includes an authenticity check of the document, a liveness check, and screening against global AML, PEP, and sanctions lists.
3. **UBO Compliance Credential Issuance:**
   * Once all identified UBOs have successfully completed their individual zkKYC, the system can issue a UBO Compliance Credential.
   * This credential is a zero-knowledge proof that attests to the fact that all beneficial owners of the entity have been identified, verified, and have passed all necessary AML/CFT checks.

## zkMe’s Role in UBO Verification

zkMe’s platform provides a seamless, privacy-preserving solution for the entire UBO workflow:

* **Automated Analysis:** Automates the complex task of parsing legal documents to identify the UBO structure, reducing manual effort and human error.
* **Integrated zkKYC:** Leverages its core zkKYC service to perform high-assurance identity verification on each UBO without requiring the business to handle its officers' personal data.
* **Zero-Knowledge Attestation:** The final output is not a list of names or sensitive documents. It is a single, verifiable ZKP credential confirming that UBO due diligence has been successfully completed according to regulatory standards.

## Use Cases

* **Regulated Financial Services:** Enables crypto exchanges, lending platforms, and asset issuers to meet their legal obligation to perform UBO checks before onboarding corporate clients.
* **DAO & Protocol Governance:** Allows DAOs to verify the human controllers behind corporate entities participating in governance votes, ensuring transparency and preventing Sybil attacks.
* **Enterprise Onboarding:** Any Web3 platform that interacts with corporate clients can use zkMe’s UBO check to mitigate counterparty risk in a compliant and privacy-preserving manner.


# Proof-of-vLEI

zkMe supports verifiable LEI (vLEI) credential checks within its zkKYB suite, enabling cryptographically verifiable corporate identity based on the globally recognized LEI standard.

## **What is a vLEI?**

A Legal Entity Identifier (LEI) is a 20-character alphanumeric code defined by ISO 17442 and governed by the Global Legal Entity Identifier Foundation (GLEIF). It uniquely identifies legal entities involved in financial transactions worldwide.\
However, an LEI alone is only an identifier; it does not provide cryptographic proof of authenticity.

A verifiable LEI (vLEI) addresses this by packaging the LEI as a cryptographically verifiable credential. Built on KERI (Key Event Receipt Infrastructure), with GLEIF as the root of trust, vLEI enables instant, automated verification of legal entities and their authorized representatives, without manual review or document-heavy checks.

The vLEI ecosystem includes three credential types:

1. **Legal Entity vLEI Credential**: Confirms an organization’s identity via its LEI, with cryptographic traceability to GLEIF.
2. **Official Organizational Role (OOR) Credential**: Verifies that a person holds an official role (e.g., CEO, CFO, Director), validated against public records or official documents.
3. **Engagement Context Role (ECR) Credential**: Verifies that a person is authorized in a specific context (e.g., signatory, compliance officer, contractor).

## **How vLEI Works in zkKYB**

### The vLEI trust chain

The vLEI ecosystem follows a hierarchical trust model rooted in GLEIF:

* **GLEIF as Root of Trust**: GLEIF establishes a Root Autonomic Identifier (AID) through KERI, anchoring the trust chain.
* **Delegation to QVIs**: GLEIF delegates authority to Qualified vLEI Issuers (QVIs), which are vetted and approved to issue and revoke vLEI credentials. Only QVIs that pass GLEIF’s qualification process can operate in the ecosystem.

When a legal entity applies for vLEI credentials, issuance follows this sequence:

1. **Legal Entity vLEI Credential**\
   The entity works with a QVI, which verifies LEI status and confirms that the applicant is authorized to act on the entity’s behalf. The QVI then issues the Legal Entity vLEI Credential, which is published on GLEIF’s website for public discoverability.
2. **OOR vLEI Credentials**\
   Once the entity credential is in place, the entity may request OOR credentials for individuals in official roles. The QVI verifies each person’s identity and validates the claimed role against public sources or official corporate records (e.g., board resolutions, articles of incorporation).
3. **ECR vLEI Credentials**\
   The entity may also issue ECR credentials for context-specific roles (e.g., authorized signatories, compliance staff, contractors). These may be issued by either the QVI or the legal entity itself, depending on the model.

Each credential is cryptographically traceable to GLEIF’s Root AID. A verifier can follow the signature chain from the credential, through the delegated QVI AID, back to GLEIF to confirm trusted issuance.

### **zkMe’s Role in vLEI Verification**

zkMe acts as both a verification layer and a privacy layer:

* **Credential verification**: During zkKYB, when a business presents a vLEI credential, zkMe verifies the full cryptographic chain: the issuer is a qualified QVI, the QVI’s authority is delegated by GLEIF, and the credential is not revoked.
* **Authorized representative verification**: Using OOR and ECR credentials, zkMe verifies not only the entity but also whether a specific individual is authorized to act on its behalf in a defined capacity. This is essential in KYB workflows.
* **Zero-knowledge credential issuance**: After validating the vLEI chain, zkMe issues its own ZKP-based credential attesting to the verification result, allowing relying parties (e.g., DeFi protocols or regulated platforms) to verify compliance claims while minimizing disclosure.

## **Use cases**

* **Permissioned DeFi**: Verify that counterparties are legitimate registered entities before granting access to institutional pools or lending markets.
* **RWA tokenization**: Validate the identity and legal standing of entities involved in real-world asset issuance and management.
* **Cross-border compliance**: Use standardized vLEI credentials for entity verification across jurisdictions without relying on fragmented local registries.
* **Regulatory reporting**: Support requirements under frameworks such as MiCA, AMLD, and FATF guidance, which increasingly require LEIs for legal-entity identification in financial transactions.


# KYT - Know Your Transaction

{% hint style="success" %}
Can't wait to get started? Skip to the [Onboarding Checklist](/hub/start/onboarding)!
{% endhint %}

***

## Credentials for Onchain Screening

This section covers zkMe’s [KYT](/hub/what/kyt) service for lightweight retail onboarding and essential onchain compliance checks.

<table><thead><tr><th width="171">Category</th><th width="275.51953125">Credentials</th><th>Description</th></tr></thead><tbody><tr><td>Compliance <br>Risk</td><td><a data-mention href="/pages/Fi67CS7hbYdfFWH2VlTu">/pages/Fi67CS7hbYdfFWH2VlTu</a></td><td>• On-chain Transaction Monitoring</td></tr></tbody></table>

Want to explore more use cases? Check out our other credential suites at [Catalog - All Credentials](/hub/what/catalog).

## User Journey

KYT's primary objective is to keep all transactions in line with applicable laws and compliance standards. It achieves this through live monitoring of user wallet activities. In addition, it helps us understand user transaction behavior, which ultimately improves risk management and compliance efficiency in the cryptocurrency arena.

## Why Monitor Transactions?

"Know Your Transaction" (KYT) is a compliance process mainly used to track and examine cryptocurrency transactions. It's a useful tool for identifying and preventing potential suspicious activities in user wallets, such as money laundering and financing of terrorism.

## How it works?

With the help of KYT, the [zkMe Dashboard](https://dashboard.zk.me) enables real-time tracking and analysis of transaction data, making it possible to spot and tackle any suspicious activities promptly. Now, [zkMe Dashboard](https://dashboard.zk.me) offers the capability to explore wallets on various networks including Ethereum, Polygon (MATIC), Arbitrum, and Base among other (see [KYT Supported Scope](/hub/what/kyt/support-scope) for the full list). We're planning to extend our support to even more networks in the near future.

## Key Benefits

KYT not only assists in meeting legal and compliance requirements but also elevates a platform’s reputation and trustworthiness among users by minimizing the risks associated with suspicious transactions.

***

## Get Started

<figure><img src="/files/OZf5NLkx943wL2xYBYOa" alt=""><figcaption></figcaption></figure>

To view a user's KYT details, navigate to [zkMe Dashboard](https://dashboard.zk.me) and locate the `Details` table. From there, select the wallet address that corresponds to the user you're interested in. This will redirect you to the KYT page.

{% hint style="info" %}
Currently, we only support retrieving KYT information from the user's EVM wallet address. You will not be redirected if you click on the Cosmos wallet address.
{% endhint %}

<figure><img src="/files/GLxflRc7nQosaKdFVDx9" alt=""><figcaption></figcaption></figure>

## Useful KYT Widgets

### AML Risk Score

<div align="left"><figure><img src="/files/623fImvEAgGRlebqnc6R" alt=""><figcaption></figcaption></figure></div>

An AML risk score is a measure assigned to an address, reflecting its blockchain interactions. This score offers users an understanding of potential suspicious activity. An address might be flagged as risky if it's associated with a high-risk entity (like a mixer), or if it has funds linked to a known risky entity. Simply put, you can assess the risks linked to each wallet address, much like a professional compliance officer, and determine if the wallet address holds unlawful funds.

The risk levels and their respective scores are assigned as follows:

| Risk Level | Risk Score |
| ---------- | ---------- |
| Severe     | 91-100     |
| High       | 71-90      |
| Moderate   | 31-70      |
| Low        | 0-30       |

### Assets Held

<div align="left"><figure><img src="/files/GITQVInYmux4BAhhCcGJ" alt=""><figcaption></figcaption></figure></div>

This widget enables you to access the asset details of the given wallet. The in-built chain selector within the component filters the supported chains, providing users with asset details on the relevant chain. Importantly, any adjustments to this chain selector will reflect on the data displayed in the remaining six widgets.

### Transaction Overview

<div align="left" data-full-width="false"><figure><img src="/files/dl0KvQlzyfFOFKrgzcHn" alt=""><figcaption></figcaption></figure></div>

This widget serves as a concise overview of the wallet's transaction history on this chain. It provides key details such as balance, total transaction count, timestamps of the first and most recent transactions, and more.

### Actions Analysis

<figure><img src="/files/wa94DTD2LSy1DLxYlzfP" alt=""><figcaption></figcaption></figure>

Unlike regular blockchain browsers, the zkMe Dashboard processes all of a wallet's past transactions and presents the data in an easily understandable format. This evaluation splits the transactions into Incoming and Outgoing Transactions, and then further categorizes them based on diverse behaviors.

### Address Labels

<div align="left"><figure><img src="/files/wp2kDmAccJoA9yHfgu8k" alt="" width="350"><figcaption></figcaption></figure></div>

The Address Labels feature is designed to help users differentiate between various types of blockchain addresses, improving their transactional experience. With this feature, users can quickly recognize different entities like exchanges, smart contracts, and more specifically, the organization an address is associated with, such as Coinbase or Binance. It also reveals both on-chain and off-chain tags, including ENS, as well as the wallet software used, like MetaMask. This detailed labeling not only makes it easier to comprehend the addresses in question but also offers a clearer view of the blockchain environment they're engaging with.

### Profile Analysis

<figure><img src="/files/Oc5Z2br1MUYBsUzqhijz" alt=""><figcaption></figcaption></figure>

The address profile analysis module is able to produce a comprehensive overview in a user-friendly format by examining all interactions tied to the address. Identify any malicious events linked to a specific address. Also, easily access further details related to an address, such as associated wallets, ENS identities, and related Twitter profiles.

### Transaction Graph

<figure><img src="/files/emg93vXvIxMJhB7Fnbay" alt=""><figcaption></figcaption></figure>

This module presents a graph as a visual tool to illustrate the connections between all incoming and outgoing transactions for the queried address (defaults to the latest 1000 transaction records). You can filter and sort data directly on the graph, and you can also monitor selected pieces of information. Any suspicious activities will be distinctly highlighted on the graph, making it easy to track.

<figure><img src="/files/s7mCNKBVWh2gNVVAVhbB" alt=""><figcaption></figcaption></figure>

Additionally, for more detailed transaction information between sender and recipient, you can select nodes in the graph or the transaction number in the table on the right. This will provide data such as the transaction amount and time, and will redirect you to the corresponding blockchain explorer for further useful details.

***

## Pricing & Integration

From startups to scale-ups, our pricing and [simple integration](/hub/start/onboarding/integration/api/get-kyt) are designed to support your growth and follow industry best practices.

A flat rate of **US$0.5 per wallet** applies, which is **around ⅓  of typical providers** charge, giving you a clear and transparent cost model.

We stand by the value of our offering and provide a price-match guarantee for equivalent services upon review of a valid quotation.

Drop us a line at <mark style="color:blue;"><contact@zk.me></mark> and let’s kick things off!


# Supported Chains

Before starting the integration, please review the supported chains and the endpoints available in our API.

## Multi-chain Support  <a href="#multi-chain-support" id="multi-chain-support"></a>

<table><thead><tr><th width="155">Chain</th><th>Tokens Tracked</th></tr></thead><tbody><tr><td><strong>Bitcoin</strong></td><td>BTC</td></tr><tr><td><strong>Ethereum</strong></td><td>ETH, USDT-ERC20, USDC-ERC20, WETH-ERC20, BNB-ERC20, UNI-ERC20, BUSD-ERC20, DAI-ERC20, GRT-ERC20, ENS-ERC20, UST-ERC20, renBTC-ERC20, WBTC-ERC20, TUSD-ERC20, SHIB-ERC20, LINK-ERC20, BAT-ERC20, CRO-ERC20, SUSHI-ERC20, stETH-ERC20, CRV-ERC20, CVX-ERC20, cvxCRV-ERC20, 3Crv-ERC20, LOOKS-ERC20, IOTX-ERC20, APE-ERC20, PYUSD-ERC20, MEME-ERC20</td></tr><tr><td><strong>Avalanche</strong></td><td>AVAX-Avalanche, WAVAX-Avalanche, BTC.b-Avalanche, USDT-Avalanche, USDT.e-Avalanche, USDC-Avalanche, USDC.e-Avalanche, WETH.e-Avalanche, DAI.e-Avalanche, WBTC.e-Avalanche</td></tr><tr><td><strong>Arbitrum One</strong></td><td>ETH-Arbitrum, USDT-Arbitrum, USDC-Arbitrum, USDC.e-Arbitrum, WETH-Arbitrum, DAI-Arbitrum, WBTC-Arbitrum, LINK-Arbitrum, GMX-Arbitrum, sbfGMX-Arbitrum, STG-Arbitrum, MAGIC-Arbitrum</td></tr><tr><td><strong>Base</strong></td><td>ETH-Base, USDC-Base, USDbC-Base, WETH-Base, DEGEN-Base, DAI-Base, cbETH-Base</td></tr><tr><td><strong>Bitcoin Cash</strong></td><td>BCH</td></tr><tr><td><strong>BNB Smart Chain(BSC)</strong></td><td>BNB, BUSD-BEP20, USDT-BEP20, WBNB-BEP20, ETH-BEP20, BTCB-BEP20, DOGE-BEP20, USDC-BEP20, SHIB-BEP20, UST-BEP20, DAI-BEP20, Cake-BEP20, BCH-BEP20</td></tr><tr><td><strong>Dogecoin</strong></td><td>DOGE</td></tr><tr><td><strong>TRON</strong></td><td>TRX, USDT-TRC20, USDC-TRC20</td></tr><tr><td><strong>IoTeX</strong></td><td>IOTX</td></tr><tr><td><strong>Polygon</strong></td><td>MATIC-Polygon, WMATIC-Polygon, WETH-Polygon, USDC-Polygon, USDC.e-Polygon, USDT-Polygon, DAI-Polygon, WBTC-Polygon, AAVE-Polygon, LINK-Polygon, UNI-Polygon, UST-Polygon, SUSHI-Polygon</td></tr><tr><td><strong>OP Mainnet</strong></td><td>ETH-Optimism, USDT-Optimism, USDC-Optimism, USDC.e-Optimism, OP-Optimism, DAI-Optimism, WBTC-Optimism, WETH-Optimism, SNX-Optimism, sUSD-Optimism, VELO-Optimism</td></tr><tr><td><strong>zkSync Era</strong></td><td>ETH-zkSync</td></tr><tr><td><strong>Merlin Chain</strong></td><td>BTC-Merlin</td></tr><tr><td><strong>TON</strong></td><td>TON, USDT-TON</td></tr><tr><td><strong>Solana</strong></td><td>SOL, USDT-Solana, USDC-Solana, Bonk-Solana, JUP-Solana, RAY-Solana, PYTH-Solana, W-Solana</td></tr><tr><td><strong>Litecoin</strong></td><td>LTC</td></tr></tbody></table>

## API Endpoint List

<table><thead><tr><th width="319">Endpoint</th><th>Description</th></tr></thead><tbody><tr><td>/kyt/v1/status</td><td>Returns API status</td></tr><tr><td>/kyt/v1/address_labels</td><td>Returns a list of labels for a given address</td></tr><tr><td>/kyt/v1/address_overview</td><td>Returns the balance and statistics for a given address</td></tr><tr><td>/kyt/v1/risk_score</td><td>Returns the risk score, risk detail list for a given address</td></tr><tr><td>/kyt/v1/transactions_investigation</td><td>Returns a transaction investigation result for a given address</td></tr></tbody></table>


# zkMe Bug Bounty Program

## Introduction

zkMe is dedicated to ensuring the highest levels of security for its smart contracts and applications. As part of this commitment, we have established a comprehensive bug bounty program to identify and address potential vulnerabilities. By incentivizing the discovery and responsible disclosure of security issues, we aim to fortify our systems and protect our users from incidents that could lead to financial losses, service disruptions, governance compromises, or breaches of data integrity and privacy.

## Reward Tiers and Threat Level Classification

To effectively prioritize and address potential vulnerabilities, we have implemented a four-tier threat level system for smart contracts and blockchains. This system evaluates the severity of threats based on factors such as the potential impact of exploitation, the level of access required, and the feasibility of a successful exploit. All submissions must include a detailed Proof of Concept (PoC). Submissions without a PoC will be returned to the submitter with a request for the necessary evidence.

## Smart Contracts and Applications Rewards Breakdown

* **Critical:** Non-user fund loss. Rewards range from 5,000 USD to 10,000 USD, calculated at 1% of the assets at risk.
* **High:** Rewards range from 2,000 USD to 5,000 USD, calculated at 1% of the assets at risk, if the issue remains unresolved for 1 month.
* **Medium:** Rewards range from 500 USD to 2,000 USD, calculated at 1% of the assets at risk, if the issue remains unresolved for 1 month.
* **Low:** A standard reward of 500 USD is offered for low-severity vulnerabilities.

Payouts are processed directly by the zkMe team and are denominated in USD. Bug bounty participants have the option to receive payouts in USDC or USDT, providing flexibility and accommodating individual preferences.

## Scope and Rules

To maintain the integrity and effectiveness of the bug bounty program, certain vulnerabilities and activities are considered out of scope for rewards. These include:

* Previously exploited attacks that have caused damage
* Attacks requiring leaked keys/credentials or privileged addresses
* Incorrect data from third-party oracles (excluding oracle manipulation/flash loan attacks)
* Basic economic governance attacks, such as 51% attacks
* Liquidity issues, critiques on best practices, and Sybil attacks

Vulnerabilities that are deemed out of scope include theoretical risks without PoC, content spoofing, self-XSS, and other low-impact findings. Additionally, vulnerabilities that require privileged organizational access or are classified as feature requests or best practices critiques are not eligible for rewards. To ensure the safety and fairness of the bug bounty program, participants must adhere to the following rules:

* All testing must be conducted on private testnets; testing on mainnet or public testnets is strictly prohibited.
* Interactions with pricing oracles or third-party smart contracts are not allowed.
* Phishing or social engineering attacks are strictly forbidden.
* Testing with third-party systems and applications is not permitted.
* Initiating denial of service attacks is prohibited.
* Automated testing that generates significant traffic is not allowed.
* Public disclosure of unpatched vulnerabilities under an embargoed bounty is strictly prohibited.

{% hint style="info" %}
**Note:** Our Bug Bounty program does not cover issues related to DOS (Denial of Service) or traffic-related attacks. These types of attacks are typically related to service performance rather than direct security vulnerabilities and are therefore excluded from the scope of this program.
{% endhint %}

## How to Report a Bug: Process and Steps

{% stepper %}
{% step %}

#### **Step 1: Identify the Bug**

Confirm that the bug is within the scope of our bounty program (see "Scope and Rules") and prepare a detailed description and Proof of Concept (PoC).
{% endstep %}

{% step %}

#### **Step 2: Submit the Bug Report**

Include the following in your submission:

* A description of the bug and its potential impact.
* Steps to reproduce the bug, with screenshots or video if needed.
* PoC for vulnerabilities, and contract details for smart contract issues.
  {% endstep %}

{% step %}

#### **Step3: Send the Report**

Submit your report via the designated platform or send it to <contact@zk.me>. zkMe will respond within 48 hours.
{% endstep %}

{% step %}

#### **Step 4: Review and Fix**

Our security team will review the report, confirm the severity, and proceed with fixing the issue. You may receive updates during the process.
{% endstep %}

{% step %}

#### **Step 5: Receive Reward**

After the issue is resolved, rewards are given based on the threat level.
{% endstep %}
{% endstepper %}

## Conclusion

zkMe is committed to maintaining the highest standards of security and continuously improving its security posture. By fostering a collaborative relationship with the security community through our bug bounty program, we aim to identify and address potential vulnerabilities proactively. We encourage responsible disclosure and value the contributions of individuals who dedicate their time and expertise to enhancing the security of our smart contracts and applications.Together, we can create a more secure and resilient ecosystem, ensuring the protection of user funds, data integrity, and privacy. zkMe extends its gratitude to all participants in the bug bounty program for their valuable contributions to our ongoing security efforts.


# zkMe Brand Kit

This page gives you access to zkMe high quality logo and icon.

### zkMe Logo - Horizontal

<figure><img src="/files/1bzrBzhVhnV9vBXk9tIk" alt=""><figcaption></figcaption></figure>

**zkMe Logo.png**

:file\_cabinet:[<mark style="color:green;">Deep Green.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FLNvVS3g2gyM9gDdiLSSJ%2FDeep_Green.png?alt=media\&token=5893efaf-0f6e-4c99-8725-8c7ac34ea996)

:file\_cabinet:[<mark style="color:green;">Light Green.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FkOmpKRst9aQ9evgU8njZ%2FLight_Green.png?alt=media\&token=0d064465-6937-4c55-964c-a46d0e116457)

:file\_cabinet:[<mark style="color:green;">All White.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2F8sdzMkkGYfYOHV297BNu%2FAll_White.png?alt=media\&token=ba14375e-99fe-4cb6-80f0-23066282d6dc)

:file\_cabinet:[<mark style="color:green;">All Black.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FSmXnejPxNyYeelMSNCGD%2FAll_Black.png?alt=media\&token=569391d8-4238-44da-ae0e-76f8dac8ea75)

**zkMe Logo.svg**

:file\_cabinet:[<mark style="color:green;">Deep Green.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2F8lvTHqzYeeak8GD9Uviz%2FDeep_Green.svg?alt=media\&token=64341497-2afb-4b42-9088-f7f3ed1e689d)

:file\_cabinet:[<mark style="color:green;">Light Green.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FrdIJb6NKHgIfCRCIZfYv%2FLight_Green.svg?alt=media\&token=b55ecd4e-a3b7-4157-a8f5-c644cf91da92)

:file\_cabinet:[<mark style="color:green;">All White.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FaQOhIENqKZbP8D0DhePV%2FAll_White.svg?alt=media\&token=c14cb9ce-fce2-4483-8d8f-c30349da5108)

:file\_cabinet:[<mark style="color:green;">All Black.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FqOtnUrLgP1C0adsuntwZ%2FAll_Black.svg?alt=media\&token=f0040f2d-2d69-4916-93eb-c31bbe497e92)

### zkMe Logo - Vertical with Text

<figure><img src="/files/boS6V5EHciivTuuWzvQj" alt=""><figcaption></figcaption></figure>

**zkMe Logo.png**

:file\_cabinet:[<mark style="color:green;">Deep Green.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FGnWnlSwcL7SK6R5MRtoI%2FDeep_Green%201.png?alt=media\&token=864ecb05-b79d-4f82-bb95-761825361ead)

:file\_cabinet:[<mark style="color:green;">Light Green.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2Fl9Mp1sEE5v1r1cfwzxJG%2FLight_Green%201.png?alt=media\&token=617a3759-f4d6-4eb8-a3a1-47d14cf28c47)

:file\_cabinet:[<mark style="color:green;">All White.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FKfzdZRUVeXqJXtlV31bS%2FAll_White%201.png?alt=media\&token=b7c21158-1c0e-4d97-b224-567fe8668916)

:file\_cabinet:[<mark style="color:green;">All Black.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FEb7QRV1TfYTsIwZg9RTp%2FAll_Black%201.png?alt=media\&token=c0947e1c-5dd0-4455-8a60-3fe4868e505b)

**zkMe Logo.svg**

:file\_cabinet:[<mark style="color:green;">Deep Green.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FigJz7ngSVHdcEk5yWutf%2FDeep_Green%201.svg?alt=media\&token=1988a2dd-e235-4a70-b1f2-dd4af0f7adb8)

:file\_cabinet:[<mark style="color:green;">Light Green.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FAh2cxM47UAgk8eotqGvC%2FLight_Green%201.svg?alt=media\&token=ee54ecd8-c89b-4ed4-bb30-b3a51b856f14)

:file\_cabinet:[<mark style="color:green;">All White.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2Feq5uGXPLAcH2l5NgKYlG%2FAll_White%201.svg?alt=media\&token=1c925428-4ed7-47a2-a58e-5c50023ca0eb)

:file\_cabinet:[<mark style="color:green;">All Black.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FYC1AS2YZXLghHUd7YEth%2FAll%20Black%202.svg?alt=media\&token=3e79e9ba-5553-462a-ad1b-556052585352)

### zkMe Logo - Square

<figure><img src="/files/rHRIuzshAkVCIFNPrVDP" alt=""><figcaption></figcaption></figure>

**zkMe Logo.png**

:file\_cabinet:[<mark style="color:green;">Deep Green.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FFAD6Wcp47VFrOCykmPPk%2FDeep_Green%202.png?alt=media\&token=7add664c-d220-47e0-ba64-8fdcf1b84c12)

:file\_cabinet:[<mark style="color:green;">Light Green.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FSP9KtXPpc8W6LU51iAYB%2FLight_Green%202.png?alt=media\&token=a5b31bf9-bde0-4bad-84c8-b9807a46d63a)

:file\_cabinet:[<mark style="color:green;">All White.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FAsTA9dSmQWMcSBPBSyfy%2FAll_White%202.png?alt=media\&token=0cd24101-4f57-498b-a7a8-38e7b66b1b5c)

:file\_cabinet:[<mark style="color:green;">All Black.png</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FWOuMVkarsyABvVSw9FNv%2FAll_Black%203.png?alt=media\&token=0f3461ed-a43c-41bd-9e4b-5987682d3952)

**zkMe Logo.svg**

:file\_cabinet:[<mark style="color:green;">Deep Green.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2F3Fk0rclCEkq7deqYcjUH%2FDeep_Green%202.svg?alt=media\&token=f5a256c4-996b-4f09-9717-5277f365928e)

:file\_cabinet:[<mark style="color:green;">Light Green.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FPoYgXaMGdTIshrUS0JG7%2FLight_Green%202.svg?alt=media\&token=277111e7-5a22-4d4a-a831-aca17698bd6c)

:file\_cabinet:[<mark style="color:green;">All White.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FPSL8gu1a3YFyFEdUgccP%2FAll_White%202.svg?alt=media\&token=fe0a2e01-c821-44c0-9ff8-a76976c27209)

:file\_cabinet:[<mark style="color:green;">All Black.svg</mark>](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW4hmKI99cixdSY00WRm8%2Fuploads%2FfdQT08BRx9CobU8wfFVA%2FAll_Black%201.svg?alt=media\&token=71de0806-73be-42f6-a909-ee746f053f40)

***

## ***Dont's***

* Don't **flip** the icon and text sides;
* Don't **change** the text color;
* Don't **distort** the text;
* Don't add **outlines** or add any other effects;

<figure><img src="/files/YDJGJgvL4LwzyBD4C4ap" alt=""><figcaption></figcaption></figure>


# Glossary

This glossary is intended to define important terms in the body of this documentation hub.

* **Anti-Money Laundering Act (AMLA)**: A US federal law that requires financial institutions to detect and prevent money laundering and terrorist financing activities.
* **Credential Verifications**: The process by which a verifier checks the authenticity, integrity, and current validity of a digital credential presented by a holder, without assessing the truth of the claims themselves.
* **Decentralized Autonomous Organization (DAO)**: An organization that operates on a blockchain and is governed by smart contracts and voting systems, without the need for centralized authority or management.
* **Decentralized Finance (DeFi)**: System of financial products built on blockchain technology that aim to provide users with a more open, transparent, and accessible financial system without intermediaries.
* **Decentralized File Storage (DFS)**: A method of storing files across multiple nodes in a decentralized manner to enhance security, redundancy, and accessibility without relying on central servers. Used to store encrypted verifiable credential data with cross-device access capabilities.
* **Decentralized identifier (DID)**: Unique digital identifier that is used to represent a person, organization, or thing in a decentralized digital identity system.
* **EU Markets in Crypto-Assets (MiCA)**: MiCA is the upcoming regulatory framework by the European Union for cryptocurrencies and related digital assets.
* **Financial Action Task Force (FATF)**: intergovernmental organization that sets international standards for combating money laundering, terrorist financing, and other threats to the integrity of the global financial system.
* **General Data Protection Regulation (GDPR)**: European Union regulation that sets rules for the collection, processing, and storage of personal data.
* **Holder**: A holder is a party that holds and controls digital assets or credentials.
* **Issuer**: An issuer is a party that creates and issues digital assets or credentials.
* **Identity Layer**: The foundational protocol or infrastructure that enables creation, management, and verification of digital identities and credentials in a decentralized ecosystem.
* **Identity Oracle**: A trusted service or system that provides verified identity information or claims to other systems, serving as a bridge between off-chain identity data and on-chain verification needs.
* **Issuance**: The process in which an issuer creates and issues a credential to a holder based on specified credential schemas and the holder's raw data.
* **Know-Your-Business (KYB)**: A process in which businesses verify the identity and other relevant information of their partners, suppliers, and other counterparties, to assess the risk of financial crime and ensure compliance with regulations.
* **Know-Your-Customer (KYC)**: A process in which businesses verify the identity and other relevant information of their clients to prevent fraud and money laundering. KYC is used in banking, insurance, and other industries where financial transactions occur.
* **Multi-Party-Computing (MPC)**: A cryptographic protocol that allows multiple parties to securely compute a function on their private inputs, without revealing their inputs to each other. MPC is used for secure data sharing and collaboration, including financial transactions, voting, and data analysis.
* **Optical Character Recognition (OCR)**: A technology that allows machines to recognize and convert scanned images of text into machine-readable text. OCR is used in various applications, such as digitizing printed documents, automating data entry, and improving accessibility for visually impaired individuals.
* **Oracle**: A trusted third party (or network of third parties) that provides data or information to a blockchain-based system. Oracles are used to enable smart contracts to interact with external data and services.
* **Politically Exposed Person (PEP)**: A person who is or has been entrusted with a prominent public function, such as a government official or a political party member. PEPs are subject to enhanced due diligence and monitoring to prevent corruption and money laundering.
* **Privacy Preserved**: A principle in digital identity systems that ensures users control their personal data and only disclose minimal necessary information, often using cryptographic techniques like zero-knowledge proofs.
* **Raw Data**: The original identity information of a holder, including identification document photos, facial photos, and personal details used as input for credential creation.
* **Regulator**: A government agency or other authority that oversees and enforces regulations and laws related to financial transactions, data privacy, and other areas.
* **Schema**: The standardized storage format for holder information within a verifiable credential, ensuring consistent data structure for the same type of identity credential.
* **Self-Sovereign Identity (SSI)**: SSI is a decentralized digital identity system that allows individuals to own and control their identity information, without relying on centralized authorities. SSI systems are based on blockchain technology and are designed to be secure, private, and interoperable.
* **Single Sign-On (SSO)**: An authentication process that allows users to access multiple applications with one set of login credentials, improving user experience and security.
* **Soulbound Token (SBT)**: Non-transferable tokens representing a person’s identity using blockchain technology. This could include medical records, work history, and any type of information that makes up a person or entity. The wallets that hold or issue these records are called “Souls.”
* **Trusted Execution Environment (TEE)**: A secure computing environment that protects data and code from unauthorized access, ensuring that sensitive operations like key management remain private and tamper-proof.
* **Threshold Signature Scheme (TSS)**: A cryptographic technique that allows a group of parties to collectively sign a message or transaction, without any one party having complete control or knowledge of the signature. TSS is used for secure and decentralized key management and multi-party authorization.
* **Universal Account**: A single digital identity or account that can be used across multiple platforms and services, enabling seamless interoperability in decentralized ecosystems.
* **US Commodity Futures Trading Commission (CFTC)**: A federal agency responsible for regulating commodity futures, options, and swaps markets in the United States.
* **US Securities and Exchange Commission (SEC)**: A federal agency responsible for regulating and overseeing the securities industry and protecting investors in the United States.
* **Verifiable credential (VC)**: A digital certificate that contains claims about a person's identity or qualifications, which can be verified by a third party. VCs are used in SSI systems to enable secure and privacy-preserving data sharing and collaboration.
* **Verifiable Presentations (VPs)**: Selectively disclosed claims derived from Verified Credentials.
* **Verifier**: A party that verifies the authenticity and validity of digital assets or credentials.
* **Virtual Asset Service Providers (VASPs)**: Entities that provide services related to virtual assets, such as exchanges, custodians, and wallet providers.
* **Web3:** A term used to describe the third generation of the World Wide Web, which is focused on creating a decentralized and trustless internet using blockchain technology.
* **World Wide Web Consortium (W3C)**: An international community that develops open standards to ensure the long-term growth and sustainability of the World Wide Web.
* **Zero-Knowledge-Proof (ZKPs)**: A cryptographic technique that allows one party to prove to another party that a statement is true, without revealing any information beyond the fact that the statement is true. ZKPs are used for secure authentication and data exchange, privacy-preserving transactions, and verifying the integrity of data without exposing it.
* **zk-SNARK**: A zero-knowledge proof system that allows for the verification of computational integrity without revealing the inputs of the computation.
* **zkTLS (Zero-Knowledge Transport Layer Security)**: The integration of zero-knowledge proofs into the TLS handshake process, enabling secure verification of cryptographic parameters without exposing sensitive data.


# Links

Follow us on the following channels

## Development & Tools

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><mark style="color:blue;"><strong>GitHub</strong></mark></td><td><a href="https://github.com/zkMeLabs">https://github.com/zkMeLabs</a></td></tr><tr><td><mark style="color:blue;"><strong>NMP</strong></mark></td><td><a href="https://www.npmjs.com/package/@zkmelabs/widget?activeTab=readme">https://www.npmjs.com/package/@zkmelabs/widget?activeTab=readme</a></td></tr></tbody></table>

## Social Media & Community

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><mark style="color:blue;"><strong>X / Twitter</strong></mark></td><td><a href="https://twitter.com/zkme_">https://twitter.com/zkme_</a></td></tr><tr><td><mark style="color:blue;"><strong>Medium</strong></mark></td><td><a href="https://medium.com/@zkMe">https://medium.com/@zkMe</a></td></tr><tr><td><mark style="color:blue;"><strong>YouTube</strong></mark></td><td><a href="https://youtube.com/@zkMe_">https://youtube.com/@zkMe_</a></td></tr><tr><td><mark style="color:blue;"><strong>LinkedIn</strong></mark></td><td><a href="https://www.linkedin.com/company/zkme">https://www.linkedin.com/company/zkme</a></td></tr><tr><td><mark style="color:blue;"><strong>Discord</strong></mark></td><td><a href="https://discord.com/invite/SJ2RDs9NGM">https://discord.com/invite/SJ2RDs9NGM</a></td></tr><tr><td><mark style="color:blue;"><strong>Blog</strong></mark></td><td><a href="https://zk.me/blog">https://zk.me/blog</a></td></tr></tbody></table>


# Privacy Policy

To learn more about our privacy practices and policies, please refer to the following policies for more information:

* [Official Website Privacy Notice](https://www.zk.me/privacy-notice)
* [App Privacy Policies](https://www.zk.me/app-privacy-policies)
* [ByteMe Privacy Policies](https://www.zk.me/byteme-privacy-policies)
* [Marketing Consent Policy](https://www.zk.me/marketing-consent-policy)


# Document Scanning Quality Requirements

Guidelines for high-quality document images to ensure accurate scanning. Key recommendations include lighting, focus & resolution, angles & framing, visibility, cleanliness.

{% hint style="success" %}
**Note:** While advanced, this system remains subject to fundamental physical limitations.
{% endhint %}

## Ensure Proper Lighting

Good lighting is essential for accurate OCR and document recognition. Avoid capturing images in overly dark or bright environments, as this can interfere with processing. Natural light or evenly distributed artificial light is ideal.

<figure><img src="/files/Nz50YOtyrglGDgLY8z3l" alt=""><figcaption></figcaption></figure>

***

## Minimize Reflections and Glare

Reflections and glare reduce recognition accuracy. Do not use your phone’s flash, and avoid shiny surfaces or lighting angles that create hotspots on the document.

<figure><img src="/files/f32110o8LR4vaISYkpeM" alt=""><figcaption></figcaption></figure>

***

## Keep the Image in Sharp Focus

A blurry photo can make it impossible to extract data. Make sure your camera is steady and the document is in clear focus before capturing. Hold the device still and allow time for autofocus to settle.

<figure><img src="/files/0CEV4dLaEsDV8GNPU8IO" alt=""><figcaption></figcaption></figure>

***

## Capture from a Straight Angle

Always photograph the document from a top-down, straight-on angle. Tilting the device or capturing at an angle may result in perspective distortion, making the document harder to process.

<figure><img src="/files/dqKq0AqpXvLd51hYdiZ9" alt=""><figcaption></figcaption></figure>

***

## Frame the Document Correctly

Maintain balanced margins around the document:

* If the frame is too tight, parts of the document may be cropped.

<figure><img src="/files/L5fmsPNNRvBRaCa4wUto" alt="" width="563"><figcaption></figcaption></figure>

* If too wide, the document may appear too small, affecting clarity.

<figure><img src="/files/E4SsSXMv5GoSnpuE3GQF" alt="" width="563"><figcaption></figcaption></figure>

Center the document and make sure all edges are visible.

***

## Ensure Clear Text Visibility

High contrast between the text and the background helps improve recognition. Avoid backgrounds that are too dark or too light, and ensure no visual obstructions are covering any part of the text.

<figure><img src="/files/Jpunpye9edm9qcfEcSsB" alt=""><figcaption></figcaption></figure>

***

## Use High-Resolution Images

Capture images at the highest possible resolution supported by your device. Low-resolution images lack the detail needed for accurate character recognition, especially for small fonts or fine print.

<figure><img src="/files/vS5CzQjKhInuiIy6vfyP" alt=""><figcaption></figcaption></figure>

***

## Keep the Frame Clean

Make sure no other objects (like fingers, pens, or nearby clutter) appear in the frame. These can block parts of the document and interfere with processing.

<figure><img src="/files/NnxMMKebXwzGBvGShaPG" alt=""><figcaption></figcaption></figure>

***

## Keep the Document Flat

Ensure the document is not folded, curved, or wrinkled when taking the picture. A flat, undistorted document ensures that all data can be captured and interpreted accurately.

<figure><img src="/files/6FcjQXJkRPzhgre16iDT" alt=""><figcaption></figcaption></figure>