Zero-knowledge KYC prevents data honeypots and massive surveillance. However, on its own, it isn't sufficient for cases where regulators or law enforcement need to investigate users suspected of criminal activity.

As a result, maintaining honeypots has become a necessary compliance practice: organizations store sensitive data that is frequently breached, just to make sure it remains available for investigations.

Solving The Dilemma: Proof of Clean Hands With Human Network

While ZK proofs (ZKP) aren't trivial, ZKPs with compliance are even more complex. Holonym has built Human Network, an AVS on EigenLayer that allows provable threshold encryption, to unlock ZKPs with programmable privacy for selective and consensual disclosure. The network allows developers to hard-code policies that require pre-existing conditions to occur before a third party can decrypt user data. Users can verify and encrypt their data to the Network's key to create ZKPs which can be "decrypted" by pre-approved parties only when a smart contract is triggered.

While this function can be used to gate any sort of data behind programmable policies, it is especially useful for provable encryption of identity.

Human ID packages this functionality into a very easy to use solution called that serves as a general-purpose tool for meeting compliance requirements.

Once a user has a proof-of-clean-hands SBT (soul bound token), we know the data is encrypted to an observer that can only decrypt a small amount of data per day, making surveillance or honeypots impossible while enabling compliance with law enforcement and regulators.

For more information, see the architecture:

Or usage:

If you need support when verifying your identity using Human ID, please follow the steps below:

1. Review or search the contents of this site, especially our .

2. Click on the support icon in the bottom right corner of this page — or in the Human ID app — to get in contact with a support agent.

Thank you!

The Human ID verification process consists of two key stages:

1. Issuance of Credentials – Obtaining credentials through identity verification.

2. Proving Facts About Credentials – Demonstrating specific details without revealing unnecessary personal information.

Issuance

On the , users scan a QR code to begin the verification process by photographing the required identity documents.

Proving

In the proof section, users select a wallet address to link their verified proof. Once the user has a Human ID, they can generate proofs of unique personhood, with more proof types planned for the future. To do so, visit , where they will receive a soulbound token confirming whether their address belongs to a unique person.

You can verify your ePassport using Holonym's Private Passport Verifier to increase Sybil resistance score. Verification is free.

To perform the ePassport verification using your NFC passport, follow the steps below:

1. Navigate to https://silksecure.net/holonym/diff-wallet.

2. Click the "ePassport" card.

3. Follow the steps to download the Private Passport Verifier mobile app.

4. Open the Private Passport Verifier app. Follow the steps to enter your information. Then scan your NFC passport.

5. After scanning, you will be redirected to .

6. At this page, a zero-knowledge proof is generated. This zero knowledge proof conceals your private information while proving that you are a unique person.

7. Enter your wallet address. Click submit. When you click submit, your address will receive a soul-bound token (SBT) attesting to your uniqueness.

Note that you can only receive one SBT per NFC passport.

Human ID is a privacy-preserving identity protocol developed by Holonym Foundation for the framework. Human ID uses zero knowledge proofs to allow for proving facts about oneself without revealing the whole identity, enabling organizations and smart contracts to verify their users without storing any sensitive information.

Motivation

Identity verification is often required for legal or practical reasons such as KYC, fraud prevention, proof-of-age, and Sybil resistance. However, verifying identity while also preserving privacy has historically been difficult. This problem is even more prominent in web3, where data is stored on a public ledger. Not only is obtaining privacy on a blockcchain difficult, but the adverse affects of losing privacy are greater: "doxxing" a user's wallet address once reveals all of the address' past and future activity.

Actors and actions in Holonym

At a high level, the Holonym system can be understood in terms of the following actors and actions.

Actors

• User. Someone who receives credentials and prove facts about themselves, often for the purpose of fulfilling requirements set by an organization.

• Issuer. A party that issues credentials to users. In the process of issuing credentials, an issuer may use 3rd party identity providers to verify users' identities.

• Consumer. A party that modifies its users' access or actions based on the facts its users have proven about themselves using. For example, an organization may require its users to reside in a certain country in order to vote on certain proposals.

Actions

1. Issuer issues a credential to a user. In the user flow, this step is called "issuance".

2. User proves facts about themselves using their credentials. In the user flow, this step is called "proving".

3. Consumer allows a user to access something or to perform an action, depending on what the user has proven.

In order to use Human ID with Stellar, follow the steps below:

