Proof of Clean Hands: Introduction
Mar 14, 2025
ZK ID with Transparent Accountability for Private Identities and Transactions
“Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn’t want the whole world to know, but a secret matter is something one doesn’t want anybody to know. Privacy is the power to selectively reveal oneself to the world.” – Cypherpunk Manifesto
Crypto needs a way to prevent hackers and bad actors (like North Korea’s Lazarus group) from using privacy protocols to funnel stolen funds without compromising privacy for everybody else. This article provides an overview of how Human ID’s Clean Hands verification solves this long-standing challenge, refuting the arguments for both mass surveillance and for crypto as an effective black-market tool.
TL:DR
Human ID's Proof of Clean Hands is zero-knowledge identity proof, combining standard KYC checks with on-chain integrity checks.
Clean Hands enables regulatory compliance through programmable privacy, establishing audit trails for malicious actors without compromising privacy for legitimate users.
User data remains private by default, unless collaboratively decrypted by Human Network (secured by billions in staked ETH) based on smart contract conditions and on-chain policies.
Applications can define fine-grained privacy controls to suit data availability requirements across jurisdictions and specific product needs. This ground-up, preemptive approach creates a safer surface where privacy and accountability coexist through cryptographic guarantees.
Build it and the anons will come
This adage is especially true for privacy-conscious users that have flocked to tools like Tornado Cash, Z Cash, and Monero. Privacy on the internet is critical to prevent authoritarian abuse of technology, provide protection for whistleblowers, and more generally helps drive efficient markets by dissociating real world from functional identities, known as nyms.
Privacy happens to also be a great tool for well-organized entities that operate from behind the shadows with little-to-no accountability. In fact, over $7 billion USD of ill-gotten funds have been laundered using crypto privacy tools intended to protect the free-speech of everyday people. North Korea’s Lazarus Group, alone, has laundered over $900M of stolen funds using mixers and cross-chain bridges, likely to support weapons development for the pariah state. Even more startling, some bridges, such as the Avalanche BTC Bridge, can trace 20-30% of their total volume of bridged Bitcoin to addresses controlled by Lazarus Group.
State of Cross Chain Crime (2023) Elliptic
Accountability vs Anonymity, A False Dichotomy
This has drawn the attention of powerful regulators and law enforcement agencies that use arguments of heavy illicit-activity to justify anti-privacy policies and enforcement actions against crypto protocols. If left unchecked, this can push the trajectory of the internet, crypto, and the future AI systems that will inevitably be built on it, towards immutable autocracy and despotism and away from individual liberty over your data, assets, and how you use technology.
This future fork in the path has fueled major debate on the merits of universal privacy as black or white, “either we accept privacy for all and the downsides that come with it, or accept the inevitable rise of technologically-empowered despotism with powers and capabilities unlike anything seen before in human history.” We believe that this dichotomy is false and that there is a third path that provides all consenting users privacy by default but accountability for those that infringe the terms of the contract they agreed to when choosing to use a specific technology.
Privacy protocols built on multi-party computation networks, zero knowledge proofs, and public key infrastructure are powerful tools that can be used to eliminate mass surveillance but also help hold regulators accountable through transparent auditability and immutable policies that eliminate the need for back-doors.
KYC Databases are Honeypots
Today, regulated Web3 financial services are required to implement Know-Your-Customer (KYC) and Anti-Money-Laundering (AML) processes to remain in business. Regulations require exchanges, on/off-ramps, and payment processors to verify the legal identity of each individual user, screen out high-risk individuals, and block services to individuals and organizations on sanctions lists. Businesses need to verify and keep data from all their customers (usually for years at a time) in order to comply with international money laundering and sanctions enforcement. Compliance requires the aggregation of sensitive personal information into honeypots for hackers, sophisticated state actors, fraudsters, and other mal-aligned actors.
ZK ID is a Breakthrough but not Sufficient On Its Own
Zero Knowledge ID lets individuals privately prove that they hold valid legal personhood and are not on any sanctions lists at the time of verification. This is typically done by receiving an attestation from a trusted identity issuer – such as Onifido or self-attestation with NFC ePassports – and generating a mathematical proof of identity that breaks any identifiable link between the personal data and the pseudonym that the proof is assigned to.
There is one key problem with this approach. Once the user is verified, they are completely pseudonymous and cannot be linked to their data. This means that businesses cannot comply with AML and sanctions laws. A “bad actor” may initially pass ZK ID only to later be flagged as a possible hacker of stolen funds, or sanctioned entity. The on-chain identity cannot be determined after the fact with ZK ID even if the identity issuer (Onifido) keeps the data on-hand.
Transparent Accountability with User Consent
How do you maintain user privacy but also provide accountability? The answer combines ZK ID with four elements:
User consent to transparent use terms & provable encryption of data to a public key
Trusted decryptor with a public key (DAO, compliance officer, power of attorney)
Human Network, a threshold network for gating custody to encrypted data
Smart contract with access control to Human Network
Along with ZK identity verification, these four elements form “Proof of Clean Hands.” dApps that operate in jurisdictions with identity verification and data availability requirements can use Proof of Clean Hands to privately verify their users at onboarding. The user identity remains unknown to the dApp at all points. Only the designated decryptor can request decryption if certain conditions are met. Users must consent to the decryption conditions that the dApp specifies in the use terms. These conditions are stored transparently in a smart contract that gates access to the data.
For example, in the event of a subpoena, (say for Tornado Cash), a user with Proof of Clean Hands will have already consented to encrypting their data to the public key of a third party (say a law firm or compliance consultant) and stored it with a third party using Human Network to gate decryption access.
At the time of consent, the user will have agreed to authorize decryption if their address appeared on a sanctions blacklist. The third party can comply with the court order by requesting the individual’s data from the threshold network. Note that discretion, and liability, for complying with a court order remains with the third party. The only entity that sees the plaintext is the decryptor. Nobody else, not even nodes on Human Network, can see it. This ensures user privacy while meeting legal requirements when necessary.
Proof of Clean-Hands Drives Real World Adoption of Crypto
Proof of Clean Hands augments on-chain ZK ID and mitigates regulatory bottlenecks across Web3 including for DeFi, Real World Asset (RWA) projects, launchpads, on-ramp/off-ramp protocols facilitating private transactions, high-value reward/airdrop distributions, and other use cases. Proof of Clean Hands can be made available as a back-end call or through Human ID’s embed. Proof of Clean Hands via the universally accessible embed is well-suited for mainstream use-cases of Web3, offering modularity and ease of integration for devs and privacy, simple UX, and accessibility of zero-knowledge tech to the masses.
How does Proof of Clean-Hands work?
Are you a developer? Want to dive into the implementation?
There are five steps in the Clean Hands flow.
Step 1: Credential issuance
First, the user verifies their identity and verifies that they are not on any sanctions lists through the ZK Government ID flow. They receive a signature from Human ID (previously Zeronym) attesting to their successful verification (see here for a description of this process)
After ID verification, the User has signed credentials. The User can use these credentials any time within a year of receiving them to generate zero knowledge proofs about their identity. When the User begins the Clean Hands flow, they send a proof (a randomized string only the user can generate with their credentials), which contains their name and date of birth, to Human ID’s server.
Human ID queries whether the User is on any sanctions lists covered by sanctions.io. Proof of Clean Hands Supports the Following Checks:
Politically exposed persons list maintained by sanctions.io.
OFAC Specially Designated Nationals.
UK Treasury Sanctions List.
Consolidated List of Sanctions maintained by the EU.
FATF Black and Grey List.
FBI Most Wanted.
FINCEN 311 and 9714 Special Measures.
Interpol Red Notices.
US BIS Military End User List.
For every query, sanctions.io includes a confidence score between 0 and 1. Human ID considers any result with a confidence score greater than 0.85 a match. Human ID does not issue credentials if a match is found on any of these sanctions lists. Human ID uses the user’s name and date of birth in its query to sanctions.io.
If the User is not on any of these sanctions lists and is requesting Clean Hands credentials for the first time, Human ID issues signed credentials to the User. The signed credential generally expires one year after issuance (but protocols can customize the frequency of expiration).
Privacy is crucial here. Human ID does not store any sensitive user information. The User’s name and birthdate passes through RAM so the sanctions list query can be conducted. This data submitted by the user is deleted and never kept in permanent storage that is accessible by any party other than the pre-defined decryptor (see Decryption section below for how to reveal data under pre-programmed disclosure requirements). Data is stored as a Zero Knowledge Proof with the user’s name and date of birth in ciphertext at the Observer node, which maintains data availability to meet decryption requests. This design creates a clear separation between the proof generator (Human ID) and the storage of sensitive data (Observer) to which Human ID has no access (for more on the Observer node, see Section 2. Proof generation).
Proof of Clean Hands Generation - Tutorial Video
Step 2: Proof generation
Second, the user generates a zero knowledge proof on client side using the credentials from the previous step. The proof says that the user has successfully verified. It also proves that the user has encrypted their name and date of birth to the public key of the Human Network.
The Observer node is a server that stores encrypted data from the User that can only be queried for selective disclosure by a designated Decryptor per the terms and conditions of the user agreement. Zero Knowledge proofs protect the user’s sensitive information, revealing nothing about the user except the fact that the user is approved. The user’s personal information isn’t revealed, but the proof still establishes that the correct information is encrypted.
For encryption, the user generates a single-use ephemeral private key, which is created and stored on the user’s device until the browser is closed. This private key is used for El Gamal encryption in the circuit. The user can only use this ephemeral key once to sign an access conditions contract - a contract which determines who is allowed to decrypt the user’s information. Thus, the user encrypts once, and then the submitted information cannot be decrypted without going through the Decryptor. For more details check the technical documentation.
Step 3: Attestation issuance
The User sends the zero knowledge proof (ZKP) and signature of the conditions contract to an Observer node, which stores the encrypted information and issues an on-chain attestation to the User. The Clean Hands ZKP takes as input a blockchain address, which the user selects. We use this to establish a link between the user's blockchain address and their ZKP in the Observer node so that the user's ciphertext can be queried with their address.
We currently use Sign Protocol to record attestations (see the attestation schema here).
Before attesting, we do the following:
Verify the ZKP.
Make sure the encryption key output by the circuit is Human Network’s public key.
Make sure the issuer address output by the circuit is the Human ID Clean Hands issuer.
Make sure the conditions contract signed by the user is on our whitelist.
Verify the user’s signature of the smart contract that contains decryption conditions.
Store the ZKP’s public values, including the ciphertext.
We send the attestation to the blockchain address that the user provided. Like the other Human ID circuits, the Clean Hands circuit outputs an action nullifier. This allows for uniqueness checks. At credential issuance, each user is given a secret nullifier with their credentials. The circuit outputs a hash of an action ID and the user’s nullifier. We include this nullifier in the attestation in case dApps or other verifying parties want to check for uniqueness.
Step 4: On-chain activity
With this attestation, users can interact with smart contracts that require it. At Holonym, for example, the Ethereum-Aztec bridge, which allows verified users to bridge to Aztec privately, prevents known bad actors from transacting privately, and users who are presently verified but engage in suspicious on-chain activity at a future time can be decrypted.
It’s worth noting that the Clean Hands attestation is not meant to be used in isolation. Any compliance organization that relies on the Clean Hands stack to help identify bad actors will want to use other tools to monitor the on-chain activity of users with the attestation before requesting decryption. Access controls for decryption and common concerns around it are discussed below.
Step 5: Decryption
If the conditions in the use terms and on-chain contract are met, the ciphertext from the user’s zero knowledge proof may be decrypted. It might be necessary to decrypt this data if, for example, the user’s blockchain address is implicated in a criminal case and a search warrant is issued by a court. However, there are strict limits on decryption requests.
There are two “layers” of decryption conditions: the terms of use and an on-chain smart contract. The terms of use is an off-chain agreement between the user, Holonym Foundation, and any third-party authorized decryptors. It defines, in legal terms, under what conditions a decryption request is allowed to be made.
There is also a smart contract which determines the conditions under which Human Network (previously Mishti Network) will even satisfy a decryption request. For example, the smart contract we use in version 0 allows a wallet controlled by Holonym Foundation to make up to 10 decryption requests per 24 hours. This prevents unscrupulous surveillance and data breaches, while still allowing for compliance with regulatory guidelines.
You can see the complete flow diagram below:
Aside: Threshold decryption with Human Network
Human Network (previously Mishti Network) is a threshold network. This means the private key corresponding to Human Network’s public key is not controlled by any single entity. So, when we say the user encrypts their data to Human Network, we mean that the user encrypts their data to Human Network’s public key.
In the decryption procedure, each Human Network node only returns a decryption share to the decryptor. The shares must be combined in a process known as Lagrange interpolation in order to arrive at the decrypted data.
A Human Network node only returns decryption shares to a requester if the requester has been granted access according to the terms and conditions that the user consented when issuing a “Clean Hands” credential. This threshold mechanism, combined with the conditions contract check, is what lets users encrypt data to Human Network, and for another party to decrypt the data according to predefined conditions.
Decryption & Decentralization Roadmap
The processes, agreements, and smart contracts that determine the conditions under which user data can be decrypted and the entities that are allowed to decrypt–all of these are highly customizable.
For example, dApps wary against hackers, rug-pullers, and bad actors can elect to specify the public multisig key of a “Forensics DAO” as the decryptor for all verified identities within the use terms of their application and services. The Forensics DAO could be composed of well-established on-chain forensics companies, cyber security professionals, or legal firms that can validate or even challenge court orders. In the event of a major hack, Forensics DAO may be able to decrypt the identity of the perpetrator if the DAO achieves consensus.
Despite the large design space here, we expect to converge on a small set of processes, agreements, and smart contracts that simultaneously maximize privacy for honest users, maximize accountability for dishonest users, and minimize potential overreach from decryption authorities. Our roadmap for this “decryption module” follows:
Version 0
To ship a proof of concept quickly, we will start with a very simple design. In this design, Holonym Foundation is the only authorized decryptor. It can decrypt a maximum of 10 ciphertexts per day. Decryption conditions are defined entirely by the smart contract. The terms of use agreement does not add additional limits on decryptions. Holonym Foundation will decrypt if law enforcement presents us with a valid court order to decrypt.
Version 1
Everything in version 0, but we add a terms of use agreement that clearly defines the conditions under which user data can be decrypted.
Version 2
We facilitate the establishment of a DAO that is responsible for requesting decryptions and interfacing with law enforcement (i.e., Forensics DAO). The smart contract still has rate limits on the number of decryption requests. This DAO will institute its own processes to determine whether a decryption request from an authority can be granted. It will use on-chain forensics tools, such as those from Elliptic or TRM Labs, and investigate allegations on behalf of users in accordance with the terms of use. Decryption requests must be signed by a majority of the members of the DAO multisig or executed by a verifiable vote. DAO membership should be highly restricted.
Version 3
We help further decentralize DAO membership, especially to include compliance officers from other Web3 projects. We facilitate contributions to make improvements to the smart contract to better suit the DAO. Namely, we modify the smart contract to allow the DAO to vote on rate limit increases or decreases (within bounds) so that rate limits can go up or down with usage, and we also add a decryptor role to the smart contract to allow the DAO to authorize one-off decryptions from specific entities without requiring the decrypted user data to be seen by DAO personnel.
Risks and Limitations
Proof of Clean Hands is experimental software and undergoing rapid development. There are key risks and limitations that may not make it suitable for all use cases. Careful thought must go into the design to fit specific use-cases.While the architecture removes trust in the identity verifier, the dApp service provider, and other middleware, it still requires the Decryptor to be trusted. The trust requirement goes both ways. Regulators and law enforcement must trust the Decryptor to act in good faith and perform the decryption when requested – as opposed to refusing to comply and burning their keys. dApps and users must trust that the Decryptor only uses their data as agreed-upon, only to facilitate the execution of the conditions within the use terms. The Decryptor must be trusted not to misuse this data.
Deterministic conditions encoded within a smart contract also pose a specific risk. These conditions may not always be relevant to current conditions or have hidden exploits that bad Decryptors can take advantage of to unfaithfully decrypt user data. FinCEN updates their AML requirements regularly and regulated protocols must be quick to adapt their use terms and have users re-consent in order to maintain compliance.
These conditions may also sometimes reference centralized “oracles” to compute risk levels or source blacklists from. Governments or other powerful non-credibly-neutral actors may have special privileges to update blacklists as they see fit. Risk levels may also be gamed by bad actors, such as by dusting accounts, or phishing honest users to interact with black-listed accounts to increase their risk levels and disrupt the normal operation of the system by saturating the rate limit.Lastly, the threshold network must be trusted to maintain strong collusion-resistance. Each individual node must have sufficient incentive to not collude with other nodes to allow the Decryptor unauthorized access. Human Network is an Actively Validated Service that runs on Ethereum validator nodes and is secured by the amount of Ether restaked into those operators. The odds of AVS operators colluding are relatively low as long as a large USD amount of Ether is at stake along with their reputation as credibly-neutral infrastructure providers.
An Emerging Ecosystem for Transparent Accountability & Programmable Privacy
The solution space for transparent on-chain accountability that leverages programmable privacy to meet real world use cases and their regulatory requirements is still early and just beginning to emerge. Proof of Clean Hands offers a privacy preserving approach with a decentralized middleware for data custody and a roadmap to decentralize decryption responses to law enforcement or requests for information. Other notable projects that address similar challenges include Privacy Pools, idOS, Predicate, Nexera and ZK.ME. These services can provide redundant offerings for KYC providers and exchanges such as Fractal ID, Binance, Coinbase, and others.
How to get involved or learn more?
Use the Clean Hands attestation in your dApp: https://docs.holonym.id/for-developers/clean-hands
Checkout the source code for the Proof of Clean Hands with encryption circuit: https://github.com/holonym-foundation/id-hub-contracts/blob/main/zk/circuits/circom/V3CleanHands.circom
Check out the docs! Or send a message to hello@holonym.id
About Holonym Foundation
Holonym Foundation’s mission is the foundation of natural digital rights for privacy, security, and data ownership. As the parent organization of human.tech, Holonym Foundation fosters innovation through strategic partnerships, research, and advocacy, ensuring that technological advancements align with fundamental human values.
About Human Tech
Human Tech is a suite of key, wallet, and identity protocols to direct capital flow for humans - not bots, middlemen, or bad actors. human.tech is rolling out the world’s best capital allocation infrastructure to billions of humans with biometric keys, self-custodial wallets, and private identity.
About Human ID
Human ID is a private digital identity protocol that verifies users without storing or seeing sensitive information. Data stays on user devices, and only proofs of identity are submitted. Programmable privacy provides transparent accountability for identity verification use cases that require regulatory compliance.