zk-KYC/ML + ERC-734/735 identity claims

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
• ERC-735
• EZKL documentation
• Approach: Private Identity
• Domain: Identity and Compliance