1. Visit https://silksecure.net/holonym/diff-wallet with an already-funded wallet you would like to use to pay fees on Aurora, Ethereum, Optimism, or Avalanche.

2. Follow the steps to get the proof of unique government ID or phone.

3. When you prove, enter your Stellar address that you want the uniqueness proof to be publicly linked to.

Now you're done! You've obtained the uniqueness proof for the Stellar SBT.

In order to use Human ID with NEAR Protocol, follow the steps below:

1. Visit https://silksecure.net/holonym/diff-wallet if you have an already-funded wallet you would like to use to pay fees on Aurora, Ethereum, Optimism, Avalanche, or Fantom.

2. Visit https://silksecure.net/holonym/silk if you do not already have a funded wallet on these chains or want to use the Human Wallet for other reasons.

3. Follow the steps to get the proof of unique government ID or phone.

4. When you prove, enter your NEAR account ID that you want the uniqueness proof to be publicly linked to.

Now you're done! You've obtained the uniqueness proof for the NEAR SBT. You can use it with sites like to prove that you are a unique person!

If you verification was unsuccessful, please follow the steps below to begin the refund process:

Step 1: Watch the Video Guide (Optional)

To make the process easier, you can watch this helpful video guide that walks you through the refund steps: Watch the Video Guide

Step 2: Visit the Refund Link

Click on the following link to initiate the refund process:

Step 3: Find the "Eligible for Refund" Label

Once you're on the page, locate the "Eligible for Refund" label next to your cards.

Step 4: Click on the Refund Label

Click on the "Eligible for Refund" label to access the refund page.

Step 5: Complete the Refund Process

Follow the on-screen instructions to finalize your refund.

We hope this guide, along with the video, helps you complete your refund process smoothly. Let us know if you have any questions!

Credential storage

Credentials are stored by the Human Wallet self-custodial wallet so that other than the user who owns them, nobody can access them.

When the user scans government IDs, the data is not stored in Holonym servers. For modern NFC-based ID and Aadhaar verification, a ZKP is created without Holonym ever seeing the data. For older types of government ID verification that do not involve ePassport NFC reading, the user data briefly passes through Holonym servers so that Holonym can sign the credentials, attesting to their authenticity, to return to the user. Data is immediately deleted from Holonym servers and from the KYC provider's servers after the signature is generated. Even if the user does legacy credential verification and does not trust a KYC provider, the protocol gives additional privacy guaranteed: Each user's ID is anonymized in what we call the Privacy Pool, i.e. an anonymity set. The Privacy Pool exists to break the link between a user's identity and a user's crypto address. This creates a level of privacy where even if Holonym, an issuer, or anyone tries to surreptitiously collect user data, they still cannot identify user wallets.

Proof storage

Proofs can be submitted on-chain or off-chain. Proofs, such as "I am a unique person" should not contain sensitive information. The Holonym website and app only permit proofs that do not give sensitive data, regardless of whether they're on- or off-chain.

Anybody can make an issuer, as this protocol is decentralized at the base layer. Of course, issuers of credentials should be trusted, despite the fact that anybody can create an issuer. Furthermore, Holonym Foundation operates the frontend and can integrate the issuer into the frontend, so we recommend reaching out in the discord to talk to us and the community before making a custom issuer.

Holonym applies modularity to the identity verification stack. This fixes a trilemma of security, flexibility, and privacy in identity verification. It has historically been difficult to combine the benefits of centralization (e.g., rigor and ease of use) with decentralization (e.g., flexibility, privacy, and composability). Holonym introduces four layers of identity verification to enable "best of both worlds" approaches.

1. Issuance layer

2. Privacy layer

3. Audit layer

4. ReLayer

Issuance layer

Unlike blockchains which benefit from being decentralized, some use cases of identity benefit from being centralized. The most common form of rigorous identification is government ID, as centralized as possible. Governments have successfully disbursed over $1 trillion in annual benefits with a relatively low amount of benefit fraud through identity theft. They have been able to conduct large-scale elections using identity to prevent fraudulent votes. These have been possible due to extensive personal information governments are privy to.

Privacy layer

While there is clearly utility (e.g., social security, secure voting processes) in having an institution like a government privy to personal information, the other risks of centralization should be mitigated. Thus, we introduce a privacy layer to separate the issuer from all other aspects of the protocol. This way, an issuer's power is only limited to verifying once; it cannot track subsequent actions of a user.

The privacy is obtained by a global Merkle tree of all credentials. For more information, see

