Proof of Clean Hands

Proof of Clean Hands (PoCH) is a credential that proves a person completed identity verification and passed sanctions screening, without exposing their identity. It lets someone demonstrate they are in good standing while keeping their name, document, and biometrics private.

How it works

1. Government ID check. The person verifies a government-issued ID (passport, driver’s license, residence permit, visa, or voter card).
2. Liveness check. A biometric liveness scan confirms the document belongs to the person presenting it.
3. Sanctions screening. The person is screened against 23 international sanctions and watchlist sources (OFAC, FATF, FinCEN, Interpol, and others), including Politically Exposed Persons data.
4. Credential issuance. On success, the person receives an on-chain credential (a soul-bound attestation). It is valid for about a year and can be renewed before it expires.

Each time the credential is presented, the holder generates a fresh proof on their own device. Nothing is replayed, and the verifying application never receives identity data.

What it proves

• The holder completed government-ID verification with a liveness check.
• The holder is not on the screened sanctions or watchlists.
• The credential is current and unexpired.

What it does not reveal

• No name, date of birth, document number, nationality, or address.
• No biometrics, IP address, or device data.
• Nothing beyond the fact that the checks passed.

Selective disclosure

Privacy and accountability are usually traded against each other. PoCH treats them as separate settings: private by default, with disclosure set by rule rather than by habit.

Concretely, the same proof that hides the holder’s identity from an application also escrows that identity as ciphertext. First name, last name, and date of birth are encrypted to the Human Network threshold key inside the zero-knowledge circuit, so the proof itself guarantees the ciphertext is well-formed and corresponds to the credential being presented. No one has to be trusted to encrypt honestly, because a proof that skipped it would not verify.

That ciphertext can only be opened when a condition agreed in advance is met.

The condition is a smart contract

Every decryption request is checked against an on-chain gate that answers one question:

canDecrypt(c1Hash, requester) → bool

Human Network operators consult that gate before releasing anything. Because the gate is an ordinary contract, who may decrypt under what conditions is a contract-design question, not a protocol change. The same surface supports:

• A multisig or DAO vote, rather than a single authority.
• Submission of a court-order hash, verified before the gate opens.
• Time-locks, expiries, and hard rate limits.
• Per-jurisdiction sub-authorities.
• Allowlists scoped to one incident and one recipient address.

Today the deployed gate is AuthorityWithDailyRateLimitV2. It enforces a hard cap of 10 decryptions per rolling 24 hours, and every request expires after 24 hours. The path forward is published terms of use that holders consent to at issuance, then replacing the single authority with a forensics DAO. Each step is a contract upgrade rather than a re-architecture.

Two custodians, not one

This is the property that separates PoCH from an escrow scheme with extra steps. Opening a record requires cooperation between two independent sets of parties that hold different things:

Neither is sufficient alone, and the failure modes do not overlap. Collusion among network operators is not enough to read anyone’s data. A colluding quorum can reconstruct a decryption capability and still has nothing to point it at, because the ciphertext lives with the Observer. Equally, a fully compromised Observer holds records it cannot open. An adversary has to break custody of the data and custody of the key and satisfy the on-chain gate.

Human Network operators are restaked through EigenLayer, so the honest-threshold assumption rests on economic security rather than good intentions.

No master key

No party holds a master key to a person’s identity. human.tech does not hold personal data in the clear, and no single operator can flip a switch and read it.

Two things stated plainly, because regulator-facing claims should be falsifiable:

• The encrypted record is recoverable, so it remains personal data under most data-protection regimes and the parties handling it stay accountable for it. Retention is a policy parameter, and the Observer can be configured to delete records once the integrating application’s stated period elapses.
• This is a strong guarantee against ordinary operators and attackers. It is not a claim of invulnerability against a nation-state adversary. Key management and rotation are auditable by design.

Under the hood

For readers who want the construction rather than the summary:

• Provable encryption. The identity fields are ElGamal-encrypted over BabyJubJub, with the encryption performed and proven within the same circuit that proves the credential. The ciphertext is a public output of the proof. See Human Network — provably encrypting .
• Threshold decryption. Key shares are distributed by DKG, and each participating node returns only a decryption share together with a proof that the share is correct. No node ever holds the full key. See decryption of provably encrypted data .
• Key derivation. Keys are derived from user-side authentication through an oblivious PRF, so no party learns the input. See OPRF key derivation .
• Proving system. Proofs are generated client-side, including on mobile, using a VOLE-in-the-head proving system. See VOLE-Based Zero-Knowledge. Source: vole-zk-prover .
• Whitepapers. holonym-foundation/whitepapers  covers the ZK identity construction, Human Network, and Human Wallet.

See also Zero-Knowledge Identity, VOLE-Based Zero-Knowledge, Disclosure Conditions, and Cryptographic Security.

Regulatory compatibility

The architecture is built to be compatible with frameworks such as the FATF Travel Rule, the EU’s MiCA and AML package, and FinCEN customer due-diligence expectations. These are architectural compatibility goals, not legal certifications. Applicability depends on the deploying institution and jurisdiction.

Where it’s used

PoCH gates compliant value flows on Shield and the Clean SDK, and provides reusable, privacy-preserving compliance for financial institutions and governments. For the enterprise framing of the same capability, see human.tech/services .