Add ERC: Zero-Knowledge Compliance Oracle#1747
Conversation
File
|
eip-review-bot
changed the title
DROOdotFOO
changed the title
eip-review-bot
changed the title
DROOdotFOO
changed the title
|
ERCs are application layer standards. They are not for product promotion or marketing purposes. |
eip-review-bot
changed the title
DROOdotFOO
changed the title
eip-review-bot
changed the title
a4acfdf marketing lingo banished. Carried the naming pattern forward to the xochi-fi/ERC-8262 interfaces in the org now that we have a # to reference. |
|
|
||
| ## Abstract | ||
|
|
||
| A standard interface for on-chain verification of regulatory compliance (AML, sanctions screening, anti-structuring) using zero-knowledge proofs. Users generate proofs client-side that attest to compliance with jurisdiction-specific thresholds without revealing transaction amounts, counterparty identities, or screening details. Verifiers confirm proof validity on-chain. No trusted third party or TEE is required. |
There was a problem hiding this comment.
Some of these abbreviations are borderline. You might consider expanding them the first time they are used.
There was a problem hiding this comment.
Good idea, I was trying to avoid verbosity.
Changed: AML -> anti-money laundering; introduced (TEE) parenthetical so later uses are unambiguous.
|
|
||
| ## Motivation | ||
|
|
||
| Public blockchains force a binary choice between transparency and privacy. Transparent execution (Uniswap, CoW Protocol) exposes trades to billions in cumulative MEV extraction. Privacy tools (Tornado Cash) have been sanctioned for lacking compliance mechanisms. |
There was a problem hiding this comment.
| Public blockchains force a binary choice between transparency and privacy. Transparent execution (Uniswap, CoW Protocol) exposes trades to billions in cumulative MEV extraction. Privacy tools (Tornado Cash) have been sanctioned for lacking compliance mechanisms. | |
| Public blockchains force a binary choice between transparency and privacy. Transparent execution exposes trades to billions in cumulative MEV extraction. Privacy tools have been sanctioned for lacking compliance mechanisms. |
It's best to avoid mentioning specific products.
| Existing approaches to compliant privacy fall short: | ||
|
|
||
| - **View keys** (Railgun, Panther): Trade privately, then reveal raw transaction data to auditors on request. This leaks the data: it is delayed transparency. | ||
| - **TEE-based compliance** (various): Rely on hardware trust assumptions that have been broken repeatedly (SGX side channels, key extraction). |
There was a problem hiding this comment.
Same comment about SGX being uncommon.
There was a problem hiding this comment.
"SGX side channels, key extraction" -> "side-channel attacks and key extraction"
| - **attestation TTL**: The duration (in seconds) for which a compliance attestation remains valid after on-chain recording. Expired attestations remain queryable via `getHistoricalProof()` but are not considered valid by `checkCompliance()`. | ||
|
|
||
| ### Proof Types | ||
|
|
There was a problem hiding this comment.
I'm about as far from an expert on ZK stuff as one can get, so it's possible this is all obvious to someone with more domain knowledge.
I just want to make sure that this section has concrete/implementable requirements and isn't just a list of programs. You have to make sure that anyone reading this standard is able to write a compatible implementation without looking at other implementations.
There was a problem hiding this comment.
Added new H3 Per-Type Circuit Specifications with 9 H4s (one per proof type), each lists public/private inputs with value ranges and a numbered constraint list.
Two supporting H3s define cross-cutting material:
Circuit Conventions (slot counts, value ranges, encoding rules, domain-tag distinctness) and,
Commitment Layouts (the field-order layout for every Pedersen commitment, including the 22-field signed-variant digest and the 25-field multi-signed slot digest).
End goal is that an implementer can write a compatible verifier without reading the reference Noir. Hope this aligns better!
|
|
||
| Strict-mode jurisdictions (US BSA, Singapore) MUST reject the self-attested tier — the reference enforces this via `JurisdictionConfig.requireSignedSignals(uint8)`. Permissive jurisdictions MAY accept either tier. Integrators whose threat model includes a dishonest user but a trusted provider MUST require the signed variants. Integrators whose threat model includes a compromised provider key MUST additionally require an ATTESTATION proof against an independently-published credential tree, ideally with an in-circuit signature over the credential root (out of scope for this specification, tracked as future work). | ||
|
|
||
| Implementations SHOULD prominently document this trust model in deployment-facing materials. |
There was a problem hiding this comment.
Keep requirements in the Specification section, or else they're easy to miss.
There was a problem hiding this comment.
Promoted to a new Spec H3 Trust Tier Disclosure; the Rationale paragraph now cross-references it instead of restating.
|
|
||
| ## Test Cases | ||
|
|
||
| The reference implementation includes binary proof fixtures in `test/fixtures/` for the six unsigned proof types. Static fixtures are not provided for the three signed variants (COMPLIANCE_SIGNED, RISK_SCORE_SIGNED, COMPLIANCE_MULTI_SIGNED) because each requires a fresh secp256k1 ECDSA witness; those are exercised end-to-end in the TypeScript SDK consumer tests instead. Each unsigned fixture contains: |
There was a problem hiding this comment.
Did you forget to include your fixtures?
There was a problem hiding this comment.
Relic from when I was drafting this from within the reference implementation repo. Good eye!
Fix:
b1f67656 qualifies every test/fixtures/, test/sdk/, scripts/..., src/..., and docs/... reference to be unambiguously about the external reference implementation repo.
Reference Implementation section now opens with github.com/xochi-fi/ERC-8262 and a sentence stating all file paths in that section, Test Cases, and Security Considerations are relative to it.
The Witness Annex (Test Cases) gives reproducible Prover.toml inputs for the six unsigned proof types so any implementation can rebuild byte-identical fixtures locally; binary blobs live at xochi-fi/ERC-8262 test/fixtures/.
Chose above over inlining ~50 KB of hex per fixture into the ERC body; the Prover.toml witnesses are the authoritative cross-validation surface, and the binary outputs are reproducible from them.
|
|
||
| Thanks to Merkle Bonsai (@Jabher) for reviewing the generated UltraHonk verifiers and identifying that the `pairing()` free function could be rewritten in inline Yul to bring all nine per-proof-type verifiers under the [EIP-170](./eip-170.md) 24,576-byte runtime size limit. The reference implementation incorporates the rewrite in `scripts/patch-pairing-yul.sh`, saving ~186 bytes per verifier (and ~800 gas per `verifyProof` call as a bonus) while staying byte-identical to the `bb`-generated semantics on the pairing precompile (`address(0x08)`) input layout. | ||
|
|
||
| ## Security Considerations |
There was a problem hiding this comment.
A lot of requirements (defined with UPPERCASE keywords) in this section. Keep those in the specification section, but do discuss their implications in this section.
There was a problem hiding this comment.
Fully rewrote.
Security Considerations is now 0 RFC-2119 keywords; each paragraph names the threat, identifies affected proof types, links to the Spec subsection that mandates the mitigation, and discusses residual risk.
MUSTs/SHOULDs migrated into 6 new Spec H3s (Proof System Requirements, Batch Verification Limits, Proof Hash Computation, Circuit Constraints, Pause Mechanism, Administrative Operations) and 5 extensions to existing H3s.
The L631-644 public-input-validation bullet block (14 MUSTs) collapsed into a 3-sentence discussion + link to the Spec table, with one preserved gotcha (the "valid proof of non-compliance" case).
| - **Generated verifiers**: `src/generated/` (UltraHonk verifiers generated by Barretenberg, pinned to bb 4.0.0-nightly.20260120) | ||
| - **Test suite**: Solidity tests (unit, fuzz, invariant, integration with real proofs for the 6 unsigned proof types) and circuit tests across all 9 circuits. The signed variants (0x07, 0x08, 0x09) are exercised in the TypeScript SDK consumer tests (`test/sdk/`) which generate a fresh ECDSA witness per run. | ||
|
|
||
| Thanks to Merkle Bonsai (@Jabher) for reviewing the generated UltraHonk verifiers and identifying that the `pairing()` free function could be rewritten in inline Yul to bring all nine per-proof-type verifiers under the [EIP-170](./eip-170.md) 24,576-byte runtime size limit. The reference implementation incorporates the rewrite in `scripts/patch-pairing-yul.sh`, saving ~186 bytes per verifier (and ~800 gas per `verifyProof` call as a bonus) while staying byte-identical to the `bb`-generated semantics on the pairing precompile (`address(0x08)`) input layout. |
There was a problem hiding this comment.
I'd move the attribution to a comment in the actual file. We tend to avoid acknowledgements within the body of the proposal itself.
There was a problem hiding this comment.
Moved the "Thanks to Merkle Bonsai" line into an <!-- attribution --> HTML comment.
- Expand AML, TEE on first use; drop product names (Uniswap, CoW, Tornado, SGX) per reviewer suggestion - Move Merkle Bonsai attribution to HTML comment - Restructure Security Considerations as pure threat-model (0 RFC-2119 keywords); each paragraph links to the Spec subsection that mandates the mitigation - Add Per-Type Circuit Specifications (9 H4s, one per proof type), Circuit Conventions, and Commitment Layouts so the ZK constraint logic and field layouts are concrete enough to implement without reading the reference circuits - Migrate scattered Security MUSTs into new Spec subsections: Proof System Requirements, Batch Verification Limits, Proof Hash Computation, Circuit Constraints, Pause Mechanism, Administrative Operations, Trust Tier Disclosure - Extend existing Spec subsections (Verifier Interface view modifier, Verifier Versioning TOCTOU, Provider Weight Publication bounded history, Validation Registries idempotency + credential publisher rotation, Risk Score Computation collusion guidance) - Convert backtick section references to markdown anchors - Softer Rationale wording: replace orphan SHOULD with a cross-reference to Trust Tier Disclosure; reword inline MUSTs that are wallet-author / integrator guidance
VARA's January 2026 anti-anonymity ruling carves out assets with "mitigating technologies" for traceability. ERC-8262 is such a mitigating technology, so adding UAE as a first-class jurisdiction lets the reference implementation route UAE- originating attestations through the same on-chain validation pipeline as the four pre-existing jurisdictions. UAE shares EU/UK's high-risk threshold (7100 bps / 71%) and adopts the strict-mode policy of US BSA and Singapore: requireSignedSignals=true, minMultiProviderThreshold=2.
DROOdotFOO
force-pushed
the
add-erc-zk-compliance-oracle
branch
from
b1f6765 to
0d43d09
Compare
|
The commit 4750669 (as a parent of 5447c33) contains errors. |
|
|
||
| ### Verifier Interface | ||
|
|
||
| The verifier routes proof verification to per-proof-type verification contracts. Each circuit produces a separate verifier via the ZK backend (e.g., `bb write_solidity_verifier` for Barretenberg's UltraHonk). |
There was a problem hiding this comment.
Barretenberg's UltraHonk
This looks like an external link. If this is defined in a paper, you might be able to link to it using its DOI or include it as an asset depending on its license. See EIP-1 for allowed linking rules.
|
|
||
| **Credential root registry (per-provider).** Tracks valid credentials Merkle roots for ATTESTATION proofs, keyed by `provider_id`. Each provider has an authorized publisher EOA, set by the administrator via a separate registration step. The publisher SHOULD publish new credential roots periodically (replacing prior ones). Roots SHOULD have a finite TTL window during which they are accepted; this window allows users with paths against an outgoing root to continue submitting proofs while a new root propagates. Implementations MUST verify the proof's `provider_id` matches the registered `providerId` for the credential root being referenced; otherwise an attacker could reuse another provider's root with a forged `provider_id`. | ||
|
|
||
| **Reporting threshold registry.** Tracks valid reporting thresholds for PATTERN (anti-structuring) proofs. Each jurisdiction defines its own reporting threshold (e.g., $10,000 for US BSA). Thresholds MUST be registered before proofs referencing them can be accepted. |
There was a problem hiding this comment.
(e.g., $10,000 for US BSA)
Might be worth spelling this out more
|
|
||
| The adjacency requirement is critical. Without it, an attacker could pick two non-adjacent tree entries that bracket the submitter, hiding any real intermediate entry that contains the submitter's address. Tree publishers MUST sort leaves by their raw value (the `value` argument to `leaf_hash_subject`). Implementations SHOULD insert sentinel boundary leaves at $0$ and $p-1$ (BN254 prime minus 1) so every submitter has well-defined neighbors. | ||
|
|
||
| Comparison MUST be performed over the full Field range using bit-decomposition (Noir's `Field::lt`). Earlier designs that cast to `u64` and compared as fixed-width integers required additional range checks on all values; the reference implementation uses Field-level comparison to support arbitrary-width identifiers (Ethereum addresses, hashes, etc.) without truncation risk. |
|
|
||
| **[ERC-3643](./eip-3643.md) (T-REX).** The ratified compliance token standard for regulated securities, with $32B+ in tokenized assets. ERC-3643 requires identity revelation via ONCHAINID claims verified by trusted issuers. This ERC proves compliance without revealing identity data, provider signals, or transaction amounts. The two standards are complementary: this ERC could serve as a ZK-enhanced identity provider within an ERC-3643 deployment. | ||
|
|
||
| **Privacy Pools (0xbow).** Live on Ethereum mainnet since March 2025. Users prove their withdrawal originates from a "clean" deposit set using ZK proofs, with Association Set Providers (ASPs) maintaining approved deposit lists. The Privacy Pools protocol validates the "prove compliance without revealing data" model. However, set membership is a subset of what regulatory compliance requires. This ERC extends the approach to multi-dimensional compliance: risk scoring, anti-structuring detection, credential verification, and membership/non-membership proofs. |
There was a problem hiding this comment.
Would be best to avoid mentioning a product specifically, but if referring to them vaguely/describing their approach isn't clear enough, you can keep it.
|
|
||
| **RISC Zero token oracle.** A draft EIP proposes an oracle-permissioned [ERC-20](./eip-20.md) that validates token transfers via ZK proofs against off-chain payment instructions (ISO 20022 format), using RISC Zero as the proof system. That proposal gates a single token's transfers through a single oracle with a single proof type. This ERC provides standalone compliance attestations with nine proof types, usable by any contract, and is not gated to token operations. | ||
|
|
||
| **VOSA-RWA.** A compliance-gated privacy token for real-world assets (Draft, 2026). Every token operation requires dual ZK proofs: a compliance attestation (Groth16/BN254, Poseidon hashing) and a transaction conservation proof. VOSA-RWA and this ERC share the "ZK proof for compliance, no PII on-chain" design, but VOSA-RWA embeds compliance into a specific token standard. This ERC is a standalone oracle whose attestations are reusable across protocols. |
|
|
||
| ## Reference Implementation | ||
|
|
||
| A reference implementation accompanies [ERC-8262](./eip-8262.md) and is published in a companion GitHub repository at github.com/xochi-fi/ERC-8262. All file paths in this section, in the Test Cases section, and in the Security Considerations section are relative to that repository. It consists of: |
There was a problem hiding this comment.
You'll need to either remove this section or include a minimal reference implementation in your assets directory, assuming a compatible license.
4 participants
This PR submits a new ERC ERC-8262: Zero-Knowledge Compliance Oracle.
Summary
A standard interface for on-chain verification of regulatory compliance (AML, sanctions screening, anti-structuring) using zero-knowledge proofs. Users generate proofs client-side that attest to compliance with jurisdiction-specific thresholds without revealing transaction amounts, counterparty identities, or screening details. No trusted third party or TEE is required.
Discussion
Forum thread (per EIP-1): https://ethereum-magicians.org/t/erc-zero-knowledge-compliance-oracle/28543
Scope
IZKPVerifier(per-proof-type routing, batch verification, version history) andIZKPOracle(attestation submission, expiry, retroactive lookup) interfacesEIP-1 compliance
title,description,author,discussions-to,status,type,category,created,requires: 165)./eip-N.mdformmarkdownlint,codespellpass locallyeipwpasses locally with zero errorsNotes for editors