or

Audit Layer

Regulators often need to investigate activities when something goes wrong. Not having identity data available for regulators is illegal in most countries and can have penalties exceeding $100M. Currently, companies record all user activity to have an audit record for regulators, as there has been no other way to comply. In current systems, absent of a way to selectively enforce data privacy, every user is monitored regardless of whether or not they are being investigated.

However, in Holonym, the user can be required to encrypt their own audit trail to the data audit layer. The audit layer should have two functions: data availability and permissioned access, which can in turn be two separate layers. Permissioned access involves a smart contract that ensures that nobody can unscrupulously spy on user activity without proper consent or a court order. It enforces that only certain actors under certain conditions can decrypt the data, allowing for provable privacy for honest users while retaining regulatory oversight for bad actors. These conditions are enforced via a smart contract rather than trusting a third party to maintain privacy.

ReLayer

The relayer layer is the way in which zero-knowledge proofs are sent. Sending and receiving reveal IP addresses and/or wallet addresses if gas is needed. Currently, Holonym uses a relayer to submit transactions and hide the address they came from. It is important that this layer remains flexible so that a relayer node can be replaced by a relayer network, and mixnets can be employed to hide IP addresses.

To put the proofs on-chain, a Verifier and Relayer are used. The Verifier attests to the proof being complete (since the proof size is too large to cheaply be put on-chain ) and the Relayer posts the attestations on-chain to the Hub contract. We plan to progressively decentralize this Verifier by achieving consensus amongst a permissionless set of verifiers.

Hub Contract

Before a user can submit a proof on-chain, the Hub ensures

1. An allowed verifier, either a server, network, or smart contract, has verified a VOLE-based ZKP

2. This verifier has posted any necessary data off-chain so others can check its steps in verifying the proof

3. Any nullifier revealed by the ZKP has not been spent

Once a proof is on-chain, the Hub sends a non-transferable ERC721 representing a SBT. The Hub also allows reading the relevant metadata pertaining to the SBT, i.e. the public values of the corresponding proof, via the method getSBT.

For more information, you may look at the

Architecture

The Human ID protocol consists of the following components:

• Client (website or mobile app)

• Issuers (either using the Human ID credential format or custom formats such as ICAO9303 for NFC passports issued by the government)

• Hub smart contracts (1 per chain)

• Relayer

The flow of data is outlined in the action sequence described in the section. The following describes the flow of data in more detail. The diagram illustrates the issuance+storage (designated by 1.*) and proving (designated by 2.*) steps. An organization can grant access to users based on the results stored in the proof contract.

1.1. User verifies themself to an issuer

1.2. The issuer signs credentials

1.3. The user generates a proof that credentials were sigend with particular attributes

1.5. User encrypts their credentials client-side. The encryption key is generated from the user's signature.

1.6. User stores their encrypted credentials in the Human Wallet

2.1. User generates a proof and (e.g., a proof that they are a US resident) and submits it to the verifier

2.2. The verifier attests to it and returns it to either the user or the relayer, depending on how the attestation is to be consumed

2.3. The attestation is given to the recipient: either the Hub smart contract or an offchain consumer

Human ID has dry run flows. These allow developers to (a) complete verification flows and (b) get mock SBTs on testnet while they are integrating Human ID into their dapp.

Get mock SBT

Option A: With Human Wallet SDK

...

Option B: With Redirect

...

Read mock SBT

Use the Holonym API to query the . For the network option, specify "base-sepolia" instead of "optimism".

If you want to run an observer, please reach out to the Human ID team.

Overview

The observer is a component of the Clean Hands Stack for programmable privacy, used for GDPR-compliant storage of encrypted user data with the DecryptBabyJubJub method for KYC.

The observer is a primary component in the Clean Hands stack with . To interact with the observer, a user generates a ZKP they have passed sanctions checks, and this ZKP outputs the ciphertext of the user's personal identifiable information (PII) and the user's associated blockchain address. The Observer's role in this system is to verify ZKPs, issue attestations to users with valid ZKPs, and to store the public outputs of these ZKPs so that the ciphertext can be decrypted if Human Network permits.

Political, social, and economic systems often need Sybil resistance. Sybil resistance is anything of the form:

1 person => 1 x

e.g.,

• 1 person => 1 vote (democracy)

• 1 person => 1 stimulus check

Before a user can submit a proof on-chain, the Hub ensures

