zkMe Protocol Smart Contract

Overview of the Smart Contracts (SC) developed by zkMe for the processing of the zkMe Network.

Smart Contract 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, minting an SBT asset directly to the Holder SSI wallet, The zkMe SBT, which contains the holder's DIDs, a key share, and most importantly the pointer to the verified ZKP. This process ensures that the Holder is able to securely own their Identity on-chain.

zkMe Mint address (Polygon Mainnet): 0x5c2bfcf9c17CD53d55033769727196736CD188b3

Please check:

zkMe Delegate

The goal of the zkMe Delegate Smart Contract is making copies of the user’s on-chain Identities available on the chain ecosystems in which the user is active in.

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.

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.

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.

Currently, zkMe SC is compatible with the following chain ecosystems:

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 of 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 verified.
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.

PreviousWhich chains we live on NextCommon Issues & Solutions

Last updated 2 months ago