Title: zk-KYC/ML + ERC-734/735 identity claims · Pattern · EthSystems

URL Source: https://original.es-internal.pages.dev/patterns/pattern-zk-kyc-ml-id-erc734-735/

Markdown Content:
---
description: Publish identity claims on-chain that are backed by a zero-knowledge proof of an off-chain KYC or AML check, instead of a flat signature from a whitelisted issuer. The identity contract (ERC-734/735) holds the claims; a verifier contract checks the zero-knowledge proof at claim ingestion or at access time. The on-chain public sees that a qualified check was performed under a specific policy, without learning the subject's personal data.
title: zk-KYC/ML + ERC-734/735 identity claims · Pattern · EthSystems
image: https://original.es-internal.pages.dev/og.png
---

[Skip to content](#main-content) 

#### Works best when

* Onboarding identities must be publicly verifiable on-chain, for example to enable instant settlement without manual gate-keeping.
* The issuer wants to prove that KYC or AML was performed under a specific policy without publishing the underlying personal data.
* A zero-knowledge attestation pipeline (proof of compliant off-chain check, proof of source-of-funds) already exists.

#### Avoid when

* A simple allowlist signed by an authorized compliance party is sufficient and public verifiability is not required.
* Off-chain auditor access with selective disclosure is preferred over on-chain proof verification.

### I2I vs I2U — context differences

Between institutions the issuer signing the ERC-734/735 claim is itself regulated. Proof content can be more detailed (policy identifier, screening vendor identifier) because both counterparties can cross-check against contractual obligations.

For users the claim pipeline must not allow the issuer to correlate on-chain activity with the underlying personal data. The zero-knowledge wrapper is what limits issuer over-reach; without it, on-chain attestation gives the issuer a free pseudonym observer. Users also need a clean revocation and re-issuance path when credentials expire.

Vector

Pairing-based proof systems used in current zero-knowledge machine-learning stacks are broken by a CRQC. HNDL risk applies to any long-lived on-chain proof that will still be relied on when CRQCs arrive.

Mitigation

Migrate the proof backend to hash-based systems (STARK or hash-based SNARK). PQ-safe arithmetization of institutional signature schemes currently imposes a large circuit-size penalty and remains a research frontier. See [Post-Quantum Threats](../domains/post-quantum.md).

## Components

* On-chain identity contract (ERC-734 for key management, ERC-735 for claims) holds the subject's claims and exposes them to gated contracts.
* Claim issuer performs the off-chain KYC, AML, or machine-learning check and generates a zero-knowledge proof attesting that the policy was followed.
* Proof verifier contract checks the zero-knowledge proof against a public policy statement and, on success, writes the claim to the identity contract.
* Source-of-proof integration: either a notarized TLS transcript of the external compliance system, a proof about an existing on-chain state, or a proof over a trusted dataset.
* Policy registry binds policy identifiers to circuit or verifier versions so that verifiers can refuse out-of-date claims.

## Protocol

1. user Complete an off-chain KYC or AML check with a qualified provider, or surface the data via a notarized TLS session.
2. issuer Generate a zero-knowledge proof that the check passed under a named policy (thresholds, sanctions lists, screening vendor) without revealing the underlying inputs.
3. user Submit the proof and the public inputs to the claim verifier contract.
4. contract Verify the proof, check the policy identifier against the registry, and write a compliance claim into the subject's ERC-734/735 contract.
5. contract Downstream gated contracts read the claim and consult the policy registry to accept or reject the subject.
6. issuer Revoke or refresh the claim as the underlying compliance state evolves; the identity contract reflects the current state.

## Guarantees & threat model

Guarantees:

* Public verifiability: any party can check that a qualified compliance check ran under the named policy.
* Minimal on-chain disclosure: only the claim and the policy identifier are public, not the underlying data.
* Instant gating: downstream contracts can settle in a single transaction once the claim exists.
* Issuer accountability: the policy registry ties every claim to a specific circuit and verifier version.

Threat model:

* Soundness of the proof system and correctness of the circuit. A buggy circuit can produce valid proofs for false statements.
* Issuer honesty for inputs the circuit cannot verify independently (for example, the output of an opaque machine-learning model over private inputs).
* Key custody for both the issuer and the identity-contract management keys. A compromised management key can add or remove claims arbitrarily.
* Revocation propagation. A stale claim can persist on-chain after the off-chain compliance state has changed; verifiers must check expiry and the revocation registry.

## Trade-offs

* Proof generation cost, which is substantial for zero-knowledge machine-learning circuits on current hardware. Batch issuance and off-chain delegation of proving reduce user-side cost.
* On-chain verification gas cost is non-trivial; consider doing the verification once at claim ingestion rather than at every access check.
* Circuit evolution is operationally costly. A policy change forces a new circuit and re-issuance for active subjects.
* Importing real-world institutional signatures (for example, government-issued digital-identity signatures) into a zero-knowledge circuit currently carries a large constraint-count overhead.

## Example

A bank onboarding an investor runs a standard KYC and AML check off-chain. The bank's issuer service produces a zero-knowledge proof that the investor passed the bank's published policy. The investor submits the proof to their ERC-734/735 identity contract via the verifier contract, which writes an accredited-investor claim. A tokenized bond contract reads the claim when the investor subscribes and settles the transfer atomically, without ever seeing the investor's personal data.

## See also

* [ERC-734](https://eips.ethereum.org/EIPS/eip-734)
* [ERC-735](https://eips.ethereum.org/EIPS/eip-735)
* [EZKL documentation](https://docs.ezkl.xyz/)
* [Approach: Private Identity](/approaches/approach-private-identity/)
* [Domain: Identity and Compliance](/domains/identity-compliance/)

### Open-source implementations

* [ github.com Solidity ONCHAINID reference implementation of ERC-734/735 (production) ↗ ](https://github.com/onchain-id/solidity)
* [ github.com Rust EZKL zero-knowledge machine-learning proving framework (research/testnet) ↗ ](https://github.com/zkonduit/ezkl)

CROPS profile

Censorship-resistance: lowOpen source: partialPrivacy: partialSecurity: medium

CRCensorship-resistancelow

The user depends on an issuer to generate the KYC or AML proof. Lifts to `medium` when credentials are portable across competing issuers sharing the same schema.

OSOpen sourcepartial

ERC-734, ERC-735, and the underlying proof systems are open. Production zero-knowledge machine-learning stacks and some notarized TLS backends are partially open. Issuer tooling and attestation pipelines often ship as closed services.

PPrivacypartial

The on-chain claim reveals that the subject passed a specific policy check at a specific time. A zero-knowledge wrapper limits the disclosure to the predicate, but the existence and type of claim are visible.

SSecuritymedium

Rides on soundness of the proof system, integrity of the off-chain computation being proved (for example, a machine-learning score), and issuer key custody. Deployed zero-knowledge machine-learning circuits have been audited only in limited cases.

Standards 2 
* `ERC-734`
* `ERC-735`

#### Referenced by

approaches1
* [Private Identity](/approaches/approach-private-identity/)
use cases1
* [Private RWA Tokenization](/use-cases/private-rwa-tokenization/)
building blocks6
* [Compliance Monitoring](/patterns/pattern-compliance-monitoring/)
* [ERC-3643 Tokenized RWAs](/patterns/pattern-erc3643-rwa/)
* [Private Client Authentication for Institutional EOAs](/patterns/pattern-private-mtp-auth/)
* [Verifiable Attestation](/patterns/pattern-verifiable-attestation/)
* [ZK Wrappers](/patterns/pattern-zk-wrappers/)
* [zk-TLS](/patterns/pattern-zk-tls/)

×

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://ethsystems.org/#organization","name":"EthSystems","url":"https://ethsystems.org/","logo":"https://ethsystems.org/icon-maskable.png","sameAs":["https://x.com/eth_systems","https://www.linkedin.com/company/ethsystems/","https://github.com/ethsystems"]},{"@type":"WebSite","@id":"https://ethsystems.org/#website","url":"https://ethsystems.org/","name":"EthSystems","publisher":{"@id":"https://ethsystems.org/#organization"}}]}
```