1. An allowed verifier, either a server or smart contract, has verified a VOLE-based ZKP

2. This verifier has posted any necessary data off-chain so others can check its steps in verifying the proof

3. Any nullifier revealed by the ZKP has not been spent

Human ID's Proof of Clean Hands establishes that a user

1. has completed KYC,

2. has verified that they are not on any sanctions or PEP lists,

3. has encrypted their identifying data to Human Network, and

4. has selected a smart contract that determines the conditions under which their data can be decrypted.

Components

The Clean Hands system is made possible by the following:

• Credential issuer.

• Zero knowledge circuit.

• Observer node.

• Smart contract(s).

The novelty of the Clean Hands system is in its encryption and decryption. Each user encrypts their data to Human Network and proves encryption. When they encrypt, they select a smart contract that determines who is allowed to decrypt. The user's ciphertext is sent to an "observer" node. An entity granted access to the user's ciphertext by the observer node and granted decryption rights by the smart contract can decrypt the user's ciphertext.

Flow

There are five steps in the Clean Hands flow.

1. Credential issuance

The user verifies their identity and that they are not on any sanctions or PEP lists. Human ID's credential issuer issues a signature to the user attesting to the veracity of the user's identity data and sanctions list status.

2. Proof generation

The user generates a zero knowledge proof. This proof uses the credentials and signature issued by the credential issuer. The proof establishes that the user has completed KYC and sanctions list checks and that they have encrypted their name and date of birth to Human Network. At this step, the user also signs, using the ephemeral private key used in encryption, the address of a smart contract. This smart contract determines who can decrypt the user's data.

3. Attestation issuance

The user sends the proof to an observer node. The observer verifies the proof, stores the proof's public outputs so that the user's ciphertext can be retrieved at a later date by authorized entities, and issues an on-chain attestation to the user. This attestation attests to the fact that the user has completed all of these first 3 steps.

4. On-chain activity

With the attestation, the user is now able to interact with smart contracts that require proof of clean hands, for example, which allows verified users to transaction privately.

5. Decryption

If necessary, the ciphertext from the user’s zero knowledge proof is decrypted. The entity that wants to decrypt must request the user's ciphertext from the observer. They must also be granted decryption rights from the smart contract associated with the ciphertext. With the ciphertext and decryption rights, the decrypter requests decryption from Human Network.

Lists checked for Proof of Clean Hands

• US / OFAC Capta List (CAP)

• US / OFAC Non-SDN Chinese Military-Industrial Complex Companies List (CMIC)

• US / BIS Denied Persons List (DPL)

• US / DOS ITAR Debarred (DTC)

What it enables

We implemented an () VOLE-based prover to enable fast identity proofs that otherwise aren't practical to do with privacy. Privacy requires all proofs to be done on consumer hardware without expensive servers. Yet most interesting proofs such as NFC-enabled passports and email proofs require expensive RSA, SHA256, or Keccak256 operations. The prover can take the existing circuits in circom, where these primitives have already been implemented and audited. We have utilized this to allow mobile browsers to perform proof of passport in seconds without running out of memory.

Users can opt to receive SBTs on Stellar. See Using Human ID with Stellar for user-facing instructions.

Off-chain

Use the Stellar SDK to simulate a read transaction to get the user's SBT.

On-chain (Soroban)

1. Fetch the wasm for the Human ID SBT contract.

2. Incorporate into your Soroban contract.

This example contract has a get_sbt function that simply wraps the function from the SBT contract.

Check out the full .

For the list of circuit IDs, see .

Human ID's Proof of Personhood via KYC consists of the following components:

• User agent (UI)

• Human ID server

• ID verification provider

• Verifier

The flow of data is outlined in the following sequence diagram. Please refer to notes for detailed explanations for relevant parts.

Issuance and Proving

Sections 1 and 2 in the sequence diagram constitute issuance. This is where the user's private credentials are issued.

Section 3 is proving, where the user proves facts about their issued credentials.

Notes on handling of user data by IDV Providers

Following data are requested by IDV providers as photo or/and video stream during the verification process.

• Selfie (photo, video stream)

• One of the following documents

  • Passport

  • Driver License

Currently, following IDV providers are supported.

Veriff has clearly outlined in its

• a list of compliances (i.e: GDPR)

• regarding data collection, retention and deletion

  • a list of

Onfido has its

• a list of

• regarding data

Facetec has two privacy policies ( and )

