🧾Zero-Knowledge KYC

Overview

Zero-knowledge Know Your Customer (zkKYC) is a solution concept for meeting KYC obligations while preserving user privacy. It utilizes zero-knowledge cryptography to prove statements without sharing any personal details. For example users can prove that they have passed KYC and are grown up without disclosing personal details, such as names or birthdays. The concept is based on a paper by Pieter Pauwels and extends it into a practical application on the Galactica blockchain. This builds synergies with other Galactica features, such as reputation, contingent transactions and DeFi.

In a nutshell, users can get KYCed through providers, called Guardian Nodes, and receive a self sovereign identity document, the zkKYC. It is verifiable on-chain and managed in a self custody wallet. Then users can prove statements, such as:

• Having passed KYC

• Being a real human

• Selective disclosures of personal details, e.g. being >= 18 years old or living in a particular city

Because this is done with a zero-knowledge proof (ZKP), the chosen statements can be verified without disclosing any other information that the statement itself. In other words, users can prove their age, without disclosing their birthday. They can prove being a compliant human in a country without sharing any ID details.

This leads to various use cases and advantages, that were not possible before:

• Online services can not misuse or leak user data, because they do not have it.

• Personal data can be used on-chain because it stays private.

• DeFi can be made compliant.

A detailed description of how it is embedded in Galactica as a whole can be found in the whitepaper.

Architecture and Interactions

There are 5 entities involved in zkKYC:

• User / Holder: The person that wants to prove being KYCed to use an on-chain DApp. The zkKYC is about the users personal details and managed in his self custody wallet (Galactica Snap for Metamask).

• Guardian Node: The KYC provider that validates personal documents.

• Verifier: The service requiring compliance from the user. It defines the requirements, the user has to prove with a ZKP and verifies it in a smart contract before giving the user access.

• Fraud investigation consortium: Set of legal authorities and institutions that can investigate fraud cases in a multi-sig like way if the zkZYC requires it for compliance. This process is explained in detail here: Galactica Investigation Module

• Galactica blockchain: Data registry for settling and verifying zkKYC in a decentralized and trust-less manner.

Entities involved in zkKYC and how they interact

Properties

• Data in the zkKYC is hashed into a decentralized identity (DID). It is added to a Merkle tree in a smart contract, so that users can prove that their zkKYC DID is included. Thus the DID stays hidden and only the Merkle root needs to be public for on-chain verification.

• Guardian nodes can not link personal details they review with any on-chain activity. There is a holder commitment that ties a zkKYC to a wallet address, but the verification of that link is hidden in the ZKP and therefore not disclosed.

ZKP Generation

There are standardized ZK circuits that generate ZKPs. The most basic one only discloses the fact that the user has a valid zkKYC and (if required) provides encrypted notes for the fraud investigation consortium. Verifiers can choose to extend the kind of proof that is required from users by adding selective disclosures. This allows them to build specialized use cases depending on personal data or compliance needs within specific jurisdictions.

The ZKP generation is performed locally by the user in the Galactica Snap for Metamask. It requires a confirmation from the user and displays what data the user is sharing publicly when generating and submitting a ZKP.

Private inputs

Private inputs are required to generate a ZKP and stay hidden from the verifier and other people on-chain. Only the holder can provide all those inputs together. For a basic zkKYC the private inputs are:

• Personal details in the zkKYC (name, date of birth, address, citizenship)

• Holder Commitment

• zkKYC expiration date

• Signature of the Guardian Node that issued the zkKYC

• Merkle proof showing that the zkKYC is included in the on-chain registry

• Signature of the holder to authorize using the zkKYC

Public inputs

Public inputs are disclosed on-chain for verification and defining the disclosed statement. For a basic zkKYC, these are:

• Merkle root hash for verification that the zkKYC is included in the on-chain registry.

• KYC Guardian public-key that issued the zkKYC

• Wallet address that can use the ZKP; can be different from holder wallet (see Privacy Precautions)

• Fraud investigation data if required (see Galactica Investigation Module)

• DApp specific HumanID (optional) for uniquely identifying a human, e.g. for voting

