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 DelegateMainnet AddressTestnet AddressGithub link

Aptos

coming soon

0xaed725b099b49a53a56fccd9e0316052416ec78798491de2d7e651dfc57ce411

coming soon

Arbitrum

0x1E3D352CA8E843AC59FdE9AD605Ba1C57813Fa0b

0x270A49849E1400867a1343b4621c458d1F81190a

coming soon

Avalanche

coming soon

0x270A49849E1400867a1343b4621c458d1F81190a

coming soon

Base

0x5c2bfcf9c17CD53d55033769727196736CD188b3

0xD923a27A8b7cf8C9f3dFA022851B503a55b095a9

coming soon

BNB Chain

0x5c2bfcf9c17CD53d55033769727196736CD188b3

0x270A49849E1400867a1343b4621c458d1F81190a

coming soon

BounceBit

0x5c2bfcf9c17CD53d55033769727196736CD188b3

coming soon

coming soon

Ethereum

coming soon

0xc32d204404F33FF38Fee42394F7E671fd96314B3

coming soon

Fantom

coming soon

0x270A49849E1400867a1343b4621c458d1F81190a

coming soon

Linea

coming soon

0x270A49849E1400867a1343b4621c458d1F81190a

coming soon

Manta

0x5c2bfcf9c17CD53d55033769727196736CD188b3

0x270A49849E1400867a1343b4621c458d1F81190a

coming soon

Mantle

coming soon

0x270A49849E1400867a1343b4621c458d1F81190a

coming soon

Neutron

neutron19t7s6aa9289e563mu9qrx5nh80xtn4vr5afdu8yctej6f7w6k9usv87acp

neutron1g374hrmmn92vpurtppdwsnrrhrftz7ky2g55n5c4f22gfaeyrwpqq06cef

coming soon

Opside

coming soon

0x270A49849E1400867a1343b4621c458d1F81190a

coming soon

Optimism

coming soon

0x270A49849E1400867a1343b4621c458d1F81190a

coming soon

Polygon

0x3b3364656BbB7A23133e3f26D7F6850acfaAc394

coming soon

coming soon

Ronin

0x5c2bfcf9c17CD53d55033769727196736CD188b3

coming soon

coming soon

Scroll

coming soon

0x270A49849E1400867a1343b4621c458d1F81190a

coming soon

Sei

coming soon

sei1dmwr4e6k4n0dlwtkh598sxp2al3wvkvwew658r3cqx98648uqhcs7sd38d

coming soon

Solana

6tVnLV3qrA7HddTzRGmeZs1cy5rAcTFs9sQiaoLbENAM

6tVnLV3qrA7HddTzRGmeZs1cy5rAcTFs9sQiaoLbENAM

coming soon

Sui

coming soon

coming soon

coming soon

X Layer

0x1E3D352CA8E843AC59FdE9AD605Ba1C57813Fa0b

coming soon

coming soon

ZetaChain

coming soon

0xf8E1973814E66BF03002862C325305A5EeF98cc1

coming soon

zkSync

coming soon

0x4630e45Edb00298Eb7872FC5e237f6f0CE4995dF

coming soon

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 VerifyMainnet AddressTestnet AddressGithub link

Aptos

coming soon

0x3e642b9d2845aa4efa3cdeb18acf6c7cd93112e4836a53e78f4b541e42a244b8

coming soon

Arbitrum

0x399488687fc3618FFaf1f5d0f61397c8E0360c02

0xf8E1973814E66BF03002862C325305A5EeF98cc1

coming soon

Avalanche

coming soon

0xf8E1973814E66BF03002862C325305A5EeF98cc1

coming soon

Base

0x8c81bbc5cC9B6cdbb5c0e5DD8b9D5bfaF3575710

0xF58De9599C57bBAD68Fea0F39b73913daFcf0976

coming soon

BNB Chain

0x3919BdCe285E82CDC6585979cfd71636b33A5582

0xf8E1973814E66BF03002862C325305A5EeF98cc1

coming soon

BounceBit

0x399488687fc3618FFaf1f5d0f61397c8E0360c02

coming soon

coming soon

Ethereum

coming soon

0xD231fF30102B34446035BA327ad4c596a5231cE3

coming soon

Fantom

coming soon

0xf8E1973814E66BF03002862C325305A5EeF98cc1

coming soon

Linea

coming soon

0xf8E1973814E66BF03002862C325305A5EeF98cc1

coming soon

Manta

0x3919BdCe285E82CDC6585979cfd71636b33A5582

0xf8E1973814E66BF03002862C325305A5EeF98cc1

coming soon

Mantle

coming soon

0xf8E1973814E66BF03002862C325305A5EeF98cc1

coming soon

Neutron

neutron19t7s6aa9289e563mu9qrx5nh80xtn4vr5afdu8yctej6f7w6k9usv87acp

neutron1g374hrmmn92vpurtppdwsnrrhrftz7ky2g55n5c4f22gfaeyrwpqq06cef

coming soon

Opside

coming soon

0xf8E1973814E66BF03002862C325305A5EeF98cc1

coming soon

Optimism

coming soon

0xf8E1973814E66BF03002862C325305A5EeF98cc1

coming soon

Polygon

0x78D247ff4543Ef08488A1127034c2cE54B12A926

coming soon

coming soon

Ronin

0x3919BdCe285E82CDC6585979cfd71636b33A5582

coming soon

coming soon

Scroll

coming soon

0xf8E1973814E66BF03002862C325305A5EeF98cc1

coming soon

Sei

coming soon

sei1dmwr4e6k4n0dlwtkh598sxp2al3wvkvwew658r3cqx98648uqhcs7sd38d

coming soon

Solana

6tVnLV3qrA7HddTzRGmeZs1cy5rAcTFs9sQiaoLbENAM

6tVnLV3qrA7HddTzRGmeZs1cy5rAcTFs9sQiaoLbENAM

coming soon

Sui

coming soon

coming soon

coming soon

X Layer

0x399488687fc3618FFaf1f5d0f61397c8E0360c02

coming soon

coming soon

ZetaChain

coming soon

0xA018F0593C1C3F62A68c3fc3B9D593961B207d96

coming soon

zkSync

coming soon

0xdbd9E736562584DB3fA1C5F39A47C2071DE0D5cb

coming soon

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.

Last updated