SDK privacy policy seems more relevant for usage for ID verification. Its documentation on privacy is sparse compared to the other 2 providers.

• In article #2, it mentions that any data sent to its server is encrypted, siloed and is never stored with any additional personally identifiable information (PII).

• In article #6, it provides detailed info on its compliance to GDPR for EU residents.

Notes on client-side encryption of IDV session result

IDV provider returns the session result to user.

With Human Wallet:

The result is encrypted on client-side using a derivative of the PRF.

With other wallets:

The result is encrypted with key derived with hash(userSignature(aConstantMessage)) to generate ciphertext.

Notes on ciphertext and storage of userCredentials

Only the encrypted ciphertext which is non PII is stored in Human ID database as below.

View to see the data included in user credentials.

Notes on verifier and SBT issuance

The user submits a zero knowledge proof of uniqueness () to the verifier server. The verifier verifies the ZKP, and upon verification, issues a soulbound token to the user. The circuit ID, issuer address, expiry, and actionNullifier, the ZK proof are embedded in the Soul-bound token.

Holonym issues an Sign Protocol attestation for every SBT it sends. The following is an example of how to query and validate Holonym attestations.

Query

See the for how to construct queries.

This query gets the first page of attestations issued by Holonym.

Query parameters used:

Human ID issues its Clean Hands attestation to users who prove that they are not on any sanctions lists (see all the lists here: ).

Off-chain with Sign Protocol

Use Sign Protocol's scan API to see whether a user has a valid Clean Hands attestation.

While Holonym can be used off-chain it is by far most commonly used on-chain. We use the term Soul-Bound Token (SBT) to refer to an on-chain record linked to a user's address. To use Holonym, you simply must direct the user to get their SBT, then you can read the SBT from from our API in one line of code, or from the blockchain itself.

1. Send a user to Holonym to get an SBT

Option A: Via Link or Redirect

You may send the user to

credentialType is one of:

• gov-id (for government ID credentials).

• clean-hands (for sanctions checks).

• phone (for phone number credentials).

ePassport

Users can also verify for free using an NFC-enabled government ID document. Please see for user instructions.

Note that the ePassport SBT is distinct from the gov-id SBT. A user can get both an ePassport SBT and a gov-id (KYC) SBT.

Option B: Via Human ID SDK

To directly embed Human ID into your website, you can import the and call

where credentialType is either 'kyc' (for government ID credentials), 'clean-hands', 'phone' (for phone number credentials) or 'biometrics'. This will prompt the user to complete the SBT minting flow.

2. Read a user's SBT

Option A: Holonym API

To check whether a user has a certain SBT, you can query the Holonym API. The JavaScript example shows how to call the Holonym API (which calls the SBT smart contract) to get whether the user is unique for the given action ID. (Use the default action ID of 123456789.)

Option B (DEPRECATED): On chain

You can call the SBT contract directly. The Solidity example gives anyone 1 gwei who has proven they're from the US. (See more examples in the .)

You may have noticed one person can claim the gwei many times in the Solidity example! This an example; please do not implement a US stimulus program from it.

Example: Sybil Resistance

1. Send users to Holonym to get government ID uniqueness SBTs

Send users to the following URL.

Users will complete verification and get an SBT at the address of their choosing.

2. Read users' uniqueness SBTs

The below JS example checks whether an address belongs to a unique person.

The smart contract in Solidity gives a privacy-preserving airdrop once-per-person to only unique people.

Holonym issues a Verax attestation for every SBT it sends. The following is an example of how to query and validate Holonym attestations.

Install

npm i @verax-attestation-registry/verax-sdk

Code

In this example, we check the attestation for the address 0xdcA2e9AE8423D7B0F94D7F9FC09E698a45F3c851.

It's important to filter for Holonym's schema ID and attester account and to validate the attestation payload. Here, we are making sure the user has a uniqueness KYC SBT.

See for the circuit IDs, action ID, and issuers.

Endpoints

• GET /sybil-resistance/gov-id/<network>

• GET /sybil-resistance/epassport/<network>

GET /sybil-resistance/<credential-type>/<network>?user=<user-address>&action-id=<action-id>

Get whether the user has registered for the given action-id.

When a user "registers", they are establishing that the given blockchain address is a unique person for the action ID. See the section Sybil resistance for more information about how action IDs can be used.