• Expiration date of the verification achieved with the ZKP (for increased privacy it is not the same as the zkKYC expiration date, it just has to be before it)

Compliance Model

Compliance on Galactica has a proactive and retroactive part. Both can be configured by DApps to fit to the regulation needs in their jurisdiction(s).

Proactive compliance works by users proving that they meet requirements before an on-chain transaction can succeed. The physical world example would be showing an ID card showing your birthday before you can enter a club. On Galactica, this can be done with a ZKP about the data in the user's zkKYC. So for example proving the age>=18 statement without showing any other details.

The first step is submitting the ZKP to become verified. The verification is saved on-chain in a Verification SBT. As long as it is valid the user does not need to repeat the same ZKP. In a second step, the user can use the DApp as on traditional EVM chains.

Another possibility for proactive compliance are Contingent Transactions for ensuring the compliance of token transactions, even as receiver.

Retroactive compliance is required by some jurisdictions to investigate fraud cases after they happened. For example, this could be an investigation of a wallet that moved funds through a compliant DApp on Galactica. It is explained here: Galactica Investigation Module To provide this possibility, ZKPs can include encrypted notes to responsible institutions.

Data Flow

The diagrams below visualize the data flow of zkKYC during creation and verification. It shows the data in the example of a ZKP proving the ownership of a valid zkKYC and being at least 18 years old.

Data flow during zkKYC creation, issuance and storage

Data flow during zkKYC proof generation and verification

Generalization to zkCerts

The concept and technology behind zkKYC can be generalized to zero-knowledge certificates (zkCerts). Besides KYC data, zkCerts can also hold any kind of structured data, such as education diplomas, memberships and property ownership certificates. This can unlock new blockchain use cases by bringing personal data on-chain in a private and compliant way. In the generalized way, zkCerts provide a solution for self sovereign identity (SSI).

For interoperability and network effects, zkCerts are standardized. Each zkCert contains the following fields:

Field	Description	Technical details
Holder commitment	Commitment linking the zkCert to a user account. Usage of link hidden in ZK.	See Holder Commitment
Provider signature	Signature of the provider, for example, the KYC Guardian
Content hash	Hash of the custom key-value data of the zkCert	Hash(list of key-value fields ordered alphabetically by key)
leaf hash	Leaf of the Merkle tree	Poseidon([content_hash, provider_signature, holder_commitment, random_salt])
DID	Decentralized identifier of zkCert	did:zkCertStandard:leaf_hash Example for standard (gip1)

The hashes are computed using the zero-knowledge efficient Poseidon algorithm.

The content hash provides the flexibility to represent any kind of data contained in the zkCert. It is defined by a list of key-value pairs that are specified in the zkCertStandard. For zkKYC this is gip1.

Coming Soon: Git Repository for Galactica Improvement Proposals where zkCertStandards are going to be specified.

Off-chain use

The zkKYC concept uses an on-chain registry for verification if a zkKYC has been issued. Naturally the verification can be implemented as smart contracts on Galactica for automation, decentralization and integration into an on-chain service. In this case, the ZKP is submitted in an EVM transaction and publicly viewable with the selective disclosures it proves.

Alternatively zkKYCs can be used off-chain. User can also submit ZKPs in some other way. The verifier can run the verification offline and only has to read on-chain if the Merkle root confirms the existence of the zkKYC. This way the ZKP and the selective disclosures can stay offline.

Revocation and sparse Merkle Trees

ZkCertificates on Galactica can be revocable depending on the registry they are issued in. ZkKYC is a revocable zkCert because guardians need to be able to correct mistakes. To support this, the zkKYC registry uses sparse Merkle trees where leaves can be changed multiple times. This has the disadvantage that Merkle proofs can become invalid and the user needs to update the Merkle proof to generate a ZKP matching the Merkle root. The Galactica ZK Vault Snap offers methods to update Merkle proofs and can call a REST endpoint of the Galactica node to fetch a new Merkle proof. The latter option is the default because it provides a fast user experience. The zk-certifiacte package provides tools to reconstruct Merkle trees from on-chain logs to generate Merkle proofs independently without querying a Galactica node for a specific zkCert hash.