If credential-type is gov-id, this endpoint uses Holonym smart contracts to check whether the user has completed KYC with a unique government ID. If credential-type is epassport, this endpoint uses Holonym smart contracts to check whether the user has a unique NFC-enabled passport. If credential-type is phone, this endpoint uses Holonym smart contract to check whether the user has proven ownership of a unique phone number. If credential-type is biometrics, this endpoint uses Holonym smart contract to check whether the user has proven ownership of a unique (non-personally identifying) face.

See the following documentation for how to use action IDs.

• Parameters

  name

  description

  type

  in

  required

GET /residence/country/us/<network>?user=<user-address>

Get whether the user resides in the US.

For the /residence/country/<country-code> endpoints, <country-code> will be a 2-letter country code following the . Holonym currently only supports queries for US residency.

• Parameters

  name

  description

  type

  in

  required

GET /snapshot-strategies/residence/country/us?network=<network>&snapshot=<snapshot>&addresses=<addresses>

Returns a list of scores indicating, for each address, whether the address has submitted a valid and unique proof of US residency.

Every score is either 1 or 0.

Use with Snapshot

To use with the Snapshot strategy, specify the strategy parameters using the following format.

Use without Snapshot

• Parameters

  name

  description

  type

  in

  required

GET /snapshot-strategies/sybil-resistance/gov-id?network=<network>&snapshot=<snapshot>&addresses=<addresses>&action-id=<action-id>

Returns a list of scores indicating, for each address, whether the address has submitted a valid proof of uniqueness for the given action-id.

Every score is either 1 or 0.

Use with Snapshot

To use with the Snapshot strategy, specify the strategy parameters using the following format. We highly recommend that projects use the default action-id 123456789 to avoid cases where users sell actions associated with action-ids that they do not care about.

Use without Snapshot

• Parameters

  name

  description

  type

  in

  required

GET /snapshot-strategies/sybil-resistance/phone?network=<network>&snapshot=<snapshot>&addresses=<addresses>&action-id=<action-id>

Returns a list of scores indicating, for each address, whether the address has submitted a valid proof of uniqueness (using phone number) for the given action-id.

Every score is either 1 or 0.

Use with Snapshot

To use with the Snapshot strategy, specify the strategy parameters using the following format. We suggest that you use the default action-id 123456789. If you are using a different action-id, replace 123456789 with your action-id.

Use without Snapshot

• Parameters

  name

  description

  type

  in

  required

GET /snapshot-strategies/sybil-resistance/biometrics?network=<network>&snapshot=<snapshot>&addresses=<addresses>&action-id=<action-id>

Returns a list of scores indicating, for each address, whether the address has submitted a valid proof of uniqueness (using non-personally identifying face vectors) for the given action-id.

Every score is either 1 or 0.

Use with Snapshot

To use with the Snapshot strategy, specify the strategy parameters using the following format. We suggest that you use the default action-id 123456789. If you are using a different action-id, replace 123456789 with your action-id.

Use without Snapshot

• Parameters

  name

  description

  type

  in

  required

Human ID Standard Credential Format

A leaf is an element of a Merkle tree. Merkle trees allow for efficient and anonymous proofs of set membership in zero-knowledge. Leaves are Poseidon hashes of 6 254-bit field elements:

Note that while credentials can only have 2 issuer- fields, nothing prevents these fields from representing more: they can be set to the hash of unlimited custom fields

Nullifier Secret

The nullifier secret is a value that only the user knows. Because it is pseudorandom, the preimage of the leaf cannot be guessed without at least brute-forcing the secret, which is infeasible at 16 bytes. Thus, even if the other fields are predictable, the credential will still be anonymous without knowing the secret. In this way, it acts as a pepper, obscuring the preimage from the publicly known digest.

It also has a particular property allowing for sybil resistance: credentials can be spent for a specific use case by publishing a salted hash of the secret pepper. We refer to this as a hashbrown because it is a mixture of salt & pepper_._ Accurate computation of the hashbrown can be verified in a ZKP without revealing the pepper. Some use cases of involve anonymous reputation, anonymous voting, bot prevention, and fair airdrops. For example

Whenever a user votes in an election with actionID abc123, they must publish hash(abc123, secret) . And they generate a proof that the result came from abc123 and secret . This hash then gets added on-chain, so the user can never vote again without people seeing they're trying to "double-spend" their secret.

Leaf Formats of Holonym Foundation Issuers

Holonym Foundation provides two issuers, though others are encouraged to create more issuers.

Government ID Issuer

Phone Issuer

Biometrics Issuer